As I write this post, Barback v2.2 has been marked as Ready for Sale in the App Store. There's of course a strange delay between that status and the update actually being pushed out to thirsty iPhones everywhere, and I thought it would be nice to write up a longer, more technical version of some of the changes in this version -- I've been trying to write more about my development process for the app, and this saves me from the anxiety of a massive bug making it past my initial test run (or something like what happened last time.

The Stats

As pulled from GitHub:

  • 68 commits to 73 files
  • 2,682 additions and 4,507 deletions 1
  • 15 new recipes
  • Seven occurrences of me angrily throwing my MacBook across the room due to Optional unwrapping

What's new

Core Data

In terms of actual code change, this is easily the biggest part of the release: the first major refactor of the app since the initial rewrite in Swift, I changed the data backend from basic objects 3 to actually storing them on disk using Core Data. In terms of anything the users notice, this is easily the smallest.

See, I absolutely knew going in that my method of data storage -- throwing everything into a JSON file and just keeping it in memory -- was an awful idea from a technical standpoint. But from a pragmatic one, who cared? I had maybe fifty recipes, and that number was (and is!) never going to scale to a point where it really matters. There's a tiny delay of parsing the files at startup, and then everything is buttery smooth.

But there were still issues, namely:

  • Storing any user-specific stuff required using standardUserDefaults, which while not bad UX just feels sort of gross
  • Adding new recipes requires me to manually and painfully write the JSON
  • I can only publish new recipes by going through the App Store

As of now, only the first issue is solved (the other ones will be addressed in v2.3, as I talk about later.) But going through my (still relatively new!) code gave me a chance to look at the patterns I've already started learning, which was nice.

Core Data, on the other hand, is not nice. It has its perks, but the lack of documentation and general clumsiness of the thing made my pine for a more modern solution. 4 But still, it's done, and I got to learn an interesting facet of the iOS ecosystem.

Revamped search


The biggest UX impact: what was initially set out to be "autocomplete" ended up being a pretty big rearchitecture of how searching handled, from a pretty naive String.contains check 5 to a massive pre-fetch amalgam that breaks down remaining ingredients and is altogether a much more pleasant experience.

From a programming perspective: this was both entertaining and frustrating, since my naive search had been replaced with something that required pretty heavy calculations every time the user enters a character: I was reminded of an initial issue I ran into with my initial Swift port where 40% of the time spent during initial startup was converting a bunch of strings to lowercase over and over again. Even now, unoptimized, the initial search population is by far the most resource/time-intensive part of Barback: the final build is much better, due mainly to clang optimizations, but it's still a reminder in how much a bunch of trivial methods can really destroy an otherwise performant task.

From a UX perspective: There's a growing motif of "Man, I don't know shit". I mean that in a positive way, since this result is like infinitely better than the previous implementation: still, there are no integration tests for intuitive designs. I cannot use the Instrument tool in Xcode and get a usability score with a certain number of significant digits. The decisions which govern how actual people use and receive this app -- who haven't spent hours upon hours looking at this app -- are the hardest ones. But I'm getting better at them. (I think.)

Brand images

Pretty much a tiny update -- now if you click on a brand you get a little popup showing a picture of the bottle!


The big question here was rolling my own versus using a dependency. I ended up going with the latter: RNBlurModalView, which does exactly what it says on the tin. Still, a little part of me cringes when I bring in outside code that I could implement myself, and I'm not a huge fan of the underlying border, so I might end up rewriting this myself somewhere down the line.

What's next

In short:

  • Some moderate design changes to bring the interface more in line with first-party apps
  • Full-on Parse integration to support pushing new recipes 2
  • Programmatically determined ABVs
  • A method for getting and displaying ingredient descriptions that isn't completely awful

I'm excited for v2.3. At some point in October I realized I'm getting a bigger thrill out of this weird state of simultaneous creation and education than most development work I've done in the past: I've got a bunch of marketing stuff that I need to do 6 that I've been consciously putting off because it's just not as fun as sitting down and trying to make the best app that I can, even if there's a lot of deleted code and painful lessons beforehand.

  1. I want a nice way to visualize this. Maybe for v2.3. 

  2. And push notifications ... maybe. 

  3. POSOs, if you will. 

  4. Magical Record appears to be that more modern solution, but my implementation is not yet awful enough that I need to recruit a dependency to help tame it. 

  5. It was a lot more than that, but ultimately it boiled down to looking at strings. Then again, everything boils down to looking at strings. 

  6. App video, Twitter marketing, yadda yadda 

If you enjoyed this article, you should , share it on facebook, or save it on pocket. Thanks!