We are always talking about the advantages of mobility; however, there is one downside that we are so used to that we tend to overlook. In terms of app delivery and updates, mobile platforms forced us to go back using the obsolete method of binary distribution. Especially on iOS, there are a number of restrictions that makes deployment complicated.
For this reason, there are a number of different ways of distributing apps for different purposes. Let’s examine each mobile application distribution use case in detail:
1. Distribution During Development
- Used by the developers that are actively working on the app.
- It may be necessary to update the app frequently.
- The main issue here is to keep the deployment times as short as possible not to impede the development process.
- For this purpose, Apple requires the use of an iOS Development certificate.
2. Distribution for Prereleases
- Used for distribution to a small group of specific devices and users, primarily for testing or evaluation of the app.
- The main issue here is the keeping track of versions and the testers both for iOS and Android. The prerelease distribution of an app must be tightly controlled.
- For this purpose, Apple requires the use of “Ad Hoc” certificates, which allows distribution to a predefined set of devices. For enterprises, the use of an iOS Enterprise certificate is also applicable, which removes this device restriction.
- One additional, usually overlooked but important concern is that after testing, the app needs to be resigned with production certificates. This requires going back to the development phase for configuration changes and recompilation. Since this is a manual process, it creates a risk with missing or unspecified changes after testing.
3. Distribution for In-House Enterprise Use
- Used for distribution to internal stakeholders such as employees or contractors.
- For this purpose, Apple requires the use of Enterprise certificates for app distribution without going through the App Store.
- Apple requires that any external party other than the employees must have a binding, protective agreement for internal use of the application. Even if it is a B2B app, the customers still cannot use the app. The only exception is the on-premise or supervised use of the app by the customers in a company-owned device (e.g. in a branch).
- The main issue here is to manage and monitor the access of to the application in an ongoing manner so that only permitted users have access (e.g. if an employee leaves the company, the access should be cut off immediately).
- The reason for these restrictions is that iOS Enterprise certificates allow distribution of iOS apps not reviewed by Apple. If these rules are broken (e.g. the app is publicly released, or the certificate is stolen), Apple reserves the right to revoke the certificate or even pursue further action. This makes it crucial to distribute the app with proper methods.
- Another concern is the prevention of the leaking of the enterprise certificate. Such leaked or stolen certificates are usually used to publish and distribute apps with malicious intent and Apple has no tolerance in such cases.
- In the same manner, if an Android keystore is obtained somehow, it is possible to create impostor malicious applications. For this reason, keeping the signing identities secure is as important as keeping the application secure.
With the Deeploy Enterprise App Store
- You get a cross-platform Enterprise App Store that can be integrated with any identity management system through LDAP, ADFS or oAuth so that you can ensure restricted access compliant with Apple’s policies.
- No MDM enrollment needed, so any employee or stakeholder can use it with their own devices instantly.
- You have reports of which users are downloading which apps so that you can have full control over app distribution.
4. Distribution for Public App Stores
- Used for distribution to end users through the App Store or Google Play.
- For this purpose, Apple requires the use of public distribution certificates.
- For the App Store, the apps must be uploaded from a Mac in a specified way and then they are submitted for review before going live and it may take a couple of days, if not more.
- For Google Play, there is a reactive review process, but still it may take a couple of hours for the app to be published.
5. Distribution for Application Updates
- Since the application updates are carried out through application binaries, this is essentially the same with enterprise or public distribution processes.
- Regardless of the scope of the update, the full binary must be resubmitted to the App Store and Google Play, going through the same review process every time.
- After the update is published, the users will be prompted that an update is available. In most cases, the app must be downloaded in full and reinstalled over the current installation.
- It is not possible to force users to download and update the app and multiple versions of an app will be present in the field, causing backend compatibility complexities.
- Some web-based solutions such as hybrid apps try to overcome this issue, but in return, they sacrifice the native user experience, features and performance no matter how close they are trying to be “like native”.
