PEP 730: Adding iOS as a supported platform

[mhsmith (Malcolm Smith)]

@freakboy3742

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.

OK, now that I’ve had a look at the existing build scripts in Python-Apple-support, I see that there is some use of GNU-style triples there. I’ve done some experimentation with this file:

int main() { return 0; }

And this command:

xcrun --sdk $sdk clang -target $target -c test.c -o $sdk-$target.o

And the resulting .o files are:

302c0d9e5a6c5ab41045a03250b13303ba39ae23  iphoneos-aarch64-apple-ios.o
302c0d9e5a6c5ab41045a03250b13303ba39ae23  iphonesimulator-aarch64-apple-ios-sim.o
c5c5daa1dcafb93eeaaf2a22055cd659c328129c  iphonesimulator-aarch64-apple-ios-simulator.o
302c0d9e5a6c5ab41045a03250b13303ba39ae23  iphonesimulator-aarch64-apple-ios.o

In other words, the suffix “simulator” does make a difference, but “sim” doesn’t.

I also found that it makes no difference whether you use “arm64” or “aarch64”. But if you omit the “apple-ios” part completely, then clang generates ELF .o files which are rejected by Apple’s linker.

So based on all that, I agree that the triples currently in the PEP are the best choices.

@freakboy3742

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.

I think the most important factor here is not the literal meaning of the words, but the way they’re already documented and implemented on the major platforms:

• architecture is clearly documented to not return the architecture at all, but the bitness and the executable format.
• processor returns “arm” on my macOS machine, “Intel64 Family 6 Model 42 Stepping 7, GenuineIntel” on my Windows machine, and an empty string on my Linux machine.
• machine returns “arm64” on macOS, “AMD64” on Windows (the only example given in the documentation), and “x86_64” on Linux.

So I think it’s safe to say that most existing code that uses machine is expecting it to return an architecture name, and that most existing code that needs an architecture name will be getting it from machine, and expecting one of a few well-known options. I recommend we stay compatible with that, and make the model name an attribute of platform.ios_ver instead.

@freakboy3742

platform.node() and os.uname().nodename return the same value: the machine’s network name for the simulator, and the device name (“Janes-iPhone”) on device. The platform.node() value is implemented directly by the call to uname().

In that case, the special case for platform.node should be removed from the PEP, because it’s already covered by “All other values will be as returned by os.uname().”