Getting mobile app builds to your customers

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.

Let’s go through the main options we see developers on our platform using. Do email us as you try these with Trigger.io to build and distribute your app. We’d love to hear your feedback.

The main options for iOS

In order of simplicity we’d recommend you consider the following options to get app builds to your customers:

  • Kickfolio for a browser-based iPhone Simulator with your app installed
  • TestFlight  to let test users and your customers install on their own device
  • Wireless distribution of your app outside of iTunes to your select audience

Each option has its benefits and drawbacks depending on exactly what you need.

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.

Let’s go through Kickfolio and TestFlight in more detail:

Using Kickfolio

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:

  1. 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 Trigger.io and follow the get started docs if you haven’t already.

  2. 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.

  3. …. Actually there’s no more steps, it’s that simple. You’ll now have a preview link that you can email to your customers where there’ll see a browser-based interactive demo like this:

  4. It’s cool technology – your customer can have their own iPhone Simulator in the browser where they can try out your app and with no need for them to have flash installed.

Give it a try now by signing up for Kickfolio.

Using TestFlight

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:

  1. 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.

  2. Setup your Apple App Id, Certificate and Provisioning Profile

    You do this in the Apple Provisioning Portal. The Apple Developer Center has good documentation on this process.

    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.

  3. 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.

  4. 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.

  5. Add more users

    That’s it!

    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

What about Android?

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.

That’s it!

If you haven’t already, sign up to Trigger.io to get started with your native mobile app. After all you need to build your app first before you can distribute it to customers to try out!

Have you found other methods that work for you? We’d love to hear about those and get your feedback on these methods. Get in touch at support@trigger.io.