Since iOS app extensions run as part of a host application rather than as part of their containing app (i.e. your app's extensions run in somebody else's app), data sharing isn't automatic. Finding standard locations like the documents directory doesn't work for shared data. In this post I'll go through the details of how to make it all work. Along the way I'll get into how to set up real-time messaging between apps and their extensions. Not Cocoa notifications, but a variation of file-based IPC that includes a notification system. Most of this is not actually specific to iOS extensions, though it's probably more useful with extensions than in other situations. Code snippets are included, and see GitHub for the full project. Sharing…read more →
iOSDevCamp Colorado was a couple of weeks ago and I did a presentation/demo on iOS app extensions. I wanted to focus on how to actually do things, so mostly I worked in Xcode rather than present from slides. But rather than paste code in as I went or (gasp!) try to do it live, I worked from a git repository I had built while developing the demo app. Every time I made a significant change, I'd commit it. During the presentation I would show some of what I was doing at each step and then jump ahead to the next commit to show the completed version. I like the idea but I need to work on doing it smoothly. One nice thing about it is that I can share the project and have it provide more information on the development process. Rather than just…read more →
Recently I've been working on some iOS 8 app extensions, and I've run into a few non-obvious details that might come in handy for anyone else in the same situation. Some of the following relates to bugs still in the system, and so will probably only be relevant for a limited time. Debugging: General The intended approach is simple: when you tell Xcode to run the extension, Xcode will ask you what host app you want to use. That app launches, you trigger your extension on the test device, and Xcode attaches to the extension so you can debug. The problem is that breakpoints often fail to actually pause execution, even if Xcode is attached to the process. Not for everyone, but for some of us. This can lead to paleo-style NSLog-based debugging,…read more →
After my past travails using iCloud with Core Data, I was both interested and concerned when Apple announced CloudKit at WWDC 2014. In this post I'm going to go over what Apple has planned for CloudKit from the perspective of someone wanting to sync app data via some cloud-based means. "Planned" is a key word here, because it's still to early to say how things work in practice. CloudKit vs. iCloud Core Data CloudKit makes a refreshing change from iCloud Core Data in that there's a lot less magic going on in the framework. Using iCloud to sync Core Data is very slick, in that you can essentially treat changes from the cloud as if they had been made on a different thread. Changes get saved, you get notified, and you merge those changes and…read more →
At WWDC 2014 Apple introduced Swift, a new programming language for iOS and OS X developers. Objective-C has had a long and distinguished run with Apple, but times change and we move on. In recognition of this, and in reference to the
[objC retain]; shirts of days gone by, I set up a Teespring campaign to say goodbye-- gradually-- to Objective-C.
[objC release];? Swift is the clear way forward, but Objective-C won't be disappearing right away. In this context "autorelease" implies "release later". Objective-C doesn't disappear right now, but just wait until the end of the run loop...
All profits from these shirts will be donated to App Camp For Girls. (This campaign is not affiliated with App Camp For Girls, I just think it's a good idea).permalink