{"id":33883,"date":"2021-10-11T16:08:23","date_gmt":"2021-10-11T20:08:23","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=33883"},"modified":"2021-11-23T11:43:46","modified_gmt":"2021-11-23T16:43:46","slug":"simplifying-backwards-compatibility-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/10\/11\/simplifying-backwards-compatibility-in-swift\/","title":{"rendered":"Simplifying Backwards Compatibility in Swift"},"content":{"rendered":"

Dave DeLong<\/a>:<\/p>\n

Every year as new OS and Swift versions are released, the question comes up over and over again: “how do I use this new thing while also supporting older versions?”. While we have a bunch of “availability” tools at our disposal (and I’ll be using them in this post), they always come across as somewhat cumbersome<\/em>: we need to do inline checks, or we have conditional logic flow that obfuscates the intent of some of our code, and so on.<\/p>

[…]<\/p>

At first glance, this doesn’t look very useful; it’s a struct that holds a single value, and it doesn’t do<\/em> anything. This is by design. Backport<\/code> exists to serve as a holding space (namespace) for shims<\/em>: the conditional code we must<\/em> write in order to do proper availability checking.<\/p>

[…]<\/p>

Unfortunately, I have not come up with a good way to backport things like specific properties on SwiftUI’s EnvironmentValues<\/code>, such as .headerProminence<\/code>.<\/p><\/blockquote>\n\n

I have typically done this sort of thing by declaring prefixed category methods, but this technique lets you keep the original method name by adding a namespace.<\/p>\n\n

Previously:<\/p>\n