Saturday, April 17, 2010

UIKit in 10.7?


Disclaimer: The following is nothing but pure speculation...

UIKit in 10.7 would mean an iPhone like environment on a touch screen Mac - even iPhone apps themselves. Seems nuts, but reserve judgement until the end.

First, a little background in Mac OS X / iPhone architecture...
Mac OS X and iPhone apps share a common underlying framework - Foundation. However, each platform has it's own application layer.


iPhone OS has UIKit = CocoaTouch

The UIKit framework contains the Application layer for iPhone apps. This includes the visual interface and user interactivity bits that makes the iPhone the iPhone. This is where touches, views, images, gestures, tables, controls and that other fun iPhone stuff lives.




Mac OS 10.0 - 10.6 has AppKit = Cocoa

Mac OS X's equivalent is AppKit and has views, windows, images, open panels, tables, controls, mouse pointers, printing etc.


The key architectural difference between Mac OS and iPhone OS is that neither has the other's application layer framework. There's no AppKit in iPhone and there's no UIKit in Mac OS X. Seems logical - what would the iPhone OS need with a save panel - after all the user interactivity is entirely different between the 2 platforms.

Good logic - Until you put a touch screen on a Mac in which case things change.


Could Mac OS 10.7 have both?


Some may argue that a Touch Screen Mac doesn't make any sense ergonomically - but what's the difference between that and an iPad with a keyboard dock?


The grab...

UIKit on Mac OS X is a very good choice if there ever is a touch screen Mac - and maybe even if there isn't. Here's why:

1. It's built for finger input
If the iPad is just a big iPod Touch, then an iMac with a touchscreen is just a big iPad. If you had told me a few months ago that UIKit was a possibility in Mac OS - I'd have laughed at you (perhaps the way some of you are laughing at me now). All of this changed with the iPad though - which has proven that UIKit (primarily the user interface) can scale up to much larger devices. It's a much smaller step to take UIKit to the Mac than it was to take it to the iPad. UIKit is the thing that makes touch input really really rock. Why wouldn't you use UIKit on a touchscreen Mac - I simply don't see what other choice there is. Sure you could bring touch stuff to AppKit (and it already exists in a sense) but why bother?

2. UIKit is more modern than AppKit
There's some brilliant design in UIKit (it's an evolution of AppKit after all) for example UIViewController, everything visible being subclasses of UIView and lots and lots of small decisions that make UIKit a pleasure to code for. More app for less code is always a good thing.

3. Third party developers
There's over 180,000 apps for the iPhone. I'm not sure how many apps are available on Mac OS, but I'm sure it's a LOT less than that. There's a huge amount of code and big investment being made in iPhone code - investment that most often can be leveraged on the Mac too. The availability of more apps on the Mac is a good thing - no matter what way you slice it. Everyone wins - users, developers, Apple.

4. The AppStore
Whatever you want to take away from the AppStore is irrelevant in the light of it working so damn well. Users get apps, developers sell apps and it's all so darn easy. Argument over. Bringing the AppStore to the Mac would be very welcome. Anything you throw at the AppStore is easily deflected by how well the model of having an AppStore on the platform works. Would the iPhone or iPhone app developers be as successful without the AppStore? I doubt it would come even close. Would the iPhone be as compelling without the AppStore? I doubt that too. Will and AppStore with 200,000 apps be awesome on the Mac platform? No doubts there.

5. A lot of iPhone apps are already usable on standard Mac hardware today
How do I know that? The simulator. Apple launched the iPad with thousands of applications, most of which had never been used on the actual device. Even using a mouse input instead of a touchscreen, the UIKit app environment is damn usable. There are so many iPhone apps that I wish I could have in my iPhone simulator and just use as apps on an everyday basis.
They'd be even better with a touchscreen, but they already work well enough to be useful.


Let's be clear that I'm not suggesting UIKit will replace AppKit anytime soon (or ever) - that simply doesn't make sense. I'm making the argument that having UIKit as an option on Mac OS makes an insane amount of sense - if you have a touch screen (and only slightly less sense if you don't).




Some Q&A….

Q. Would developers need to invest much time to bring their iPhone app across?
A. Probably just recompile. Unless they did something stupid - like violated iPhone SDK 4 term 3.3.1 and used an intermediate library like Flash to iPhone.

Q. Well what would happen to my other applications in Mac OS X - can I print and use my mouse and stuff?
A. Of course. AppKit and the traditional application environment can still exist quite happily. Maybe launching a UIKit app just goes modal - like FrontRow, which notably doesn't have a mouse either.

Q. Wouldn't that take a lot of work?
A. No. That's what the simulator does now. It runs UIKit on the Mac. Job done.

Q. But the iPhone / iPad runs on ARM and the Mac uses an x86 processor. Doesn't that pose a problem?
A. Evidently not for Apple and their Universal Binaries. These were introduced back in the PPC to x86 switch, but are still very much in use today. Todays apps that are compiled for 32 and 64 bit x86 processors are using a universal binary. You can even do PPC / x86 and 32 / 64 bit apps - all 4 permutations of which exist in the same universal binary. Right now apps that run in the simulator run as x86 apps whereas apps that run on the device rum as ARM apps - so the hard work is already done. Creating a Universal Binary containing both x86 and ARM code would be a walk in the park for Apple's engineers.

Q. Wouldn't you need an accelerometer or rotation or something?
A. Not necessarily. Sure some apps need it, but many many don't. Some apps need a camera, some need a GPS, some need a magnetic compass. It won't mean all iPhone apps will be available for the Mac - the same way not all iPhone apps are available for the iPod Touch.

Q. What about the extra screen real estate?
A. That became a non-issue with the iPad. Building apps for dynamic screen sizes is now a given when creating apps for the iPhone OS. Did you really think Apple were going to use 320x480 screens forever?