Over-the-Air (OTA) app distribution is one of the methods Apple provides that allows you and your users to securely install iOS apps on devices. Other methods you've most likely seen and used are directly installing the app via Xcode on a device in your possession, TestFlight (Apple's beta distribution system), and of course via the App Store.
Each of these methods has their purpose.
- Direct via Xcode: Debugging and initial testing
- TestFlight: Beta testing
- App Store: Distribution to customers
So when is the OTA method needed?
Not every app can be distributed via the App Store: In-house apps for your staff, apps that Apple may not approve, or custom apps for your business customers that need to be distributed via Apple's private B2B store.
If the app you're building can't be distributed via the App Store, you're unable to use TestFlight for beta distribution either. OTA is a great way to distribute beta versions, and/or release builds for these apps.
Should you use OTA to distribute your apps?
Most likely, no. If you can use TestFlight and the App Store, use those. If you're building enterprise apps, or have a very early build that you can't get approved for TestFlight distribution yet, then OTA may be for you.
Why use OTAgo?
Setting up an OTA distribution system isn't very difficult. When you use Xcode to build your .ipa file, it gives you an option to create a manifest.plist file that's required for OTA distribution. You can basically drop that manifest.plist and your .ipa on your web site and set up the appropriate links. However, doing it this way, doesn't give you any protection and anyone that finds the link can install your app.
You can put the link behind basic authentication using Apache's .htaccess, or similar via nginx. But since iOS 13, using basic authentication requires the user to enter their credentials 3 times each time they install a build.
See @GeekAndDad's tweet here:
In Old Days™ hosting Ad Hoc build on http server in Basic Auth protected folder then involved 1 pwd entry in iOS Safari to install app.
— Dad (@GeekAndDad) January 18, 2020
In iOS 13 it’s now THREE pwd prompts (1 in Safari and 2 in the install process somewhere).
Know how to self-host w/ apache that works better?
You might be thinking, let's just use an obscure link no one will find, and we'll rely on security by obscurity. This of course is never a good plan, with search engines and malicious web spiders, your hidden link is unlikely to stay hidden.
On top of that, Apple has a new requirement that's coming into play in 'Spring 2020'. Due to rampant abuse of Enterprise accounts being used to distribute apps outside of the App Store, Apple is cracking down and now asking developers using an Enterprise profile how and where the app will be distributed. They're requiring developers to use a secure authentication method. This means either username/passwords or a restricted network accessible only via VPN/Intranet. See a screenshot of the current settings (note you'll only see this in your developer account if you're using an Enterprise account):
OTAgo handles the secure authentication for you, and it does it in a way that works around the requirement to enter a username/password 3 times. I've designed it in a way that it should be easy to set up and configure. The initial version includes a `simpleAuth` mechanism that lets you authorize users as simply as providing a list of username/password pairs.
I've also made the authentication system pluggable, so if you want or need to link into an existing authentication mechanism, you can do so by adding in your own plugin. If OTAgo proves to be useful/popular, I'll likely add some additional authentication methods, OAuth, MySQL/MariaDB etc. Of course feel free to send pull requests with additional ones. :)
You can check out the project here: https://github.com/DaveWoodCom/OTAgo. Let me know what you think. If you find it useful, please star it on GitHub!
Acknowledgements:
My thanks to Freepik at flaticon.com for providing the koala used in the OTAgo logo.
Also thanks to Paweł Czerwiński on Unsplash for the background of the banner above.