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 objc.io. 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.


Alamofire is a new networking library — written in Swift — from the creator of AFNetworking. So far I’ve just read the post on NSHipster about it, but I like what I see. It’s not a value judgment, but something AFNetworking has never quite sat right with me. This looks very lightweight and more like something written to be idiomatic Swift rather than Objective-C in Swift’s clothing.

Vendor Unique Identifiers

I haven’t needed to get a unique device ID since before we stopped being able to use -[UIDevice uniqueIdentifier] until today. Apple added the method -[UIDevice identifierForVendor] in iOS 6 which totally replaces the old method for any of my needs.

What the method does is give a unique ID for any apps from the same vendor on a given device. The part which might be a little confusing at first is that “vendor” does not mean the same developer account, but instead means any apps where the first part of the bundle identifier (CFBundleIdentifier) is the same. So com.collindonnell.myapp and com.collindonnell.myotherapp would get the same identifier, but com.albinadevelopment.anyapp would not.

Objective-C Without the Smalltalk

This is a really good post lamenting some of the direction Swift has chosen to take:

Gone is the dynamic nature of ObjC; it has instead been replaced by a rigid, generic based type system. I know the world of C++, Java, and C# programmers have rejoiced. Myself, having worked in Visual Studio building tools for .NET and Windows developers for many years and leaving that for the world of Cocoa and ObjC, I am greatly saddened by this turn of events.

Objective-C without the C is a worthwhile goal, but I don’t think anyone was asking for Objective-C without the Smalltalk. I’m still learning and planning to use Swift, but I think dividing into pro-Swift and anti-Swift crowds is probably too narrow of a view. Both languages are better and worse in different ways. It’s going to be up to us to learn those differences.