As always, WWDC, Apple’s annual developer conference, is a bit of a firehose even when you’re sitting at home just reading the blogs and watching the occasional session video. I’m not sure how people in San Francisco actually keep up!
What I’m trying to say is that this post is far from complete. I’m sure that I’ve missed something important. But here is my top four things that I’ve taken away so far.
I list this one first because this is the one I’m most concerned about. The gist is that instead of compiling apps down to ARM and ARM64 code and sending that to Apple for review and release, we send a “partially compiled” app to Apple. When a user downloads it, Apple’s servers finish the job, compiling this intermediate code down to the specific hardware that they have.
Clearly this is Apple’s way of saying that new hardware is on the way — also see App Thinning — and they don’t want us to have to recompile our apps before they’ll work on it.
Why is that bad? Well, I have no idea what code will be executing on my users machines. What optimiser settings are Apple using? What compiler are they using? Are there any bugs in it?
Or put another way, Apple put an invisible step between the developer and the user. If it works, users get an optimised app. If it doesn’t, the developer gets a bunch of one star reviews for something that they had no ability to test. It doesn’t seem to me that the upside outweighs the risks.
Let’s hope they do it well and cautiously. Or that the new hardware is worth the hassle!
This one is going to sell a lot of iPad Air 2’s to developers in the next couple of months. I love this both as a developer and as a user.
As a user, being able to run two apps side by side suddenly makes the iPad far more useful. Can I say, finally?
And as a developer, it’s not even terribly hard to implement as long as the app is relatively new. With the caveat that more testing is needed, I got Yummy up and running in the Simulator without changing any code.
It’s basically a “Safari view controller” that developers can use to show web content in their apps.
I thought that this would be ideal for Yummy. The value of the browser in Yummy is diminished by its lack of autofill (of password, addresses, credit card details, etc.) and log in details. SLSafariViewController, which suffers from none of those disadvantages, sounds like the solution.
However, in the first beta at least it’s limited in two important ways that means it won’t work in this scenario. Firstly, it’s modal. Secondly you can’t edit the URL. I’ve raised bug reports about both. We’ll see.
Still, I can see uses for it in its current form.
Spotlight searching inside apps
This is another good one, both for users and developers. Using Spotlight search — which has had lots of other nice improvements too — it will be possible to find things inside apps.
For example I was able to use Spotlight to find bookmarks that had been indexed by Yummy. This is more work that the multitasking but is not super hard.
Yeah, I didn’t mention Swift or the Apple Watch. I think both have a great future but I don’t have any immediate applications for either right now. (For what it’s worth, my first app with Swift in it will probably ship before the end of the year.)
Like the multitasking, the Spotlight searches are going to create more reasons for more users to keep using compatible apps. But, more than that, it’s going to make apps considerably more useful without having to invest vast amounts of time to get the benefits.
This contrasts greatly with the last two releases of iOS. With 7, a huge amount of work was required just so that apps didn’t look out of place in the New World. For many apps, that work resulted in no new features or stability improvements. Version 8 required none of that, but it was a huge release for developers. Extensions were brilliant, but required a lot of work, especially since the development tools were flaky.
iOS 9 appears to be a stability release for Apple and the new features seem to give a lot of “bangs per buck” for developers. That’s my kind of release.