Hybrid Apps Open the Door for Containerisation
There are essentially two different approaches to building mobile apps: native and hybrid. It is important to understand the high-level differences to put this article in context to then see how we can leverage Container Apps to de-skill, de-risk and accelerate our time to market.
Meeting Today’s Challenges and Tomorrow’s Changes
The ability to ensure the apps are compatible and able to run properly on different kinds of mobile devices, via different operating systems and a multitude of different versions for each of those is crucial.
This is because modern businesses are faced with employees expecting to use their own personal mobile devices, updates to OS versions which can’t be controlled, unexpected new releases, plus many more moving pieces and variables.
A containerised distribution approach and architecture helps organisations manage this ever-changing mobile environment. It both ensures the apps will continue to perform for all users regardless of what device they use or what OS they prefer as well as future proofing for any device policy changes.
The Value of ‘Container Apps as a Service’
While hybrid apps are a huge benefit to organisations, their distribution still requires an initial native installable app for each of the various OSs into their app stores, as well as ongoing maintenance.
This is managed by splitting the app into two deliverables – the installable package or ‘container’, and the business application itself, which is what has been built for the end users to actually interact with.
What this means is that container apps can be delivered as a service, in terms of their build, testing, submission, monitoring, maintenance, and upgrades.
This provides enormous value to the business by making complex applications far more accessible. This approach to delivery and distribution results in lower costs, reduced effort, and quicker timeframes for completion.
This time, effort and budget can all in-turn be transferred and used to add further functionality or usability to the actual business application.
Reducing the burden – what to specify for a Container App
Once the development and submission has been removed by utilising a Container App service approach only the following is required to be provided to get your single codebase app.
App Icon, Splash Green Graphic, App Name, Styling Guide
This information and assets are what your users will see when searching and downloading the app from the relevant store as well as the imagery they will see when installing and running up the app prior to hitting the application code/UI itself.
Container Key & Salesforce URLs
The Container Key is a unique key built into the Container App and is used to ‘bind’ the Container (or native) side of the app with the Dynamic (or hybrid) element of the app that is initially downloaded from the platform on first run-up.
The URLs specified will be used during initial login and subsequent platform calls. This could be the standard test or login endpoints, my domain endpoints or even community URLs.
For the non-standard URLs (ie for community or my domain) these are built into the container app to allow easy switching.
User Account for App Review
For the final steps of submitting the app to the relevant store, a test user will need to be created to allow for example the Apple reviewers to login and test the application and confirm the functionality matches the listing information submitted in Step 1 above.
This user can be a Sandbox user. The data as long representative can be mock/test records.
Unique Requirements for each OS
Along with the above items, there are also a number of specific requirements for each operating system (these are shown and explained in full in the downloadable guide below). These cover things like an App Category for Android and Keywords for iOS. All of these are simple requirements with no development requirement.
For PoC Apps
For Proof of Concept apps it is worth noting that it is possible to build an MVP style Container App which needs less information/assets but can be used to run and present a PoC and still convey the OS interoperability, the branding and the overall combined look and feel of the Container App running the business app that has been developed.
These won’t be submitted to the store, but available to side-load (for internal use and demo on iOS and Android devices quickly and easily). They only require a subset of the above information as can be seen from the list below:
- Splash Screen and App Icons
- Salesforce End Points
- Container Key
- Targeted OSs (ie Android, iOS, Windows 10)
The Benefits of MobileCaddy Container Services
Sophisticated fully branded iOS, Android, and Windows 10 mobile apps on the Salesforce platform do each demand their own skill sets if a native approach is taken. By using a hybrid model with containerisation services like MobileCaddy, these are now far more accessible and affordable.
The real benefit though is summed up by our CEO Justin Halfpenny who asserts “For a client, once the mobile application has been deployed to production, the peace of mind of taming the highly dynamic mobile environment is by far the biggest benefit. The apps being delivered are now themselves delivering critical processes and OS upgrades must not be allowed to stop or limit the availability. ‘Container Apps as a Service’ means the whole team can concentrate on the application delivery”