Created
September 29, 2019 21:55
-
-
Save steipete/c2260a9631c9d84e6864c0a7f9b21895 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For https://forums.swift.org/t/swift-should-allow-for-suppression-of-warnings-especially-those-that-come-from-objective-c/19216/23 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We're working on releasing our app for Mac Catalyst. This is a challenge as Catalyst uses iOS 13 as min OS level, whereas our main app still supports iOS 11. On Catalyst, we see loads of deprecation warnings.
We're able to work around them all, but it creates a lot of useless code, with the opportunity to introduce new bugs. Just see a few diffs, so you get an idea:
I completely agree that we eventually need to move to the new API, however the best time to do that is when we drop the old OS completely. Introducing branches to use new API that basically does the same thing, when the OS still supports the previous way of doing things is... not very useful.
Sometimes we have code that is not really used on iOS 13 anymore, but still has some references, so we can't deprecate the whole class. This would be all done once we completely remove that (in that case, our legacy theming). However until that's done, I have to write code whose only purpose is to hide a deprecation warning:
We use
UIMenuController
, and the API changed quite a bit in iOS 13. However until we can drop this from all our products, we either do this or introduce a category that encapsulates this:There's code that might need more rethinking once we can drop iOS 12, however until that is the case, we branch:
You can argue that this is a Catalyst issue, and it really should have a setting to override the min OS level, however that's unrealistic as well.
The preferred way would be a an annotation to suppress deprecations, just as we have in Objective-C. Swift's goal is to provide an environment where people write safer code in a more expressive way. Not having a way to control deprecations seems counter to this goal.