Releasing Regular Builds with Trello and TestFlight

In the last post I wrote about the process of reviewing your own work. As I’ve worked on Codename: Instalist there have been some aspects of my workflow that have worked well; others, less so. Here is one I’ll look to repeat…

Planning regular ‘builds’.

Once I reached a certain stage in the development I wanted to start getting feedback on the general feel and usability of the app; feedback on the design elements that I knew I would spend time iterating over.

I’ve been using Trello to track development backlogs for ages now. During this project I changed my workflow slightly. I started planning bite-sized builds that grouped together a bunch of related functionality.

I’d make a new list, call it something like “Beta Build #7”, and when all of the items were done I’d make a new build to distribute with TestFlight.

Trello board for beta builds.

The benefits.

Focus. Selecting work like this has been useful because it made me concentrate on making small, cohesive increments.

My current working schedule is to spend something close to 2.5 hours on my iOS project before going to work; I planned to get one of these build out weekly, which also helped with the focus and drive.

Iteration. This helped me to iterate on parts of the design without getting bogged down. Say I wanted to try some variations on the icon, I’d work on that for a while, select the best, and then put that into the build.

It gave me the feeling of continually reviewing and working on parts of the design, without being consumed with needing to finish it before moving on to the next thing.

Review points. I covered this a lot in the last post. After uploading a build to TestFlight and dropping some notes about what had changed – the process of selecting tasks for the next build formed a useful review point.

Beta tester(s). I pretty much had one person looking at these builds. That’s a small set, but feedback and suggestions from just a single person can be invaluable.

Generally, I found this way of working to be fun. Putting out regular builds made it feel like I had an audience, or customer, as the app was developed. To the best of my ability, I wanted to make something good. This helped.