Published in


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 most important.

1) Don’t run away from the stores

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:

Updates get to customers really fast

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

Maybe not that fast…

And this is ignoring the client’s own firewall, browser cache, etc. 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 updates

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 10 mobile apps automatically updated

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:

Auto updating mechanism. A customer that installs the app with V6 in production will get a delta of 1120 files.

As you can see, if the customer is constantly picking up the updates we’re again in a happy path (small updates). 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 (2G) or network transitions (e.g.: entering an elevator, subway, etc), might not be smooth.

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 — shell is just the name we give to the native wrapper). 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?

Adding native interactions

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.

Deploy to the stores in advance

#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.

Deploy at the same time

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 app:

Different paths — hard to control with thousands of users

Tip 2: Although you have the applicational updates “pushed to the client”, native functionality will go through the stores and you must have a combined strategy to make your developments reach the customer’s hands in a safe way.

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.

Possible “cache poison”

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 where something will not work. You don’t need to avoid that, but protect yourself. 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 (on the customer side), 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 focus 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:

Must read: OutSystems Mobile Best Practices

Training: Becoming a Mobile Developer

Originally published at www.cesarafonso.pt on September 28, 2017.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store