Windmill made continuous delivery of iOS apps accessible by moving away from the idea that developers need to manage and maintain a set of scripts alongside some obscure configuration as part of a toolchain.

Windmill was designed to uphold developers’ privacy and security by not asking them to share their credentials or private keys.

The architecture of Windmill also meant that developers didn’t have to pay for infrastructure on the cloud.

Unfortunately, a developer tool like Windmill is not possible within the Apple ecosystem.

Additionally, with version 3, Windmill can now distribute your app so that you can install it to registered devices. Effectively Windmill helps you take your app from a feature branch all the way to the iPhone.

Individuals

As a developer working on a feature branch, you can take advantage of Windmill whenever you commit, to make sure your code has no errors, your tests still pass, and you have a test summary.

Once the time comes to merge to master, Windmill will ensure there are no regressions as well as enabling you to install your app on a device. Eventually, you will upload to iTunes Connect as you prepare for a public beta or release to the App Store.

Teams

With Workflow, small teams in the same office space, can now benefit from Windmill too. Whereas an individual developer runs Windmill on a development Mac, as a team it is recommended that you use a dedicated Mac to monitor your “master” branch. To make the most of your workflow, you can introduce a “develop” branch in order to have a shorter feedback loop on your way to master.

Conclusion

Workflow changes everything about what Windmill does, where it comes in and how it supports the development lifecycle for your app. I strongly advise you to read the updated Frequently Asked Questions.

I can’t wait to make Windmill on the iPhone available which has been in beta for 3 weeks now and in review with Apple for 13 weekdays.

Whether you are an individual developer or working as part of a team, Workflow is the best opportunity to give Windmill another try and take it for a spin. It is available for free on the Mac.

This is a transformative milestone for Windmill, turning it into a Quality Assurance tool for your development workflow. Continuous delivery of iPhone apps will never be the same again after this.

As always, you can reach me on Twitter, email or iMessage.

Windmill on the Mac continuously monitors for code changes, building, testing, archiving and exporting your app.

Windmill on the iPhone further enables the distribution of your app to registered devices.

On a mission to make continuous delivery of iPhone apps during development both ubiquitous and accessible, Windmill kicks off with an ease of setup, offering an unparalleled user experience, built with security and privacy in mind.

Ease of setup

With Windmill on the Mac monitoring your project, use Windmill on the iPhone to purchase a subscription.

As soon as you have an active subscription, Windmill on the Mac distributes a new build for your application.

You can request to be notified when the new build has successfully been distributed.

Unparalleled user experience

Windmill on the Mac continuously monitors your project repository for code changes and is responsible for distributing new builds.

As soon as a new commit is made, on a successful run, Windmill will distribute a new build for your application.. This ensures that you never end up with a broken version.

Tap the INSTALL button to download and use your application. Windmill will start the process in the background. Once done, your application will be available on the home screen of your device.

Windmill will display detailed information about your application at a glance which can prove useful when you demo or test it.

Windmill also knows when a distribution certificate expires or your application requires a later iOS, giving you useful alerts right on the iPhone when required.

Security and privacy

Windmill uses your Apple credentials to secure your Windmill account and create a seamless experience across your devices. The added benefits are:

• No extra password to remember.
• You remain anonymous to Windmill.

Windmill leans on Xcode and its command line tools to sign, export and distribute your application without going anywhere near your private key and distribution certificate or asking you to share them.

Windmill installs apps only on devices you have chosen to register under your Apple Account. It does not store your Apple Account Credentials.

You can also give time-limited access to install your application by sharing a URL outside of Windmill on the iPhone and delete the build of your application at will.

This Privacy Policy notice describes how data collected and shared with Windmill across devices and platforms is stored, processed and transmitted.

Welcome to a future built with Windmill.

Requirements

• Windmill on the Mac version 3.0.0 or later (macOS 10.14 Mojave, Xcode 10).
• An iPhone with iOS 12.2 or later.
• An Apple Account.

The beta

The beta is invite only with invites going out today. Before you can get started you need to understand a few important details.

During the beta, subscriptions are free but expire in a matter of minutes. That makes the experience bite sized and not representative to that of a continuous delivery.

The beta is meant to be used for testing. Before you decide to get involved, please know that you have to put some time aside.

You also need to be signed in with the same Apple Account on both the iPhone and Mac. If you work in a team of developers as part of an organisation, you should use one common account.

To request an invite, send an iMessage to qnoid@windmill.io

Notices

• Keep in mind this is a beta version of Windmill and can stop working as expected at any time.

Things to try.

• Purchase a new subscription.

  Does Windmill on the Mac distribute a new build for your application?

• Install an application

  Is the application downloaded in the background, installed, and can run as expected?

• See the details of an application by tapping the info button.

  Does everything look ok? Is any data missing or malformed?

• Delete a distributed application.

  Is the application removed successfully from the list? Please note that a subscription may still elapse between deleting an app and refreshing the list. If that happens, purchase a new subscription and refresh the list.

• Distribute multiple applications.

  Use Windmill on the Mac to distribute more than one application. Windmill on the Mac may only monitor one application at a time yet can still distribute many over time.

• Read through the Help sections.

  Is everything clearly explained? Is there a help section you think is missing?

• Purchase a subscription on one device. Restore purchases on a second device.

  Does the second device get access to the applications?

Use it as normal and report back any issues related to reliability, poor network conditions and device specific visual artefacts.

Thank you!

On every commit, Windmill builds the Application bundle as well as the Archive bundle. The Application bundle enables you to run your app on the Simulator, say to use the Xcode debugger to inspect and understand the view hierarchy of your app.

The Archive bundle is used to create your project’s IPA so that you can demo your app with your team and later prepare for a public beta using TestFlight or a release through the App Store.

When using Xcode to build and run your app, a collection of build settings referred to as build configuration is used to package the Application bundle.

To see what build configuration Xcode uses, open the Scheme editor. In Xcode choose Product > Scheme > Edit Scheme…, then select the Run action for the app.

“A build configuration specifies a set of build settings used to build a target’s product in a particular way. For example, it is common to have separate build configurations for debug and release builds of a product.” - Apple, 2011-05-09: XcodeConcepts, Build Settings

By default, Xcode uses the “Debug” build configuration, also used by Windmill, to build and test your app. To see what build configuration Windmill uses, open the Side panel. In Windmill choose View > Side Panel > Show Side Panel.

Equally like Xcode, Windmill uses the “Release” build configuration to produce the Archive bundle. The build configuration used by Windmill for the archive is also visible in the Side Panel.

How does that help?

There are at least two ways to take advantage of using a “Debug” and a “Release” build configuration for the development and release of your app respectively.

1. Conditional compilation

You can use a build setting, one for a Swift codebase and one for Objective-C, that allows you to conditionally compile a block of code.

In Swift that is the “SWIFT_ACTIVE_COMPILATION_CONDITIONS” or “OTHER_SWIFT_FLAGS” setting.

In Objective-C that is the “GCC_PREPROCESSOR_DEFINITIONS” setting.

By default, Xcode sets the value to “DEBUG” for both Swift and Objective-C under your Application target.

You can use this value as an identifier in your code to conditionally compile a code path. As an example, this can be helpful if you want to use a different endpoint during development than the release.

“Unlike the condition of an if statement, the compilation condition is evaluated at compile time. As a result, the statements are compiled and executed only if the compilation condition evaluates to true at compile time. The compilation condition can include the true and false Boolean literals, an identifier used with the -D command line flag, or any of the platform conditions listed in the table below.” - The Swift Programming Language (Swift 4.1), Apple, 2018-03-29: Language Reference, Conditional Compilation Block

2. File management

Some build settings specify a file to be used. A common one is the “INFOPLIST_FILE” setting which specifies which property list file to use when packaging a bundle.

As an example, for NSAppTransportSecurity you want to make sure that any exception rules you have for development don’t leak into your release build. This is the case if your development build uses different endpoints to your release one.

In closing

Windmill’s integration with Xcode’s build configurations gives you the ability to manage the development of your app towards a release in a streamlined way.

Regardless of how much you have a need for the “Debug” and the “Release” build configurations, Windmill uses them to build your app accordingly.

Have a look at Xcode’s build settings to make the most of them for each build configuration.

Share your thoughts, experience and how useful Windmill has been so far to you. How has it changed the way in which you develop, iterate, get feedback and deliver your app?

If you are missing out, what’s preventing you from using it?

Did anyone try @windmill_io yet? It fill an interesting niche for indie devs that do not want to use hosted services for continuous integration. And unlike the Xcode bot mess, I trust @qnoid to actually make it work.

Windmill was released on February 14th so that us, iOS Developers, could have an alternative to Jenkins for automating building and testing our iOS apps.

You can finally use a native macOS app alongside Xcode, which is highly integrated, to continuously monitor for code changes on your git repository, enabling you to always have your app ready to do a demo, public test or release.

Although Windmill requires next to no effort to get started, the initial release did not make it any easier to identify and fix failures than going through the logs. Here is where version 2.0 comes in, alongside many great features to help you with delivering a high quality app.

Build Failures

Windmill 2.0 highlights and surfaces build errors in a familiar way. This gives you a consistent view while debugging. It leaves no ambiguity as to how many errors there are, what these are and where each of them lies.

It is purposely designed in a way so that you do not have to learn new visual cues, communication language or put the mental effort required to associate Windmill errors to Xcode ones.

Since Windmill proactively builds your app for testing, you will get build errors for your test code too.

Test Failures

Another failure that Windmill will highlight is that of a test failing.

At a glance, you will be able to see if and how many tests have failed. In order to help you understand and cross check test failures with Xcode, Windmill will also give you a test summary.

More useful logs

As Windmill goes through your project, it will stop as soon as it encounters a failure. The Distilled Log will give you a more fine grained view of what Windmill was doing at the time of the failure (e.g. compiling a file) as well as a hint on how to fix it.

Simulator support

As part of building your app for distribution, Windmill will give you the option to launch the latest build of your app on the Simulator.

This can be useful when you want to check what your app looks like right there and then. It also enables you to install and run the app on the Simulator without access to the source code.

The app bundle

Each time you commit to master, Windmill will build your app bundle. You can choose to save it under the commit for future reference.

Terminal access

@windmill_io how best to manage dependencies in Windmill, like Carthage or pods?

— John Nye (@john_nye) February 20, 2018

hey @qnoid @windmill_io! Is there a support for projects using cocoapods?

— Viktor Malyi (@victormalyy) February 20, 2018

You can now use the Terminal to bring in any external dependencies (e.g. using Carthage or CocoaPods) to your project as monitored by Windmill. For a How-To, open the Windmill Help menu (⌘?).

Keep in mind that Windmill will not automatically update any dependencies as part of a new commit pushed to master.

What’s stopping you?

It is as simple to get started as opening your Xcode project/workspace. Windmill will also provide support along the way to recover from failures and works with even more project configurations than before.

To be part of an upcoming “Showcase” on the website please send screenshots of your app running on the Simulator alongside Windmill.

If there is anything preventing you from using Windmill or you have any feedback I would like to hear it.

If you are the only iOS Developer at a startup or a freelancer working for a client, please get in touch to better understand how Windmill fits into your development workflow.

You can reach me personally at qnoid under the Windmill domain or Twitter @windmill_io.

Windmill 2.0 lays the foundation for the future. With your support, what comes next is only a matter of time.

One more thing…

Windmill already makes it easy to install your app on a device.

Running your app on an iPhone allows you to see how the app looks and feels. It is a great way to do a demo either 1 on 1 or as part of a team meeting.

However it does require a provisioned device to be physically present, making it less convenient for showcasing small updates, asking for feedback, ad hoc sharing of tidbits with the rest of the team.

You can now record and share a 10 second clip anywhere you can share a video.

I develop on a MBP. Can't imagine using this alongside regular XCode build/run cycles.

@qnoid Also interested on your thoughts as to processor overheads if developing and debugging whilst Windmill is running. Dev > commit > push > dev > commit > push ... is a common workflow for me. I wonder if Windmill might run at inconvenient times and slow this down?

— Sammy C (@dubblewordscore) February 19, 2018

“I commit code quite frequently during the day.”

TL;DR Windmill monitors your master branch. You can utilise it every time you merge and push to master while you keep your existing development workflow on a feature branch.

The goal of Windmill is to establish a process that enables you to:

• know when your app can no longer be released, give you the reasons that hold you back and provide you with feedback/support on how to resolve them.

e.g. build no longer compiles, distribution certificate has expired etc.

• monitor the “quality” of your app through metrics and reports.

e.g. do tests pass? how many tests are there? what’s the code coverage?

• see the “progress” of your app by providing you with an IPA that you can install on a device

e.g. does the “pull to refresh” feature look and feel as expected?

This, among others¹, is the value that Windmill aims to provide you with.

Windmill is not meant to be used while practicing TDD, working on a feature branch (Windmill have since added branch support) or as a replacement to a continuous integration service².

Windmill exists to monitor your master branch for release candidates. A candidate that you decide when to turn into a public release by evaluating what is in front of you.

See also: Frequently Asked Questions

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