Thoughts on iOS build tools

Up until now you had 2 good ways to build and sign your application from the command line:

  • Use the built-in xcodebuild command
  • Use the third party tool shenzhen

Both approaches have their problems

xcodebuild

When using xcodebuild you have to fiddle around with a long list of available parameters:

That's not something you remember and just enter every time you want to build an ipa file. The command above will generate a huge amount terminal output (talking > 10MB). For every source file that gets complied xcodebuild prints out around 60 lines of information you don't really care about:

The best way to fix the output annoyance is to use xcpretty in which you can pipe the xcodebuild ouput.

shenzhen

shenzhen was the easiest way to build your iOS application: It took care of generating the xcodebuild commands to build your application. But instead of showing a clean output while building, it omitted the complete output of the whole process. 

The main issue with shenzhen was the information you received when you run into an error: 

You know what you'd need to do to solve this issue? No, it's not clear, you don't get any information that helps you fix this issue. That's a simple code signing issue, in which the project defines a provisioning profiles that doesn't exist.

shenzhen is a great tool, but hasn't received any updates recently. With fastlane I used a fork of shenzhen to fix some bugs. After a time I decided to build 'gym', a tool which should replace the building part of shenzhen. (shenzhen also does distribution to beta testing services)

Improving the process

In my opinion it's really important a tool does different things depending on the outcome:

  • When the tool succeeded, the user doesn't need a lot of output/information, except that everything worked fine
  • When something went wrong while building, the user should get as much relevant information as possible to make it easy to quickly fix the issue.

Tools should actively help the user resolve common issues. By showing as much useful information as possible and even telling the user how to fix it, a tool automatically becomes much more useful.

Tools can automatically detect all kinds of issues and help the user fix them really fast:

When gym succeeds the terminal output is minimalistic but still shows relevant and useful information while processing

Another important point is being compatible with existing technologies. With gym for example I want the user to still be able to use the Xcode Organiser to distribute the archive or dSYM file

Information

When writing about developer tools I don't want to forget the famous "Fix Issue" button. 

 How can we improve it? 

The most important things a developer tool should do

  • Expose information about what Xcode is going to try when you click "Fix Issue"
  • Show a log of what was tried and what failed
  • If possible show the user how to fix an issue manually

In the example of gym you get every shell command that is being executed printed out so you can manually try fixing something in case the build process fails.

If you need even more information, the you can use --verbose flag.

Conclusion

Besides standard features like sensible defaults and convention over configuration, I think it's important the user knows what's going on with the tool. This allows the users to debug issues themselves. By being transparent you build up trust. Developer see what the tool is doing.

You can check out gym on GitHub: https://github.com/fastlane/gym