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:

Swift NSManagedObjectContext Extension to Delete All Core Data Objects

I made this NSManagedObjectContext extension so that I could delete all of a users data when they log out of the app I’m writing. The alternative was to delete the sqlite file itself and reinitialize my Core Data stack, but that seemed potentially more problematic and less safe.

The two instance methods on NSManagedObjectContext for deleting objects are:

  • func deleteAllObjects(error: NSErrorPointer)
    • Delete all objects in a context. Bails out and returns an error if there’s any problems.
  • func deleteAllObjectsForEntity(entity: NSEntityDescription, error: NSErrorPointer)
    • Delete all objects of an entity type. Bails out and returns if there’s an error.

I also included a convenience initializer for creating a new context with a parent. The way I use the deletion methods would be to create a private queue child context, block out the UI while this is going on with an activity indicator or something, and then call deleteAllObjects(_:) on the child. If there’s an error, you can just throw away the child context, and otherwise save your main context and commit it back to the store. Like this:

Here’s the code for the extension:

Core Data Programming Guide Updated

I’ve used Core Data in most apps I’ve written since 2009, and I’ve felt for a long time is that the documentation was pretty lacking and out of date in a lot of places. I haven’t read it yet, but Apple has updated the Core Data Programming Guide today to “reflect current best practices and APIs.” I’m hopeful that things are getting a little better, but there’s apparently no reference to Swift, so, who knows.

Real-World Testing with XCTest

Kind of old now, but I really like this post from the August issue of The two things that stood out for me was that it used XCTest instead of a third party testing framework, and that it gives real examples of how to approach which tests to write. I’ve been totally totally on board with the idea of unit testing for a long time, but my biggest hurdle has always been knowing what to test. Thinking of what tests to write in terms of Given-When-Then pattern they go over has given me some new ideas.

Trying Swift Again

On my most recent project, I decided to try going Swift from the start. I did the same thing when I started working on a rewrite of the Lovely app around the end of last summer, but found the tools too immature then. This time I’ve spent about a week with it, and everything seems is working out fine (so far). I’ve tried to keep up reading about the language itself, so the syntax hasn’t held me back much. One difference between now and the last time I really dove into Swift is that either something in my brain has clicked regarding optionals, or the language changed a bit over the past six months to make optionals align with my brain more. I still can’t what the debugger commands are.

The other day on Twitter, I was part of a discussion comparing Swift to Objective-C. My feeling is that Swift isn’t better, but some parts of it are delightful to me, and I like it. For example, method overloading in Swift is pretty great, and I’m looking forward to doing interesting things with enums. Better though? In some ways, but not in others. Colin Cornaby pointed out that the ease of dropping down to C in Objective-C comes up a lot, and that C++ compatibility is pretty much a requirement for a lot of apps. I think he’s right.

The way I look at it is this: Objective-C didn’t have to be “broken” for Swift to be a great language. I don’t expect Objective-C to go anywhere in the near future, and that’s a good thing.

Idea for a Web App

All of my experience writing web apps have been to learn or test an idea, or something that I decided wasn’t such a great idea after all. For a long time I’ve wanted to come up with something useful enough to want to publish, but simple enough that I thought I could get it done in a reasonable timeframe as my first project. I think I’ve thought of something.

Neither Xbox Live, Nintendo Miiverse, or PlayStation Network gives you a way to find your Twitter/Facebook friends. What I’m thinking of doing is making a site (probably using Django) which lets you login with Twitter and/or Facebook, enter what someone would need to find you on any of those gaming networks, and then use that information to find your friends who’ve done the same on the site.

I’m imagining that as far as web apps go, this is a pretty simple one. In my mind it’s just social login, a form to enter your Xbox/Miiverse/PSN usernames, some API calls to get your friend lists, and some database queries to match it up to users of the site. Am I missing anything here?

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.

Ninety Days

Justin Williams recommends that you don’t spend more than ninety days on a 1.0. I’m with Brent that I want to see apps that take more than three months to make, but I still think Justin has the right advice.

Some apps are deep, and there’s no way around the time they’ll take to get right. Coda comes to mind. Overcast might too. A majority though — especially on iOS — are really all about one thing that makes it unique and everything else falls out of that one thing.

Don’t ship garbage. Do figure out what your app is really about, do the hell out of it, and then start shipping updates.