At Steamclock, like any other modern development studio, we use a variety of tools to do our work. As we grow and learn better ways to build great apps, we get to try out a variety of languages, frameworks, apps, and services. Recently we’ve had a few folks ask what tool we’re using for this or that, so I wanted to share some of what we use every day.

Code

We build a lot of different software so we use a lot of different languages and environments, but in the last two years we’ve made our biggest investment in Swift. As I wrote last year, we’ve been doing most of our iOS development in Swift for some time now:

The results were blow-away: of roughly a dozen clients, only one opted for Objective-C. Swift became our default programming language almost overnight.

Although Swift is still evolving and this necessitates some project maintenance over time, we’ve found this to be a small cost relative to the size of the projects we’re working on. Overall, it’s been paying big dividends. In production we’ve seen a big reduction in the number of crashes or other runtime issues that users are seeing, and anecdotally we’re shipping new apps faster than ever before.

While we’ve experimented with using Swift on Android, and we’ve had some success with React Native, we still do most of our Android development natively in Java. While Java isn’t exactly a delightful language for app development, the modern Android Studio tools have improved a lot since they switched from being Eclipse-based to IntelliJ-based, and it’s let us ship a lot of high-quality Android apps over the years. That said, we’ll keep experimenting with Java alternatives on Android. One promising option is Kotlin, a modern Swift-like JVM language that’s getting a lot of traction on Android.

Design

Historically we’ve used the industry standard tools for design and prototyping, Photoshop and Illustrator. Recently though, we’ve been spending a lot more time in Sketch and Invision. Photoshop and Illustrator are still great for working with photos and illustrations, but for app design Sketch and Invision give you speed.

With speed, we can either get where we need to be faster, or get more iteration and refinement on a design in the same amount of time. Sketch has been popular for long enough that “Have you tried Sketch?” has become a joke in the design community, but it really does pack a punch.

Ops

It takes a lot of tools to deploy great software. Unfortunately, via the UNIX Philosophy, teams often end up with a patchwork of scripts, under-documented micro-apps, and manual steps cobbled together into some sort of build and deployment approach.

A recent big improvement for us on that front has been using Buddybuild. We’ve been using Buddybuild as the central place to build and deploy our apps. The more apps we migrate there, the less of our time we waste hunting down signing keys, wrangling with provisioning profiles, and generally wasting time getting changes out to testers or the App Store. Buddybuild also has an SDK for crash reporting, which we’ve been trialling in place of Fabric or Hockeyapp.

For hosting we use a variety of tools and services depending on what a project needs. For prototypes we’ll sometimes use a quick Platform as a Service, and for long-term systems we’ll often stand things up on AWS. A lot of our clients are tech companies with proven web infrastructure that need a mobile app, so we don’t spend a lot of our time administering servers – which is probably for the best.

Accounting

We use pretty standard tools for keeping track of our books, Xero and Harvest, and they work well enough. There’s one issue that’s been a big challenge for us though, and that’s been invoicing software.

Everything we’ve tried for invoicing produces unappealing invoices that aren’t customizable enough to meet our (admittedly exacting) standards. Our current process relies on the Harvest API, a custom Mac app, Pages, and a bunch of manual work. The final result is nice enough, but it’s overly labour-intensive to configure and proof. Any manual labour in invoice creation is an opportunity for a typo in an invoice, which is a serious issue. When we do settle on a better system for invoices, whether it’s using one of the suggestions we got on Twitter or building a better custom solution, we’ll share what we’ve learned.

Communication

Projects succeed due to communication more than anything else, so we try to pick our communication tools thoughtfully. Most of these tools aren’t surprising: Slack, Dropbox, Google Docs, Gmail, and so on. One somewhat unusual one, however, is Github Issues.

We’ve long used Github Issues to track bugs, define milestones, communicate with many of our clients, and triage what’s going to go into any given release or iteration. The unusual thing is that even as we’ve grown from 5 to 10 people, we haven’t outgrown preferring Github issues for most projects. In contrast, most teams our size, especially consulting shops, either move to opinionated Agile or Kanban oriented tools, or more heavyweight bug trackers like JIRA.

For clients that already use an alternative issue tracker, we typically work in their systems, so we’ve experienced the strengths and weaknesses of a lot of systems. So far, for the projects we typically work on that involve 2-10 people, Github issues is the least bad system we’ve used.

That said, we occasionally push Issues’ limits, and find ourselves wishing for an extra feature or configuration. Over the next year, depending on how Github follows through with their stated goal of improving Issues in response to the Dear Github controversy, we’ll probably more actively try alternatives for workflow and issue management that let us define a slightly stricter workflow without being overbearing.

Just keep swimming

When we started almost six years ago, it seemed like tools in the mobile development world were moving rapidly. At that time, the rise of variables like PhoneGap, CocoaPods, Backbone.js, and Android made it seem like the right way to make apps was about to shake out.

Today, the tools are evolving even faster. We have new IDEs, new build systems, new services, and even new languages breaking onto the scene. Things may eventually settle down, or maybe there’s something inherent about mobile development that will keep it perpetually moving forward. Only time will tell.