Announcing Windmill

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 allowed¹ 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:

• check out the code whenever there is a new commit.
• build the app, making sure it still compiles after any code merges.
• test the code, making sure there are no regressions.
• archive the build so that it is always ready to publish.
• export an IPA so that the app can be run on a device.

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 maintain². 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.

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 beginning³ 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:

• using Jenkins just to checkout, build, test your app
• an indie developer
• an iOS freelancer working for a client
• the sole developer in a startup
• developing a side project
• a student
• a teacher

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