Announcing Windmill

approx. 5 minutes read

Background

For far too long us iOS developers have relied on Jenkins to, at the very minimum, automate checking out, building and testing our iOS apps.

Apple realised the need and in 2014 introduced Xcode bots as part of Xcode Server. In 2017, Xcode bots became part of Xcode bringing automation to the development Mac rather than explicitly requiring setting up a server.

Numerous cloud based services are also available that mirror Jenkins in terms of their offering when it comes to building and testing iOS apps.

Where are we today?

Jenkins

Jenkins appears to be the market leader according to MacStadium’s survey and anecdotal evidence seems to back this up.

Even though Jenkins is a generic “automation server”, its open source nature and plugin architecture has allowed1 the iOS community to provide support for iOS apps.

Setting up Jenkins requires considerable time and effort. It also assumes you are familiar with Apple’s Command Line Tools and feel comfortable using, what looks like, an ops tool.

There is only so much integration Jenkins offers with the rest of your iOS development process. Namely, any test devices to install your app to, or Xcode for App Store and Testflight distribution.

Xcode bots

Xcode bots, almost 4 years later, hasn’t challenged Jenkins.

Xcode bots is a native offering, with out of the box support for building and testing your iOS apps. Going as far as providing both IPA and archive files.

It only takes a few clicks through a series of dialogs to setup, guiding you through the process. Before long, it will monitor for code changes, build, test, archive and export your app. It will even publish the IPA on a web server running locally so that you can install it on a device over the air.

Cloud based services

Cloud based services don’t seem to be focusing on iOS development. The exception being buddybuild that has recently been acquired by Apple.

Cloud based services typically mirror Jenkins and offer a scalable infrastructure. They too provide automation but typically leave it up to you to set them up.

As a result, like Jenkins, they require you to have knowledge of the tooling so that you can put everything together.

Unlike Jenkins, they don’t come “free”. Instead, limiting the work by some combination and factor of time, users and builds.

Should you wish to create an IPA and/or an archive you are expected to share your Apple account credentials or at the very least your signing certificate and private key.

Last but not least, access to your source code is mandatory.

Where does Windmill fit into all this?

At a bare minimum, an automation tool for iOS development must be able to provide support for the following scenarios:

Windmill does all the above as a native macOS app, built on top of Apple’s command line tools, taking into account existing conventions and development practices as defined and established by Apple.

It is designed to be at opposing ends to Jenkins by being easier to setup and maintain2. Also aiming to provide an “out of the box” level of integration paralleled to that set by Xcode bots. It offers support for all scenarios listed above as a standalone macOS app for free.

comparison

Windmill aims to bring a basic level of automation to building, testing and distributing an iOS app in a way that is both accessible and made ubiquitous to every iOS developer.

To achieve that, Windmill relies heavily on existing conventions as set by Apple and aims to establish a best practice on how to automate building, testing and distributing apps. At this stage, what Windmill is able to achieve and to what extent is defined by Apple. There is no way around it. This is a conscious decision. To pretend otherwise would be to rely on reverse engineering, side effects, undocumented features and observable behaviours. For bringing that basic level of automation it should be enough.

Windmill is not meant to be customised at this stage and definitely not in a way of writing and maintaining scripts. It is a slippery slope that leads to complexity, overhead and creates a dependency to those few people writing the scripts. As a result, there is currently no support for using third party tools or integrating with third party services.

Windmill takes its first step, looking into the future.

It is time iOS automation takes a leap when it comes to delivering apps. Not by zealously automating every step and integrating end to end. But by bringing sense, establishing a common understanding across iOS developers and businesses through a platform that focuses on what the goals are.

To safely make code changes. To have an app that runs on a device. To have a build ready for in house testing. To be ready for a demo. To have visibility on business metrics.

It is fair to say that this is just the beginning3 of Windmill. A humble, yet determined entry to make a mark in a crowded market with big players.

Windmill should be able to cover your needs today if you are:

If you are indeed any of the above and there is a use case preventing you from using Windmill, I would like to hear it. You can reach out by posting to qnoid at windmill.io or on twitter @windmill_io


  1. With Apple’s blessings by offering command line developer tools. 

  2. There are no scripts to maintain and Windmill is, by design, only using the public, documented functionality of command line tools. Any breaking changes due to Apple updating the command line tools (as part of an Xcode upgrade) can still occur to Apple’s discretion. At which point, an upgrade to Windmill will be required. 

  3. Windmill recognises that as a business grows, so does the complexity around delivering apps. As Windmill evolves, accessibility and ubiquity remain strong anchors.