Linked List: June 9, 2014

Monday, 9 June 2014

Mark Gurman:

While Apple did, indeed, announce a health tracking application and an API for partners to hook into, the interface did not match up with our screenshots from March. The reason, a source confirmed this week, is that Apple revamped the user-interface and dropped the “Healthbook” name late in development due to the leak. While the icon and interface is new, the entirety of the earlier reported functionality and in-app graphics are identical. […]

As you can see, the icons for each data point are identical in our March screenshots to the ones in the current iOS 8 build. The only change is the overall interface, and many Apple employees that I have spoken to agree that the original Healthbook UI is far superior in usability than the current look.

Let me get this straight. Apple completely scrapped a superior interface to Health because Mark Gurman published screenshots back in March. That is to say, Apple cared more about the surprise of revealing a never-before-seen Health interface during the keynote than they cared about the actual design quality of an interface that will be used by hundreds of millions of iOS users for years to come.

It’s public knowledge that Jony Ive now oversees all software design at Apple. So in this scenario, we are to believe that Ive is so petty, juvenile, and impetuous — and more concerned with secrecy than design quality — that he either approved or himself demanded a radical design overhaul not because it was better but merely to have something un-leaked to show on stage last week. This, for a feature which was deemed worthy of less than three minutes of keynote time (68:30 to 71:20). Jony Ive.

OK, sure.

(Another possibility: Health’s design was far from finished in March, and the intervening months of Apple’s iterative design process resulted in what we saw last week. Designs within Apple are never born finished, and often, if not usually, change radically before shipping. And though Mark Gurman is prodigiously talented, his youth has led him into the solipsistic trap of thinking that his personal perception of Apple — as a guardian of secrets — accurately reflects Apple’s actual institutional priorities, when in fact nothing, not even secrecy, trumps design in the halls of Cupertino.

But what do I know?)

Intrigue Regarding Katie Cotton’s Successor ★

John Paczkowski:

And though there are at least two well-qualified internal candidates for the job — comms veterans Steve Dowling and Nat Kerris — Apple is also looking outside the company for Cotton’s replacement. Sources in position to know tell Code/red that CEO Tim Cook is overseeing the search, aiming to find some high-profile external candidates for consideration. And he’s paying particular attention to those he believes could put a friendlier, more approachable face on Apple’s public relations efforts. Hardly surprising, as VP of comms is a position that reports directly to Cook, and he obviously wants to put the best person he possibly can into it. But interesting nonetheless, as passing over a pair of veterans groomed under company co-founder Steve Jobs for an outsider could herald a big shift in Apple’s PR strategy and its comms team.

I find this intriguing on two levels:

Who from the outside might Tim Cook bring in, and what changes would they make?
Who is Paczkowski’s source for this story? Surely there are only a few people in a position to know this. Either Tim Cook wanted this leaked, or, someone leaked this against Cook’s wishes. Either way it’s intriguing. The only reason I can think of why Cook would want this leaked is to cast a wider net for candidates — to spread the word that he’s at least considering hiring an outsider. Or, I suppose, to preempt the inevitable gossip once he does start interviewing candidates.

Update: A third level that I’ve been thinking about all day, succinctly expressed by Daniel Jalkut on Twitter:

@gruber Isn’t it also intriguing that after so many years of top-level service, Cotton didn’t stick around to hire a successor?

Or that she left before WWDC, instead of after.

‘The Next Five Years’ ★

Justin Williams:

And then in two hours, Apple shut me up. They pretty much offered a solution for every single thing I have bitched about over the past five years. Extensions, CloudKit, a new iTunes Connect. And Swift, an entirely new programming language that will likely power the future of iOS and OS X development for years to come.

I came into this years WWDC fairly mellow to what would or wouldn’t be announced. There wasn’t any anticipation or excitement the night before. Just a standard amount of curiosity. After the Keynote, I can’t remember being that excited since the announcement of the original iPhone. They blew the roof off Moscone.

iOS 8 Uses Randomized MAC Addresses When Scanning for Wi-Fi Networks ★

MAC addresses are used by both marketers and government agencies to track device location — this is a nice win for privacy.

iOS 8, WebKit Performance, and XPC ★

Mike Beasley, writing for 9to5Mac:

When iOS 7 launched, developers discovered that their apps with built-in web browsers were unable to achieve the same level of JavaScript performance as the stock Safari app. This was because Apple restricted use of its improved Nitro JavaScript engine to its own app, leaving third-parties with a slower version.

As of iOS 8, however, it seems that decision has been reversed. All apps will now be able to use the same improved JavaScript engine that powers Safari. That means Google’s Chrome browser on iOS will now be just as quick as Safari, as will the pop-up browsers embedded in apps like Twitter and Facebook.

The Nitro JavaScript compiler appeared all the way back in iOS 4.3 in 2011, and there has been a split in performance between Mobile Safari and third-party apps ever since. As I wrote then:

The real answer is about security. Perhaps the biggest reason for Nitro’s performance improvements over WebKit’s previous JavaScript engine is the use of a JIT — “Just-In-Time” compilation. Here’s Wikipedia’s page on JIT. A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.

What’s new in iOS 8 is not that a “decision has been reversed”. It’s that inter-application communication APIs — XPC — have been greatly improved. This is why we’ve got all sorts of new stuff: third-party keyboards, sharing extensions, photo filters, and a full-speed embedded WebKit. All very different, all enabled by XPC.

In the old days, things like this were insecure and dangerous: plug-ins executed inside applications. A bug in a plug-in could crash your app or create security vulnerabilities. iOS never allowed that. Now, with improved XPC, we have extensions that run as separate sandboxed processes. This isn’t something Apple tackled in the past year alone — they’ve been working on iOS XPC for years, but only now in iOS 8 is it ready to be opened to third-party apps.

Scott Hanselman on URL Shortener Redirects ★

Scott Hanselman:

I saw a URL today on Twitter to an article on Slate.com. It was a custom short URL - http://slate.me/1h0svt8 but since I was visiting it via Twitter, it was wrapped with Twitter’s t.co URL, so I really started at http://t.co/sxSvcJnT2L.

When I visited it for the FIRST time, I got this lovely HTTP interaction. That’s SEVEN HTTP 301s, count them, 7, before I get to the destination page.

Slate is effectively doing the opposite of what I’ve done with DF short URLs.

(Via Michael Tsai.)