Are you referring to the various styles of location permission alert on iOS? You supply (at build time) the message that gets displayed in the middle. As for how best to write that message, check out this video tech talk: Write clear purpose strings.

The carrier name is being received as -- whereas the code was being received as 65535. That is the new expected behavior on iOS 16.4 and later, because privacy. See this thread for more.

It’s going to be the same answer as last time.

You might also consider NSISO8601DateFormatter (link) which is designed to work with non-localized internet dates like this with less trouble than using NSDateFormatter. Also see this thread for further discussion of this topic.

Even better, don’t use DateFormatter to parse internet dates; use the newer ISO8601DateFormatter (link) instead. It Just Works™. Your example date almost works with the default options in ISO8601DateFormatter except that it’s missing a time zone marker on the end. So this is what Just Works™: let f = ISO8601DateFormatter() f.formatOptions.remove(.withTimeZone) print(f.date(from: "2023-04-25T02:07:29")!) // 2023-04-25 02:07:29 +0000 Note the formatter defaults to GMT, so you may also need to set timeZone. (This is different from DateFormatter which defaults to your local time zone, not GMT.) @eskimo: Maybe that old tech note could use an update to mention ISO8601DateFormatter?

First, read this: TN3111 - iOS Wi-Fi API overview. Then if what are you trying to do falls under one of the specific use cases it covers, then you may be able to find a way to do it in Flutter. But if not (and this may be the case, based on your description) then there’s no solution no matter what toolchain you use.

It's using dataWithContentsOfURL I’d stop investigating right there and just switch to a modern network API immediately. Consider that API a ticking bomb, as the documentation warns: Don't use this synchronous method to request network-based URLs. For network-based URLs, this method can block the current thread for tens of seconds on a slow network, resulting in a poor user experience, and in iOS, may cause your app to be terminated.

There’s obvious, and then there’s actual...

Interestingly, the email notification for watchers rendered slashes for the preceding reply. But it also transformed the HTML entity example in the first bullet point, which doesn’t seem correct:

You’re not missing anything. There is no separate SDK for iPadOS.

Does this thread describe what you are seeing?

There’s no documented setting for that. Imagine if there were: many apps would use it and thus defeat the purpose of the offload feature. For now your best bet is to advise the user to disable the global offload feature, with a detailed explanation of the motivation for doing so. But it’s still the user's choice. You could also file a Feedback requesting support for this, such as a hard-to-get entitlement for apps like yours.

As for iOS 13 support, also consider this: all devices that can run iOS 13 can also run iOS 14 and even iOS 15. So if you are not also supporting iOS 12 or earlier, then there’s no good reason to set your minimum target platform to 13 or 14. Anybody with an iOS 13-compatible device should be running iOS 15 or higher.

Can you give details of the bug affecting only 16.3? This may be helpful to someone else.

And by the way, this list on 14.3 is not showing enough simulators. You can create more simulators yourself. Click Manage Run Destinations at the bottom of that list, then switch to the Simulators tab and hit the + button at the bottom. It looks like the oldest simulator supported is iOS 13.7, but this may be sufficient to reproduce the problem. BTW, the App Store usage chart shows very few people are still on iOS 13. And as you can see it’s a pain to support such old versions. Just something to think about.