For the last few months I’ve been working, as part of the mobile-apps team, on building a new version of the Songkick iPhone app. We’ve been busying adding some new features, including a complete UI redesign (to bring the app more inline with iOS 7), better ticketing integration, and the ability to scan your Spotify library to import your favourite artists.
We launched a couple of weeks ago, and were lucky enough to be picked as the “Editors’ choice”, as well as being featured in over 200 App Stores. Check it:
Some things I’ve learned along the way:
- iOS 7 promotes the use of native controls without customisation. This is a really nice way to develop apps, as it removes the need to add custom gradients, shadows and styles throughout your app. However…
- Converting an existing app to mirror the iOS 7 look-and-feel is quite a lot of work. At least, it was in our case. The upside of this was that we removed a whole bunch of redundant design code. You can get an idea of the UI changes with these before and after screenshots:
- You need a convenient way to distribute development builds. We use TestFlight. It’s got great integration with OS X and Xcode – archive your app in Xcode and TestFlight will automatically detect and prompt to distribute it. The service occasionally suffers from the odd outage, but for the price of free, we really can’t complain.
- Super-users are really important. We have a small group of super-users who help test development builds, and provide us with bug reports and general feedback. These guys are awesome, and really have helped shape what the final production build became (as well as helping improve stability on the way!). I regularly interact with our super-users over email, and we send them Songkick swag to let them know how much we love ’em.
- You need a crash-reporting solution. We use Crashlytics, and to be honest, I have no idea how we survived without it. It’s a crash reporting library, which may not sound terribly exciting, but it’s definitely something you can’t skimp on. Crashlytics has the smoothest install and setup “wizard” of any application I’ve ever used – we were setup and running in no time. The crash reports are detailed and well presented (grouped by version and number of users affected), and it makes finding and prioritising bug fixes really easy. We no longer have to wait for users to complain over Twitter or App Store reviews to start working on bug fixes (or know of their existence). In addition to this, their support team are crazy-responsive and really (really) friendly. Just go get it.
- Tests, tests, tests. We have unit and acceptance tests, as well as code analysis tasks, that are kicked-off after every Git check-in. Our setup consists of an OS X server running on a dedicated Mac Mini, XCTests and Xcode bots. We submitted our app for review around the same time as the new version of Xcode server was released, so unfortunately most of the following was setup after the latest Songkick app went out the door, but it’s still worth an honourable mention. The latest version of Xcode server introduces bots, which are processes that run the analyse, test and archive steps for a selected scheme any time you push code to your repository. In true Apple style, it also provides a shiny dashboard to display the results:
- Use Automatic Reference Counting. We’ve been working to convert our Manual Reference Counting (MRC) app to use Automatic Reference Counting (ARC). We’ve spent time with this release converting existing MRC-based classes to ARC. I’m grateful to MRC for teaching me the finer details of memory management in Objective-C, but now I’ve learnt that, ARC is a joy to work with. Classes are shorter, much more readable, and less likely to have memory leaks.
If you haven’t already, you can download the lastest version of the app here. Let me know what you think!