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

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:

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

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.

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.

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?

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.

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

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.

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.

is it requiered to upgrade the last number of version ? The new release version does need to be greater than the old one, but you aren’t specifically required to bump the last segment. Valid new versions would include 1.2.2, 1.3, 1.11, 2.0, or even 99.44. But for a “hotfix” the customary one to use would be 1.2.2. Going forward, you may find it easier to bump the 2nd segment for any “new things”, which would be 1.3 in this case. Then you can always add a 3rd segment just for bug fix releases.

I am receiving the error - Couldn't parse lesssonData.json as array fatalError("Couldnt parse \(filename) as \(T.self):\n\(error)”) Is the output from fatalError() missing the actual content of the error variable that you are trying to print as a 2nd line? If so, try removing the line break (\n). Or just put a breakpoint there and examine error directly. You need to see exactly what error is being thrown in order to debug the problem.

I have only verion 1.029. Does apple truncate it and consider 1.029 as 1.29 ? Yes, exactly. The individual segments in a version string are treated as integers and leading zeroes are meaningless. A two-segment version string may look like a decimal fraction but it’s not.

Debugging with that version of iPadOS requires Xcode 14.3.

Is it possible to "force" Xcode update from 14.2 to 14.3 ? If there’s some workaround to get 14.3 to run on Monterey, it’s not supported by Apple. The right approach is to upgrade your macOS to Ventura. Of course the feasibility of doing that for any particular developer is a separate issue.