See a significant correction below; an earlier version of this story claimed incorrectly that Windows on ARM would be limited in how it can exploit native audio code.
I hear a lot of pro users afraid that Mac OS X will suddenly turn into iOS, making their computer into a giant, hinged phone they can’t use any more. Mountain Lion, the update Apple introduced privately to a handful of journalists hand-picked by their PR, may throw more fuel on those fears. Apple brought over some familiar features from iOS to Mac OS, and even prods users into installing apps from the App Store or containing some special developer key.
But let me give away the punchline in one line: With Mountain Lion set to default, developers can distribute software without using the App Store. That’s really all you need to know. For our community, my guess is that plug-ins shouldn’t be impacted at all, which makes this even more of a non-news-item.
I spend a lot of time talking to developers about what it’s like to work with Mac OS, and looking at how this impacts your experience as a user. So, even though I wasn’t on Apple’s short list, I can say with some confidence that this announcement – unless we hear something new – most likely means:
1. You’ll probably switch off this new Gatekeeper feature and use whatever software you want.
2. The name “Mac OS X” will be “OS X,” but you’ll keep calling it the Mac. (Heck, some of you will still call it Macintosh. Just don’t say “ex,” okay?)
3. The notification system isn’t all that different from Growl. If anything, that continues an Apple tradition of aping ideas from the third-party that goes back to the days when OS releases began with the word “System.”
4. Those of you using Mac OS to make music will probably continue to do so, because the OS still has the benefits that are the reason you use it. Those of you who use other operating systems, we’ll continue to look at how to get the most out of those.
That’s it. Really. You can safely ignore the debate – on all sides – likely to rage about what this OS update means. The stuff that matters most to us as musicians isn’t necessarily what matters to other people. (Now, you might personally decide you like iCloud and notifications and other little features; I’m just saying they don’t directly impact all music software. Nor do I see any indication they’ll get in the way if you don’t like them – and to the extent they do, you should be able to switch them off, as in notifications.)
In fact, even if music devs decide they want to make themselves compatible with the new app safeguards without getting on the App Store, they can get a developer certificate (apparently a few minutes’ work). My guess is, given almost no music devs have jumped into the App Store as distribution model, this means this changes nothing. And because those same developers usually certify their software before they say it’s compatible with a new OS update – on Windows as well as on the Mac – the certificate could even be a good indication that an app was tested on Mountain Lion.
Given the overheated coverage talking about how this revolutionizes computing or turns the Mac into an iPhone or an HDTV or the spawn of all that is evil or something, I thought I’d – for once – write something a little shorter. Mac hardware and software have loads of stuff that isn’t available on mobile. (For instance, I’ve gotten no indication yet that Thunderbolt, which is increasingly looking like the future of pro I/O in very cool ways, is coming to mobile platforms any time soon.) And the guts of Mac OS X remain the same under these surface-level changes – even if some people find them a bit creepy.
There’s a lot of understandable worry about how iOS and Mac OS X – erm, “OS X” – are merging. But under the hood, it’s the same OS.
For a great overview, free of lots of spin, check out Jason Snell at Macworld:
Hands on with Apple’s new OS X: Mountain Lion
Apple gets a lot more attention – and more impassioned emotions – these days. But the only really fundamental change I’ve seen is Microsoft blocking third-party Windows desktop code on ARM.
Correction: I was simply wrong when I claimed, however, that this means that Windows 8 will not allow native code; the WinRT API model will in fact do that, as readers, including Martin Törnsten, observe:
Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store.
Building Windows for the ARM processor architecture
Since you can’t directly port “desktop” Mac or Linux apps to iOS or Android, respectively, this wouldn’t be a fair comparison with OS X in the first place. The more interesting question to me that will require further testing is whether Windows on ARM will have some of the audio real-time prioritization benefits that Windows on Intel does, and if it can avoid some of the latency and reliability pitfalls seen (for now, at least) on Android. But I retract my earlier statements on two levels – one, they were wrong, and two, they weren’t really relevant to a discussion of OS X’s app distribution model.
If Apple does do something that causes serious problems for music development, believe me, you’ll hear about it here.
Macworld Looks at GateKeeper; More Reason Not to Panic:
Jason Snell goes into some detail:
Mountain Lion: Hands on with Gatekeeper
Here’s the important bit:
It’s not a background check for developers. Getting a developer certificate isn’t like getting a passport or a driver’s license. A developer signs up for an account and gets a certificate. That’s it. What’s more, these apps have no seal of approval from Apple. Apple never sees them. Developers don’t need to check with Apple before signing apps. Apple’s not involved other than providing them with a certificate that Apple can revoke later if it feels the developer is distributing malware.
Moreover, given that GateKeeper appears to verify at app at launch time, it would appear to me that plug-ins will be exempt. That means that updating your host – something you’re likely to do anyway with a new OS – would presumably make all your plug-ins work, too. (Well, apart from any potential changes to the plug-in architecture, but that’s nothing new.)
There seems to be no evidence, for instance, that those of us building something like Ardour or SuperCollider or Pure Data couldn’t simply get a developer key (possibly for free) and use that. Free and open source software would be allowed. None of the restrictions in the App Store or on iOS appear to be present. OS X remains a proprietary OS, but it’s not any more proprietary with Mountain Lion than it is with Lion.
Indeed, using signing to verify the authenticity of software is something common to many operating systems, including free OSes. Apple’s situation is different in that there’s one vendor (Apple), but there’s substantial evidence in just the hours after press have seen the OS that the signing process will be straightforward. And, once again, the important thing is that you can turn the feature off. My frustration with iOS’ inflexibility remains – Apple could simply have an “allow unknown sources” checklist as Android does, and a lot of us would be happier. But that checklist is precisely what’s on the forthcoming OS X. And I wouldn’t expect Mac users to settle for anything less.
Apple’s Mac market is tremendously lucrative; it’s part of why they’ve got all of this money in the bank, it has some of the biggest profit margins in the entire tech industry (certainly the largest of any major computer maker), it’s the one computer that has shown dramatic growth (often at the expense of PC rivals), Apple has built an extraordinary logistics and inventory system behind selling it, and it represents a lot of the soul of the Apple brand and developer and creative markets that have propelled iOS devices. It seems logical to assume Apple would protect that market. Adding some iOS technologies is not necessarily killing the Mac. And it appears the restrictions everyone is freaking out allow you to run 100% of the software you’re running today.