How to Optimize Your Workflow for iOS Development

Before switching to iOS development I worked as a web developer, and in the time since one of the things I miss is the feedback cycle involved with writing code for the web. Changes to CSS or Javascript can be reflected instantly in the web browser.

iOS Development is a lot less mature in this regard. Code changes bear the cost of a minimum ~10 second wait time between developer hitting ⌘B and seeing something on-screen. Doesn't sound like much, but that time is enough to get distracted and removed from a flow-like state.

This daily struggle leads me onto thinking more about workflow optimisations, and being pragmatic about where effort should be re-directed. Every developer has this problem in some regard, but depending on your platform, its severity on your ability to be productive is different.

Workflows


Workflows encompass the things we do to get our work from inception to production ready. At the early stages workflows are a private sandbox. Your laptop is customized to you with key bindings, applications and project structure being individual choices. As we get further along, our workflow gets more public, you may create a pull request, share a specification or even (!!!!) organize a meeting.

In the private stages the goal is move fast and break things. I often find myself writing documentation for methods only to delete the method later. Writing the method served a purpose of testing an implementation, the documentation was a little wasteful since nobody had an opportunity to read it.

move_fast_and_break_things

Your private workflow stage should be very enjoyable and creative; there's freedom to learn and make mistakes. But there's a downside: you're in a cave, a dream world. Everything you do in this state should be getting you ready for pushing to future stages of your workflow.

Once we hit the public stages things start to get interesting. In the public stages your goal shifts to iterate and review, while widening the audience at each later stage. We're now placing burden on other people's time, and the asynchronous feedback causes work to slow down.

Iterate, Review, and Audience


I have listed a flowchart of the development process used for the Hinge iOS app. This process should be familiar to any experienced developer so I'll skip over the details, it is used to illustrate 3 concepts in the public workflow: iterate, review and audience.

Each diamond halts the work for review, and iteration. Each successive stage expands the audience

flow

The non-public process here is the first Implement box, and each successive review can also be considered private.

Each next stage is a widening audience, to minimize the cost of review.


  • Pull Request is a peer review performed typically 1 other developer, time allocated: 5 minutes to an hour.

  • Internal QA is a deeper dive into the functionality by 1-4 QA experts, additional time is re-invested each time a new version is available. 100s of hours can be invested over the course of a release

  • External QA is included as production because the goal is to simulate those conditions, but technically still a pre-production. At this stage we rely mainly on analytics tools such as Mixpanel, Crittercism, and other tools to get feedback, and perform the review before the final green light.

  • App Store The widest audience we have, reviews here are by your customers


As the audience expands, getting feedback and iterating becomes more costly so the tools and process change to reflect this. Also work that fails a review is sent back to the beginning.

We utilize automation using Travis CI to give this process a rhythm.

Git versions and Travis build numbers become part of the vernacular when reviewing changes. This is to keep changes fully traceable, our internal version is an amalgamation of each step in the review.

A build uploaded to HockeyApp might be labeled:

Version 3.4.1 (10343.502.274a09f)


The format follows:

Version A.B.C - {external build number}.{travis build number}.{git hash}


  • Version number : What the end user sees publicly in the App store (“3.4.1”)

  • External build number : This number is incremented when submitting to iTunes Connect (“10343”)

  • Travis build number : Incremented for each travis build. Can be accessed using TRAVIS_BUILD_NUMBER environment variable (“502”)

  • Git hash : Short git commit hash git rev-parse --short HEAD (“274a09f”


This gives any internal tester confidence as to what their testing is correct, and if they need additional context there are breadcrumbs to follow.

We can then attach this version to stories in our bug tracking system, making the workflow fully traceable. Again allowing for this traceability helps reviewers to gain context (be it now or in months/years from now) and perform their review with confidence.

So far this worked great for us but we’re always refining it to find the right balance.

One area I’d like to improve is the feedback from our testers in external Test Flight phase. Currently we’re not getting 100% confidence in App store releases, and the soak testing gained from a strong group of Beta testers will help immensely with that.

We'd also love to hear what works for your team and personal workflows! Or get an invite to our beta group by emailing us ios-beta-feedback@hinge.co