OAuth for native apps is the worst of all worlds. It’s horrible to implement, it’s a horrible user experience and nobody understands it. That’s a little bit hand-wavy, true. Nobody who actually uses your software actually knows what the hell this OAuth business is nor do they care.

Yes, when they use OAuth they are presented with a page that appears to be branded similarly to your website. A website that, despite what all the big cats seem to do, may actually seriously and honestly strive to protect your personal data. So it’s possible that this branding may well make the user of a native app feel more comfortable submitting their login information. After that is done the native app receives a token that can then be used to communicate with your service.

The problem is that there is absolutely nothing here that precludes native applications from acting as phishing terminals. Nothing. In fact it is completely possible that a malevolent application could use genuine OAuth authentication most of the time but, very occasionally so as not to draw attention, present a phishing attack instead.

Craig Hockenberry went into great detail in his piece about this today — In-App Browsers Considered Harmful. If you’re not a nerd you should be aware that the “Considered Harmful” title is not by accident. This is the language used when developers are warning other developers from following a common practice. You don’t use it lightly. Unless you’re using it lightly because it’s dumb. This is not dumb.

Craig booted his app out to iOS Safari in order to do the OAuth dance. He did this because despite being more steps for the user to take it avoided the issue of trust I outlined above. A user didn’t need to trust Iconfactory or Craig. They needed only to trust Apple. Which is a fair assumption since using an iPhone implies a fair amount of trust in Apple in the first place.

Turns out Apple rejected the app because they thought the user experience of going through Safari to obtain an OAuth token was too onerous. First, yes, it’s completely stupid that’s the way things need to work. Second, “user friendly” doesn’t mean what it appears Apple thinks it means in this case.

Less tapping around and not leaving the app? Yes. That’d be a good thing. It appears, however, that Apple rejected this application because it strove to do the right thing for users over the long term — establish a level of trust and transparency vetted through Apple’s own web client for the platform.

“That’s a shitty experience” is, as far as I’m concerned, a decent reason for rejecting a submission to the App Store. What happened here was an application that didn’t take a short-sighted and myopic view of what a “shitty experience” really means was punished for doing so. It is not in Apple’s interest, or for anyone serious about the platform, to enable or accept a culture where phishing attacks are not only possible but the potential is encouraged by the platform vendor in the name of fewer clicks and less task-hopping.

Yes, it’s a pain in the ass to do it. No, the solution isn’t to reject apps that take the time to do it right and, more over, will take it on the chin from Apple and their customers in order to be as transparent, secure and honest as possible.

The issue is OAuth. It’s cumbersome, difficult to implement well and requires hoops to be jumped. Rejecting a developer for doing the right thing by their customers (who are all Apple customers) encourages a culture of not giving a fuck. That’s never turned out well in the long run.

I’ve been excited about this for a while now and I’m really happy to be able to finally talk about it. In late April CocoaConf will be holding an event at Yosemite National Park.

Yosemite is best known for being the the home of El Capitan, the rock face that Captain Kirk climbs at the beginning of Star Trek V: It Never Happened. And, of course, Yosemite is the birthplace of Yosemite Sam who vies with Elmer Fudd to be the canonical Bugs Bunny villain. Apparently, it’s also the marketing name of an operating system for personal computers and, I’m told, an incredibly beautiful place.

I can’t say enough great things about the speakers they’ve lined up. It’s a terrific collection of some of the most insightful people in the field. I’m looking forward to this for so many reasons. If you can make it please join us. Registration is now open.

Here’s how streaming works. In general. This is not news and is not really helpful. I’ll post it anyway.

There are three main tasks when you’re streaming. Could be audio, could be video, it doesn’t really matter. First, you’ll pull the content from the network. Buffering. Then you’ll decode the content. Then you’ll render it. (Yes, the output of audio is rendering it to the output buffer)

Many applications express these three job systems by using multiple threads. It’s a wise choice and makes a lot of sense. The problems appear when the specifics of the implementation come in to play. What happens when a network connection fails half way through? You’ve spun up three threads, one provides the other with raw data, one decodes the data, and one outputs the data as audio. How do you handle a stall?

Now, how do you handle a decoding error? It’s totally possible your source has promised a MIME type that it doesn’t conform to. Promised MP3 but given an M4A? With audio, it’s often close enough.

Once you start? That’s the easy bit. Stopping is hard. Three threads working away delivering data asynchronously? You need to coordinate them all stopping immediately. Without just shutting down the app. That may sound like a piece of cake but it’s really a pie in the face.

The concept is dead simple. One thread downloads the data and then passes it off to the decoding thread. The decoding thread turns MP3 or whatever format into the native PCM format that can be output by the device. The device takes that input and queues it onto a native audio output channel.

Sounds easy, right?

— Guy