The easy ones: You can delete DerivedData at any time. It grows back as you load and build projects. In iOS DeviceSupport you can delete any OS versions that don't correspond to devices you actually use for debugging. That could be old versions (after you install OS updates on your devices) or devices you just don't use any more.

In semantic versioning "major" means the first segment of the version string, so it means the version starting with 27 or higher.

Dimension can be subclassed to create the custom units. You probably don't want to subclass Dimension for reciprocal units since there's no good way to convert between measurements of different Dimension types. Instead, you can extend the existing classes to add the new reciprocal units, and then conversion will work like usual. subclass [UnitConverter] to something like UnitConverterInverse Yep you'll need that. Interestingly, there's already a reciprocal unit buried in the existing measurement API. It uses a reciprocal converter that is exactly what you need, but unfortunately isn't part of the public API. Check this out: Welcome to Apple Swift version 6.2.3 (swiftlang-6.2.3.3.21 clang-1700.6.3.2). Type :help for assistance. 1> import Foundation 2> print(UnitFuelEfficiency.litersPer100Kilometers.converter) <_NSStatic_NSStaticUnitConverterLinear_NoConst: 0x20761bfc8> coefficient = 1.000000, constant = 0.000000 3> print(UnitFuelEfficiency.milesPerGallon.converter) <NSUnitConverterReciprocal: 0x10055d880> reciprocalValue = 235.215000 4> print(UnitFuelEfficiency.milesPerImperialGallon.converter) <NSUnitConverterReciprocal: 0x10055f400> reciprocalValue = 282.481000 So the system already has this internal NSUnitConverterReciprocal just to support the fuel efficiency dimension. That bit of debug output basically shows exactly how it works. It’s actually simpler than the linear converter since it has a coefficient (reciprocalValue) but no constant. For now I'd propose you do this: make your own version of this reciprocal converter; extend the relevant existing dimension classes with your new units (for your examples above this would be UnitFrequency, UnitSpeed, and UnitElectricResistance); submit a Feedback requesting that UnitConverterReciprocal get promoted to the public API.

See the Unsolicited Idea Submission Policy.

we were able to use certain methods to suppress this confirmation popup A quick web search suggests those "certain methods" amounted to relying on undefined behavior rather than using any documented API. And that's never safe or recommended. However, this suppression no longer works on iOS 26.1 and later. Yep, that eventually happens to a lot of undefined behaviors. Is there any valid method to prevent this popup from appearing on iOS 26.1+? If by "valid" you mean "supported by any documented API" then it appears the answer is no. Hopefully you'll just decide that trying to restore the old behavior isn't worth the trouble and move on.

Is there really no way to update the app screenshots Yep. Screenshots are part of app review so there's no way to quietly sneak in changes outside the review process. But you don't need to literally update the app in any meaningful way. Just rebuild it from the current version's source, fix the screenshots, and give it vague release notes like Bug fixes.

Check out this thread (and the tech talk video it links to) for more general guidance on how best to use reachability checks in your app. You can also find similar threads with a search term such as user:eskimo preflight. Basically, don't rely on preflighting network operations. Either of the reachability APIs is still asynchronous to your actual network request and can't possibly guarantee that any given request either will or won't succeed. So first make the app solid around network requests that fail for any reason. Then use reachability to add user-facing polish where you can.

If you're reposting this because the comments on your original thread went unanswered, check out point 5 in Quinn’s Top Fourteen DevForums Tips: don't use the comment feature for followup discussion because people tend to miss them. Does this suggest that iOS 26 does not support this functionality? What's supported is what Apple documents. Any behaviors that aren't documented should be considered undefined and unsupported. is it possible that versions of iOS 18 and earlier may also not support this behavior in the future? Of course it’s hard to imagine Apple tasking some poor engineer with deliberately breaking this behavior in some future patch release. But IMHO a better way forward is to just update your app to give a consistent experience on all OS versions rather than trying to manage two paths, one of them being on a legacy OS whose user base shrinks every day.

There’s also an icon associated with the developer itself, as described in this thread and this thread. A few apps have a custom image but there seems to be no documentation on how to do it. Perhaps the ability to customize it was withdrawn long ago. Or you just need for Apple to really like you.

another short-term solution: Create this no-net-changes build with Xcode 16 and just special case the OS version. Unfortunately that may not meet the OP’s requirement to report an accurate version for troubleshooting, since it sounds like the compatibility version will be stuck at 19.0 forever. So a compatibility-mode app can only infer it’s running on 26.0 or later but not determine the actual version. But hopefully that’s sufficient for the OP since it doesn’t sound like this drives any core app functionality.

showing iOS 19 to the customer instead of iOS 26 might confuse them. You could file a Feedback (and could cite my simple analysis above) but hopefully you have enough time to just prepare (at worst) a no-net-changes build of your app using Xcode 26. If you release that close to the iOS 26 release date then the confusion should be minimal. And for anyone who gets a confusing result running your old app on the beta, just chalk it up to ”well, it’s a beta.”

And that brings us into the why question territory And therefore unlike competing on the popular American quiz show Jeopardy!, I made sure not to phrase that response in the form of a question. 😉 OTOH, the how of this is fascinating. Interesting! Of course if you multiply that by the number of “if your app is linked on or before version x...” cases scattered through the documentation, it’s probably not a lot of fun to maintain.

So it’s the same trick that was used in the jump from macOS 10.15 to 11.0, where legacy apps saw the new version as 10.16 instead of 11.0. But that was ostensibly to support old apps with faulty version checking logic that assumed the major part would be 10 forever and the minor part would increase forever. But for the jump from OS 18 to 26 on the other platforms, it’s not clear why this would be needed. As happens every year on those platform, the major part still gets bigger and the minor part still gets reset to 0.

Start with this recent thread.

The specific settings pages you can navigate to are documented here: Supported URL Schemes. Unfortunately it doesn’t currently include Wi-Fi settings. The latest version of the app_settings Flutter library does seem to document this limitation under AppSettingsType.wifi here: https://pub.dev/documentation/app_settings/latest/app_settings/AppSettingsType.html