Friday, September 29, 2017

OutSystems mobile app at scale

The goal of this post is to actually provide some tips when using OutSystems 10 to develop Mobile apps. It's so easy to develop an app using the platform that sometimes we tend to forget a few things that might be important at scale. So, if you're planning to build the next Facebook using OutSystems 10, keep reading. Tip 6 is the more important.

1) Don't run away from the stores
It's a fact: you're not in control anymore. With web apps, whenever you wanted a customer to get a new version, you just had to "One-click publish" and that was it. "Hit F5 and you're done". The happy path simplified:

One-click publish

Ok, here we're ignoring all the operations behind it (from development to production). With this "web", you could still have issues that you must keep an eye on: add a proxy, bad network, cache servers, load balancers and a huge frontend farm and the scenario gets a bit trickier:

One-click publish

Nevertheless, you have almost all the control (Days of thunder - Control is an illusion). Why should the mobile world be any different? OutSystems 10 brings you Mobile Apps with an amazing capability: no need to go through the stores to push a new version to your customers! There are lots of applications that do this already, even facebook (facebook lite app):

Facebook Lite

This is a huge advantage (pushing updates to the customer on-the-fly) because it no longer implies a round trip to the stores. So, looking at a typical update scenario:

OutSystems update

Looks like "the web" scenario where your "One-click publish" goes to the customer in seconds. So far so good, the happy path is always a delight. However, this feature doesn't mean one submit to the stores for life. The mechanism that checks for updates will get the "delta" from what's new in the server and what the customer has:

OutSystems Lifecycle app
(click to enlarge)

As you can see, if the customer is constantly picking up the updates we're again in a happy path. However, imagine a customer that installs the app from the store 2 months after your release in the store. When he opens the app, the in-app update mechanism will check for updates and see that there are 1120 new changes (V6 is in production). If the files have, in average, 10KB each, that will imply approximately 11.2MB for the update. This will bring overhead and, in bad networks or network transitions (e.g.: entering an elevator, subway, etc), might not be smooth (2G).

So, tip number 1: don't run away from the stores. Create checkpoints whenever you start to witness a big difference from the original submit. It's a balance.


2) Understand the upgrade model
The updates "on the fly" are amazing, no doubt. However, some features require a new shell (e.g.: using a new plugin that interacts with native features - camera, bluetooth, NFC, etc). Now you'll have to deploy your app to production and go to the store. Let's go with an example: suppose you have an app and now you add a functionality to scan QR Codes by clicking a button. You go to the OutSystems Forge and grab the supported Barcode plugin. This requires a new shell as it now interacts with a native capability and code to interact with the camera. How to "glue" everything? Publish to the store first? Deploy to production first?

OutSystems update

Let's look at this scenario. The first thing you MUST do is to protect your code to not "blow" if the plugin is not there. Hide the button, provide a graceful message to the user when he clicks, whatever. Just make sure you don't try to scan if the user doesn't have the plugin. This is a must do no matter what's your deployment strategy. Now, for the complete experience to be in the hands of your users they will need to have both a new shell with the plugin and the logic in the app.

#First approach - long time prepare
If you know you're going to need this plugin, release today a new shell in the stores. Wait a few weeks until your customers update to the new app from the store (or force that update in the app). After that, deploy to production the new feature.

OutSystems update

#Second approach - Deploy code first
You might not be aware in advance that you'll need a given plugin. So, you can't prepare it so easily. Go to production with the code protected and deploy to the stores right afterwards. You must properly protect the feature to scan the QRCodes.

OutSystems update

Keep in mind that unless you programmatically force the user to update from the store, you don't control how much time the user will have an old shell:

OutSystems Lifecycle app
(click to enlarge)

Tip 2: Keep in mind that although you have the applicational updates "pushed to the client", native functionality will go through the stores and you must have a combined strategy.


3) Caution with infrastructure
If you're not in the cloud and have the responsibility to have all the infrastructure in place, then, besides all the work you'll have, you will also be the one dealing with cache servers, load balancers and several frontends. So, this means that in a deployment to production, some customers might get a new version while others don't. Some might be affected by cache poisoning (e.g.: Cache is returning bad JavaScript files while returning new HTML files...), others might not.

OutSystems update

Tip number 3: properly setup the production infrastructure and be aware how you deploy to production.


4) You will have a customer with a rooted Xiaomi 3422-y-k-x-a-89002893-whatever-the-model-it-is
This isn't something particular to OutSystems. It's on all Mobile. Due to the market fragmentation, particularly in Android, you will have a customer with a Xiaomi model that something will not work. YOu don't need to avoid that, but protect your app to avoid possible unhappy users. Example? Do you want to accept rooted Android devices that you don't have the slightest idea of what's hammered or not? How will you deal with a complaint from a customer using a device you don't have access to?

Tip 4: Prepare yourself to customer's free of will to buy whatever mobile device they want and you not having access to it.


5) Phased rollout is king
Because the control you have is little, a phased rollout is almost mandatory. YOu have the ability to push improvements to customers, take advantage of that and do a DevOps approach, releasing things to internal users first, then some customers, then... It's the same logic that TestFLight and Play Beta use, but faster and better! Maybe you have the new button to scan QRCodes. Well, make it visible to a given set of internal users or friends. Then open to the world.

Tip 5: Take advantage of the fast updates to gather feedback faster from a subset of your customer base.


6) Just because it's easy...
... doesn't mean you don't have to read some documentation. Most developers out there are used to a web world where the concerns are totally different than mobile. Performance, battery consumption, network conditions, device fragmentation and all those mobile world intrinsics must be a primary concern from the first day of the project.

The technology makes it easy to bring your ideas to life. But you still have to care for your ideas and your project.

Tip 6: