porting-barback-to-swift
Porting Barback to Swift
Mon, Sep 22, 2014
On Saturday, I finished a project that I started this summer – as you might guess, it was porting my cocktails app Barback to Swift, a task that quickly grew from a weekend line-by-line port into a complete overhaul of the codebase. I had more or less finished it by the end of July – as you can see below, the work leveled off pretty quickly – but Apple was prohibiting Swift apps until the fall.
After pushing out v1.0.1 of Barback in mid-March, I was in a little bit of project ennui: that version worked, and ran, and sold a couple of copies every day, but it was flawed in a lot of ways. The design was passable but flat 1; the functionality was incredibly brittle; every aspect of the code was locked behind a half-dozen awful decisions since this was my first iOS app.
And when Apple announced Swift, I got excited – not only because it looked amazing compared to Objective-C but because it gave me a reason to burn everything down and start again, which is exactly what I did – starting with a fresh Swift project and using v1.0.1 as reference material.
A few months later, v2.0.0 is complete. It’s still not quite where I want it to be, but it’s much much better than the previously released version – v1.0.1 – in literally every way. The design is better, the code is better, the functionality is better. I did a final walkthrough of the two apps before submitting the new version and was stricken by how much more I liked the new version. (If you own the app – I hope you feel the same way.)
What follows is a collection of notes and thoughts that I’ve compiled over this process, both regarding the move to Swift and the rewrite process in general.
You can check out the entire source code for the app on GitHub and purchase it on the App Store. 2
Design
I am never creating an app without wire framing ever again. Being able to look at exactly what I wanted the final views to be, from a high vantage point, made it so much easier to decide how I wanted to structure the code and use shared elements.
If you, like me, will want to fiddle around with font sizes and arbitrary hex colors, do yourself a favor and abstract everything out into easily configurable global constants as soon as possible (and not, say, once you’ve referenced seven different variables of
TINT_COLOR.) Trust me on this.The curse of being a developer first and a designer second: whenever I think of an interesting animation or interaction, my initial thought is about how much effort it will take to implement. This is one of the big sore spots of v2.0.0: there are lots of minor design losses that I’ll spend the rest of 2014 fixing.
Swift
Swift is great. UIKit may never be great, but I love Swift. Even if, at its core, its a vaguely shittier Scala, that’s still great.
There are a lot of pain points in my development that aren’t necessarily unique to Swift but seem as though there should be an easier way to accomplish. For instance, my data store is simple JSON files and I ended up implementing a JSON mapper for each model – a rare instance where I know how to do something much more cleanly and simply in Java. Or the idea that you have to define your own iterator for all values in an enum. Broadly speaking, writing in Swift makes me spend a lot of time thinking there’s a better way of solving certain problems, which is concerning.
Similarly, convenience inits are bullshit.
I wish support for TDD was more of a thing when I started messing around with the initial beta: now that XCTest has been bolstered somewhat, I’ll probably try and go back to gradually add in some unit tests. First-party documentation would be incredibly helpful in this regard.
Features / Product Development
Going into v2.0.0 I knew I wanted to replicate 100% of the original functionality of the app, as well as hit a couple new features. The problem was that those ‘couple new features’ sprawled out into ‘dozens of new things to try out’, which was bad. After a certain point I had to just baseline stuff for 2.0 and then keep the non-vital stuff on the back burner – after some time, I ended up pushing a lot of 2.0 stuff, like iPad support, to the indefinite future. I suddenly have much more sympathy for my manager.
The pace of pushing things to the next version increased as I more fully realized the inherent value of “this looks better” and “this runs faster” and “no, really, this looks much better.”
I used GitHub Issues as a task management tool, which turned out great – it’s pretty perfectly minimal for a one-man project like this, giving me the ability to tag stuff and add details and generally get the hell out of my way.
Currently sitting at 16 open issues and 32 closed ones 3. I prioritize bugs over accessibility over features over everything else, which means that my migration to Core Data will probably never happen.
Misc.
It’s not really related to the port itself, but I realized that I need to get better on the marketing/PR side of this, which will be a learning experience in of itself. Sales quickly dropped to a low drip after the initial launch – after the first month, the peak day was with ten sales, since apparently a bar in Montana forced it on their employees.
A side effect of spending many evenings staring at cocktail recipes is that I have a newfound addiction to Suburbans 4.
As I was writing the above footnote, I said to myself: Hm, there really should be an easier way to share recipes from the app! So, yeah, make that 17 issues.
Building stuff is really, really fun.
Alrighty, thanks for reading. Time to work on converting my tab bar icons to code-generated vectors.
- And not in the hip, trendy way. [return]
- It’ll help me pay for the guac at Chipotle. [return]
- That 32 would be much larger except I only switched to GitHub once I had a bare-bones recreation up and running. [return]
- Rye, dark rum, and port.
[return]
You should follow me on Twitter and subscribe to my newsletter.