# PEP 730: Adding iOS as a supported platform **URL:** \ **Category:** PEPs\ **Created:** [October 10, 2023, 2:51pm UTC](https://discuss.python.org/t/pep-730-adding-ios-as-a-supported-platform/35854 "2023-10-10T14:51:36Z")\ **Posts on this page:** 1\ **Showing post:** 39
**Author:** ![freakboy3742](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/freakboy3742/32/1273_2.png) [@freakboy3742](https://discuss.python.org/u/freakboy3742)\ **Post date:** [October 14, 2023, 4:24pm UTC](https://discuss.python.org/t/pep-730-adding-ios-as-a-supported-platform/35854/39 "2023-10-14T16:24:24Z")
> [@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? --- _[View the full topic](https://discuss.python.org/t/pep-730-adding-ios-as-a-supported-platform/35854)._