My New Podcast: The Run Loop

The first episode of my new podcast, The Run Loop, is now available in iTunes, Overcast, and wherever else great podcasts are found. You can also listen and subscribe on the shows website. The Run Loop will be a weekly discussion about making iOS and Mac apps with great designers and developers. In this episode I talk to my friend Samuel Goodwin about how he got started, peer mentorship, our trip to Japan, and more.

If you like what you hear, please subscribe, rate, and recommend the show.

You can also help support the show through Patreon. If you donate $1 or more a month, you will receive my sincere gratitude and help me make more and better content, but up to five people can also donate $50 a month and receive an hour a month of my time for a design or code review.

I also want to thank to Joe Cieplinski for creating great artwork for the show. I hope you enjoy this first episode, and I’m looking forward to making many more.

Creating StoryWorth for iOS 1.0

I’m really excited to announce that a new app I’ve been working on for several months has come out today. The app is called StoryWorth, and you can download it now. It’s a companion to the website of the company I work for. StoryWorth lets you collect and share (with recipients you choose) your family stories. To get started, you invite a storyteller (mom, dad, grandma, etc), and then we start sending them questions. They can answer through the app, email, or on the website with text, images, or audio. Once you’ve collected some stories, we can print them up in a nice book (you can pay to have audio transcribed) you can put on a shelf and keep forever, regardless of what happens to us. I should mention too that StoryWorth is a paid service. We’re not interested in showing you ads or selling your information.

Oh, also, we have an app now. It looks like this:



For the design, a big focus was accessibility. We have users as old as one hundred, so we could be pretty sure some of the people using the app would have limited mobility or vision. The default sizes for text in the app tends to be a little on the large size, but I also did my best to support Dynamic Type so that users who needed to could turn up the font size. I’m looking forward to taking the accessibility stuff even further in future versions.

Aesthetically, we wanted to go for sort of a book feel, while still looking cool and app-like. We did that mostly by focusing on typography and restricting the color palette so that the content and actions really stand out from each other. We use a sans-serif font (Lato) in our primary red color (except in navigation and toolbars) for actions, and a serif font (Merriweather) for most content and long form text entry. Overall I’m really happy with how the design of the app turned out.

When choosing what features the app would have, our goal for 1.0 was to get parity on the most important things (writing, reading) with the website. It’s not completely one for one yet, but it’s an awful lot of it. Having a solid basis of a native app is also going to let us do things that the website can’t do easily when it comes to things like recording audio, offline reading.


StoryWorth is the first app I’ve shipped that’s entirely written in Swift. In the beginning, learning Swift while writing the app probably slowed me down a little bit, but it didn’t take me very long to become productive. At this point I feel completely comfortable in Swift and think I made the right decision. Swift still has some rough edges, but there’s enough good there to make it an overall win. Mostly the problems I run into have to do with using it with the iOS frameworks, storyboards, and other things that came around before Swift existed.

Speaking of storyboards: I don’t know, man. I used them, and I guess they made things easier, but I also sort of want to tear them out half the time. I hate how they’re stringly typed, I hate prepareForSegue:, and I hate how using them pretty much precludes being able to use non-optional properties in my view controllers. On the upside, they’ve improved a bit over time. Storyboard references make it easier to break up a big monolithic storyboard into many smaller ones. Setting up child view controllers is really easy in a storyboard too. I only used a static table view in one place, and it ended up needing some cells to show or hide conditionally, so that wasn’t especially useful. As cool as that is, it turns out I never end up having more than one or two static table views in an app.

Going back to Dynamic Type, there’s a couple of things I did to implement that. The first was to create UILabel subclass which listens for content size category notifications and adjusts itself as needed. This worked pretty well for pretty much anywhere I had labels, but not for some other things. Dynamically sizing table view rows were also a godsend, since all I had to do was set up my constraints and the table view would do the right thing if the font of it’s contained labels got bigger. Overall, I found working with Dynamic Type sort of a pain when it comes to native views. I’d like to come up a better solution in the future that will make it easy for me to support it in the places I didn’t get to in 1.0.

I do use web views in a couple places in the app though, and it turns out supporting Dynamic Type in those is crazy easy. All you have to do is use one of the -apple-system styles for your CSS font property, set font-family and font-size (in em) to whatever you want. Make your controller listen for UIContentSizeCategoryDidChangeNotification, and whenever a notification comes in, reload the web view. Easy. There’s a good post about it on the official WebKit blog.

Grab Bag

  • UIStackView is rad.
  • Protocol extensions are neat and useful.
  • The new Swift selector syntax doesn’t like nil targeted actions.
  • Carthage breaks much less than CocoaPods for me.
  • I love universal assets.
  • I don’t know if I’m going to stick with Core Data.
  • Color spaces are confusing.
  • App review remains a magical experience.


I took a job at StoryWorth because I wanted to work with nice people on something that’s actually useful, whose business model I understood, and where I could have a big impact. It’s been a while now, and I really like it still. I’m excited to improve the app over the next several months. Please download the app and invite your family. There’s a free trial, and if you decide to subscribe it helps us a lot. Getting to know your family and having something to hold onto forever is something you’ll thank yourself for.

Updating an iOS 6 App

Been working on a new version of an app of mine called Closeby that I haven’t touched since iOS 6.

A few thoughts about the process:

  • My design taste has come a long way in the last two years. Some features in I remember spending time on that now I can’t imagine why I’d want them. Others I didn’t do then seem obviously necessary and I have no idea why I didn’t.
  • I really like iOS 7+ style design.
  • I’m a lot better at programming than I was two years ago. It’s not awful, but there’s code in here I’d never have written today, and it’s nice to see than I haven’t stagnated.
  • Cocoapods can be a pain in the ass, but it’s still the best bad choice.

Maybe I’ll post some before and after screenshots when I get a chance to work on it more.

Band App Diary #1: Initial Design Thoughts

If you read this blog lately, you know that I have (am) a band called Fisherman’s Porch, and that I’ve been making music for a long time. One idea I’ve had for a while has been to somehow combine my app making and music skills in an interesting way. I’ve also wanted a reason to do something with development that would give me some real world experience writing server side code. I’m going to follow Brent’s footsteps and put all of my design and code thoughts out there, so that hopefully I can learn something from the feedback I get.

The other day when I posted on Twitter that I was trying to think of a side project I could use Microsoft’s Azure Mobile Services to write a backend for and Nick Harris responded with this:

@collindonnell write an app for your music with a blog like feature talking about the songs.

This seems like the perfect project to try this out on for a few reasons:

  • There aren’t thousands of Fisherman’s Porch fans out there (yet!), and it’s not going to be storing a bunch of peoples important personal data, so I can experiment as much as I like with the design and backend architecture.
  • It’s not an idea anyone can “steal,” so I don’t have to be secretive at all about creating it and blog about the whole process.

An App Worth Downloading

I don’t want to make an app that’s just a static advertisement for my music, because no one will download it, and if they do, they won’t keep it. Plus, designing an app like that just isn’t as interesting to me. I want to use this to stretch my design muscles and see what I’m capable of. Ultimately, the hope is that the app could somehow get people who would have otherwise never ever heard of Fisherman’s Porch to become interested, and people who are interested to stay that way. If you think about how stupid most apps that are created to advertise different brands and whatnot actually are, it’s a pretty big goal.

So, I think it’s got to do a few of things to have a chance at achieving that. First, the content can’t suck. If my music and other things I put into it are lame, it doesn’t matter what I do. I’m going to take it as read that my content can’t suck. Good content alone is going to be enough though. There’s tons of bands with good songs no one cares about.

The second thing is that it’s got to be fun to touch and look at. The UI has to be great. It can’t look like a list of songs in the Music app. For the kind of apps I’ve created in the past (productivity mostly), I’ve gotten a lot of mileage out of “what would Mail/Contacts/Music do?” as a starting place. If I were a famous rockstar, that might fly, but I’m not at all. It has to feel like something special.

The design also needs to look full with the amount of content one person (me) can put out. If I had a table view of six songs, another separate photos view with a few photos, and a videos list with two videos on day one, that’s going to look empty. Instead of a tab bar app with a separate tab for each of those things, or some kind of table view based navigation hierarchy, I’m thinking a single feed that has everything in it. If you want to just listen to my music, you can do that in this app, but the main purpose of this app is to find out what Fisherman’s Porch is up to right now. The types of content I can think of right now are:

  • Music.
  • Videos.
  • Photos.
  • Content from social networks like Twitter, Instagram, etc.
  • Other links to things like blog posts.
  • Shows.

On the technical side whatever I do should also accommodate the possibility of me coming up with new types of content in the future. I don’t know what those are yet, but I guess that’s kind of the point. Out of all of those types of content, shows are the one that I think deserve their own special view. Giving shows their own view gives me a nice place to put things like getting a push notification if I’m playing a show nearby or requesting a show in your area. Requesting a show could be as simple as a single button. I’d store the location on my server and if I see a bunch in one general area, I can find out about booking a show there at some point.

Inside of the feed list, I think it would also be nice if people could comment on items that show up there. Review a show, give feedback on a song, that sort of thing. Of course this is the perfect place for trolls to tell me that I “totally suck, lol,” so I think before someone can leave a comment I’d ask them to authenticate with either Twitter or Facebook to remove some of the anonymity. If there’s a way to do it without being a total tool, it might be cool if I could use that as a chance to ask them to like/follow Fisherman’s Porch. I’m thinking more like a checkbox which is default off instead of an alert view that pops up in their face after they log in.

Other random things the app could maybe do that might be cool:

  • Notifications for new content. If this is annoying people will just delete the app though, so I might have it somewhere that people have to turn on instead of just on for everything by default.
  • Passbook passes for shows. Maybe.
  • Have some basic analytics so I know which songs get listened to the most or the general geographic region people who listen to my music are in. Nothing creepy, but it would be useful to know if I have a big cluster of fans in one area when I go to book a show there.

I don’t know if all of this will make it into the first version, but I’m kind of excited about this app as a place I can try new things. Since I’m already over a thousand words into this post, I think I’ll take a break and collect my thoughts on what’s all going to need to happen technically.

10 things designers need to know about iOS 7

Really good article that covers most of the high level changes in iOS 7 that designers need to be aware of:

We’ve scoured Apple’s Transition Guide and picked out the 10 most important considerations for designers. Read on to find out what you need to know about iOS 7 and how it will necessitate changes to the way you present your content.

You can read the entire thing here.