PEP 730: Adding iOS as a supported platform

[freakboy3742 (Russell Keith-Magee)]

@mhsmith

So for those places which must use triplets (and I’m neutral on whether that should include _multiarch), I think the best course is to follow what Rust does, since we’re likely to have closer contact with them in the future, and they’re more consistent with autoconf.

While Rust is definitely a common target, I’d argue that every binary iOS package needs to interact with Apple’s tooling; only a subset of those need to interact with Rust.

autoconf tooling isn’t a good guide here either, because their support for iOS is… spotty. Aside from the arm64 vs aarch64 schism, they recognise ios as an OS, but not any other Apple platform; and they don’t have any representation of simulators at all. One component of the reference patches is an update to config.sub that adds these details; I’ve tried to submit this patch upstream to autotools, but their patch submission process appears to be a black hole you throw code into and hope it gets merged.

As for _multiarch; the discussions I had at the core team sprint seemed to suggest that _multiarch is an intentionally undocumented internal detail that assumes whatever value is helpful for the platform in question.

@mhsmith

platform seems like a better place for that, because it already has various platform-specific functions with a consistent naming convention

Counterpoint: sys.getandroidapilevel() exists (for which there should probably be an iOS analog as well, since there’s a comparible minimum iOS version), so there’s history of the sys module being used for low level platform descriptors.

That said - the other detail to consider is that sys is a compiled module, whereas platform is a Python module, which alters how hard it is to access various APIs. It seems best suited to values that are defined by the configure/Makefile, or can be satisfied by C system calls (Calling [UIDevce currentDevice] would be difficult inside sys - possible, but inelegant).

@mhsmith

This is inconsistent with the existing platforms, where platform.machine returns the architecture

The documentation for platform.machine() describes the value as “The machine type… empty string if it can’t be determined”. This falls to CPU architecture because that’s about all you can really tell about most laptops and servers; however, I’d argue “iPhone13,2” or “iPhoneSimulator” is a much more accurate description of “the machine type” than “arm64”, especially given that platform.architecture() and platform.processor() exist.

@mhsmith

nstead, how about adding a new function platform.ios_ver(),

The reference patches include this, mostly as a utility method for the other platform APIs; but it could be documented and exposed same as mac_ver().

@mhsmith

And if you can just do model == "iPhoneSimulator", is the simulator flag even needed?

Sure - we could omit it and require the user to write a check of the mode stringl; however, given that it’s a known to be a boolean property, and comparing with a string is potentially error prone (e.g., spelling errors, capitalization inconsistencies, …), it seems like a no-brainer to include it somewhere as a boolean.

platform.is_simulator() perhaps?