How to approach Continuous Delivery for mobile apps

‍Continuous Integration (CI) — the practice of regularly building and testing incremental changes to your app’s codebase — is probably well understood by you and your mobile team by now. But what should you actually do with these incremental builds? Enter Continuous Delivery (CD), the natural extension of Continuous Integration. The goal of Continuous Delivery is to always have code in a state where it can be bundled, distributed, and tested through a process that’s standardized and automated. A good Continuous Delivery pipeline promotes quick feedback and iteration loops which allow teams to ship higher quality code, faster. In short: get builds in the team’s and testers’ hands quickly and often. As part of a team’s mobile app development process, this means regularly building and uploading a testable app binary to a distribution platform that allows for any number of testers to easily download and use the build. 

Be careful not to confuse Continuous Delivery with the other CD, Continuous Deployment. The latter takes the Continuous Delivery philosophy one step further by encouraging immediate, just-in-time distribution of production-ready binaries directly to your app’s live user base. This practice is actually impossible for mobile app teams, because they rely on third-party app stores to distribute binaries, gating the process and making true Continuous Deployment unattainable. Continuous Deployment is only practiced in the realm of web and backend applications.

There are many benefits to adopting a Continuous Delivery approach, and mobile teams of all shapes and sizes stand to benefit. Here is some of what you can expect:

• Increased confidence in code quality: there’s no need to wait for a production release to test changes with real users and see progress being made
• Increased team-wide visibility into changes: CD makes it possible to share new features as soon as they’re ready with everyone on the team
• Shorter feedback loops: bugs are found and fixed more quickly when more people have access to the most recent changes and up-to-date builds
• Increased developer happiness and productivity: automated CD removes the burden of having to manually generate and share testable builds around, and a well designed setup can save the team from friction and time wasted looking around for the right builds
• Increased confidence in the build process: practice makes perfect – when builds are already being created and distributed regularly and reliably, teams can feel more confident in their ability to quickly ship changes to prod when needed

Implementing Continuous Delivery at various stages of the development and release cycle can be useful for getting feedback from different kinds of users throughout the entire cycle.

For example, something as simple as distributing a testing build to your immediate team any time code is merged into the main working branch means greater visibility into the progress of work within the team. Dogfooding – the practice of distributing a build to a group of testers who can actually use the product in a real way – can be a great way to catch issues earlier because it puts your app in the hands of testers (often employees) who will use it in an intentional way long before it reaches your mass user base. Beyond this, teams may choose to invest in a more formal beta testing program where Release Candidate builds are distributed to a larger group of opted-in testers – usually real users – so they can try out new features for a period of time before they’re made available to the wider user base. By putting builds in the hands of testers throughout the development cycle, your team can benefit from early and varied feedback allowing you to iterate and make improvements more quickly.

Continuous Delivery best practices for mobile app development

So you want to implement Continuous Delivery on your mobile app team, or level-up your existing CD setup? Here are some best practices to help your team get the most out of your Continuous Delivery pipeline:

Start with CI

There’s a reason why CD is often seen as an extension of CI. They work well together because CI ensures that you have error-free, functional builds before you even attempt to distribute a binary; once your CI build succeeds, you can generate and distribute a binary with increased confidence.

Define a cadence

It used to be the case that teams felt it unnecessary to distribute testing builds more than once a week. That practice has recently shifted towards a philosophy of creating and distributing testing builds as often as possible, given your team’s pipeline complexity. Distributing builds multiple times weekly, daily, or even on a per-integration (e.g. per-PR) basis is now the norm on many teams. This sort of frequency has been made easier in recent years thanks to the increased capabilities of cloud-based CI and CD tools.

Automate everything possible 

Testing, build generation, provisioning, signing, deployment and monitoring can all be automated with modern tooling setups. Plenty of open-source options exist to help automate parts of the process, like fastlane.

Measure stability & performance

Having the correct tooling in place for measuring the stability and performance of your app is table-stakes for improving the quality of your app earlier in the release cycle. By empowering your team to easily evaluate the stability and performance of any given build, you can identify and fix issues earlier in the development cycle. And, comparing these metrics against some standardized acceptable baseline that your team defines, you avoid any ambiguity around what makes a build or release “successful” versus not.

Communicate with testers

One of the most important and often overlooked elements of a robust Continuous Delivery strategy is the tester experience. After all, CD can’t help you improve the quality of your app if testers aren’t able or willing to download your app’s beta builds. An important part of the tester experience is open communication between testers and developers. Invest in putting together clear and concise beta testing notes so testers know what to look out for. Make joining a beta testing program a simple process by communicating what to expect both during the setup process, and once they’ve fully joined your testing program.

Collect and act on tester feedback

Some of the highest quality feedback you’ll get on your app will come from early testers. Make sure the process for giving feedback is clear and streamlined, and have a plan for synthesizing the feedback you get into actionable improvements for your app

Prioritize consistency

At the core of the Continuous Delivery philosophy is the idea that by delivering incremental builds continuously – and seamlessly – into the hands of testers, the feedback loop can be shortened and improvements to the app can be made with a quicker turnaround time. Disruptions to your continuous delivery pipeline should therefore be considered highly undesirable, since they break the reliable and tight feedback loop which underlies many of the benefits of CD.

Getting started with mobile Continuous Delivery

There are two primary pieces that make up Continuous Delivery: creating and uploading testable builds, and distributing those builds to testers. When it comes to the first piece, creating and uploading testable builds, most CI providers today already support that, sometimes even out-of-the-box. Where needed, you can build on top of your existing CI pipeline to add CD support relatively easily – tools like fastlane make this possible with just a few lines of extra code.

But in order to add that second piece of Continuous Delivery, the distribution piece, you have to first choose a distribution platform to upload your builds to and serve builds from. Luckily there’s no shortage of great distribution platforms out there, and to help you navigate choosing, we’ll explore some of the most popular options below.

Mobile distribution platforms

When evaluating different distribution platforms, how quickly and seamlessly they’re able to distribute new builds to testers is arguably the most important characteristic to look at. After all, efficiency in the feedback loop is one of the main benefits of adopting a Continuous Delivery philosophy, and any delays in getting new builds into testers hands (e.g. long beta review times on certain platforms) mean longer feedback loops, and slower release cycles. This applies on both sides of the distribution coin: it should be frictionless to push out builds, and it should be frictionless for testers to grab and test those builds.  

But beyond speed and seamlessness, all the rest of the Continuous Delivery best practices discussed above should also be kept in mind when evaluating different distribution platforms. For example, the quality of the tester experience is hugely important: a better tester experience leads to more testers downloading and testing more of your builds, and more testers testing more builds means a higher likelihood of feedback or issues being flagged before a build is more widely released. Many distribution platforms will also have support for features like collecting tester feedback, stability monitoring (crash and error reporting) and basic analytics.

Let’s dive in.

TestFlight

Some people may remember TestFlight as it existed before it was acquired by Apple, but these days it’s widely known as the beta distribution platform integrated directly within App Store Connect. It supports the distribution of builds to individual testers and to groups of testers that can be managed from TestFlight. These testers and testing groups can be “internal” or “external”, and there are some tradeoffs with each. Distribution to internal testing groups can be quick and immediate, but the size of internal testing groups is limited to 100 testers. By contrast, while distribution to external testing groups has a much higher tester count limit (up to 10,000 testers) it also requires the first build of each new version to go through an Apple-managed beta review process. You can invite testers manually from within TestFlight, or enable a public invite link that can be shared around so people can seamlessly join a testing group and start testing your app.

For testers, getting set up for beta testing on TestFlight is relatively straightforward. The TestFlight iOS app is generally intuitive and easy to use, giving testers a place to view testing release notes (“What to Test”) and a quick prompt for sending beta feedback to the developers. Testers can also take screenshots of issues within test builds and send them along with feedback through a streamlined flow. Recently, Apple also released a new TestFlight macOS app, which provides a more intuitive and responsive interface for your team to manage distribution and testers.

Google Play Store

The Google Play Console, in combination with the Play Store, has built-in support for Android build distribution via internal, closed and open testing tracks. Individual testers can be added to these tracks, as long as they have Gmail email addresses. Testers can also be managed by creating Google Groups which are then assigned to tracks. Internal testing tracks are limited to 100 testers and aren’t subject to Google’s review process. The limits for closed testing tracks are much higher: the limit for individual testers on closed testing tracks is 2,000 users, but when using Google Groups to manage testers for closed testing tracks, there are no size limits to these groups. However, both closed testing tracks and open testing tracks are subject to Google’s review process, which can slow down the distribution of new builds to your testers.

For testers, accessing builds is relatively simple.For internal and closed tracks, testers can download new builds directly from the Play Store once they’ve accepted the initial tester invitation email. Distributing builds via the open testing track means anyone can opt into being a beta tester for your app and then can immediately download builds directly from your listing in the Play Store. Testers can easily provide feedback for your app through Google Play as well. 

Firebase App Distribution

Firebase App Distribution is a distribution platform maintained by Google, which expands on features provided by the Play Console and adds support for the distribution of iOS apps as well. Testers can use the Firebase App Tester app to easily view and download available builds to their devices, and integration of an optional SDK gives testers in-app alerts when newer builds become available. Firebase App Distribution limits the number of testers that can be added to a Firebase project to 500, and a maximum of 200 testers can be added to any given app distribution group. Inviting new testers can be done through the Firebase Console, or by enabling public invite links which can be easily shared for quicker onboarding of new testers. While Firebase doesn’t yet have an integrated tester feedback system, it can be seamlessly combined with Firebase’s Crashlytics, Performance, and Test Lab products for advanced stability monitoring capabilities and automated testing suites right from the same dashboard. And, with no formal review process, apps distributed through Firebase become available to testers right away – a huge advantage for teams frequently distributing new builds.

App Center (Distribute)

Microsoft’s App Center (and specifically, App Center Distribute) is another multi-platform app distribution provider with a solid set of core features, making it a compelling alternative to platform-specific options. Beyond iOS and Android, it has support for even more platforms like Windows, macOS and even React Native Code Push. With support for public invite links, inviting new testers is simple, and there is no limit to the number of testers allowed for a given app. One downside is there’s no standalone app for testers, which makes the overall tester experience slightly less streamlined. 

TestFairy

TestFairy caters towards enterprise customers with its increased focus on security and support for less common cross-platform frameworks like Xamarin and Cordova (in addition to the usual cast of iOS, Android and React Native). TestFairy allows teams to distribute any number of internal enterprise apps to a private corporate app store. It provides stability monitoring, in-app bug reporting, and even session recording through an SDK. TestFairy’s free plan includes basic app distribution for 5 apps and up to 200 testers.

Appaloosa

Appaloosa is another distribution provider that caters to larger enterprise customers that have a need for securely managing and distributing a number of custom apps to users – usually their own employees. With the platform, you can even create and customize a private app store from which users directly download new versions of the app and give feedback. Appaloosa also offers support for finer control over the apps installed on users’ devices, with features like remote app wipes and silent update installs for mandatory apps. You can try everything out for free for 14 days, after which pricing varies a bit depending on how many apps need to be distributed and the number of users interacting with the private app store.

Final thoughts

As you can see, there’s no shortage of full-featured (and, often, free) app distribution platforms out there, so adding robust distribution to your team’s mobile practice and really leaning into Continuous Delivery should be a no-brainer. As we’ve seen, implementing solid CDcan shorten and streamline the feedback loops in your app’s dev and release cycles. In turn, your team will be able to find and fix bugs faster, and you’ll be able to iterate on feedback more quickly. Whether just getting started with CD or shoring up your existing process, following some of the best practices we shared above will ensure you can make the most of the benefits on offer. Your team, and your end-users, will thank you for it!