One of the big hurdles we face in our mission to ensure the continuous delivery of business critical mobile apps is that the vast majority of requirements only focus on the app and possibly the requirement for offline.
This misses some really big differences in the way these apps will be delivered and what a ‘simple’ requirement like Offline brings into the mix.
Most of us have either transitioned or grown up in the era of what I have called below ‘Browser Apps’. This is our typical SaaS application, delivered via the browser with a multi-tenant architecture. I know this is a simplification but the purpose here is to use this definition to compare to what I have summarised as ‘Mobile Apps’ and here I mean business critical mobile apps (which you will know by now are Offline capable by default).
So lets take a look at the four key elements where these two delivery models differ:
This difference is where we start to diverge. In our Browser delivery model it is nearly universally accepted that to work our ‘app’ requires a data connection.
For mobile, where we are roaming, or maybe we have a device that is Wifi only and will only connect when we can locate a friendly Wifi login, we have no control over our data connection and it is best described as transient.
This single change sets up up for the other three changes to our application delivery model .
I have written before on why offline is non negotiable (and is a key requirement for 100% mobile app uptime) so won’t cover that ground again here, but suffice to say if your mobile app is business critical, full offline capability (ie data AND logic) is an absolute must.
In the world of Salesforce.com browser apps we are very used to deploying our changes from a sandbox environment to a production environment. And we are used these successful deployments immediately not just being available but actually now being the version that all users will receive.
So for an example if we updated an apex class and deployed to production as soon as the deployment is successful we know anyone hitting that class will be using the updated logic.
In the case of Offline mobile we deploy the changes in a similar way except we are now not in control of when that user (who may well not be connected) will actually be served that upgrade.
In fact if they are offline for many days they will continue to use the previous version long after you initially deployed. This is a big mindset change and actually has a lot more affects than just a delayed upgrade.
For example if I wanted to add a validation rule on the platform but that was not catered for in my mobile app then I would need to wait till all my mobile users had been migrated to the newer mobile version (that included this validation rule in the offline logic) before I could activate this logic on the platform
One of the recurring themes in SaaS Browser based apps is that we all share one large data store ie Multitenancy / Single Store.
As you are no doubt seeing as a theme here, in our offline robust mobile app model this is not going to be the case.
Just as our Application Versions can diverge we now have ‘local’ device data stores. As soon as we drop our connection from a sync we are at risk of these differing from the primary platform store (as well as all the other local/device data stores on my co-workers devices).
This opens up all sorts of exciting possibilities (or really ‘issue to solve’). For example we now have the very real scenario of data conflicts, missing data (ie data deleted on the platform but still residing on the device store) and a whole host of other sharing and config issues.
Leading on from the Application Deployment going from instant to staged we now realise that there is a very strong likelihood of multiple versions running on our devices.
This is one reason for multiple versions. But there are others.
For example final testing in a sandbox environment just does not cut it when it comes to mobile apps. There are just too many variables. So for a strong delivery model we need to be able to run production testing to select users and devices in isolation to the previous version so that the bulk of users can continue using the tried and tested GA version.
We also often have a requirement to create ‘versions’ of the app to suit different form factors. There is a choice here. We could go down the responsive design route but sometimes it is more practical to build specific versions (for example same logic/different UI) that targets different form factors or device capabilities.
Connection, Deployment, Data & Versions – 4 Key considerations for business critical mobile appsClick to tweet
There are many good practices already developing around solving these problems – and as long as these differences are understood from the outset then these can be managed.
The purpose of MobileCaddy is to provide a Mobile Application Lifecycle platform that sits atop Salesforce.com and neatly deals with all the issues above (and a whole host of other [pesky details).
Most importantly it does not slow down the app development, in fact it is even more rapid than tradition mobile app builds. To find out more request a demo and see just how quick you can get a robust mobile app out and delivering value.