Document a pattern to replace @available
(Obj-C) / #available
(Swift)
#1588
Labels
Milestone
@available
(Obj-C) / #available
(Swift)
#1588
iOS/macOS development has a common pattern where an SDK introduces a new preferred API and deprecates the old API at the same time. In the old days this was a pretty painful experience for developers, but at some point Apple introduced the
available
system to make it much simpler and safer.Main features:
available
check, that warning goes away, and then you automatically have the logic to do whatever runtime conditional is necessary (usually calling the now-deprecated API in theelse
).#300 covers throwing instead of crashing, but doesn't solve the problem that
available
and the associated warnings does, which is making it very easy to handle iOS version differences correctly, and very hard to accidentally fail to do so.We should have a recommended pattern for doing the runtime check, and clearly document it somewhere as how to handle APIs that aren't available on newer OS versions. But if it's just an OS version check, that will still be significantly more error-prone than
available
because developers will be responsible for looking up every single API they are using to check its availability. If we want to replicate the same level of safety and ease of use thatavailable
provides, we would need to propagate version annotations through into the generated code in some way, somehow make the Dart analyzer aware of min native deployment version, and create new lints that replicate the warnings for missing checks.The text was updated successfully, but these errors were encountered: