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

Does the device self-identify via any of its services? See if it implements the Device Information Service (which defines various characteristics including serial number) or maybe it exposes similar information in a custom service. Otherwise, there may be no good solution.

See this thread for some history. This part from an  engineer probably isn’t what you are hoping to hear: Battery level reporting is as accurate as it is intended to be.

There is a local variable [...] to store which alert action the user chose. Do you mean it’s a local variable on the caller’s stack, or is it actually a global/static variable, or something else? How does the alert presenting function access it? If it’s currently a local stack variable and is captured by the async block, can you test by changing it to a global/static?

Start reading here: iOS Background Execution Limits.

There’s always a lag of a few hours or days before App Store gets the memo. Just need to be patient.