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.

Or the issue is that the bezels don’t match any iPad device. The aspect ratio for both is longer than any known iPad so it does sort of look like an iPhone. The one for iPad Pro (2nd generation) is way off: that model has a thick top bezel and square corners, as shown in the tab thumbnail above it. The iPad Pro (6th generation) has thin bezels and round corners so it matches a little better, but note one of your shots has both square and round corners. Your best bet is to regenerate all these screenshots using the correct simulator, and include the device bezels when capturing the screenshots.

Do you have an Apple (not 3rd party) crash report for this? See the note about that from @eskimo in your other thread. If this 3rd party report happens to be accurate, then you’ll need to take it up with the vendor of the closed-source SDK you are using. But it would be unexpected for anyone to actually be calling setDefaultFormatterBehavior and extra unexpected for it to crash, so I’d suspect the crash report isn’t accurate. The crash may still be caused by that SDK but you need an Apple crash report to be sure.

//serialize the lambada //deserialize the lambada and use it Are you referring to the Java technique of serializing lambdas, like what’s described at https://www.baeldung.com/java-serialize-lambda ? Swift has no equivalent feature.