How to Master Salesforce Mobile App Distribution with Containerisation Services

As the demand for custom mobile apps continues to skyrocket, it’s becoming easier to meet business requirements by using hybrid apps built with standard web technologies, and using container apps to overcome the challenge of distribution. This article provides an overview of how to easily distribute Salesforce mobile apps across iOS, Android, and Windows 10.

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.

Note: We have omitted web apps here, due to limitations with persistent authentication and secure data storage.

Native Apps

Native apps are built exclusively for a certain operating system, require specialist development skills relevant to the targeted operating system as well as specialist skills for the submission and distribution.You can think of Native apps as being made up of a single installable package which includes the application’s business logic and UI. If the app is required to run on more than one operating system, these will have to be built and maintained for each OS.

Hybrid Apps

A hybrid approach allows the app (here referring to the business logic and UI the users interact with) to be run on various different operating systems and mobile devices with a single codebase.This single code base removes the need for different and specialist development skills, which ultimately reduces costs, time spent on the project, and other commitments such as maintenance and testing. With this approach, the app itself is built using much more common and familiar web technology skills.

The distribution of these hybrid apps to each operating system can be abstracted, which opens the door for the all-important containerisation method and associated services. The hybrid app is placed within specific containers native to each OS without any extra effort, making distribution far easier for the business.

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.

Using Container Apps to Accelerate Proof of Concepts

The Container App service is also ideally suited to the early phase of a mobile initiative when Proof of Concepts need to be delivered to help assess and select technology, scope and device capabilities.

Having built the business logic and interfaces for demonstration the app can then be run, fully working on iOS, Android and Windows with the added benefit of full branding and if necessary plugins added to access specific device capabilities.

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.

  • 1

    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.

  • 2

    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.

  • 3

    Support Email & Privacy Policy

    When submitting to the store a support email will be required for the listing along with a Privacy Policy link to a published and publicly available webpage.

  • 4

    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.

Download the full Container App Guide

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:

  1. Splash Screen and App Icons
  2. Salesforce End Points
  3. Container Key
  4. Targeted OSs (ie Android, iOS, Windows 10)

The Benefits of MobileCaddy Container Services

The MobileCaddy Application Delivery Framework (ADF) provides this as a service for all its clients and partners as a standard part of the offering. This means businesses using MobileCaddy to deliver their apps have far more opportunity to focus on delivering value to their users.

By using MobileCaddy container apps for your Salesforce projects:

  • No specific developers skills are needed
  • Accelerates delivery
  • Allows you to run the developed app on iOS, Android, or Window 10
  • Provides long-term peace of mind by outsourcing pre-release testing and maintenance

Final Thoughts

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”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to Top