Life in the Fastlane
Releasing on iOS is no fun. It is time consuming and error prone which makes it stressful. Enter Fastlane, a suite of automation tools for iOS. We gave Fastlane a try and fell completely in love and currently use it for everything we can:
- Sending out an internal build to HockeyApp every time something gets merged into master.
- Run our test suite, lint our Objective-C code and Swift code on every commit to an open PR. Sending out an external beta build to HockeyApp once every 24 hours.
- Build an external build and upload it to s3
- Submitting to the app store.
- Updating the version of our app.
We use Jenkins to run our lanes but to keep things simple all of our jobs look like this:
fastlane submit
Everyone who has submitted an app to the AppStore knows that it sucks. The more complex the app gets, the more it sucks. Archiving on your machine (which takes a lot of time). Making sure that translations are up to date and change logs are set. Doing a lot of regression testing, without having 100 confidence that you are testing the same thing you submitted. The list of error-prone and tedious things goes on.
Our submit lane now does all that for us:
The Submit Lane
The first thing it does is make sure that the head is clean before doing work.
Next up is a custom action that checks out the release branch. Then it merges the current master into that branch. We currently do feature pull requests into master but we submit the release branch. The reason for that is if we need to resubmit than we can just checkout the release branch and fix what is needed and then submit that release again. Meanwhile we still merge code into master for the next release
QuizUp is currently localised into 7 languages, and making a fun change log and getting it translated by 7 different people is a lot of work. We also found that we were rarely put anything substantial in there as we A/B test a lot of our new features. Here another custom action comes to the rescue — prepare_change_log. It takes a new joke change log for each locale, writes it to the release_notes.txt in the metadata folder and fastlane takes care of the rest. We have the list of possible change logs in our git and automatically delete the ones we have used.
The heavy lifting starts once the release branch is up to date with master with fresh change logs. We call the lane submit_ipa.
The Submit IPA Lane
The lane starts by using sigh to make sure that we have the latest provisioning profiles for our enterprise account. Then it builds our beta target with gym and submits that build to our HockeyApp beta group. Checking the crashes in the beta app before we click ‘Release this version’ in iTunesConnect really gives us peace of mind.
Once the HockeyApp beta has been uploaded then the lane uses sigh to check if our main account provisioning profiles are up-to-date. Then it builds the AppStore target and uploads the dsym file to HockeyApp. Finally we upload the build and metadata to iTunesConnect using deliver.
We notify the various members of the company once uploading to iTunes connect finishes. We notify QA and start doing some basic regression testing. We notify our community managers so they can take a look at the change log and update it if they want to notify users about a certain feature. Then we add a git tag and push that.
We have a hook in Jenkins that, once the submit job succeeds, runs a job called bump_version. That job bumps the version on master.
What was once almost a day’s work, checking off a list of some 30 items, is now two steps.
1) Run the submit job in Jenkins.
2) Log into iTunesConnect choose the correct build and press submit. (Once Apple finally finishes processing the build).
Our entire fastlane setup can be found here.
