Microsoft has released an article detailing how to port a particular Cocoa Touch to Windows mobile. The catch: the app in question relies particularly little on the Cocoa framework, it handles its own widgetry and visual display. This is rarely the case in an iPhone app… most of them make heavy usage of UIKit and Foundation objects to get the job done. The best advice for porting these apps? Don’t.
There is no analog to most of the Cocoa Touch frameworks on Windows Mobile, and most WinMo devices simply can’t DO at the hardware level what a lot of iPhone apps take for granted as basic device functionality. Porting an app of any complexity will usually be nigh impossible… it will require a complete rewrite. The rewrite process is basically what Microsoft’s article details. The same goes for Pre, Android, or Blackberry.
For any given app, when you’re beginning development, Microsoft would probably advise that you not use any of the frameworks Apple has provided, outside of basic executable functionality, opting instead for custom drawing routines handwritten by the developer, or using only the most basic shared libraries. This would definitely benefit their platform, as your app would be easier to port, but it would entirely negate the rapid app development advantage offered by the iPhone (and Mac OS X, for that matter) frameworks over every other API out there. And to top it off, you’d be going through all this extra effort for what is becoming an ever smaller marginal increase in revenue.
While I do recommend creating code with an eye toward portability (especially stuff like custom drawing or OpenGL code), my advice to developers seeking to do a multiple-platform release is the same advice I’d give to a desktop developer: create a common C library for handling proprietary data formats, specialized encryption, custom communication protocols, etc. Then, build your UI using the native frameworks available on each device, taking advantage of each platform’s special functionality, and maximizing the fit and finish for each.
Unless you’re living in a Faraday cage, you’ve seen the Internet hype around Android, Google’s mobile platform. The iPhone-alternative seekers and FOSS evangelists are engaging in a collective circle-jerk around it, because it has the potential to “beat the iPhone” and bring open-source to mobile. I think it will definitely have a profound impact on mobile devices, and there’s no disputing that an open mobile platform is exciting, especially one backed by Google. But guys, I’m not ready to circle up just yet. My apologies.
Yes, Open Source is definitely awesome, but its potential for “beating the iPhone” is limited. If there’s one way that Apple humiliates everyone else, it’s with their ability to make something universally usable. Personally, I love all that Android’s open nature has to offer the hardcore power users and developers. Open-source is great, offering infinite freedom for niche geeks like you and I, but that doesn’t translate to something that’s going to make it in the mainstream market.
Here’s a truly rare bird: a UI heuristic where most GUI toolkits get it right, but Apple (Cocoa) goes horribly wrong. In the above example, what will happen when “List” is selected? On the Mac (right), It’s not clear, is it? Will “List” also become checked, or will “Large Icons” become unchecked?
In virtually all pull-down menu implementations across all platforms, there are basically three types of functionality for any menu item (which does not have a submenu, and is not a separator):
When developing a Mac OS X application, you can specify what extensions your app can open. Furthermore, you can specify, for each document type, whether your app is able to open that document for editing, or just as a viewer.
So why is it that I can not utilize this differentiation in the Finder? For any given “.jpg” file, why can I not choose to view it (using Preview.app), or edit it (Adobe Photoshop CS2.app)?
The experience could be simple enough: double-click to view, triple-click to edit. Command-O to view, Option-Command-O to edit. Think of the time you would save that is otherwise spent tediously dragging an image to an icon in the Dock.
With the capabilities now built into the core of Mac OS X, the “Open” command just doesn’t cut it. I Demand Better User Experience.