I'm trying to understand how to best position my iOS apps in the event that—for whatever reason—I'm unable to release another version after submitting a version built with Xcode 26 that uses UIDesignRequiresCompatibility = YES.
For the sake of this discussion, assume that my apps require updates for proper UI presentation with the Liquid Glass UI, and that I'm submitting an initial version with UIDesignRequiresCompatibility = YES.
I need to make an initial update for iOS 26 right away, because running the app linked with the iOS 18.x SDK (as currently shipping on the App Store) on iOS 26 introduces UI usability problems.
Now, I have actually revised the UI for Liquid Glass and this requires slightly different behaviors for the legacy UI path (iOS 18.6 or iOS 26.0 with UIDesignRequiresCompatibility = YES) versus Liquid Glass UI path.
My Liquid Glass adoption UI may be "good enough," and it's certainly better than the results obtained when rebuilding with Xcode 26 and running without any updates at all (which produces a very poor, if not unusable, user experience), but I am not satisfied with these updates at present and I hope to make additional improvements before enabling the revised UI for users.
However, in the event that I cannot make another update for whatever reason, I need to ensure that users will never be exposed to the UI behavior that results from running with UIDesignRequiresCompatibility = NO with the code supporting Liquid Glass adoption disabled.
As long as Apple will guarantee going forward that an app built with Xcode/iOS 26.0 SDK including UIDesignRequiresCompatibility = YES in its plist will always use the old rendering mode in any future OS, then perhaps everything is fine.
However, if that's not the case, then I think I need some way to detect the enablement state of the new Liquid Glass UI at runtime (which goes beyond a simple @available check, e.g. iOS 26+ with "compatibility mode" disabled) so that I can provision to have my code supporting Liquid Glass adoption be automatically enabled in the event that my app never receives another update and a future OS ignores the UIDesignRequiresCompatibility key in its plist. I'm assuming that testing the value of the key in the plist at runtime would be insufficient, since it would still be present but ignored.
This sort of continuity planning seems like something that many developers would be concerned about.
What is Apple's guidance on this? So far I haven't found any clear discussion of this concern.
Note: My app is UIKit-based, mostly Objective-C with a bit of Swift only for TipKit.