31

I want to start learning to program for OSX but have only programmed for iOS.

What are the significant differences on a programming level other than hardware related issues such as memory, processing power etc.

In terms of the actual api and programming, like items to be used by the mouse and keyboard rather than the touch screen.

I would like some advice from people who have experience with this and possibly good book links or tutorial links to get started.

Thanks

some_id
  • 29,466
  • 62
  • 182
  • 304

4 Answers4

23

Let me put it this way: Don't just try to port all your stuff over to the Mac without thinking about design principles. A lot of developers are seeking to get on the Mac developer bandwagon without putting time into their apps. Simply moving apps from iOS to Mac doesn't bring forth good interfaces.

Face it, iOS is built for touchscreen, while Mac is not. Thus, simply transferring your interface over might work, but it is bad and frowned upon by many users. What I would do is just download some well-known Mac applications (demos work fine), and just study how the interface is laid out compared to iOS. There are similar concepts, but there are more differences than similarities.

The most fundamental difference is that the interface on the iPhone can only have one window, while the Mac can have unlimited windows (theoretically). Stuffing all your views into one window just doesn't cut it on the Mac. Users have come to expect multiple windows, and honestly it's a much better way to do it.

So my suggestion is to learn Cocoa from the ground up, and then think about transferring your apps over...not by simply porting it, but instead by making a completely new interface. Your model can still be used, because both platforms use Objective-C.

Platforms so similar, yet so different. :)

enter image description here

sudo rm -rf
  • 29,408
  • 19
  • 102
  • 161
  • 1
    Thanks sudo rm -rf. I am planning to learn OSX from the ground up without trying to port anything at first. And yeah, its a lot better designing apps with so much screen resource space. I will get a cocoa book and work through it. Thanks – some_id May 06 '11 at 18:53
  • 1
    No problem. I'm a relatively new programmer, and I started out with iOS. Transferring over to Mac was hard initially, but once I wrapped my mind around `NSViewController`s and how windows are created and destroyed, it wasn't that hard. I've learned to love Cocoa Bindings. They're magic. :) – sudo rm -rf May 06 '11 at 18:59
  • 1
    Awesome. well, my "Desktop" experience is with Java, and using Swing is a nightmare. – some_id May 06 '11 at 19:05
  • and yeah, those images you posted really confirms how the window size effects user experience and design capabilities. – some_id May 06 '11 at 19:11
  • 1
    It sure does. Toolbars really change the way that the user interacts with your application, **as well as menu items**. – sudo rm -rf May 06 '11 at 19:12
11

In writing a modern OS X app you will typically use Data Binding to connect your model(s) to your view(s), ofter via generic controllers like NSArrayController.

Wrapping one's head around Cocoa Data Binding is a challenging task for newcomers, at first very frustrating and then very exciting. If your master Data Binding it may fundamentally change the way you design your software.

The problem is that none of your iOS apps were designed with Data Binding in mind, and that's a bridge you will have to cross in order to be a happy and effective OS X developer (along with learning the various sundry SDK differences)

Darren
  • 25,520
  • 5
  • 61
  • 71
9

I went the other way 2 years ago and had an unexpectedly hard time moving over.

OS X is a much older, and was created before Objective-C 2.0 so there aren't very many properties in the legacy AppKit / CoreFoundation classes. Most of my old iOS code looks like:

[[self navigationController] popViewControllerAnimated: YES];

The UI: most of the resoponder/view/control hierarchy is similar, but now called NS (from the latin for NextStep) rather that UI (latin for little screen).

Controls:

a bit different, you connect an action to a control and the control decides when to send the action message, ie. if a scroll bar is set to continuously send the message or not. which is slightly different to the way UIkit does it, where you connect to an event type: value changed, touch up inside, etc.

You get more than one Window in OS X which gives you new opportunities and challenges. You have to worry a lot more about responder hierarchy.

The little things will always get you, like in UIBezierCurve the methods are named ever so slightly differently than NSBezierCurve, addLineToPoint: rather than lineToPoint:

Pay attention to your compiler warnings and grab a new book and you will be fine.

Vivo
  • 768
  • 1
  • 8
  • 20
Grady Player
  • 14,399
  • 2
  • 48
  • 76
8

The 2 platforms have gotten a lot more similar over the years, with many OS X APIs being migrated to iOS. The main difference I think is the UI pieces. On OS X you use AppKit to present your UI instead of UIKit. (Although you can use Interface Builder for both).

Some APIs have made the reverse trip: CoreLocation used to be an iOS-only framework and it's now available on OS X.

Other changes:

  • The event models are different (NSEvent vs UIEvent).
  • CoreImage is available os OS X

Depending on your experience level, I'd start with some of the Apple-provided AppKit examples in Xcode. HTH

nielsbot
  • 15,922
  • 4
  • 48
  • 73