Document a pattern to replace @available (Obj-C) / #available (Swift) #1588
Description
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:
- If you unconditionally call an API that's available on OS version N, but your minimum deployment target is <N, you get a development-time warning.
- If you correctly wrap that call in an
availablecheck, 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 that available 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.
Metadata
Assignees
Type
Projects
Status
Todo