Dave might be right in broad strokes, but the post is very muddy on what it would mean for "iOS apps" to run on the MacOS.
Fundamentally, it would be pretty straightforward for Apple to allow iOS apps to be easier to port to the MacOS: bringing some of the UIKit APIs to desktop Cocoa would make things very much easier. As it is, anything that touches images or the user interface has essentially zero overlap between the desktop and mobile APIs. Very frustrating.
However, the speculation about MacOS on the Air being a "compatibility layer" is utterly ludicrous and unfounded. A quick peek inside /System/Library/Frameworks will indicate that the build of 10.6.4 that runs on the Air uses exactly the same set of frameworks that Apple has built up for the MacOS as any other traditional computer they sell.
While the brief preview of Lion given the other week indicates that there will be significant cross-pollenation between desktop and mobile OSes for Apple, in both user interface and (one assumes) APIs, it's hard to exaggerate how off-base this particular item of speculation is, in the right-here and right-now.
I would be unsurprised to see a third architecture added to "Universal" iOS apps to allow them to be run on Lion desktops, but as any iOS developer can tell you, even porting an app from the iPhone to the iPad is hardly a set-it-and-forget-it affair. Winer snarks about the multitouch trackpad at the end of this article, but he's just as wrong about it now as he was when he first said it.
The iPhone is a fundamentally different user experience from the iPad is a fundamentally different user experience from the MacBook Air, even if 10.6.5 + Mac App Store includes all of UIKit.
I would be unsurprised to see a third architecture added to "Universal" iOS apps to allow them to be run on Lion desktops
Disclaimer: I haven't read the post; I can't because the site isn't loading for me. Instead, I'm replying to the OP.
I would be very surprised to see this. I contribute to Colloquy — An IRC client available for Mac OS X and iOS (iPhone and iPad). Having three separate UIs aside, the shared code between the projects doesn't go through the same build steps. It cant, because iOS doesn't allow third party dynamic frameworks to be loaded; they have to use a static library instead.
In the case of Angry Birds, if you take the .ipa from iTunes and unzip it and then run otool -l on the binary, you can look at the frameworks it uses.
The iOS-specific frameworks it uses are: UIKit, OpenGLES, MediaPlayer and GameKit. GameKit could likely be ported fairly easily. MediaPlayer with a bit of work, could be mapped to QTKit. OpenGL to OpenGLES, I can't say; I don't know anything about either. And UIKit? Mac OS X has to run on Mac Pro's and iMac's as well. Which may or may not have a multitouch device attached. UIKit would be a kludge with multitouch trackpads, and downright useless without one all together.
All very good points, and I think we agree on the major bits. Reading over my last post I think I might have been unclear on the main takeaway: desktop apps are fundamentally different from mobile apps.
If Apple lets us write apps that run on both platforms, I would expect the desktop versions to include substantially different resources and have fairly divergent codebases: different nibs, different build processes (perhaps with the disparate binaries packaged into one .app bundle), different interaction metaphors etc.
UIKit would be a kludge with multitouch trackpads, and downright useless without one all together.
This is largely true, but there's more to UIKit than touchesBegan:withEvent:. In particular, UIKit's view controllers/navigation controllers/table views could work quite well on OS X (and looking at iLife '09 and the preview of full-screen apps in Lion, this seems quite likely). Further, more iPhone apps use these classes than do advanced multitouch.
Again, this is not to say that writing one app that could conceivably run on both platforms will be at all easy; I still think the OP is way off the mark about that. But it's not unthinkable.
I have vmWare on my Mac desktop, running XP. If you look in the Windows folder you'll see everything you'd expect to see in a Windows installation. It is a Windows installation. That's the sense that I meant to raise the question for thinking purposes about which is the compatibility box. I meant to say you could see it either way. And my guess is that the strategic thinking at Apple is that the box is contianing the Mac software not the IOS software.
That's based on watching Apple evolve stuff, very slowly and carefully, since 1997. There was even some of this kind of thinking in the move from the Apple II to the Apple III, back in 1981!
I'm not looking at this one year at a time, nor are the people at Apple. They're thinking of a transition that might go for ten or fifteen years.
The neat thing about iOS and MacOS, compared to Windows in VMWare, is that iOS apps are never 'emulated' on MacOS—they're 'simulated'. In fact, I'd wager that during its development, Angry Birds was run on a Mac far more often than on an iOS device. The iPhone Simulator is just a wrapper for x86 binaries linked against iOS frameworks.
If this is actually in Apple's plans, running iOS apps on MacOS wouldn't be much harder than making these frameworks first-class citizens... plus a whole lot of work reconciling the fundamentally different interaction, document, window, and application models. (Guess which of those 80 and which is 20. :)
The thing is, _every_ cocoa mac app currently uses the old UI classes, and it might be difficult to get existing mac developers to move to UIKit.
Typical Apple style is probably to move the UIKit stuff in for a release, then deprecate the old stuff in the next release (e.g. powerpc on snow leopard). Remember the Office 2010 apps that were being praised at the Apple event? Bam, deprecating the old UI APIs means that Microsoft has to re-code all of that to get their apps working again. And Adobe, not to mention all of Apple's apps, both internal and external. And devs can't target multiple versions of OS X.
The alternative that Apple is probably going to choose is to make the old UI stuff the new carbon - supported for a while, but not getting any updates. The real people this would hurt are, again big corporations, but some of the open-source projects who could spend their time on new features but are instead spending their time re-coding for the new UIKit APIs.
Dave might be right in broad strokes, but the post is very muddy on what it would mean for "iOS apps" to run on the MacOS.
Fundamentally, it would be pretty straightforward for Apple to allow iOS apps to be easier to port to the MacOS: bringing some of the UIKit APIs to desktop Cocoa would make things very much easier. As it is, anything that touches images or the user interface has essentially zero overlap between the desktop and mobile APIs. Very frustrating.
However, the speculation about MacOS on the Air being a "compatibility layer" is utterly ludicrous and unfounded. A quick peek inside /System/Library/Frameworks will indicate that the build of 10.6.4 that runs on the Air uses exactly the same set of frameworks that Apple has built up for the MacOS as any other traditional computer they sell.
While the brief preview of Lion given the other week indicates that there will be significant cross-pollenation between desktop and mobile OSes for Apple, in both user interface and (one assumes) APIs, it's hard to exaggerate how off-base this particular item of speculation is, in the right-here and right-now.
I would be unsurprised to see a third architecture added to "Universal" iOS apps to allow them to be run on Lion desktops, but as any iOS developer can tell you, even porting an app from the iPhone to the iPad is hardly a set-it-and-forget-it affair. Winer snarks about the multitouch trackpad at the end of this article, but he's just as wrong about it now as he was when he first said it.
The iPhone is a fundamentally different user experience from the iPad is a fundamentally different user experience from the MacBook Air, even if 10.6.5 + Mac App Store includes all of UIKit.