macOS Porting an iPhone app to the Mac?

[firewood]

I've developed a couple dozen iPhone apps, several in the App store. Now I'd like to port a few of them to run on a Mac without the Simulator environment.

How much work would it be to port the source of a basic iPhone UIKit app so that it runs natively on a Mac?

Are app delegates, text views, buttons, Core Graphics, audio queues, etc. mostly the same between the iPhone UIKit and the Mac Cocoa frameworks? Or will significant rewrites be required in these areas?

What's the minimum new code that has to be added? I assume at least an outlet to handle a "Quit" menu item. Anything else necessary?

Thanks.

 

[kainjow]

The UIKit doesn't exist on Mac OS X. Instead you have AppKit which is similar. None of the UI* classes exist, instead you have NSTextField, NSApplication, etc. Your existing Core Graphic functions will work, but depending on how your Mac UI will be setup, you probably won't reuse much of it because OS X has the built-in NSBezierPath class which greatly simplifies drawing for you. For playback of audio files, you can use NSSound and QTKit.

Most likely you're going to redo your UI completely since the iPhone UI doesn't make sense on the Mac, unless you have a game or something that uses a custom UI.

 

[firewood]

It's a custom UI, Core Graphics (with some particle animation rendered into a bitmap) with some text fields and buttons on top. Also audio synthesis using either Audio Unit RemoteIO or Audio Queues. Are there any major differences between UIKit and Cocoa AppKit that might require a major rewrite in these limited areas?

I, at least, assume that it will be far far easier to port my current iPhone code than anything from my old pre-Carbon MacOS System 7 codebases (anyone here remember Consulair C, Lightspeed C or Think C?)

 

[kpua]

Like kainjow said, the UI in UIKit and AppKit are completely different, but they should be, considered one uses purely a touch interface, and the other is a traditional mouse/keyboard interface.

There are a lot of similar paradigms between UIKit and AppKit though. For example, both a UITableView and NSTableView have delegates and dataSources to populate and control them.

On the other hand, where in UIKit you usually architect your apps around UIViewControllers and UIViews (at least, I think that's true... I haven't done much UIKit work myself), with AppKit, you'll likely need to throw NSWindowController's and NSWindows in the mix too. I don't think you'll need to drastically modify your architecture, just add a little to it.

Since it seems like your app relies more on Core Graphics and audio APIs, I would be more concerned about the potential differences between those libraries on the phone vs the desktop. Unfortunately, I'm not aware of what differences there might be there.

 

[kainjow]

It's a custom UI, Core Graphics (with some particle animation rendered into a bitmap) with some text fields and buttons on top. Also audio synthesis using either Audio Unit RemoteIO or Audio Queues. Are there any major differences between UIKit and Cocoa AppKit that might require a major rewrite in these limited areas?

I'm not familiar with those audio APIs but if you have custom UIViews, it should be very easy to port those to NSViews, which has an almost identical drawRect: method.

Some of the UIImage functions that UIKit has for creating images to draw into can be done just as easily with NSImage and NSBitmapImageRep.

And since you're already using lots of CGContextRefs everywhere, the easiest way to get one from an NSView or an NSImage is:

CGContextRef ctx = (CGContextRef)[[NSGraphicsContext currentContext] graphicsPort];

 

[ghayenga]

It's a custom UI, Core Graphics (with some particle animation rendered into a bitmap) with some text fields and buttons on top. Also audio synthesis using either Audio Unit RemoteIO or Audio Queues. Are there any major differences between UIKit and Cocoa AppKit that might require a major rewrite in these limited areas?

I, at least, assume that it will be far far easier to port my current iPhone code than anything from my old pre-Carbon MacOS System 7 codebases (anyone here remember Consulair C, Lightspeed C or Think C?)

If you don't have a lot of UIViewControllers pushing and popping, and aren't using the touchesBegan, touchesMoved, touchesEnded parts of UIViews then switching to NSButtons and NSTextFields should be relatively minor changes. And it sounds like you don't have a complex iPhone specific UI design either.

Speaking as someone who has used both Lightspeed and Think C it will indeed be *far* easier to port your iPhone apps over to the Mac than update those old versions.