I would like to ask which is the best strategy for creating an application that will be developed both on Mac and iPad, so to make minumum effort to port it from one platform to the other, starting from iPad, for example, but rather trying to make both at the same time. The application, in fact, would be an iPad-style one on the Mac too. How should I have to plan the project? Which are the main tricks to easily get the goal?
-
Have you determined that the UI will work well on the Mac? There's two distinctly different kinds of hardware packages here.– David ThornleyJan 12, 2012 at 15:10
-
The app is very simple so it appears the same on both the platforms. It would need little adjustments for the mouse or trackpad events to replace touch events. I just ask for some advice for not wasting too much work by making wrong early decisions. In the Cocoa guide they say that the two platforms are not so different.– P5musicJan 12, 2012 at 15:32
3 Answers
You'll have to recode the UI no matter what. The OS X UI is different enough to the iOS UI to mean that any lesser attempt at porting the UI direct (such as the one mentioned by Chiron) is going to result in a less than perfect compromise.
For instance:
- OS X users expect there to be a set of menus on the menu bar through which you can access most of the functionality. There's no direct equivalent on iOS.
- OS X users expect resizeable windows.
- OS X users expect to be able to open multiple document windows (if your app is a document based app).
- Many iOS style controls simply do not work well if your input device is a mouse.
- Some of the OS X style controls have richer functionality while also being easier for the programmer to use than their iOS "equivalents" (compare NSTableView with UITableView).
So, given that you need to redesign your UI, you need to separate the functionality from the UI as much as possible. This is somewhat encouraged in MVC anyway. However, one way to enforce this is to physically separate the model (the M part) by compiling it as a static library on iOS and a framework on Mac OS X. Careful design of the controllers (the C part) using maybe protocols or delegates might allow you to reuse some code there too.
Anyway, the one thing you should never do (this applies to any app on any platform) is compromise the UI in the name of portability.
I can't really answer your question but I may suggest a new route.
Have a look at Chameleon Project:
If you're an iOS developer, you're already familiar with UIKit, the framework used to create apps for the iPhone, iPod and iPad. Chameleon is a drop in replacement for UIKit that runs on Mac OS X. In many cases, your iOS code doesn't need to change at all in order to run on a Mac.
This new framework is a clean room implementation of the work done by Apple for iOS. The only thing Chameleon has in common with UIKit are the public class and method names. The code is based on Apple's documentation and does not use any private APIs or other techniques disallowed by the Mac App Store.
It is used to develop Twitterrific.
Design the model for reuse. There's very little that's platform-specific about a data model, and you should be able to use the entire model on both iOS and MacOS X. As much as possible, you'll want to include business logic in your model so that any given operation yields the same result on either platform.
Create a visual design that can be reused. Using the same aesthetic elements (color palette, textures, proportions, terminology) in the same ways in both applications will go a long way toward making the user feel that your program works the same way on both platforms.
Make the most of each platform. Forget about reusing user interface code or even reimplementing the same UI on both platforms. Users will want your app to feel the same on both platforms, but they won't want it to be the same. Take advantage of the larger screen, menu bar, and windows on MacOS X, and the touch interface on iOS. You can show lots of information at the same time on MacOS X; on iOS it's better to stick to one or two kinds of data at any moment.