Our BlogTips, Tricks, and Thoughts from Cerebral Gardens

Introducing OTAgo, an OTA app distribution system

OTAgo

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:

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):

Screenshot from the Dev Portal

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.

8 Developer Tools You Should Use

Today I'm going to cover some awesome developer tools that can make your life easier. These are listed in no particular order.

AppViz: http://www.ideaswarm.com/products/appviz/

AppViz is a tool for automatically downloading your sales, trends and financial reports from iTunes Connect, as well as the reviews for your apps. The app works by scrapping the information from the web so it breaks whenever Apple changes something at iTC, but, IdeaSwarm, the creators, are insanely fast at analyzing the changes and pushing out an update to accommodate. This is by far the best $30 I've spent, and to be honest, I don't know of a single developer with published apps, that isn't already using AppViz. So I guess this tip is for newbies. Get this app now, you'll love it.

MajicRank: http://majicjungle.com/majicrank.html

MajicRank by David Frampton (of Chopper 2 fame) is the tool to use to track how your apps are doing in the top 200 lists. It scans all regions, so you can see results in countries you can't normally access. It's similar to AppViz in that it scraps info from the web and so it can break, but it rarely does. MajicRank is free so there's no excuse not to use it.

TestFlight: http://testflightapp.com/

I mentioned TestFlight a couple of weeks ago but they're worth adding to this list too. They've created a great service so far, it's almost too easy to use! There are still some kinks to work out, but note that they moved quickly to resolve the security issue I pointed out in the last article.

DropBox: http://dropbox.com/

DropBox is a fantastic cloud storage system for users. It lets anyone backup important files or easily transfer files to another place/person effortlessly. They provide an SDK that lets you add DropBox support to your apps so that you can let your users backup and/or transfer their app data easily.

Amazon AWS: http://aws.amazon.com/

Amazon Web Services actually consists of several great tools. The two most popular so far seem to be S3 (another cloud storage system, but intended for companies not users), and SimpleDB (a simple database in the cloud). If your app is data intensive, there doesn't seem to be a better solution than Amazon for hosting that data. They now have a free starter plan too so you can try it out at no risk.

Matt Gemmell: http://mattgemmell.com/

Mr. Matt Legend Gemmell isn't really a dev tool, but he does make a few that you can use in your apps. The most popular ones are MGTwitterEngine (an implementation of the Twitter API) and MGSplitViewController (a replacement for the iPad's UISplitViewController that gives you more control/options). Check them out here: http://mattgemmell.com/source

Accessorizer: http://www.kevincallahan.org/software/accessorizer.html

I found out about Accessorizer through Jeff LaMarche who said it was one of his favourite apps. I can see why. The app is a source code generator. You teach it your coding style, and then it pumps out code for you. No, it won't build your next app for you, but it will save you tonnes of repetitive typing setting up all your class properties etc. If you value your time, Accessorizer will save a lot of it for you.

TouchXML: https://github.com/TouchCode/TouchXML

TouchXML is a library for reading in and parsing XML files. If you store your app's data and/or configuration in XML files, this is a far faster way of getting that info than using libxml. You can quickly extract exactly what you need from XML in just a few lines of code. Truly indispensable. And if you'd prefer JSON over XML, there's a TouchJSON available too.

Hopefully some of these tools will help you or a friend on your next project.

TestFlight Your Apps

You've been working on your new app for ages and it's finally ready for beta testing. Prior to iOS 4.0, it was a considerable pain in the neck to get a build on to your testers devices. You needed to package up your apps and ad hoc profile, send them to each tester, and then they needed to use iTunes to install the profile and app on their device. It seemed like an art more than a science getting an app installed, never mind an updated build later. It was a very clunky system, and it didn't always go smoothly.

With iOS 4.0, Apple made it much easier to install test apps on a device. It's now possible to install profiles and apps without going through iTunes. Using XCode's Build and Archive option, you can create an .ipa file that embeds the ad hoc profile. Just put the .ipa file on a web server, (or your public Dropbox folder), and send the link to your testers. They can install the build by clicking the link in mobile Safari.

You're still required to collect your users UDID's, add their devices to your developer account and create an ad hoc profile that includes their devices.

Last week, TestFlight, a new service for distributing your test builds to your beta testers, went live. TestFlight promises to revolutionize the way developers beta test their apps, and after testing it out for a bit, I'm pretty sure they're going to do just that.

The free service, found at testflightapp.com, allows a developer to invite people to become a beta tester. The tester creates an account through the web site in Mobile Safari on their device, and then they register their device with the system. This process involves installing a configuration profile (different from an ad hoc profile, but listed in the same area on the device's settings). This gathers the device UDID and reports it back to the server. A tester can register more than one device. The tester, and her device(s) then show up in the developer's account. As a developer, you can export the UDID's of all your testers and import them into Apple's iOS Provisioning Portal. One issue I found here though, is that if you attempt to import a file of UDID's that contain a record that you've already added to the Portal, it will reject the entire file, instead of just ignoring that record.

Once you've imported all the new UDID's into the iOS Provisioning Portal, you can update your ad hoc profile to include all of your testers. Then, use it to create a test build of your app. You still need to use XCode's Build and Archive Option, and then use it's sharing wizard to create the .ipa file (all in all, a simple process, more details here: http://iphonedevelopment.blogspot.com/2010/05/xcode-32-build-and-archive.html).

Next, you upload your .ipa file to the TestFlight web site, and select the testers you'd like to notify of the new build. TestFlight emails each of them a link to a page that lets them install the build easily.

TestFlight lets you see how many times the .ipa file was downloaded (though, not by whom for some reason). I had one person delete it from their phone and redownload it, and it counted as another download. So a list of 5 people, with 5 downloads, doesn't really mean they all downloaded it. But it will likely be close.

I tested this entire process with some extremely non-technical people, not one had an issue. They were all able to create their accounts, register their devices, and install my test app with ease.

If you need more beta testers, TestFlight offers a recruitment tool. You can start recruiting random people through Twitter, your web site, or wherever. It's just a link you post. When people sign up to be a beta tester for you, you can accept or reject them based on whatever criteria you like.

Overall, I'm very impressed with the initial service offering TestFlight has. And, remember, it's entirely free (for now) for developers. They are charging for enterprise accounts.

I do have to point out one concern I have with TestFlight however. During my limited testing of the service over the last couple of days, I uploaded a few builds, sent them out to some testers, including myself, and then deleted the builds. When I went back to one of my test devices, I still had the link open in Safari to do the install, for a build that I had deleted in the TestFlight dashboard. So, I tested, and tried to install the build, that should have been deleted. It installed perfectly. This is my concern, because I had deleted the build! Which means, that TestFlight, is not actually deleting the bits of the builds you tell it to delete, it's just removing them from your dashboard. Whether or not you consider this acceptable is up to you (and your personal level of paranoia) . But remember, that when you upload your .ipa to TestFlight, you're letting unknown people view and test your ideas (yes, the TestFlight people can view and run your .ipa files, if they so choose).

If you are concerned, you can use Hockey to manage your beta installs. It's not as easy to manage as TestFlight, but you con trol everything on your servers so it's arguably more secure.

You can even mix and match some of the TestFlight features (UDID collection, recruitment etc), and then deliver the actual builds via Hockey.

Paranoia aside, TestFlight is excellent so far, and will change the way you deliver your test builds to your testers. Down the road, they plan to support additional features, such as adding analytics so you can view what your testers tested and for how long.