Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
- Subject: Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
- From: Oleg Krupnov <email@hidden>
- Date: Wed, 07 Sep 2011 09:19:35 +0300
So, gentlemen, the OP has ended up completely baffled with your discussion :)
Do I have to build and ship two separate versions of my app, for 10.6
and for 10.7??! This would be a nightmare!
At the bottom line, what is the legitimate way of supporting older
versions of Mac OS X (10.6) in an app designed for newer ones (10.7)?
This should be an easy and well-known topic, because Mac OS X gets
updated all the time! How can it cause so much discussion at all? Is
there an official recommendation in the docs regarding this question?
On Wed, Sep 7, 2011 at 7:23 AM, Chris Hanson <email@hidden> wrote:
> On Sep 6, 2011, at 8:52 PM, Ken Thomases wrote:
>
>>> And has been discussed in the rest of the thread, you should not leave your Base SDK set to an earlier OS and then invoke methods introduced in a later OS, because the new methods may require new-OS framework behavior.
>>
>> When did I say anything about invoking methods introduced in a later OS?
>
> This thread is the result of someone trying to take advantage of 10.7 features in code that needs to run on 10.6.
>
> If a developer who wants to do that builds against the 10.6 SDK, and invokes new-in-10.7 methods when running on 10.7, they can get incorrect behavior as a result. That's because the frameworks are allowed to call their own methods too, they're not public-only entry points.
>
> So the new-in-10.7 -bar may invoke -foo, which has different behavior when linked on 10.6 or before, but expect -foo's 10.7 behavior. Boom, the app is broken. Don't do that.
>
>> If one develops an app for, say, 10.7 and has tested/validated it, but has set their SDK to Latest, then merely building it on the next generation of the OS/tools _will_ break it. Without one having made any changes to their code.
>
> Merely building it with any different tool chain at all — and even a different build of "the same" SDK — invalidates all of your testing and validation as well. (SDKs can and do change over time too; an SDK is "an artifact that describes the API of an OS version" not "guaranteed to be the exact bits from the headers and libraries of an OS version.")
>
> Since you need to re-test/re-validate any time you switch tools, it should be no more burden to have an updated SDK at the same time any more than it is to have an updated compiler, linker, or IDE.
>
> You don't actually win anything just by preserving the SDK version you're building against. And as I explained above (and others have explained in this thread) you can run into significant compatibility issues when attempting to build for an older SDK but use new-than-that-SDK methods.
>
>>> It is a very strong recommendation that you set your Base SDK to Latest and use the Deployment Target to specify the least recent OS on which your application will be run.
>>
>> It may be a very strong recommendation, but it isn't a wise one.
>
> You're welcome to think anything you want about it. Nonetheless, it doesn't change how developers should be building their software for OS X.
>
> It's already how developers are used to building applications for iOS, so it can't be that huge a burden.
>
> -- Chris
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden