Questions: Development for Mac OS X on a PPC system

[Richard Kiernan]

Recently, I received an operational Power Mac G5 with the dual 2.0GHz processor configuration from 2005. This is the first Macintosh computer I've owned, although I'm not exactly short of computers otherwise; I own five x86 computers running Windows or Linux, along with a modified Wii running Linux, and I have an ARM-based Raspberry Pi on the way. Suffice it to say that I don't really "need" the Power Mac, particularly not for internet browsing, word processing or other light computer tasks.

That said, I want it to earn its keep, as it were. I'm an IT student at the moment, and I have enough computers running Linux not to just want to turn the Power Mac into Yet Another Standard Development Box. Therefore I'm looking for tasks to do specifically with Mac OS X. Having ruled out iOS development because of the age of the computer, my mind has turned to Mac OS X development.

I had a couple of questions to do with that. Given that the Power Mac is running Mac OS X 10.4 Tiger, I was wondering how close that operating system is to Lion. Specifically, are Universal Binaries still supported on Lion? If not, could I write a GUI application in Tiger using Objective-C and port the source code over directly to Lion, expecting it to compile without any changes required?

 

[goMac]

Leopard from a developer/library standpoint is not at all close to Snow Leopard or even Lion.

Not to say you couldn't write software targeted for 10.5 or lower. But 10.6 was a big shift in the underpinnings, mostly because of all the PowerPC stuff that was dropped. But you'd be stuck with Obj-C 1.0 and all the older APIs, meaning most the newer content out there for learning Mac programming wouldn't be useful to you.

I also wouldn't bother writing software for Intel Macs without having an Intel Mac to test on.

 

[Madd the Sane]

10.5 did introduce Objective-C 2.0 and Garbage collection. In fact, my Cocoa SVG importer uses the @property keyword a lot. In fact, on 10.5 you can build a four-way universal binary. 10.6 did move towards more formal protocols and away from informal. 10.6 didn't drop PowerPC support: 10.7 did.

One thing I will caution you about: the LLVM-GCC seems to have issues on PowerPC: keep to GCC 4.0 or 4.2.

 

[goMac]

10.5 did introduce Objective-C 2.0 and Garbage collection. In fact, my Cocoa SVG importer uses the @property keyword a lot. In fact, on 10.5 you can build a four-way universal binary. 10.6 did move towards more formal protocols and away from informal. 10.6 didn't drop PowerPC support: 10.7 did.

One thing I will caution you about: the LLVM-GCC seems to have issues on PowerPC: keep to GCC 4.0 or 4.2.

Garbage collection is dead and Apple is telling people not to use it. Just noting that in case anyone is visiting this thread in the future. Do not use garbage collection.

You want to use ARC instead, which requires the 10.7 tools.

10.5 does not support the full set of Objective 2.0 features, specifically blocks. Blocks are extremely important, especially with Grand Central Dispatch. Without those things you're out of sync with current Cocoa.

I would highly recommend against this. Even if you can compile universal binaries, you have no way to test them, and no path into the Mac App Store.

 

[TacticalDesire]

You could be a PPC developer . There seems to be a shortage of those these days.

 

[TSE]

Do not expect any recent software to be written or compiled for Mac OS X Leopard or PPC apps, except for a few browsers, etc.

Do not expect making any money off being a PPC developing if you go that route, although it would be appreciated by the small (and extremely diehard) amount of PPC fans around.

Facts are PPC is getting long in the tooth and is only acceptable for the most basic of tasks.

 

[Madd the Sane]

10.5 does not support the full set of Objective 2.0 features, specifically blocks. Blocks are extremely important, especially with Grand Central Dispatch. Without those things you're out of sync with current Cocoa.

I would highly recommend against this. Even if you can compile universal binaries, you have no way to test them, and no path into the Mac App Store.

IIRC, Blocks are a C extension, not Objective C. I'm also pretty sure that Apple posed Leopard's Objective C runtime as Objective C 2.0, not Snow Leopards'.

It also hasn't got to the point that you need to use Blocks in your code: they help, but aren't neccesary.

As for the App Store: there are other ways to distribute apps on the Mac. In fact, some classes of apps can't be on the App Store.

Also, ARC is good, but is limited to 64-bit apps at this time. It will also be hard for Apple to re-implement the 64-bit System Preferences, which have to be garbage-collected.

 

[goMac]

IIRC, Blocks are a C extension, not Objective C. I'm also pretty sure that Apple posed Leopard's Objective C runtime as Objective C 2.0, not Snow Leopards'.

They are a C extension but Obj-C heavily depends upon them. Objective-C, after all, is also a C extension.

It also hasn't got to the point that you need to use Blocks in your code: they help, but aren't neccesary.

If you're using the new APIs, they are necessary. You cannot not use them anymore.

But you need a 10.6 machine to use the new APIs anyway, so I suppose it's a mute point. It does mean you can't use a PowerPC machine to learn the current Mac APIs though. You'll be stuck coding for the past, which is fine if that's your thing.

As for the App Store: there are other ways to distribute apps on the Mac. In fact, some classes of apps can't be on the App Store.

Sure there are. Just sayin, don't expect to be on the Mac App Store.

Also, in since you can't sign from 10.5, don't expect to be on many 10.8 Gatekeeper machines anyway.

Also, ARC is good, but is limited to 64-bit apps at this time. It will also be hard for Apple to re-implement the 64-bit System Preferences, which have to be garbage-collected.

Again, and I can not repeat this strongly enough, do not use garbage collection. Apple has told people not use it. It has bugs. The bugs will never be fixed.

Given that we're talking about a PowerPC that can't even compile ARC, 32 bit a non issue. Just don't expect to learn current development without ARC. You can learn manual memory management, but again, not current. Do not use garbage collection. It's preferable to use manual memory management over garbage collection. They've even hidden the garbage collection option away in current versions of XCode it was so bad.

Apple added Garbage Collection -> ARC conversion to the latest XCode, so I don't think Apple migrating sys prefs will be an issue at all. But that's unrelated. They'll just make people recompile third party sys prefs like they always do.

 

[tdbmoss]

Specifically, are Universal Binaries still supported on Lion?

Yes, Universal binaries are still very much supported, it's only PowerPC-only applications which will no longer run on Lion as Rosetta was removed, so you shouldn't have any trouble making something that runs on a PPC running 10.5 and an Intel running 10.6/10.7. You should definitely get 10.5 Leopard though; 10.4 Tiger is very old these days. It is very easy to virtualise Lion in VMware on an Intel-based PC that has VT by the way, if you want to test your work on Intel 10.7 as well (OS X is only officially licensed for virtualisation on Apple hardware though).

There was an older version of the iPhone Simulator application that ran on PPC (although the iOS SDK was always said to be Intel-only; the earlier versions of the Simulator were actually compiled by Apple as a Universal binary) though I suspect that while you can run that and it's good to see it on a PPC, you can't actually do iOS development on the PPC (and even if you could, it's an old version).

 

[Richard Kiernan]

OK, so what I'm gathering here is that it's possible, by virtue of the Universal Binary system, to program something which would work on both PowerPC and Intel, but that it wouldn't be the ideal measure by any means. I'm not expecting any miracles, to be honest, so any sort of benefit would be a bonus, and if not, I still have a fairly nice system.

Again, and I can not repeat this strongly enough, do not use garbage collection.

Don't worry. I've never thought that garbage collection was all that desirable with any language that wasn't a Lisp dialect.

It is very easy to virtualise Lion in VMware on an Intel-based PC that has VT by the way, if you want to test your work on Intel 10.7 as well (OS X is only officially licensed for virtualisation on Apple hardware though).

Would this also work with AMD-V? The idea's broadly the same behind both virtualisation schemes, but I'm aware that Apple hasn't used AMD processors, and while I'm looking covetously at Ivy Bridge, I don't think my fortunes stretch enough to get a new processor, motherboard, RAM and all the rest.

 

[Madd the Sane]

There was an older version of the iPhone Simulator application that ran on PPC (although the iOS SDK was always said to be Intel-only; the earlier versions of the Simulator were actually compiled by Apple as a Universal binary) though I suspect that while you can run that and it's good to see it on a PPC, you can't actually do iOS development on the PPC (and even if you could, it's an old version).

I think there was an issue with signing apps, IIRC. That and I doubt that Apple would accept apps written using such an old version of iOS.

Would this also work with AMD-V? The idea's broadly the same behind both virtualisation schemes, but I'm aware that Apple hasn't used AMD processors, and while I'm looking covetously at Ivy Bridge, I don't think my fortunes stretch enough to get a new processor, motherboard, RAM and all the rest.

As far as I know, OS X support for AMD processors is nonexistent. You would probably have better luck using a patched version of Qemu.