Git Taggin’

The importance of tagging your iOS builds

Photo Credit

What?

Every iOS developer should tag all of their releases. What’s a tag? A tag is a label on a specific Git commit.

A pack of the elusive Git tags, as rendered by the very excellent Tower app.

That looks neat, but why should I bother?

Like many best practices, this one will both save you time and result in better quality apps. There are many use cases where tagged builds come in handy. Here are three compelling ones:

1. So you can actually use crash reports

Crash reports are an awesome tool, but they are useless if you are not looking at the exact codebase version from the crash. By tagging your builds, you can easily checkout the problematic version and troubleshoot the issue.

2. Upgrade Flow Testing

Updating software is boring. Users crave excitement. Sure, iOS has made great strides in terms of automatic updating, but once your app is out there in the wild, there is no gaurantee what version your users will be running.

Seriously, though, have you ever looked around at a concert? The “guy still running iOS 6” is as much of a trope as the “tall guy who stands in front of you.”

Therefore, whenever you release an update, it’s important to test the upgrade flow from all previous versions, not just the most recent one. This is especially important if you’re using Core Data. You need to make sure there are no changes to previously released model versions. I have seen too many apps release updates that have a mistake in, resulting in a flurry of 1-star “they deleted all my stuff!!” reviews.

3. Play nice with iTunes Connect & TestFlight

iTC requires all builds to be a higher build or version number than previous uploads. To make matters more frustrating, you don’t get the error message until after you’ve archived and uploaded the entire package. “Uploading” has become the iOS developer’s “compiling” excuse.

The dreaded ITMS-90188

Avoid this hassle by integrating an automatic versioning tool into your build system.

How?

Automate it!

I’d love to tell you I built this awesome tool that makes this process super easy. But I don’t want to lie to you. I built an okay tool that makes this process easier.

Then I discovered Fastlane, which makes this, and countless other iOS automation tasks, super easy and painless. With a single terminal command,

fastlane beta

I can enjoy this nice, tasty carnitas burrito.

Photo by Jinxi Eats

Meanwhile, the script takes care of the boring stuff:

• Update Cocoapods
• Increment the build number
• Archive
• Commit, tag, and push in Git
• Upload to iTunes Connect
• Release to External TestFlight Beta Testers
• Post in Slack (because who doesn’t love Slack integrations)

You can view my Fastfile here, or my janky Ruby gem (aka “jrem”) here.

Protip

I highly recommend you use the following format:

{label}/{version_number}/{build_number}

The “label” helps you differentiate different release types, such as beta releases vs. App Store releases. The /’s allow Git interfaces to create hierarchical lists. Spoken from experience, it sucks to scroll through 1000s of tags to try and find the exact one that you want, while your coworkers shout from the distance “Use the command line!”

Left: 10 out of 1,791 tags our CI system created, with no hierarchical navigation. Right: A nicely organized, collapsable list.

So there you have it, folks! With a little bit of automation and organization, you can save yourself time and focus on what really matters. Now if you’ll excuse me, that burrito is calling.

Thank you for reading! If you like this article, please take a moment to click the Share or Recommend button so more people will be able to read it.

To read more of my writing, check out my other stories.

Meet Your New Fitness Buddy, Sweaty Bird

Lastly, you can follow me on Twitter, where I talk alot about iOS design & development.

Pat DeSantis (@patdesantis) on Twitter

P.S. — Special thanks to @KrauseFx and the Fastlane team for all their hard work!