Fastlane to the Simulator

Daniel Larsen
Atlas

--

Ask any experienced iOS developer and they’ll tell you that app signing is the part that smells most of farts. It won’t kill you, and you can get through it, but it’s fraught with inconvenience, anger, and a bit of mystery. That’s why Apple has worked very hard to automate the process, so that for product developers all that’s require is checking one box. And when that box can’t be checked there’s other tools to help relieve the pain.

Because it’s just the worst, we lazy engineers have made enough tools to make complete app signing tolerable. But what about the in-between steps? Just because we can fly from New York to LA doesn’t make it easier to drive to Philadelphia.

The Simulator

From time to time, people like to test code before they send it out. This might be a best practice, I don’t know, I’m an engineer, so sue me. Some people even like to automate their testing.

If you do like to automate your testing on iOS that means you’ll be testing in the simulator. Now how will you do that on builds made to be distributed to an actual device? You know, those fancy builds we were talking about earlier? Those won’t work for the simulator.

No, now you need a new process. This might seem mysterious, but it’s really just kinda doing what you were doing before, but stopping about a quarter of the way through.

In fact, Xcode creates what is effectively a simulator build every time you run a debug build of an application targeted on a simulator device. After running a build targeted on the simulator you can find the simulator build itself in the derived data folder. It’ll look something like: ~/Library/Developer/Xcode/DerivedData/{App GUID}/Build/Products/Debug-iphonesimulator.

But that’s no good. What, are you gonna debug your app each time you test it, pulling out the simulator app for testing like some Philistine? No, you’re better than that. You deserve something better than that. You deserve something automated. And maybe a cookie.

Automated Simulator Builds with Fastlane

I’d say TLDR, but it’s a little too late for that. Here’s how to create a simulator build using Fastlane.

xcodebuild(workspace: "#{workspace}",
scheme: "#{scheme}",
xcargs: "-configuration #{configuration} -sdk 'iphonesimulator11.3' -destination 'generic/platform=iOS Simulator'"
)
zip(path: "./simulator/Build/Products/Debug-iphonesimulator/#{app-name}",
output_path: "./build/#{build-name}.app.zip"
)

So, yeah. That’s about it. There’s a bit to unpack there, as you might expect.

Environment Variables

A few assumptions have been made about environment variables. You’ll have to have things setup just right, like this:

  • workspace — This is the name of the .xcworkspace you want to build. If you’re not using a workspace, you can change the variable to be project:.
  • scheme — The name of the scheme you’re building. This is the text that appears next to the run button in Xcode.
  • configuration — The configuration that Xcode should use to build your app. If in doubt, use Debug.
  • app-name — This is the name of the app that you’re building. You can find this in the application settings in Xcode.
  • build-name — This is what you want the simulator build to be named in the filesystem. It’s useful to append the build number to the app name so you can have a reference to the individual builds going forward.

Behind the Scenes

Fastlane is a great tool, and typically you can sign and package an app with a single command. Something along the lines of

gym(scheme: "#{scheme}", 
configuration: "#{configuration}",
output_name: "#{build-name}")

That is great, but the problem is that the gym() command is the direct flight to LA. It’s too far, and there’s no way to stop it short. That’s why we need to go back to basics. We just want Fastlane to run the xcodebuild command line utility, with the appropriate architecture, and then step away.

Fastlane provides the xcodebuild() command to do just that. Once it’s done, it’s time to zip up the .app (which is itself a directory) and you’re ready to go!

Summary

Using this script, Fastlane will generate a build that can be installed to the automation testing simulator by just dragging and dropping. There’s no code signing needed, so there’s no certificates or provisioning profiles involved. Just run the build and copy and paste the app to the simulator.

And that’s it.

--

--

Daniel Larsen
Atlas
Writer for

I love playing with new tech more than doing stuff with it. Is that a bad thing?