Skip to content

Instantly share code, notes, and snippets.

@steipete
Created September 29, 2019 21:55
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save steipete/c2260a9631c9d84e6864c0a7f9b21895 to your computer and use it in GitHub Desktop.
Save steipete/c2260a9631c9d84e6864c0a7f9b21895 to your computer and use it in GitHub Desktop.
For https://forums.swift.org/t/swift-should-allow-for-suppression-of-warnings-especially-those-that-come-from-objective-c/19216/23
@steipete
Copy link
Author

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:

Screenshot 2019-09-29 at 22 22 30

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.

Screenshot 2019-09-29 at 22 38 53

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:

Screenshot 2019-09-29 at 23 46 50

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:

Screenshot 2019-09-29 at 23 50 12

There's code that might need more rethinking once we can drop iOS 12, however until that is the case, we branch:

Screenshot 2019-09-29 at 23 51 11

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment