`Platform.isIOS` does not distinguish between `macOS catalyst` or `macOS run on iPad`

[bvoq]

The dart:io core library has the following problem. Platform.isIOS falsely reports true when running a flutter application using macOS catalyst or macOS designed by iPad mode. I think we should keep it this way for backwards compatibility but offer two more modes: Platform.isMacOSDesignedByIpad and Platform.isMacOSCatalyst.

The respective Swift calls are: ProcessInfo.processInfo.isiOSAppOnMac and ProcessInfo.processInfo.isMacCatalystApp

This issue is related to:

• Dart core libraries (dart:io)

[lrhn]

The isIOS getter, and the other is<OS-Name> getters, are fairly naive.

They attempt to distinguish operating systems, because sometimes that's relevant for how you use dart:io, which is an operating system based API.

The getters do not attempt to do anything else. They do not distinguish different versions of the same OS, they do not distinguish different CPU architectures, bit-sizes, UIs or anything else. Pretty much just what the File operations depend on.

Whether an iPad emulation mode on MacOS should report MacOS or iOS is a choice we can make, but we should not try to make any further distinction, not unless we choose to accept that mode as a third and different operating system. (Or maybe it can be distinguished using Platform.operatingSystemVersion, in which case you should do that directly.)

And even if we choose that it is a third kind of operating system, I'd rather not introduce any more getters on Platform (I was against adding isFuchsia too), because we shouldn't try to hard-code an open-ended set of values in source names. We should not assume that we even know all operating systems. So I'd rather just make Platform.operatingSystem report a third string value, have both isIOS and isMacOS report false, and have you check the string, if you expect to be on that third platform.

[brianquinlan]

Would it make more sense for this level of differentiation to exist in Flutter or some non-SDK package?

[lrhn]

Probably, yes. And we're working on a package, but it's still limited to the information available in Platform when running on the VM, which means an operatingSystem (which will be one of a few known values) string and an operatingSystemVersion string (which has not specified format). We're trying to extend the API to web code too (just claiming that operatingSystem is web or browser, not assuming we can find the underlying operating system), and we're not even sure what we want to do for Wasm. (Is Wasm native and Wasm browser two different operating systems? Or should it show the underlying operating system, and can it even see that?)

The underlying issue is that the amount of possible information to reveal is fractal. Any information we give, there'll be two or more variants of that which someone will want to distinguish, down to the patch level, locale and country configuration. (We have had bugs that only occur in Chinese time zones, or Russian languaged Windows. If someone wants to work around those, they'll want to make that distinction.)

Which means that any package which tries to give "platform" information will have to stop at some level, and then someone will ask for more.

So yes, putting things into non-SDK packages, and stopping at some point, letting non-Dart-team owned packages take over, is the best choice. It's choosing the stopping point which is tricky.

And deciding what the information at that level means, what a user can infer from it.

(Here, the true answer for isIOS is supposedly wrong, since the VM is running on MacOS, but it's being run in an environment which behaves like iOS, so is any answer really right or wrong? Or is it just a distinction that needs a further level of detail?)

I have very little idea where we should draw the line. I can see arguments in all directions. But I definitely want it all moved into a package, not hard-coding OS names into the SDK.