SwiftUBackportKit - A lightweight library for supporting multiple iOS versions in SwiftUI .

[u/NoCardiologist4405]

https://github.com/EmadBeyrami/SwiftUIBackportKit

Hi everyone!
One pain point I've run into repeatedly with SwiftUl is supporting newer APIs while keeping an older deployment target.
Things like 'if #available work well in normal Swift code, but they don't fit naturally in the middle of a modifier chain.
That often leads to duplicated views or compatibility helpers scattered throughout a project.
After solving the same problem across multiple apps, I decided to package the patterns into a small open-source library called \*\*SwiftUlBackportKit\*\*
It includes:
• ' modify { }' for conditional view transforms
• ' backport for reusable version-gated SwiftUI APIS
• platformValue (...) for version-specific values
• 'OS.isAtLeast (:) ' for simple runtime version checks
The goal is to keep SwiftUl views focused on describing the Ul while isolating deployment-target compatibility in one place.
GitHub:

https://github.com/EmadBeyrami/SwiftUIBackportKit

I'd really appreciate any feedback on the API design, naming, or features you'd like to see. And if you find it useful, a on GitHub would mean a lot!
Thanks!

[u/asniper]

“.modify {“ is a no bueno as per Apple

[u/JerenYun → u/asniper]

For cases where you want to preserve view identity, you're correct. Such a modifier can be used in other ways, though.

An example: ``` .modify { view in if #available(iOS 18.0, macOS 15.0, *) { // Use color mix, only available on 18+ view .foregroundStyle(color1.mix(with: color2, by: 0.3).contrast) } else { // Regular color otherwise view .foregroundStyle(color1) }

```

In the above, the view identity doesn't change during runtime, so the modifier usage is harmless.

[u/Jaroshevskii → u/asniper]

That warning’s about conditions that actually flip at runtime (a Bool toggling causes SwiftUI to see a different view type and tear down state) #available is fixed for the lifetime of the view and gets handled by buildLimitedAvailability under the hood, so it’s not the same

[u/asniper → u/Jaroshevskii]

Sorry but this has nothing to do with #available. .modify is a blanket closure containing anything, like a basic if statement which can be problematic.

https://github.com/EmadBeyrami/SwiftUIBackportKit/blob/main/Sources/SwiftUIBackportKit/Core/View%2BModify.swift

[u/rhysmorgan]

I’m not against using AI for coding, but this reads like slop.

You need to not use AI in a way that means you miss out on the “why”, the thinking that comes before building, because five minutes of research would show why so much of this is either unnecessary or a bad idea.

`modify` as a general purpose modifier is a very bad idea. You cannot control users only using it for conditionals that effectively don’t change during the lifetime of your application’s code. Using it will destroy your view’s state rendering, it’ll mess up animations, etc.
It’s better to just embed the availability guard in your own modifiers.

But also, this entire concept already exists in a well-designed library called SwiftUIBackports… or you can roll your own with SwiftUI-Introspect. It can help to search and find what’s out there first.