Making apps available to end users is the final step in a mobile app deployment workflow. You might think that mobile application distribution is straightforward but, unfortunately, it is not. It can be difficult enough for mobile app developers who are most familiar with the mobile app distribution process. For DevOps, which is increasingly responsible for all the deployment activities that must be undertaken once mobile app development is complete, it is worse because enterprise app distribution is one of the many things that they are responsible for, but it is done relatively infrequently. Making matters more challenging is the fact that the mobile apps that DevOps is tasked with distributing originate from both internal engineering teams and third-party developers, which contributes to the complexity of mobile application distribution.
There are several mobile app distribution channels through which DevOps can make mobile apps available to end users. Apple’s App Store, Google Play, and Samsung Galaxy Store are examples of well known public app stores where anyone can view a mobile app. Then there are enterprise app catalogs, often part of unified endpoint management (UEM) solutions such as BlackBerry UEM and Microsoft Intune, which can be used to make mobile apps available to a restricted group of users such as enterprise employees. Each mobile application distribution channel has unique requirements, and therefore unique challenges, for publishing an app.
Apple has the most restrictive mobile app distribution process. This restrictive process is both a benefit and a curse; a benefit because apps are vetted, there is less malware, and there is lower likelihood that apps will have compatibility problems in the future; a curse because it is cumbersome for anyone—app developers or DevOps—who wants to publish an app. Mobile app developers often encounter problems, despite distributing apps to the Apple App Store frequently.
What makes publishing through the Apple App Store incredibly challenging is the requirement that the provisioning profile used to sign the app match the provisioning profile for the app container created for the app in the Apple App Store. These provisioning profiles contain app information and entitlements, which specify the system resources an app can use. The entitlements are set either into the app ID, which is a string used to identify one or more apps from a single development team, or the provisioning profile. The functionality that uses the entitlements lies in the app. A misconfiguration may result in unexpected behavior or crashes.
A provisioning profile acts as a link between the app testing device(s), the developer account, the app, and the app container in the Apple App Store. The same provisioning profile must be used for both the initial signing and any re-signing. Without the correct provisioning profile, the entitlements coded into the app may not be available. Obviously, removing app functionality is not suitable for the user experience.
When DevOps is tasked with deploying an app, it will need to obtain the provisioning profile used for the initial signing and keep track of it for any subsequent signings. That can be inconvenient when working across departments within a company, perhaps adding delays to a deployment. Think about how much more difficult that will be when deploying an app built by an external vendor. While it may not be an issue for a single app, it will rapidly become one for any reasonable sized mobile app portfolio.
By contrast, Google, which has a well-documented process for publishing Android apps through Google Play, is much less restrictive. There are some technical and legal restrictions and requirements, but generally speaking, they are not significant headaches. Resources and documents are readily available describing the steps required to publish an app. You can find answers to many questions about app visibility and discovery issues in the Play Console Help Center. Regardless, some element of automation and codification of processes for distributing mobile apps through this channel can only be beneficial.
While enterprise app catalogs such as those available through Blackberry UEM and Microsoft Intune may be less restrictive, they each have unique requirements. For example, with BlackBerry UEM, DevOps needs to know the shared network location for storing mobile apps. If the mobile app is to be installed on an Android Enterprise device and it is being managed as a private app in Google Play, the app will need to be added to Google Play. The BlackBerry Dynamics-enabled apps’s entitlement ID, which is used to manage end user entitlements, will need to be recorded in BlackBerry UEM. If DevOps doesn’t know the entitlement ID, they’ll have to get it from the app developer, which could delay a deployment significantly if the app is sourced from a third party. Different requirements will need to be accounted for when distributing through Microsoft Intune. The net is that it will get to be a bit much for DevOps to keep track of the rules for what to do and how to do it for each enterprise app distribution method.
Some issues that are merely inconveniences when distributing one or two mobile apps become huge problems when the size of the mobile app portfolio increases.
For example, consider a situation when DevOps has to distribute an app through multiple channels because employees, contractors and consultants must be supported. An enterprise app catalog, say BlackBerry UEM, will be used to make a mobile app available to employees. Google Play and the Apple App Store will be used to make that app available to contractors and consultants, as there is no guarantee that these end users will be able to access the company’s BlackBerry UEM app catalog.
A number of activities are required to successfully publish a mobile app.
Manually handling the unique requirements and restrictions for multiple app distribution channels is a recipe for failure. With one app to deploy, mobile app distribution is manageable even if there are complications. But with a more extensive mobile app portfolio, distribution is challenging. For a DevOps team that is already stretched thin, even distributing three apps may be unmanageable. The complexity of obtaining and managing artifacts that scale across publishing venues and geographies, provisioning profiles, and the sheer number of apps cries out for automation.
If an organization has an extensive mobile app portfolio with different apps going to various public and private app stores, keeping track of everything using manual processes is messy and inefficient. Automation with orchestration is tremendously beneficial: automation to repeatedly handle the rote distribution tasks that are potentially prone to errors that derail a mobile app deployment; and orchestration to ensure that distribution is execute at the correct time as part of a deployment workflow, and with any required notifications to the different teams involved in a deployment flow when manual intervention is required.
Orchestration with the Blue Cedar Platform can ease the distribution process and complexity, providing time and resource savings to teams not familiar with the vagaries of various distribution channels, including: