Category: <span>CocoaDev</span>

My friend Brent Simmons has recently written a series of blog posts—seven parts so far—on How Not to Crash, for Cocoa and iOS developers. Brent is an experienced and thoughtful programmer, and these are well worth a read. Most are probably useful even to programmers working in other languages.

Check them out!

How Not to Crash #1: KVO and Manual Bindings
How Not to Crash #2: Mutation Exceptions
How Not to Crash #3: NSNotification
How Not to Crash #4: Threading
How Not to Crash #5: Threading, part 2
How Not to Crash #6: Properties and Accessors
How Not to Crash #7: Dealing with Nothing

Update: Brent added two more How Not to Crash posts since I originally wrote this:

How Not to Crash #8: Infrastructure
How Not to Crash #9: Mindset

… and wrapped them all up in this post on

CocoaDev Development Uncategorized

My long-time friend Brent Simmons has been pretty prolific on his blog recently — sadly me, not so much. (I’m working on it.) Monday, he wrote a response to Marco Tabini‘s Macworld article, Why you should care about CloudKit:

“While it’s technically possible to use the public data for group collaboration, it’s only the code in the client app that enforces this. CloudKit has no notion of groups.

“It would be irresponsible to use the public data for private group collaboration.

“Neither of the two apps mentioned as example — Glassboard and Wunderlist — should use CloudKit.”

I completely agree, and actually the question of whether Glassboard (or Twitter) would be possible to build with CloudKit, was the source of some discussion among some of the folks with whom I attended WWDC this year.

CloudKit doesn’t actually provide any mechanism at all for natively declaring that person X and person Y have access to resource Q (and noone else does). It provides the ability to securely and privately store some data for a single person as associated with an app -and/or- to store some data that’s available to everyone who is associated with that app. That’s it (mostly).

It’s possible separately via a web portal (not programmatically as far as I know), to configure a subset of data to be editable only by specific people, but the idea is more about providing a way for the maintainers of some data resources to update that data, than it is about providing a mechanism for users to create ad-hoc groups among themselves. (i.e. dynamic configuration data that’s loaded by the app at launch.)

While this is a super useful feature, the value of which hasn’t really been called out much by the iOS dev community, it is not what Marco Tabini described. (I can see how the misunderstanding arose though.)

But can’t I do groups on top of CloudKit?

Seems like a reasonable question, right? Why not leverage the lower-level infrastructure that Apple is providing, and implement the security over the top of it? Bad idea.

While it’s probably be theoretically possible to integrate an encryption library and set up a mechanism for building and maintaining groups that is actually private and secure — on top of Apple’s CloudKit service, this would be a terrible idea from a security, testability, and code maintainability perspective.

First there’s the issue of bugs and vulnerabilities in the encryption library you choose to include. I’m not saying anything specific about any particular open-source or licensable encryption code or algorithm, but this is a notoriously difficult thing to get right, and encryption is under constant attack from every angle you could imagine. The world’s government intelligence services and organized crime syndicates are almost certain to do a better job hacking these things than you (or the maintainers of the open source code) are going do at protecting your users.

Then there’s the problem of an external dependency keeping up with changes to iOS itself. Let’s say for example that two years from now you want to move your code to Swift, but you’re dependent on an open source project that hasn’t been updated to work either with Swift or with ObjC in the latest version of iOS. Guess what: You’re now in a holding pattern until either (gasp!) you port or patch the open source code, or someone else does. That’s a dependency you don’t want to take.

Then there’s Apple. It seems likely (and I speak without any insider knowledge at all) that at some point Apple will start to add group collaboration features to CloudKit itself, to its successor, or to some higher-level service.

Now you have another horrible choice to make: Do I continue to bear the burden of technical debt that comes from having rolled my own solution, or do I hunker down for six months and port to the new thing? And how do I migrate my users’ data? What’s going to break when I have a data migration bug? How am I going to recover from that? Where’s the backup?

(Brent also made the excellent point that if you want your users to be able to get to their data from anywhere else besides their iOS devices, CloudKit isn’t going to get you there right now.)

Architectural decisions should not be taken lightly

I’ll say it again: Architectural decisions should not be taken lightly.

You have to think deeply about this stuff right at the beginning if you want your app, your product(s), and your company to succeed over time. The big design decisions you make early on will have a lasting and possibly profound impact on what happens in the long run…

… And, when it comes to privacy and security, we almost never get second chances. You should fully expect that a breach of trust, whether intentional or not, will be met with revolt.

Looking at the situation from 30,000 feet: Would you rather go with a somewhat more difficult solution up-front, one that came perhaps with some of its own problems, but which solved the privacy, security, and platform-footprint issues right now?

Or would you rather build something you don’t fully understand yourself, on top of a service which isn’t really intended to do what you’re forcing it to do?

Just sayin’…

CloudKit is very promising

For simpler scenarios, CloudKit is going to provide a ton of value. More than likely, the service will meet the needs of a huge number of developers… with some caveats:

  • It’s Apple-only. You’re not going to get to the web or Android right now, and no promises at all about the future.
  • Access is public or individual. There’s no good way to deal with groups right now.
  • You can’t write any server-side business logic. It’s purely a data store, and that’s it. This might change in the future, but don’t bet your business or livelihood on it.

Those are the big ones. There are almost certainly others, including pricing, resiliency, backups, roll-backs, etc.

Cloud-based data storage is a huge and complex field. I for one am very happy to see Apple taking a methodical and measured approach to it this time around. But that inherently means we have to live within its limitations.

I’m confident that CloudKit is the right approach for a lot of developers, and mostly confident that it will work for those developers and not fall on its face. It’s not the end-all and be-all that some folks would want it to be. And frankly I’m glad it’s not trying to be.

Cloud CocoaDev

Here’s a discussion on StackOverflow about how to fix the “stutter” or “slow start” playing back a sound on iOS using AVAudioPlayer:

Basically there are two recommendations – preflight the player by playing a very short “silent” sound (on another thread), or calling [audioPlayer prepareToPlay].

It seems like the main cause of the hiccough when first playing audio is firing up the audio hardware and allocating playback buffers. Apple’s documentation seems to confirm this between the lines.

See AVAudioPlayer Class Reference