What Happens When You Run Deprecated Code in Swift

What happens when you run deprecated code in swift?

how it treats is unknown

Basically, that's right. It wouldn't crash, probably, but it isn't guaranteed to work either.

In the case of the UILocalNotification world, experience shows that if you link against iOS 10 your code won't work properly. You must switch over to the new UNUserNotificationCenter code.

But this is determined not by rule but by experimentation.

The one reliable general rule is that if something is deprecated for the current iOS version, don't use it. That is precisely what deprecation means.

Of course, if you want your code to link against iOS 10 but to run on both iOS 10 and iOS 9, say, you might have to include two completely different sets of code, taking advantage of Swift's if #available() syntax to respond to what system we're actually running under. In this particular case, you would have to do that in order to manage local notifications. But that is the price of progress. Apple (deliberately?) makes it hard for you to write backwards-compatible code.

Can deprecated code have negative effects when using a deployment target where the code is not deprecated?

Yes and no... Normally code is deprecated because it's no longer maintained, and or has known issues. Nothing should directly change for deprecated code between the time before it was deprecated and afterwards, so nothing should reduce stability etc. However, the fact that it is deprecated should make you keener to change it to the recommended replacement.

It should probably be noted that deprectaed methods tend to not disappear, despite that being the intention of deprecation. As the backwards compatibility would be broken, unless there are very serious security / privacy concerns, it's not likely a deprecated method would be removed.

It should also be noted that unlikely things happen with a greater frequency than one would expect ;)

What does deprecated really mean in iOS

What are deprecated methods:

Deprecated methods or classes that are outdated one which will eventually be removed.

Apple deprecates some methods/ classes, when they introduce a superior replacement, usually because they want to take advantage of new hardware, OS or language features (e.g. blocks) that were’t around when the original method was conceived.

When a deprecated method will be removed:

It depends according to the severity of method/property. For example:

cell.textColor

This property has been deprecated since iOS 3.0 and we can still use it. So unfortunately there's no any tight deadline of removing the stuff being deprecated.

Will Apple accept Apps with deprecated code?

Yes. Deprecated doesn't mean unavailable or disallowed; if it did, it would be called something else, or those methods would simply be removed from the API.

Deprecation is a way of letting you know that you should start transitioning your existing codebase. The rule of thumb should be: don't add code that you know uses deprecated functionality, that's just silly. Be aware as you work on older code bases that deprecated methods you were using may need your attention sooner or later.

One of the risks of continuing to use deprecated methods is that they may be more primitive and dangerous than newer versions, may not take into account all current OS realities, and possibly less well tested by Apple over time. You run the risk of having this bite you even before they vanish from the framework.

deprecated warnings in xcode and how to handle deprecation

1. Apple is unaware of any compile-time warnings you receive with your code.

2. Yes, you are handling this practice correctly. Clearly, in this case, you only need to go through this effort if you're supporting iOS prior to 5.0. But, in general, the technique for testing whether a method can be invoked and then calling the appropriate rendition is absolutely correct.

3. If you want to turn off the warning, you would simply temporarily suppress the warning and then turn it back on afterwards using the appropriate #pragma syntax:

   if ([self respondsToSelector:@selector(dismissViewControllerAnimated:completion:)])
   {
       //post-iOS6.0
       [self dismissViewControllerAnimated:YES completion:nil];
   } 
   else
   {
       // pre-iOS6.0
   #pragma clang diagnostic push
   #pragma clang diagnostic ignored "-Wdeprecated-declarations"
       [self dismissModalViewControllerAnimated:YES];
   #pragma clang diagnostic pop
   }
   

   By the way, if you want to know what the -W code is for your particular warning, go to your Log Navigator, select the recent build that included the warning, and expand the log, and you'll see it there:

   

Also note that while you could suppress the warning like I've illustrated above, in practice, you rarely need to do so. Using your example, if your project's iOS deployment target was 4.3, you wouldn't get the warning. And if your deployment target was 6.0 or higher, you'd get that warning, but then again, you probably wouldn't need this conditional code to call dismissModalViewControllerAnimated because effective iOS 5.0, you can always use dismissViewControllerAnimated.

The only time that you'd need to suppress this warning in your code is if you have source code, to be included in projects in the future, for which you don't know what the deployment target will be. Using your example, if you don't know whether the above code will be included in a project with a 4.3 deployment target or a 5.0+ deployment target. In that case, this syntax is quite useful. But, then again, I you could also use conditional checks on __IPHONE_OS_VERSION_MIN_REQUIRED, e.g.:

#if __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_5_0
    if ([self respondsToSelector:@selector(dismissViewControllerAnimated:completion:)])
    {
        //post-iOS5.0
        [self dismissViewControllerAnimated:YES completion:nil];
    }
    else
    {
        // pre-iOS5.0
        [self dismissModalViewControllerAnimated:YES];
    }
#else
    [self dismissViewControllerAnimated:YES completion:nil];
#endif

How to manually deprecate members

You can use the Available tag, for example :

@available(*, deprecated)
func myFunc() { 
    // ...
}

Where * is the platform (iOS, iOSApplicationExtension, macOS, watchOS, tvOS, * for all, etc.).

You can also specify the version of the platform from which it was introduced, deprecated, obsoleted, renamed, and a message :

@available(iOS, deprecated:6.0)
func myFunc() { 
    // calling this function is deprecated on iOS6+
}

Or

@available(iOS, deprecated: 6.0, obsoleted: 7.0, message: "Because !")
func myFunc() {
    // deprecated from iOS6, and obsoleted after iOS7, the message "Because !" is displayed in XCode warnings
}

If your project targets multiple platforms, you can use several tags like so :

@available(tvOS, deprecated:9.0.1)
@available(iOS, deprecated:9.1)
@available(macOS, unavailable, message: "Unavailable on macOS")
func myFunc() {
    // ...
}

More details in the Swift documentation.

use deprecated methods in iOS 5

1. You will probably not have a problem on iOS 5 devices using methods that the compiler is telling you are deprecated. Of course, it would be a good thing to clear up this issue over time because deprecated means those methods might not be present in iOS 6 (or whatever it will be called).

   • What you need to watch out for are compiler warnings or errors that an object may not respond to a particular method call. These would occur for methods that actually were removed along the way. It sounds like you have already done this, but be sure that you have set your SDK set to iOS 5 in XCode to ensure you are getting all the errors/warnings. But the lesson here is test, test, test (on devices as well).

2. As long as your code compiles and runs against iOS 5, using a deprecated method alone probably won't get your app disqualified. If it causes any crashing or anything like that during testing, however, they will likely kick it back to you for rework.

---

Related Topics