Mobile applications need to be updated for many reasons. It’s common for an initial release of a new app to contain bugs that weren’t caught in sandbox and developer environments, for example, or for a misunderstanding of workflow to pass through the UAT stage unnoticed.
Beyond this, once an app is live and mature, it will still need to evolve in line with many factors including (but not limited to): new business requirements, regulatory updates, alignment with new OS and hardware capabilities, and of course in our world modifications to support new Salesforce releases.
Unfortunately, Salesforce mobile applications limits you to an all-or-nothing upgrade approach, replacing an existing app with new versions to all users. This is of course risky in reference to having no control – or reporting – over which users have updated. It also brings the challenge of managing the app store submissions.
With Partitioned Versioning from MobileCaddy, you get a prescribed methodology for updating your mobile applications. Included is the ability to run multiple versions of an app in a single instance (org) and target versions to specific users’ devices.
This enables the following across all org types (Developer, Sandbox, Production):
Existing “GA” Dynamic Versions are those that are automatically provisioned to new users, whereas new DVs can be set to “Testing”. Once in this state they can be manually provisioned to specific users’ devices, ideal for running full integration tests in production environments.
Limited, controlled rollout of updates are Over-the-Air (OTA), and are built so they won’t take place if there is data that still needs to be synced to Salesforce. They won’t interrupt the user during critical workflow processes either. OTA updates skip the need to re-submit to app stores (iTunes, Google Play etc) and it is very common that most app updates can be performed via this method.
It’s clear that Partitioned Versioning has value. That value only increases when you look at a typical scenario across enterprise software projects.
Let’s say the first drop of our app is out the door, and as soon as that happens our team is disbanded, with SAs, lead developers, and BAs all being pulled straight onto other projects. You’re now in a position where your app has a large active user base, but these first-drop CRs (Change Requests) and tickets are being raised. The structured MobileCaddy approach allows changes to the app to be made, and speedily make their way through to production release with the minimal amount of risk to the current running version.
The bottom line
A complicated or hazardous update process can cripple a business’s ability to react to new and changing requirements, and support the rollout of bug-fixes. Any CTO found being held ransom by such a setup knows this all too well.
MobileCaddy has attacked this issue head-on, from the inside-out. Partitioned Versioning means that not only are initial versions of applications deployed with ease, but so are updates and fixes, with a growth in confidence through each stage of the process.