When iOS5 came out, over the air (OTA) updates were introduced. They were not automatic though, yet. Come iOS9, automatic OTA updates were introduced, allowing for automatic updating of applications while a user’s device was idle and plugged in.

Blue dot signifies auto-updated app in iOS 9

Of course, automatic OTA updates enraged a few, but for the companies making apps, it was fantastic: with this new feature, apps would be automatically updated at much faster rates, keeping the percentage of users on the latest version much higher. This even further improved the usefulness of fast releases.

With that background in mind, let’s dive into the iOS development team’s options for releasing quickly. To ensure stability in the App Store, any release needs to be tested thoroughly before going out into user’s hands. In addition, and this is specific to the Apple App Store, when releasing apps the timing of the review process must be kept in mind: while recently it has been hovering around two days, it once used to be over seven.

Outside of the review, what exactly constitutes rigorous enough testing on a release candidate build? Realistically, that’s up to the team making the app. There are some obvious metrics to monitor post release, such as usage rate changes or crash free session rate changes, but pre-release processes are where the work starts.

Most development teams will have one or more QA resources. On top of that, many teams use crowdsourced user testing sites, such as test.io. We use this for our releases at Creatubbles. When a project becomes big enough, however, and wants to move with a certain amount of speed, a manual pass alone is not enough.

A manual QA pass is just not good enough!

Test automation is a huge component in releasing applications to the app store at breakneck speeds. When a test automation harness gives enough confidence that any diff the system approves is shippable, that’s a great place to be in.

For any diff to be shippable, however, there needs to be another infrastructure component. Through the use of an experimentation framework, the features being shipped and released to users can be decoupled from the actual code being committed.

When I was at LinkedIn, the system was dubbed LIX, or LinkedIn Experiments. It allowed for feature flags in code, which were then controllable through an internal web dashboard. Of course, LinkedIn is a big software company, so on top of just being flags, LIX allowed for geographic and demographic targeting as well as gradual release.

More importantly, LIX allowed for detailed statistical reports to measure impact of features in isolation, since many feature combinations existed through various LIX configurations.

Without such a framework, each new feature release would be much riskier, and releases just could not happen as fast. There’s just no feasible way to maintain a weekly cadence when unable to properly turn off unstable features. It also would mean a feature would need to be merged in it’s entirety within the course of a release period, impossible for more complex features that evolve with user feedback.

So, combining test automation, automatic OTA updates and an experimentation framework, any iOS team can release on a weekly cadence to the App Store. What are the benefits, though?

By releasing every week, on a fixed schedule, 5 positive things happen:

Critical bug fixes go out on a weekly cadence Add a chance to deliver new user value each and every week Through code & feature decoupling, UX iterations are quicker and validated by actual users Weekly app diffs can only be so big, meaning faster review times since smaller and more incremental Developers know when their work will be live on production

As a software engineer myself, the last point is critical. When a feature takes weeks, and sometimes months to hit production, it is hard to stay motivated to follow up on it’s success. However, when what was built last week is this week getting thousands and thousands of eyeballs, that’s an exciting proposition. An engineer is then more engaged in the release, in monitoring it’s success, and able to see any possible follow up features and tasks that may arise.

Weekly cadence is not for all teams!

Is deployment on a weekly cadence for all iOS teams? Absolutely not. It works for big teams, especially in the social media space. LinkedIn and Facebook both have features going out the door constantly coming from massive development teams. At Creatubbles, even as a startup and a small team, we are well underway towards a release train approach. However, many teams will find this is not in the best interest of their business or their users, in which case don’t do it!

Three weeks, though, is what Creatubbles is starting with. Building a solid experimentation system is tough, and paying for one is hard on a small company’s burn rate, and as such that is still not something we have invested in. It is on the horizon, however, which is very exciting.

iOS11’s new App Store brings more changes, one of which is new updates no longer need to reset your star rating. This is great news for a release train approach. Releases that do poorly can be hidden away, while chaining successful releases does not hamper the accumulation of good reviews.

A regular cadence removes the need for any decision making when it comes to scheduling a release. It shifts the conversation into not when to release a feature, but which release it will be bundled into. The train will leave the station on time, as it should. Is your feature on board? If not, there’s always the next one.

All onboard the release train as it departs

Please share your thoughts on the release train approach, and let me know if you or your team are using it, or not! Thanks for reading. 🖖