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.
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
ymlwhich defines the interface of the step, input and output variables with possible values and such. The metadata of the
ymlwill show up as useful information on the UI of bitrise.io helping others understand the configurability.
It was a pretty straightforward addition to the existing version for iOS with adding the extension of Mac
You can upload your certificates and provisioning profiles in your app's workflow editor under Code signing & Files.
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.
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!
The archive step creates an archive and exports an
.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
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:
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
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.
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,
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.