Mac OS X 10.7 Brain Dump

On Wednesday, Apple revealed their plans for Mac OS X 'Lion', which will bring a lot of ideas and research from iOS to the desktop.


A lot has been made of Apple's new 'Launchpad' feature; basically a re-imagining of the iOS home screen for the desktop. It makes a lot of sense, application discovery, installation and removal has always been problematic on Mac OS X. But it also signifies something far more interesting for the platform - the idea is to create an abstraction between your 'Applications' and the /Applications folder on your hard disk. Maybe in an OS release or two, you won't even have an Applications folder on disk anymore - all your application access and management will happen through Launchpad.

This signifies, at least to me, a move away from the files and folders model of interaction with computers. As with iOS, the location the applications are stored in becomes an implementation detail. In the very near future, we may not even need a Finder app to browse our hard disk; folders just become metadata, and everything lives in a global 'soup' (Apple Newton users will be familiar with this idea).

Never Quits

According to rumors I've heard, and evidenced in the demo of Lion given, apps in 10.7 also do not seem to differentiate between 'running' and 'onscreen'; there is no indicator in the Dock when they're open, and when you quit them and reopen them they re-launch in exactly the same state you left them. You effectively do not know what's running or not without a window onscreen. It sounds like an insane change, but actually isn't if you think about it: in the near future, there may not be a speed difference between something being 'in-RAM' or on-disk, if the two storage media are equivalent in speed (SSDs, while still a long way off, are getting there). If disk access is as fast as RAM access, what *is* the difference between 'quit' and 'offscreen'? There effectively is no difference. It may be a bit premature for 2011, and perhaps this decision will be reversed by the time Lion is released, but it's an interesting view of the future.

App Store

Apple also announced plans for an App Store on Mac OS X, something I've seen coming as a logical conclusion ever since it came to the iPhone. Feelings are mixed about this, but it doesn't matter - in the next few months the App Store is going to become the dominant distributor of Mac applications and developers will be scrambling to retrofit their software to abide by the store's rules. Whether the walled garden is good or evil, there's no doubt that it will change the desktop computing landscape just as it did in mobile.

Right now, you can't use the same application ID for your iOS app and your Mac App Store app. I think it's conceivable that in the future there will be no difference between a Mac and iOS app binary, so I can understand why they don't allow you reuse the same ID across both platforms.

Speaking of App Stores, I find it curious that neither Dashboard Widgets nor Safari Extensions have received an App Store of their own yet; I can definitely see both getting their own integrated stores eventually, as it just makes too much logical sense. I'm totally against putting either in the Mac App Store, however; that would defeat the purpose of a single-purpose, streamlined store.

Still no mention of iBooks on the desktop either - I've always imagined that Preview would gain such capabilities, but it's also possible that a standalone 'iBooks' app for Mac is coming.


Apple devoted quite a lot of stage time to talking about multitouch on the desktop, and saying how their solution is their powerful multitouch trackpad. They reason that touch screens don't want to be vertical, and they're fully right. Unlike many in the media, however, I certainly do not interpret this as Apple saying they won't implement multitouch screens on the Mac line. On the contrary, they kept saying how *vertical* touch screens don't work. This leaves them wide open to introducing horizontal touchscreen Macs, and they have many patents on such ideas so have obviously been working on them. Don't be surprised if in a year or two Apple introduces real touch screens to the Mac.

Lion looks to have much better, integral multitouch gesture support, which is going to be awesome for pro users. Right now the mouse is generally a point and click affair, but with multitouch it turns into something far more like a practical version of the Minority Report UI; every flick, swipe, pinch, rotate has a function in the OS.

Contextual UI & Fullscreen

This is also a big one - of course, people have defended iOS' unitasking and fullscreen apps saying it allows them focus better on whatever they're working on on iOS. There's a lot of truth to that, and it will be interesting to see how much of a difference it will make on the desktop. I definitely feel more at-peace and relaxed when unitasking on the iPad (this blog post was written on the iPad, for reference).

The contextual UI is something that interests me a lot; quite apparent in the iLife demos, specifically iPhoto, is a lot of contextual UI. It appears when it's needed, just like on iOS. It doesn't clutter the screen when not needed, and it shows up near the object you're interacting with instead of in some global toolbar or sidebar. I believe this is going to be a big thing as Mac OS X assimilates more of the design philosophy of iOS. It's definitely going to be a big deal on smaller screens, like the 11.6" MacBook Air. Mac OS X is also losing the permanent scrollbar, replacing it with a contextual scrollbar (again, just like iOS).

Wrap Up

There's so much coming in Lion that they've shown already, way more than I expected. I was expecting Mac OS X and iOS to become far more similar, but not this soon! Even now, it's clear that Lion is going to change the Mac landscape vastly, and the App Store is going to have a huge effect on Microsoft's planning for Windows 8. The stringent rules on the App Store will be a pain in the ass for Mac developers, but it will end up accelerating the evolution of the Mac platform immensely (no private APIs, no external dependencies beyond what ships with the Mac OS, no writing outside of specific locations - it will allow Apple to make huge and rapid changes to Mac OS X without worrying about backwards compatibility).

For the first time in many years, I am actually excited about the future of desktop computers. The iPad hasn't killed the Mac, it's brought it to a whole new level.

AppleTV + Apps

I guess it's no surprise that the new iOS-based AppleTV was jailbroken instantaneously on release, but as the former AppleTV plugin developers race to the new platform to disassemble it and get their own plugins up and running on the new system, I can't help but wonder how the future of AppleTV will play out as regards developers.

It's widely rumored that Apple will open up the AppleTV platform and create an 'App Store', allowing developers write apps for the big screen. It seems almost inevitable that they will make this play, if not to compete against Google TV then to at least make the AppleTV a relevant platform; leverage against the movie studios reluctant to agree to Apple's movie rental terms and who knows what else.

What I don't see is an AppleTV SDK being built around BackRow, the current framework that provides the UI on the device. Previous AppleTV plugins have all been built for BackRow, using a framework that is decidedly not very Cocoa-like or developer friendly. They have nonstandard design patterns, and they run as actual plugins to the UI process; a crashed plugin can currently take out the entire UI. From what I've seen (and I've been using it since the original AppleTV hacks back in 2007), the BackRow framework is not fit for third party developers and was never designed to be.

Assuming Apple does launch an App Store, then, how are we going to write apps? The only option I see is UIKit. UIKit is familiar to all iOS developers, is very Cocoa-like, and very powerful. In fact, since iOS 3.2, 1280x720 (720p, or the same resolution as AppleTV) is a supported resolution for developers, mainly for those creating TV-out UIs in iPad apps (Chopper 2 is a great example of this). Developers have already started crafting ten-foot-UI experiences in existing iOS apps, so it would be a no-brainer for that to translate over to AppleTV wholesale. To make it work, Apple would have to build remote control support into iOS… - but hold on a second, Apple already added that in iOS 4! Effectively, all the pieces are in place to build a remote-control driven 720p iOS app. All Apple needs to do is build the distribution mechanism and open the floodgates, and 'Universal' apps would be a definite possibility.

Of course, some people will complain that UIKit isn't the native UI for AppleTV; our apps will look and act differently from the native experience on the device. Point taken, and it's an important one; I think Apple could effectively build an AppleTV UI framework on top of UIKit that internally uses the BackRow APIs but offers the developer a much cleaner way to implement common features. Does it need to happen? No, but it would certainly feel unfinished if they didn't do it. Then again, Apple can be surprising: I'm still astounded they let the iPad ship with that horrific iPhone app scale-to-2x support :o).