The CocoaPods App

Managing third party code on iOS has always been a pain. In the past 9 years or so I’ve done everything from dragging source directly into projects, to Git submodules, to CocoaPods, to Carthage, to Git submodules again. Right now I’m using CocoaPods.

I’ve had three problems with CocoaPods from the beginning:

  1. It messes with my Xcode project files.
  2. It stops working for me all the time.
  3. I don’t want to mess around with Ruby gems.

While the first issue seems pretty much intractable, the CocoaPods app seems to (potentially) fix the second two by bundling its own Ruby environment in the app. Because it’s from the people who make CocoaPods, I assume it’ll keep updated to match the command line tool.

The app itself is pretty barebones. I’d love to see a future version let me see what updates are available for my pods from within the app and abstract away me having to edit the podfile by hand. Either way, I’m going to give it a shot. You can check it out on the CocoaPods website.

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:

HomeStorytellerStory

Design

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.

Technical

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.

Conclusion

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.

Moving From Parse to OneSignal for Push Notifications

Parse is shutting down, and if you want your app to keep working, you’ll need to move to something else. I’d recommend doing it sooner than later. Thankfully our app isn’t out for another few weeks, and since the only thing we were using Parse for was push notifications, it wasn’t more than a couple hours of work to switch over to something new. The thing we found to handle our push notifications was One Signal.

Aside from Parse I’ve also used Urban Airship, Push IO, and a custom push server. Custom was definitely the worst. If I were writing the backend myself, custom might not have been so bad, but since I was always working with other developers, it was always a pain because it required involving someone else to test the thing and there was always something wrong with the certificate setup on the server. Out of all of those OneSignal has been the easiest, followed by Parse. I like OneSignal better than Parse though because it’s just push instead of one part of a larger thing that sort of expects me to be using their whole platform.

Email Validation String Extension

I’ve been using this extension on on String to make checking if a string is a valid email easy. If you know a better place this could live, let me know, but an extension on String felt as good a place as any. I didn’t write the original regex (although I did need to tweak it to make addresses with + in them work), but I’ve tested it and it works well as far as I can tell.

extension String {
    func isValidEmail() -> Bool  {
        if self.isEmpty {
            return false
        }

        guard let regex = try? NSRegularExpression(pattern: "^([a-zA-Z0-9_\\-\\.\\+]+)@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.)|(([a-zA-Z0-9\\-]+\\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\\]?)$", options: []) else {
            return false
        }
        return regex.numberOfMatchesInString(self, options: [], range: NSMakeRange(0, self.characters.count)) == 1
    }
}

Less Gross Storyboard Segue to a Navigation Controller

This is a really ugly piece of code I’ve found myself writing in Swift whenever I’m preparing a storyboard segue where the destinationViewController is a UINavigationController whose root view controller is the thing I actually need to set properties on:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
    if let viewController = (segue as? UINavigationController)?.topViewController {
        // Set up the view controller
    }
}

And so I decided to make this slightly less terrible by adding this category to my app:

extension UIStoryboardSegue {
    var navigationController: UINavigationController? {
        get {
            return destinationViewController as? UINavigationController
        }
    }
}

So now that ugly line becomes this:

if let viewController = segue.navigationController?.topViewController {
        // Set up the view controller
}

Brent Harping on Swift Limitations

Brent is harping on limitations you hit when trying to use protocol oriented programming in Swift:

But these days we’re smarter: we use protocols. There’s no reason Folder and File should descend from the same class — they’re almost entirely different, and inheritance is a pain to deal with, so we use protocols instead.

And we’re happy. It works great.

Until you realize that, in Swift, you can’t do this.

I hit something like this yesterday. So no, it’s not just him.

The Growing iOS SDK

David Smith writes about how much the iOS SDK has grown over time. One thing that was interesting is that more “SDK elements” were added in iOS 8 than iPhone OS 2 (which is crazy).

The last paragraph echoes something I’ve felt for a while:

There was a time when I felt like I knew my way around pretty much every non-game SDK available on iOS. Now I often find myself stumbling across frameworks that are completely foreign to me, which is both kind of exciting but also extremely daunting.

I suppose that’s normal. I can’t tell you how often I find out about a “new” API only to realize it’s been around since iOS 5.

Answers Events by Crashlytics

I’ve used Crashlytics for beta testing my new app, including their lightweight analytics-thing Answers. It’s cool in that it shows you the most relevant data, but I was never going to be able to sell it as a replacement for Flurry or Google Analytics (which I loathe). Today they announced Answers can do event tracking, and on top of that it looks fabulous. The web UI makes it really easy to see and add the most common kinds of things I’d actually want to track, and the iOS SDK looks like it was made by people who have written Cocoa before.

Hopefully Twitter can keep from fucking this up.

Fix Broken Swipe to Go Back With Hidden Navigation Bar

Occasionally you need to a show a view controller as part of a UINavigationController stack where you want the navigation bar hidden. Unfortunately, hiding the navigation bar breaks the swipe right to go back feature.

You can fix it by doing this in your viewDidLoad method: