Deprecated method and Apple Store Connect

What happen when a deprecated method is used in project submitted to Apple Store Connect ?

Generally the Apple documentation give the alternative like "Use ***: instead" but sometime the documentation do not suggest anything.

What to do when a such Warning happen ?

Answered by DTS Engineer in 825037022
Written by Alain_B in 774417021
What happen when a deprecated method is used in project submitted to Apple Store Connect?

Unfortunately there’s no single answer to this question. The immediate answer to your specific question is “Typically nothing.” App Store Connect usually doesn’t reject programs that use deprecated APIs [1]. However, there’s a bigger picture and it’s important that you understand that. But first…

Written by Alain_B in 774417021
sometime the documentation do not suggest anything.

Right. In that case:

  • Make sure to look at the deprecation notice in Xcode. It’s not uncommon for that to include more information than the documentation.

  • If it’s an [Objective-]C API, check the header that declares the symbol. In some cases the headers contain useful comments about the best path forward.

  • If you’re concerned about a specific API, feel free to start a DevForums thread about that.


Using a deprecated symbol is less than ideal, so it’s a good idea to research the best path forward, and then schedule some time to get on that path. These paths vary from API to API, but there are some common approaches:

  • In some cases the path is obvious. The UIWebView to WKWebView transition is a great example of that.

  • In some cases there’s no path forward. For example, various properties on CTCarrier were deprecated without replacement for privacy reasons. See this thread for more on that.

  • In some cases it’s a mix of things. The file-based keychain [2] is a great example of this. There’s a recommended path forward for app developers (moving to the data protection keychain) but that doesn’t work for everyone. If you’re building a launchd daemon that needs the keychain, your only option is to keep using the file-based keychain until Apple creates a path for you.

As to what happens to the API itself, that also varies from API to API. I explain one common path in this post, but there’s no guarantee that any given API will follow that path.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Although there have been exceptions, the most notably one being UIWebVIew.

[2] To learn more about that case, see TN3137 On Mac keychain APIs and implementations.

Effectively, documentation is usually very short on providing answer. probably because we can search the web for it…

There is one hope, that intelligent auto completion (which is really fascinating) will be the solution to it.

In the meantime, you should not worry too much. Deprecated means Apple may remove it anytime in the future. It may work for a few more years but one day it will crash and you can't say you have not been warned.

Get details here: https://stackoverflow.com/questions/42586403/what-happens-when-you-run-deprecated-code-in-swift

Accepted Answer
Written by Alain_B in 774417021
What happen when a deprecated method is used in project submitted to Apple Store Connect?

Unfortunately there’s no single answer to this question. The immediate answer to your specific question is “Typically nothing.” App Store Connect usually doesn’t reject programs that use deprecated APIs [1]. However, there’s a bigger picture and it’s important that you understand that. But first…

Written by Alain_B in 774417021
sometime the documentation do not suggest anything.

Right. In that case:

  • Make sure to look at the deprecation notice in Xcode. It’s not uncommon for that to include more information than the documentation.

  • If it’s an [Objective-]C API, check the header that declares the symbol. In some cases the headers contain useful comments about the best path forward.

  • If you’re concerned about a specific API, feel free to start a DevForums thread about that.


Using a deprecated symbol is less than ideal, so it’s a good idea to research the best path forward, and then schedule some time to get on that path. These paths vary from API to API, but there are some common approaches:

  • In some cases the path is obvious. The UIWebView to WKWebView transition is a great example of that.

  • In some cases there’s no path forward. For example, various properties on CTCarrier were deprecated without replacement for privacy reasons. See this thread for more on that.

  • In some cases it’s a mix of things. The file-based keychain [2] is a great example of this. There’s a recommended path forward for app developers (moving to the data protection keychain) but that doesn’t work for everyone. If you’re building a launchd daemon that needs the keychain, your only option is to keep using the file-based keychain until Apple creates a path for you.

As to what happens to the API itself, that also varies from API to API. I explain one common path in this post, but there’s no guarantee that any given API will follow that path.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Although there have been exceptions, the most notably one being UIWebVIew.

[2] To learn more about that case, see TN3137 On Mac keychain APIs and implementations.

Deprecated method and Apple Store Connect
 
 
Q