This article aims to present various deployment options available for iOS App distribution. At Unvired, along with the development, we also undertake the job of managing Customers’ Apple developer accounts, build server configuration and maintenance, code signing, submitting the app for review, and app distribution using TestFlight.
It’s a good practice to decide on the deployment options for the project even before you start the project. Because, depending on the deployment model, you can make certain changes in the way you develop the app. There are three ways to distribute the iOS app:
- Public Distribution Using Apple AppStore: This is the most popular way of distributing your iOS app. The app gets published to a public AppStore. Anybody with a compatible iOS device can install the app. This requires very little maintenance once you publish it. The app remains in the public store forever and you typically update the app only in the case of bug fixes or bringing a new feature. You need to sign up for an Apple developer account & need to provide access to developers at Unvired. At Unvired, we take care of automating the build generation process through CI/CD, build generation & submitting the app to the AppStore.Since the app is distributed via AppStore, Apple guidelines need to be followed. Every release of the app needs to be submitted for review. Some of the points for consideration include:
- App being responsive: At no point in time, the app should hang giving a sense of not-so-great user experience to the user. Apple has published a clear set of UI/UX guidelines one should keep in mind while developing the app. . It is best practice to adhere to the UI guidelines right from the beginning so that there are no surprises when the app is submitted for review.
- Usage of private APIs: APIs are what makes an app function. These are the intermediaries provided by Apple which enable apps to perform various activities including making a network call and storing data in the database. While Apple has a published list of APIs one can use, there are some restricted APIs which one can typically use for some specific scenarios, but they should never make it to the final build.
- Demo account for Apple: Apple requires a demo account to login to the app and view all the features. We need to set up a demo account/demo landscape for Apple’s approval. If you have any concerns about exposing the app’s data with the demo account, you can disable the same once the app is reviewed.
- Installation through AppStore: Users can install the app directly from the AppStore. You can push updates to your app through the AppStore and users can configure their AppStore settings to install the updates automatically. App review times typically take from a day to three days. The initial approval time may be more compared to the updates. Usually, initial approval is provided after seeking few clarifications based on the review.
- No proprietary VPNs: Apple is stringent on not installing any third-party VPNs to access the functionalities of the app. Companies usually provide a demo account that does not require access to a VPN for enabling Apple to review the app.
- Payments: Apple directs all payments to happen via their In-App Purchase interface. Any other payment method outside of this mechanism is usually turned down.
- Timing of release: You can time the release of the app based on your business factors. Of course, you can also set the app to be released as soon as it passes the review. This timing can be updated any time before Apple reviews the app.
- Justify the usage of special hardware features/technologies: If you are making use of hardware features in the Apple device for example NFC, Bluetooth, AI & ML, you would need to justify it to Apple with the exact feature name for which it is used. Apple needs to ascertain whether the hardware or the technology declared in the app is really being used as intended before giving approval.
- Private Distribution using Business Manager: If the app is built for a limited set of users (ex: your employees) and not for the public at large or if you do not want your app to be publicly visible, you can opt for this mechanism where you can make the app available only for a set of users. All the guidelines and processes are the same as that of public AppStore distribution except that the app won’t be available for download in the public AppStore. Some additional points of consideration here:
- You need to sign up for an Apple Business Manager account. There is no cost involved in this and it requires you to provide your company registration information (Ex: DUNS number).
- Development of the app can happen either through Unvired’s developer account or yours. After the app is developed, it needs to be submitted to the Apple Appstore for approval. Once the app is approved, the app will be made available for distribution to specific Businesses using the Business Manager account. You need to provide your Organization ID and name as it appears in your Business Manager account in order to publish the app.
- You would have to use your own MDM software for distributing the apps to your sets of users, employees for example. Intune is a popular MDM solution by Microsoft which many of our customers use for managing devices. Intune has documented steps for downloading apps uploaded through a Business Manager account.
- One important note about the Business Manager app which you should be aware of is that apps distributed through the Business Manager account cannot be directly distributed through the public AppStore and vice versa.
- Private Distribution using Apple Enterprise Account: This was the preferred way of distributing apps a few years ago but not anymore. Apple has updated eligibility criteria to apply for an enterprise account. You can find the details here. There are a number of benefits if you do manage to get an enterprise account. Apps using this mechanism for distribution don’t go through the AppStore process for approval. There is no review process involved and you could be flexible in terms of following a specific set of UI/UX guidelines, usage of private APIs, having your own payment mechanisms, and distribution channels.
However, it comes with some maintenance overhead. Apps will have something embedded called provisioning profiles. Provisioning profiles are what gives the app permission to run on a specific iOS device. While the apps distributed through pubic AppStore or through Business Manager don’t have any expiration dates, apps distributed through enterprise account expire in a year’s time. If the app is installed and the profile expires, apps stop working. So, developers have to regenerate the profiles every year, embed them in the app by generating the new build, and have all the users install the latest version. It’s not as complicated as it seems to be if you are using an MDM solution, but this maintenance overhead is something to be taken care of every year.
