port an iOS (iPhone) app to mac?

Is there a preferred way to go about this?

The app in question is not too large . . . single-player game that I wrote over the course of a couple of months.

EDIT: I should add that I have no experience with mac development . . . outside of what 开发者_运维百科comes naturally with being an iOS developer.

EDIT: Classes heavily used in the game: subclasses of NSObject, UIView, and UIViewController. I don't know much about NSView, but I'm pretty sure all the UIView stuff will work in that class. Also some use of UITableViewController. I do also have Game Center, but I can leave that part out for now. There is no multi-touch.

EDIT: My graphics is all stuff that is in the QuartzCore and CoreGraphics frameworks. I do have a moderate view hierarchy.

EDIT: If you are doing such a port, you may also be interested in the issue of memory management

1. There's no easy way. It's that simple. Depressingly, you simply have to become good at programming the Mac.

2. "I'm pretty sure all the UIView stuff will work in that class" -- unfortunately, no. Everything is different that enough you have to work hard.

It's not a fun gig. Make sure you really, really think it's worth it financially.

Apart from anything else, be aware of the "sibling views don't work on OSX" problem if you stack up a lot of views in your iOS app. Essentially, you will have to change to using layers (instead of simply views) on the Mac if you rely on nested hierarchies of views here and there on the phone!

Click this link: Is there a proper way to handle overlapping NSView siblings? for the gory details on that particular problem!

http://chameleonproject.org/ UIKit for Mac from Iconfactory is worth checking out.

"Chameleon is a work in progress. The framework currently implements about 60% of UIKit after nine months of work."

https://github.com/BigZaphod/Chameleon

You may have a lot of work ahead of you. While purely algorithmic classes will port without any change, anything that touches UIKit will likely need to be rewritten, or heavily adapted. The UI class design pattern on OSX is that of a relationship between views, where your code is responsible for managing controllers; while on iOS it is one of a relationship between view controllers, where view management is implied.

Of course, as BoltClock mentioned, you have the issue of interaction. Since touch no longer works, you will probably need to work on your interaction model first, even before you start porting.

There exists an open source (BSD) UMEKit library that may help with porting a few UI classes, but you may have to rewrite a fair amount of the UI to better handle the mouse/keyboard/multi-window/menu GUI environment. Basic NSObjects, and some Open GL and Quartz graphics rendering, may port with only minor touch ups.

As others say, porting can be a chore. The general techniques work, though. You redesign the interface in Interface Builder (where applicable) and check what the different controls are called (CocoaTouch only has a small subset of typical desktop controls). UI* typically becomes NS*. Tableview delegation is similar, so it will probably be easy.

I'll have to recommend the Aaron Hillegass book as usual. It's a great introduction to Mac development, and knowing iOS development gives you an edge.

Since it's a game, you probably need to consider how to do fullscreen mode. The game doesn't necessarily take up the entire screen anymore, and you shouldn't force it. A whole new set of preferences will now be necessary. There is of course some "fun" involved now that there are new ways to handle resolution listing/changing with Snow Leopard (with the previous ways giving you deprecation warnings).

Just accept that there will be a possibly lengthy transition period until everything "clicks" :)