It’s good practice to send builds to your customers or test users early and often. But what are the best ways to do that?
Here we outline the main options and our recommendations, especially focusing on iPhone and iPad apps where the process can be a lot trickier than Android.
Our customers value the simplicity with which they can build native mobile apps using their web skills with Trigger.io. So we’re happy to say that there is a very simple option and we’re delighted to work with Kickfolio for online app previews.
In order of simplicity we’d recommend you consider the following options to get app builds to your customers:
Trigger.io does support wireless distribution – that’s probably the most flexible option but also the most complex (and possibly expensive) to set up. You’ll need to buy the iOS Developer Enterprise Program if you want to distribute to more than 100 users. If you don't need that many then TestFlight is easier to setup than doing it manually.
But once you're setup, that method does allow you to make your app available to a private audience with a really simple install mechanism for them where they can click through an email link to a download web-page and install your app from there. Email us if you’re considering it.
Kickfolio is by far the simplest option. If all you need is for your client to be able to quickly try out an app build in a simulator to see your progress or provide feedback, this is going to be the best method.
It’s ideal for sending builds early and often in your development cycle when you’re still ironing out the user flows – best to get them in front of customers early for feedback rather than finding out that something fundamental is wrong when you thought the project is nearly done!
This is the process for using Kickfolio to show a Trigger.io app build to a customer:
Use the Trigger.io Toolkit or command-line tools to build your app and run it on your own iPhone Simulator.
On Windows or Linux simply create the build with our ‘forge build ios’ without running it.
Sign-up for Kickfolio and upload your build. Your build is created at 'development/ios/simulator-ios.app' inside your app directory. Zip it up using a command like ‘zip my-app.zip –r simulator-ios.app’ and then click ‘Upload New Version’ from your Kickfolio dashboard.
When you’re at the point that you need clients or test users to rigorously test the app out on their own device then TestFlight is the way to go. It helps you manage the process of ‘ad-hoc’ distribution and managing your users’ feedback.
It’ll require a more setup from you, and several steps from the person trying to install the app which can result in frustration if not done right. But it’s a necessary step when you’re at the user-acceptance testing stage and to try out features that are tricky to see in action in a simulator, such as fine geolocation or real barcode scanning.
Here’s an outline of the process you should follow:
Create your TestFlight project and invite your customers or test users
Click ‘Invite People’ from your project dashboard
They’ll get an email inviting them to your TestFlight project and have them setup their device to prepare it to be able to install your build. They will need to open up the invite email on their device and click to install the TestFlight app.
This process will end up with them appearing as a team member in your TestFlight project and you being able to see their device UUID there.
Setup your Apple App Id, Certificate and Provisioning Profile
The important thing is to add all your test users’ devices in that tab. You can add up to 100 devices with a normal developer account. Any more you’ll need an enterprise account.
When you come to create the provisioning profile you’ll want to select the ‘Ad Hoc’ distribution provisioning profile type, and make sure to associate it with all the devices you just configured.
Package your iOS app with the Trigger.io Toolkit or command-line tools
You’ll need to download the certificate and provisioning profile you just created and use the package command in the Trigger.io tooling:
forge package ios --ios.profile.provisioning_profile ad_hoc.mobileprovision
You can do that at the command-line or the Trigger.io Toolkit UI with detailed instructions here.
Upload the build to TestFlight
From your TestFlight dashboard you can now upload the app package which is a .ipa file in the release/ios subdirectory inside your Trigger.io app directory
You’ll then be prompted to inform your test users that a build is available to install by way of an email from TestFlight.
Add more users
But if you want to add more users to your TestFlight project, there’s a small gotcha: once they’ve accepted their invitation to your project, you’ll need to go back to the Apple Provisioning Portal to add their device.
You’ll also need to regenerate your provisioning profile with the new device associated with it, download it, and be sure to use it in the Trigger.io tooling when you create your next build.
Unfortunately the new user won’t be able to install the builds you’ve uploaded in the past since their device id wasn’t associated with the provisioning profile that you used to create those builds.
Phew! Now TestFlight manages the process of informing your test users about the build and prompting them to install it and provide feedback
The good news it that for Android, it’s a lot simpler for customers to install your app builds – you can simply package up the app into a .apk file and send it to them to install over email.
There are also options for showing them browser-based previews like Kickfolio provides for iPhone / Android apps. But most people opt to simply send the build to install since the Android emulator can be a lot slower than real devices and the process is simple enough.
To package and Android app into a .apk with Trigger.io follow our tutorial on preparing your app for release.