“We Don’t Need”

Marco Arment writes:

We don’t need major OS releases every year. We don’t need each OS release to have a huge list of new features. We need our computers, phones, and tablets to work well first so we can enjoy new features released at a healthy, gradual, sustainable pace.

You won’t have missed this piece. It’s been linked to widely. Rightfully so. It captures the zeitgeist of a lot of iOS and even Mac developers.

What I’d like to call out is this particular paragraph I’ve quoted. We don’t. We don’t. We need.

Marco may be passed off as a developer here and dismissed as expressing developer thoughts. The truth is, at least the truth I’ve known from supporting and dealing with people who aren’t technical who use these devices every single day — “we don’t” isn’t about developers.

Sure, it’s a pain in the ass for us at times. But “we don’t” is starting to echo through the people for whom iOS devices were a revelation. These devices made people believe in the magic of technology again. Now? I hear a lot about planned obsolescence and buggy software.

“No! I know these people and I swear that’s not at all their intent!”

That really only goes so far.

The worst thing is that it’s seldom anything big, onerous or serious. It’s just weird little things that don’t work that add up to create the impression that “computers” are incomprehensible.

Nobody ever gave up their evenings and weekends to achieve that outcome.

Marco is right but perhaps his framing is too narrow. This simply isn’t an issue that developers grouse about and move on from. This is something that, at least in my experience, has been affecting customers who have otherwise loved their Apple devices.

The problem seems to be quite simple: they’re doing too much, with unrealistic deadlines.

I agree. Gruber and I talked about this on The Talk Show in early October. I stick by what we said on that episode.

I also really hope that priorities can be examined and release dates changed in order to support the best possible software releases rather than the most systemic.

Debug in 2014

It has been a pretty good year for Debug. We kicked things off in January with an interview with Evan Doll of Flipboard fame. Then we ran the table with a long string of amazing guests throughout the rest of the year.

I really enjoy Debug for a few reasons. Primarily I think it’s a worthwhile endeavour that captures stories that would have other wise have been missed. I know there are people in Apple who listen to the show and learn some of the history from the stories our guests have told. That’s amazing to me. For whatever reason our guests are universally open, honest and forthright. Our guests seem to trust us and I’m really proud of what we’ve managed to achieve.

Which brings me to the second reason I enjoy doing Debug. I love having conversations with these people. I’m always excited and sometimes I’m even nervous. Every interview I’ve done has found me five minutes in and me wondering how the hell I can fill an hour. That’s when the interview stops and the conversation starts. Three hours later we have a show in the can.

We’ve had some terrific conversations this year. On episode 40 we had Jessie Char, Serenity Caldwell, Brianna Wu and Georgia Dow run the show and the result was one of the things I’m most proud and happy to have had a part in creating. We had a brief series about alternative languages and their ecosystems. We had Nitin Ganatra. We had a lot of Nitin. Too much Nitin. Nobody likes that guy. And nobody likes Don Melton, our other repeat offender. They even teamed up for a couple of shows. Jerks.

Thank you all for listening. Our audience is far beyond what I’d have anticipated. We peaked at over one hundred thousand and our average listeners are well up there. I’m so sorry for all the pauses. I swear I’m thinking and not just wasting your time.

We’ll continue to have incredible guests. If anything the reason I feel comfortable saying nice things about a project of mine is that, really, the show is about the guests. We’ll keep having in depth discussions and fleshing out the historical record.

It has been a thrill. Thanks for coming along for the ride so far.

Regarding OAuth for Apps

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.