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:
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:
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):
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:
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:
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?
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.
#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.
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:
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
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.
Must read: OutSystems Mobile Best Practices
Training: Becoming a Mobile Developer
Originally published at www.cesarafonso.pt on September 28, 2017.