Comments on: Cocoa code branching per release?

By: Sean Patrick O'Brien

Sean Patrick O'Brien — Mon, 16 Jul 2007 19:04:58 +0000

Check the release notes and connect.apple.com for info on a Tiger compatible IB version in 10.5. You should be pleasantly surprised. :)

By: Chris Hanson

Chris Hanson — Sat, 30 Jun 2007 23:36:43 +0000

I doubt that would work; a 10.y SDK is free to use features from 10.y itself (for example, changes to the compiler, such as the introduction of a deprecation attribute in GCC 4 with Tiger) which may not be available on 10.x.

By: Mike Zornek

Mike Zornek — Sat, 30 Jun 2007 08:21:28 +0000

@Chris Thanks so much for the help. One more question: I have a Tiger hard drive and a Leopard hard drive for my Mac Pro. Could I use Xcode 2.4 on Tiger and point it to the sdk living on the Leopard HD to build against that SDK? I ask cause I’m not ready to live in 10.5 yet. My NIBs (cause they use some open source IB Pallets that haven’t been upgraded to IB 3 yet, and who even knows how ready IB3 is for such things) don’t open in IB3 so it’d be really awkward to do all the code in Xcode and reboot to 10.4 just to edit the NIBs.

Old IB used to be in the seeds. I don’t know where it went. :-(

Thanks again.

By: Chris Hanson

Chris Hanson — Sat, 30 Jun 2007 04:54:01 +0000

You're sort of right that you have to use the "if" block to interact with a 10.y-only class from code that might run on 10.x (where y = x + 1; this has been true since Jaguar). You actually need to use NSClassFromString to refer to the class itself as well:

Class MyNSNewCoolClass = NSClassFromString(@"NSNewCoolClass"); if (MyNSNewCoolClass != nil) { id coolInstance = [[MyNSNewCoolClass alloc] init]; }

Jonathan is right to suggest using a separate bundle; this is required if you want to subclass 10.y classes.

There's one correction I'd like to make though. When you build against an SDK, that SDK defines which version of the Mac OS X APIs you're building against. There's a separate build setting - the Mac OS X Deployment Target - that defines the earliest version of Mac OS X that you want your code to run on. This causes any global symbols (functions, global variables like notification names, etc. - sadly not classes though) introduced with a later version of Mac OS X to be weak-linked and automatically nil when run on an earlier OS.

Thus you can write an application that runs on Mac OS X 10.3 but uses 10.4 API when present by doing the following:

(1) Building the application against the Mac OS X 10.4u SDK, because that's the version of the API you want to use.

(2) Setting the application's Mac OS X Deployment Target to 10.3, because that's the minimum system you want it to run on.

(3) Checking that any functions or global symbols introduced in 10.4 are nil before using them.

(4) Using NSClassFromString as above to interact with classes introduced in 10.4.

(5) Using a separate bundle to subclass 10.4 classes.

Hope this helps!

By: Jonathan Wight

Jonathan Wight — Sat, 30 Jun 2007 04:02:58 +0000

Compile your main code for 10.4.

Put 10.5 specific code into a loadable bundle...