The 5 Mobile App Distribution Methods and Channels in the Mobile App Lifecycle

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.


With the Smartface Development Module

  • You don’t need to recompile your app every time you make an update.
  • You can deploy your application remotely and when you make an update in the code, only the delta code will be downloaded just in a few seconds.
  • You don’t need a Mac or a development certificate to test your app during development.


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.


With the Smartface Testing Module

  • You get a cross-platform testing distribution environment. No need for separate tools for iOS and Android.
  • You can share the app with individual testers and testing teams and keep track of each tester.
  • You can keep a full archive of binaries of all versions previously shared.
  • You can resign the application for production without going back to development so that you can make sure that the tested application is released to production without any additional changes.

For more information, you can visit



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 Smartface Enterprise App Store and Cloud Build Modules

  • 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.
  • With the Cloud Build module, you can restrict access to the signing identities, protecting them from unauthorized downloads while allowing developers to use them for publishing applications.

For more information, you can visit


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.


With the Smartface Store Submission and Cloud Build Modules

  • You can upload your binaries directly from Smartface Cloud to the public app stores, there is no need for a Mac and it allows segregation of duties as the application developer and uploader roles can be separated.
  • With the Cloud Build module, you can restrict access to the signing identities, protecting them from unauthorized downloads while allowing developers to use them for publishing applications.

For more information, you can visit


5. Distribution for Application Updates

Standard way of updating apps without Smartface

  • 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”.


With the Smartface Remote App Update Module

  • Actual native apps can be updated remotely with hot deployment.
  • As long as you comply with Apple’s policies, almost any kind of change can be made in the app remotely.
  • Especially for small updates, there is no need to go through the review processes.
  • Updates can be forced and deployed instantly so that critical fixes can be applied without any complexities and backend compatibility issues can be eliminated.

For more information, you can visit


With Smartface Cloud, you get a fully integrated mobile application and lifecycle management platform, eliminating the complexities of distribution in the full lifecycle of a mobile app from development to production.