Re: Xcode 6 does not warn on use of iOS8 only method when deployment target is iOS7
Re: Xcode 6 does not warn on use of iOS8 only method when deployment target is iOS7
- Subject: Re: Xcode 6 does not warn on use of iOS8 only method when deployment target is iOS7
- From: Fritz Anderson <email@hidden>
- Date: Fri, 26 Sep 2014 09:51:59 -0500
On 26 Sep 2014, at 8:27 AM, David Hoerl <email@hidden> wrote:
> I have a fairly strong recollection that I **use** to get warned if I tried to use a new API method when the Deployment target was set to an older release.
>
> I tested my app on iOS8, worked fine, crashed in QA - turns out I inadvertantly pulled in a newer method on NSString (I guessed at a name, command completion filled it in for me).
>
> // From CMD-click - (BOOL)containsString:(NSString *)aString NS_AVAILABLE(10_10, 8_0);
> NSString *foo = @"FOO";
> if([foo containsString:@"OO"]) {
> NSLog(@"WOW");
> }
>
> Xcode 6 and 6.1 compile this just fine, no error or warning. I entered rdar://18459505, but hoping that someone can tell me the error of my ways, and what magic option that when set re-enables the old behavior.
The painful summary is “works as intended.” For quite some time, developer tools have silently passed all API from the latest release of Apple’s operating systems, and I know of no way to turn that off. (I’ve searched the Build Settings for “API,” “unimplemented,” and “target.”)
---
TL;DR
Likely your used-to-work case was when you built using Xcode 3 (4?), which gave you a choice of SDKs. If you selected the SDK of the target machine, later API would be undefined, and the compiler would flag it. Very, very useful.
Since then, Apple has fallen back on the rule that so long as you set your target OS (separate setting) to the earliest you want to run on, it’s okay to use the maximum-available SDK. In fact, you now get the latest SDK only. If the target is earlier, clang “weak-links” the new symbols so they are always defined, but you can test for their presence at run time before using them.
If you have the resources to rigorously audit and validate every use (conservatively, thousands) of Apple API in your code, this is a win for you and Apple. I have a cynical theory about the value to Apple on a policy level, but I won’t indulge it.
Also, each API library demands additional maintenance from Developer Tools to preserve its compatibility with each release of the tools. Supporting only one is least-frustrating (which matters), and frugal. I sympathize.
Apple’s line to developers is that the policy has no cost to them, because they don’t have to adopt new API if they don’t want to. Well, no, they don’t _have_ to, but by accident and contrary to their customers’ needs, they inevitably will. The loss to them is very real, and significant. I infer from this point’s never being even acknowledged, that the policy has deep roots, and is nonnegotiable.
— F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden