macOS target 6 and implement 7 ?

[zeppenwolf]

I would like my application to run on X.6, but also implement features introduced in X.7

In the case of NSWindowRestoration, I'm stuck.

Calling member functions which may or may not exist seems easy enough, I think:

SEL	setRestoreClassSel = NSSelectorFromString(@"setRestorationClass");
if ( [self respondsToSelector:setRestoreClassSel] )
    [self performSelector:setRestoreClassSel withObject:[self class]];

What I can't figure out is how to instance an NSWindowController which does or doesn't conform to <NSWindowRestoration>. It's like I need two separate classes:

@interface MyWindTrol6 : NSWindowController

and

@interface MyWindTrol7 : NSWindowController <NSWindowRestoration>

and I need to runtime pick which one gets instantiated, somehow from the X.6 code which knows nothing about a <NSWindowRestoration> protocol.

Can it be done, or am I peeing in the wind here? The decision to call or not call a member function was so easy, after all...

 

[hokan]

Does XCode complain if you add <NSWindowRestoration> when Base SDK = 10.7 and a OS X Deployment Target = 10.6 ?

A protocol is basically only a way to tell the compiler that certain methods are implemented by a class. The protocol is defined in a header (somewhere in Xcode). As you compile for 10.7 I would guess that your Xcode includes the 10.7 headers and SDKs.

My guess would be that Xcode will compile, if you add the NSWindowRestoration protocol to your class and implement the protocol methods.

Running on 10.6 should pose no issues as the NSWindowRestoration methods will never be called, so the implementation of them can assume that they are only called from 10.7.

 

[zeppenwolf]

Does XCode complain if you add <NSWindowRestoration> when Base SDK = 10.7 and a OS X Deployment Target = 10.6 ?

No, it doesn't complain.

A protocol is basically only a way to tell the compiler that certain methods are implemented by a class.

I think I intuited that part-- a protocol is really just an artifice of the compiler in aid of the programmer.

Running on 10.6 should pose no issues as the NSWindowRestoration methods will never be called, so the implementation of them can assume that they are only called from 10.7.

So anyway, I've tried monkeying around... including setting the build options to Base SDK = 10.7 and a OS X Deployment Target = 10.6, but I can't get any benefit, so far. With Target=X.6, I can't get it to invoke the X.7 methods:

SEL	setRestoreClassSel	= NSSelectorFromString(@"setRestorationClass");
if ( [self respondsToSelector:setRestoreClassSel] )
	[self performSelector:setRestoreClassSel withObject:[self class]];
else
	NSLog( @"MyWindController doesnt respond to setRestoreClassSel" );

prints out the "doesn't respond" message, even though Base=X.7

At the same time, I can't get over the curiosity that you pointed out: if "base SDK" and "Target" were identical in purpose, then Xcode wouldn't need them both... And if Xcode has both, and allows them to be set differently, then what is the benefit?

Aaargh....

 

[hokan]

SEL	setRestoreClassSel	= NSSelectorFromString(@"setRestorationClass");
if ( [self respondsToSelector:setRestoreClassSel] )
	[self performSelector:setRestoreClassSel withObject:[self class]];
else
	NSLog( @"MyWindController doesnt respond to setRestoreClassSel" );

prints out the "doesn't respond" message, even though Base=X.7

At the same time, I can't get over the curiosity that you pointed out: if "base SDK" and "Target" were identical in purpose, then Xcode wouldn't need them both... And if Xcode has both, and allows them to be set differently, then what is the benefit?

Aaargh....

Are you running the code on a OSX 10.6 system ? -respondsToSelector: is a runtime check so will return YES/NO depending on the OSX version the mac was booted into. I would recommend multiple OSX installs (on HD partitions or VMs) for testing.

OS X Deployment Target is essentially the minimum system requirement of the app.

Base SDK is usually set to "latest" - which OSX version this expands into will depend on the version of Xcode. Note that OSX may occasionally chose to support old class/method behaviors for compatibility reasons when the current OS is newer than the Base SDK used to compile the app.

 

[zeppenwolf]

Well, it works!

Hallelujah and Praise Ozzy it really works!

I have to admit that I'm having trouble understanding how... But thanks to you, I've found the "SDK Compatibility Guide", wherein Apple tries to explain it to dummies like me... And I still don't quite get it, I mean, what is *really* happening in machine code when BaseSDK != TargetOS, but I suppose I'll get it eventually. At least for now I got around the catch 22 of <NSWindowRestoration>, and my executable behaves as desired and expected on both 6 and 7.

tHnaks!!

 

[hokan]

... , I mean, what is *really* happening in machine code when BaseSDK != TargetOS, but I suppose I'll get it eventually.

Nothing is happening in the machine code (to my knowledge).
The Base SDK and OS X Deployment Target are simply stored in a .plist file inside the .app folder.

OS X Deployment Target acts as the minimum OS version which tells OSX if the app can be run on the current OS version that the user is using. If the OS is to old it will refuse to start the app and also mark the app icon in some manner to indicate this.

Base SDK is a kind of "maximum" OS version which tells newer OS versions if certain OS frameworks should behave more like they did in the Base SDK version of the OS for compatibility reasons, to avoid breaking older apps (assuming that the behavior of the frameworks have changed).