Last year's main challenge for me was to turn myself into a Mac developer. It had some rough periods, but it also shed some light on details I've always missed to appreciate during the time I was working with iOS. The past year let me understand a lot more about the origins of the platform, where the roots are. When closing the year, I could confidently specify the biggest pain points I experienced compared to the iOS world.

less/outdated documentation community is focused on iOS less third party tooling support

That's why I decided to work on that a bit and made it happen for all the Mac developers out there to enjoy the flawless care of Bitrise.

Continuous integration/delivery

After years of struggle I finally found salvation for the big continuous integration problem. Not every team of iOS developers like the idea of setting up a complex system of Jenkins jobs, solving all the issues with dozens of different plugins. I know teams doing it smoothly, although I'm pretty sure they used black magic to wire it up!

Anyway, my choice is Bitrise, I love the concept of organizing the build flows to workflows of interchangeable build steps, with such a straightforward UI helping people to take the first steps with confidence and without confusion. Exceptional support from the developers and a welcoming community behind them. This is the combination that encouraged me to build the support for Mac projects to this lovely OSS.

Since all of these build steps are already available for iOS, I just had to go through the implementations and figure out what to do differently to make it work for Mac projects as well.

Steps consist of a script and a yml . You can write the script, aka the logic of the step in bash, Go, Swift, or Ruby for example. This step will be interpreted by bitrise through its yml which defines the interface of the step, input and output variables with possible values and such. The metadata of the yml will show up as useful information on the UI of bitrise.io helping others understand the configurability.

Certificates/provisioning

It was a pretty straightforward addition to the existing version for iOS with adding the extension of Mac .provisionprofile .

You can upload your certificates and provisioning profiles in your app's workflow editor under Code signing & Files.

Tests

Adding a test step runs unit tests for your app. In the Mac test step modifications were about wiring up some input and output vars for the xcodebuild command, making it possible to modify the default setup. For example if you would like to test a different scheme, or from a different working directory than your project root.

Testing the step was easy with the offline CLI, I just added a bitrise.yml for my repo defining what should running bitrise do.

A bitrise.yml is basically the recipe of your workflows. Since you don't have the UI of bitrise.io when using the CLI locally, you can describe your workflow(s) in this file. It defines which workflow should run which steps. It's also a diff for each step where you can define values to be different than the defaults for inputs/outputs. If you are looking for an example, it's always a good choice to hit up bitrise.io and check out your bitrise.yml in the editor which is generated based on the workflow editor's content.

Let's see some input vars from the step's yml for a sec:

When it's merged into the steplib and deployed, it looks like this in the editor:

Easy, right? If you disagree, leave me a comment, I'm super curious about others' experience!

Archive/export

The archive step creates an archive and exports an .app or .pkg from it. Running this step will also generate some output variables you (or other steps) can get use of later, like the path to the exported file.

Since Xcode 7, xcodebuild uses an exportOptions plist to collect the necessary information for the export. This plist is built up based on your project's build settings when you export from your archive in the Xcode Organizer and you will have to choose a method how to export it.

So I have to compose a basic plist manually on Bitrise. The minimum information the plist should contain is the method which can be:

app-store , development , or developer-id

I've added the export_method variable for this as an input for the step.

Now the simplest plist looks like this:

For more information about the keys and possible values of the plist can be found at the end of xcodebuild -help .

It is possible to export the app without re-signing it, just select none as the method in case you need that.

Clarification over code signing

There are two ways of distributing Mac apps, in or outside of the Mac App Store (MAS). For MAS distribution, you have to sign your app with a Mac App Distribution certificate and a Mac Installer Distribution certificate to sign the installer. If you are planning to distribute your app outside the MAS, you have to sign your app with a Developer ID Application certificate and for exporting a package, you will need a Developer ID Installer certificate.

Read more about distributing outside the Mac App Store in Apple's docs.

If you'd like to use more than one certificate/provisioning profile in your workflow, just add them under Code signing & Files in the editor and add a new Certificate and profile installer step for them. For more info, check out the article about generic file uploads on Bitrise's dev center.

Analyze

There's an Xcode analyze step on bitrise.io for both iOS and Mac.

Installer

In case you need a pkg to export you have to upload an installer signing certificate and add a step for it as described above. Set the proper method, app-store as export_method .

OS support

Currently, the VMs run 10.10, but you can opt-in to 10.11 as from today, which will be the default soon. If your team needs older OSs please contact Bitrise about the possibilities.

Missing something?

Leave me a comment, drop an issue, or if you feel the power, contribute your own step to the collection. Check out the integrations page first, there are more than 60 steps up there already.

Ping me or Bitrise on Twitter or join the team's Slack for help, issues or compliments, all of these are very welcome. Happy building!