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.

The documentation isn’t explicit about what “send” means but I think it does imply that the operation is asynchronous: This [return] value is [...] false if the update isn’t successfully sent because the underlying transmit queue is full. From this I infer that it just attempts to add the data to a fixed-size transmit buffer, while the actual transmission over the air via the Bluetooth stack happens later.

Well, I suppose that could work but it doesn’t exactly improve readability. :wink: If this landed in the inbox of peer code reviews at my day job here, I’d ask them to redo it using a struct implementing Encodable, a JSONEncoder, and either string modifier addingPercentEncoding(withAllowedCharacters:) or one of the URL APIs that does percent encoding automatically.

For me, Xcode 16 is showing the match count in the find bar when I hit ⌘E when the find bar is already open, or when I hit ⌘F to open the find bar after ⌘E. Still need to hit ⌘F either way to get keyboard focus into the find bar, however. But note a huge advantage of ⌘E over ⌘C ⌘F ⌘V is that it puts your search text in the system’s find pasteboard, which is separate from the general pasteboard. So it won’t clobber regular code or text that you are editing via copy and paste.