Making the move to the Mac

As should be pretty clear from previous ramblings, I've about given up on Windows and am in the process of trying to reinvent myself as a Mac developer (I should perhaps say re-reinvent myself, since I worked with Macs back in the early days of the original 128K Mac, over 20 years ago). Things are going pretty well so far, …

[Ian Halstead]

There's something wrong...

... I understood every word, and the only thing I've ever programmed is a clockwork cooker timer. Well written.

[Anonymous Coward]

Looking forward to the mini-series

Nice, looking forward to it. Although could you also compare how it differs to Java? My C++ is practically non-existent!

[David Harper]

Or you could just use Java ...

... and bypass the whole OS-dependency thing altogether.

And your apps would work on Linux too, with no extra work, earning you the love and admiration of penguinistas everywhere.

[Gavin Lyons]

Prepare to re-wire your head with Objects and Connections :-)

It's best not to think of Java. So comparison would be confusing. The syntax and back to pointers for objects is real guts of it. Then there's Interface Builder and wiring up the classes, actions and outlets. These things are things to get your head around. Aaron Hillegass has excellent book on Mac coding.

[Aric Friesen]

Well written, good work

I look forward to your coverage of Interface Builder, which I think is the most difficult component for a someone to get used to when moving from say Visual Studio or Delphi to XCode.

[Blain Hamon]

Vs. Java

As it might or might not have been mentioned, Obj-C was one of the inspirations for Java. The real difference is not just C and its speed, but in what things are vs. what they can do.

A big win of Obj-C and cocoa is the delegate and protocol concepts. That is, rarely do you subclass in as much as simply support various messages; since it's dispatched at runtime, it'll work out. If it handles the functions fine, who cares what the internal structure looks like?

As for UI, there is a Cocoa for Java API, but it's quickly falling by the wayside. And using straight Java is pretty much a garunteed failure. Not just for the usual reasons (Speed, etc) but because mac users are very demanding on the interface. What is perfectly fine for Windows and Linux is considered barely marginal at best for the Mac.

For example, we expect any text field to support the text-to-speech, interapplication drag-and-drop, the full spell-checker, unicode and multi-lingual support, and the other services in text fields. Fortunately, NSTextField provides all this for free. Want a spell-checker in your program for this text field? Check a box in Interface Builder. These are features that a one-size-fits-all approach will fail to have.

[Graham]

Good to see

I'm a Mac developer who moved to Cocoa about three or four years ago, and has never looked back (I was using C++ before that with Carbon). It's good to see articles like this coming from a not obviously Mac-related site. As a professional developer I find Cocoa to be the most productive API (and with Xcode, toolset) I have ever used, bar none. And that' s by a considerable margin. I'd say to anyone wanting to dip their toes in the waters of Mac development: go for it. Obj-C's syntax might seem odd at first but after a while you'll appreciate its readability if not actually love it. And you can build a very functional small app (say, a complete word processor) in an hour or two which should be enough to impress the most hardened old coders. As for Java - well, it may be cross platform but (Mac) users know a Java app when they are forced to use one, so if you really want to make "proper" Mac apps, Cocoa is about the only reasonable way. I also find Java's documentation and class libraries bewilderingly complex compared to Cocoa's. Cocoa isn't perfect and has a few holes, but one of the great things about it is that plugging them is really easy (thanks to categories, among other things). I could go on... but I think I've made my point.

[Anonymous Coward]

Meanwhile, back in reality-land...

"But the end-user sees only a single file which can be installed by simply dragging to the Applications folder or de-installed by dragging to the trash. Ah, if only Windows worked like that."

There are lots of Mac apps that require installers - heck iLife - arguably the showcase Mac app set - requires an installer. Anything that comes in a .pkg file is going to be using an installer. If you just drag the application to the trash for these, you'll leave bits of the application behind - and you may even break tasks that the installer installs. The day of 'uninstall any app by dropping the app in the trash' disappeared a long time ago and it's weird that this myth is still being promoted.

On the flip side, .Net apps (which are the foundation of Windows moving forwards) not only do not require an installer (although they may use them) - the use of them is highly discouraged (xcopy is preferred). All .Net apps I write are drag install/uninstall. None of them have installers.

I hope the rest of this article series is a bit more accurate...

[Douglas Norton]

Xcode - lowercase 'c' please

There's this guy at Apple who will correct people who post to Apple's discussion lists when they write XCode.

I would recommend anyone interested in Mac programming to visits lists.apple.com and sign up for the Cocoa list (lot of traffic, sometimes daunting so stick with it), and the Xcode list.

[Anonymous Coward]

RE: Looking forward to the mini-series

Anonymous said: "Nice, looking forward to it. Although could you also compare how it differs to Java? My C++ is practically non-existent!"

Hi Anonymous. I don't really want to get too bogged down in language comparisons. The main aim here is to look at things from a typical Windows developer's POV. I guess you could argue that a Windows Java developer moving to the Mac will just carry on using Java. Or so the Java zealots would have us believe. ;-)

Uncle Mac

[Anonymous Coward]

RE: Xcode - lowercase 'c' please

Sorry Douglas. I guess old (case-insensitive!) habits die hard...

Uncle Mac (one time Delphi programmer) ;-)

[Anonymous Coward]

RE: Meanwhile, back in reality-land...

Anonymous said:

"There are lots of Mac apps that require installers - heck iLife - arguably the showcase Mac app set - requires an installer."

In context, I was trying to explain bundles & frameworks, not trying to write an article on Mac installer technology. For sure, there are Mac apps which you can't just drag-install. But there will always be exceptions on both sides: contrary to what you imply, for example, there are plenty of .NET apps which use a custom installer.

I believe that one of the reasons iLife uses an installer is because it installs a certain amount of shared stuff into /System/Library/PrivateFrameworks. As an example, iLife '08 updates the media browser framework. But at the expense of some extra disk space, there's no reason it had to be done that way...

Uncle Mac

[Anonymous Coward]

Re: .NET install/uninstall

"All .Net apps I write are drag install/uninstall. None of them have installers."

Really? So you never put anything in the GAC? That doesn't sound like a proper .NET app to me!