New SwiftUIIntrospect Module, Version specifier

[paescebu]

Love the new SwiftUI Introspect Module. Great job. It indeed seems very stable and reliable.
I could get rid of many workarounds directly. Great job!

I had one question though about explicitly listing the versions that we want to cover with an introspection.

Is this TextField example safe to do/ use in your opinion?

@_spi(Internals) import SwiftUIIntrospect
import UIKit

extension iOSViewVersion<TextFieldType, UITextField> {
    public static let v15AndAbove = Self(for: .v15AndAbove)
}


extension iOSVersion {
    public static let v15AndAbove = iOSVersion {
        if #available(iOS 15, *) {
            return true
        }
        return false
    }
}

And then in an introspection:

 var body: some View {
      content
          .introspect(.textEditor, on: .iOS(.v15AndAbove)) { uiTextView in
              uiTextView.inputView = keyboardType.keyboardInputView
          }
  }

Because in my library I want to assure that I should I forget on updating the library code for new iOS releases, I want it to implicitly cover (potentially) newer versions already, without me needing to issue a new update.

Or do you see an issue/risk in doing that?

Example where i am trying to adapt CustomKeyboardKit to use the new API:
paescebu/CustomKeyboardKit@master...task/update_to_use_new_swift_ui_introspect_module

[davdroman]

Hi @paescebu, glad to hear you're happy with the new module, and thank you for being an avid user :)

In short: yes, it's completely fine to do. If the underlying UIKit view type changes in the future, the callback simply won't be called.

I debated with myself quite a bit whether it makes sense to cover future platforms by default. But this comes with a few uncomfortable API quirks that ultimately make the library less intuitive and predictable. At the end of the day, I didn't want to sacrifice intuitiveness for the sake of ergonomics — which was arguably one of the biggest pitfalls of the original API—, and so this strictness is a trade-off I believe to be worthwhile for most users.

For library developers such as yourself, I do encourage rolling out more lenient, custom version specifiers that encompass whatever scope you're after. At the end of the day, extensibility is one of this library's strongest suits to support advanced use cases just like the one you mentioned.

I hope this helped.

[paescebu]

Awesome to hear!
Yeah this helped a ton!

I definitely try to keep up to date often, but as this is just a small side project of mine, i just want to make sure that users updating to a new version and me forgetting it doesn't cause end user issues and at least gives them a chance to have a working app.

But overall really love the approach. Searching for the View Type only downwards in the hierarchy makes sense, and the ancestors being opt in is amazing for people that need it.

Great flexible solution.

Will directly use it in my library.

[davdroman]

Update for anyone who finds this discussion in the future: advanced mode released in 0.8.0 now enables a much easier way to accomplish this.