Angry Birds on MacBook Air(scripting.com)
scripting.com
Angry Birds on MacBook Air
http://scripting.com/stories/2010/11/01/angryBirdsOnMacbookAir.html
30 comments
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.
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.
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.
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. :)
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. :)
Yeah Dave Winer tends to always get details wrong.
But, could not Apple make a super set of the iOS UI APIs that eventually become a new UI set of APIs that a future version of MacOSX uses?
Or am I over simplifying it?
My apologies I have not programmed on mac platforms for 10 years..so my assumptions may be wrong
But, could not Apple make a super set of the iOS UI APIs that eventually become a new UI set of APIs that a future version of MacOSX uses?
Or am I over simplifying it?
My apologies I have not programmed on mac platforms for 10 years..so my assumptions may be wrong
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.
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.
No. No no no no. iOS was created in the first place because a touch-oriented direct-manipulation user interface demands entirely different solutions and paradigms than mouse/pointer-driven user interfaces do.
Apple is not going to lead any initiative in trying to pretend that these fundamental differences in user experience don't exist. User experience is something they tend to take seriously.
Apple may provide tools to make it easier for developers to port apps and games between the platforms, but absolutely no way are they going to suggest that developers should gloss over the differences in user experience offered by OS X and iOS.
Having iOS apps run directly on OS X would be to do precisely that. Apps wouldn't be optimized for neither touch/direct manipulation, nor mouse/pointer interfaces.
User interface elements, widgets and paradigms would be general purpose, rather than tailored specifically to the strengths and weaknesses of a particular device.
Just look at the differences between made-for-iPad apps and made-for-iPhone apps. The difference in UI can be astounding when you take the properties of each device into account when designing the app.
OS X isn't just a little bit different than iOS, the way iPad is "just" a big iPod touch. It's fundamentally different — which is why iOS exists at all.
Apple is not going to lead any initiative in trying to pretend that these fundamental differences in user experience don't exist. User experience is something they tend to take seriously.
Apple may provide tools to make it easier for developers to port apps and games between the platforms, but absolutely no way are they going to suggest that developers should gloss over the differences in user experience offered by OS X and iOS.
Having iOS apps run directly on OS X would be to do precisely that. Apps wouldn't be optimized for neither touch/direct manipulation, nor mouse/pointer interfaces.
User interface elements, widgets and paradigms would be general purpose, rather than tailored specifically to the strengths and weaknesses of a particular device.
Just look at the differences between made-for-iPad apps and made-for-iPhone apps. The difference in UI can be astounding when you take the properties of each device into account when designing the app.
OS X isn't just a little bit different than iOS, the way iPad is "just" a big iPod touch. It's fundamentally different — which is why iOS exists at all.
Doesn't the new Air have a large (multi) touch pad? That might allow for a more transitional 'middle ground' to exist. Lion and it's feline ancestors will get more touchy over time, plus what Dave W is hinting at is more of a virtualization strategy rather than a sudden leap I think.
I too think that Apple cares deeply about UX, but you're probably discounting the enormous amount of money/users that could be made if this evolution could be made to fly?
I too think that Apple cares deeply about UX, but you're probably discounting the enormous amount of money/users that could be made if this evolution could be made to fly?
I play Angry Birds by physically dragging the birds around the screen. How exactly do I do that when the trackpad is somewhere different than the screen?
Good point, though I think Angry Birds is one of the apps that would lend itself better to being ported from iOS to OS X. But like you pointed out, it would be quite different still.
Think about how different the official Twitter client would be for example. Refreshing the feed by dragging the list of tweets down; something that feels intuitive, just right, on the iPhone and iOS; would seem weird and retarded on OS X.
Or how about when you swipe over a Tweet (or any list-view item) to manipulate it? Works great in a touch/direct manipulation interface. That would be incredibly poor UI design on OS X. Astoundingly bad. Buttons and widgets would be oversized on OS X. Form factor and layout would be needlessly limited. Etc, etc.
Think about how different the official Twitter client would be for example. Refreshing the feed by dragging the list of tweets down; something that feels intuitive, just right, on the iPhone and iOS; would seem weird and retarded on OS X.
Or how about when you swipe over a Tweet (or any list-view item) to manipulate it? Works great in a touch/direct manipulation interface. That would be incredibly poor UI design on OS X. Astoundingly bad. Buttons and widgets would be oversized on OS X. Form factor and layout would be needlessly limited. Etc, etc.
That's my point. Do we really expect to merge iOS and desktop apps someday?
We've created a new class of direct-manipulation apps on the iOS devices that we just can't bring to the other machines without using a mouse...or turning them into iPads.
We've created a new class of direct-manipulation apps on the iOS devices that we just can't bring to the other machines without using a mouse...or turning them into iPads.
Sorry, I don't know - don't have one. Large comedy finger pointer perhaps? I do remember the last Stevenote having something about why touching monitors wasn't going to fly and how the pad would all be ok (waves Steve's magic field over joezydeco)
I don't think there would be enormous amounts of money to be made from porting made-for-touch-interface driven apps to a mouse/pointer driven system.
iOS apps on OS X would feel terribly weird and out of place, since, again, they're made for an entirely different user interface paradigm.
They'll make a lot of money off the Mac App Store though; because the software on it will be great. As opposed to weird.
iOS apps on OS X would feel terribly weird and out of place, since, again, they're made for an entirely different user interface paradigm.
They'll make a lot of money off the Mac App Store though; because the software on it will be great. As opposed to weird.
Apple's explanation of why a touch UI would be horrible on an iMac or MacBook suggests strongly that they are not interested in moving to a touch screen and touch pads with gestures are the future.
vertical touch = bad : horizontal touch = good
vertical touch = bad : horizontal touch = good
Touch is only part of what makes the iOS devices different from OS X. The other half is direct manipulation — you touch the very thing you want to manipulate. On OS X, there is a pointer between you and the things you want to manipulate.
That pointer gives you increased accuracy, speed, etc. But it also means your hands and fingers don't block your view of the screen. All things put together you end up with a drastically different way of interacting with your computer.
People who aren't UI or UX designers may gloss over these things. But Apple is obsessive about this stuff.
That pointer gives you increased accuracy, speed, etc. But it also means your hands and fingers don't block your view of the screen. All things put together you end up with a drastically different way of interacting with your computer.
People who aren't UI or UX designers may gloss over these things. But Apple is obsessive about this stuff.
I was replying to the "middle ground part", and Steve made it pretty clear touch on a desktop / non-tablet portable was not in the cards. I was making no comment on the various advantages of touch / direct manipulation / pointing devices.
It's like clockwork:
- a scripting.com link get submitted to hackernews
- the first 20 people get to read it
- the site crashes, leaving everyone else with nothing but the comments.
Dave, have you considered upgrading to a 56k modem? :)
- a scripting.com link get submitted to hackernews
- the first 20 people get to read it
- the site crashes, leaving everyone else with nothing but the comments.
Dave, have you considered upgrading to a 56k modem? :)
I shouldn't go out after a discussion starts on YC. ;-)
Glad to see the smiley on your question cause it's a static site running on an EC2 machine.
Glad to see the smiley on your question cause it's a static site running on an EC2 machine.
It is a defense-mechanism for HN. The first 20 people get to read it and alternate between facepalm-level "WTF is he thinking" and incredulous "I can't believe he is that dumb, it must be another one of his (many) trolls." The rest of us get to avoid the frustration of actually reading Dave's drivel and can enjoy the pile-on from a distance.
Something that people might want to keep in mind...
The "Emulator" that is used to test iPhone and iPad isn't emulating the iOS hardware. It is implemented with MacOS APIs. Essentially the iOS that you use on the synthetic target is just the same graphics and system libraries that are compiled for the Mac hardware instead of the ARM. That is why the emulator works so fast, even on underpowered machines.
There is no porting for Apple, it is the same.
There is no porting for Apple, it is the same.
How do they do this?
Do they use an x86 build or do they use an arm emulator to run the software?
Do they use an x86 build or do they use an arm emulator to run the software?
Maybe in the first rev the IOS apps are emulated. I bet in the second one it's the other way around. We've already started a transition. They haven't announced it yet, because they want to ease us into it, but I'm sure this is where they're going.
Would make sense. I wonder whether its feasible to emulate a 1ghz high end game on a 2.4ghz dual core macbook though.
A lot of the comments here don't take into account things Jobs said at the Back To The Mac event. He said the oversize trackpad was there so the Mac could run IOS-like apps. So it's too late to say you can't run them on MacBooks. He said they could.
Conceivably you could use the new Magic Trackpad on the desktops (Mac Pro, mini and iMac). What I think would be needed, is better visual feedback that relates to where your multitouch actions as positioned. A single cursor is fine for a mouse, but it seems limiting for touch gestures.
Dude, he specifically said that's why he shipped the trackpad. It's one thing if the reporters didn't accurately report the story, quite another when they broadcast the press conference so we call can hear directly what he said.
[deleted]
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.