rust-lang
Raise minimum supported macOS and iOS versions
Proposal
I propose to raise the minimum versions to macOS 10.12 (Sierra) and iOS 10 to better match recent expectations for developers publishing on these platforms and to clean up the compiler and standard library. Additionally, the minimum tvOS version would be raised to 10 as well to match iOS.
rustc and the standard library currently support back to macOS 10.7 (OSX Lion) and iOS 7. However, both of these versions have long since been marked deprecated and unsupported by Apple, not having received an update for 9 to 8 years, respectively. While that may not be extremely old for other platforms such as Linux, the Apple ecosystem is known for most of its userbase staying on modern versions. Both macOS 10.12, iOS 10, and tvOS 10 use the same kernel, Darwin v16. By increasing each's minimum version at the same time, problem cases where APIs are available only on one OS can be avoided, which prevents unnessecarily cluttering the stdlib.
macOS specific
Looking at what versions other programming languages support:
| Language | Supported version |
|---|---|
| Go^1 | 10.13+ |
| Zig (unofficial)^2 | 10.12+ |
| Swift^3 | 10.9+ (with bundled runtime) |
| Java[^4] | 10.15+ |
| Python 3^5 | 10.9+ |
| Julia^6 | 10.9+ |
One more point worth noting is that all major browsers have dropped support for versions prior to 10.12 (or more):
| Browser | Supported version |
|---|---|
| Firefox^7 | 10.12+ |
| Chrome^8 ^9 | 10.13+ |
| Safari | 10.15+ (Safari 12 was the last supported by 10.12) |
A final set of data points is some of the Rust ecosystem:
- Tauri, an Electron alternative written in Rust. It supports 10.15+. It has 273k total downloads (26,440/month).
- Mlua, a set of bindings to Lua. It supports 10.9+. It has 371k total downloads (22,851/month).
- mac-notification-sys. It supports 10.8+. It has 347k total downloads, and is a dependency of Tauri but works alone too (25,758/month)
- Nativeshell, a way to embed Flutter Desktop into a Rust app. It supports 10.13+. Its download count is lower compared to the others.
- Wezterm, a cross-platform terminal emulator. It supports 10.9+.
- Espanso, a cross-platform text expander. It supports 10.13+.
- Alacritty, another cross-platform terminal emulator. It supports 10.11+.
iOS specific
According to Apple's app store stats, 82% of all iPhones use iOS 15, and, going back further 96% of devices have iOS 13 at a minimum. Given the proposed increase to iOS 10, this shows that an incredibly small number of devices still run iOS 9 and earlier. This is in stark constrast to something like Android, where old OS versions linger for many years past official vendor support.
Additionally, Apple semi-recently has begun requiring all mobile apps submited to app store to use XCode 13, with the iOS 15 SDK. This requires iOS 9 as the minimum deployment target, and iOS 10 in the simulator. A requirement of iOS 10 would also bring the minimum device requirement from the iPhone 4 (2010) to the iPhone 5 (2012). Given Apple's cadence bumping the SDK requirement, iOS 9 will most likely be unsupported in 1-2 years for new app versions.
Winit also requires iOS 8. It has 3,693,208 total downloads (156,839/month). No other (public) crates seem to define a minimum iOS version beyond what Rust specifies using IPHONEOS_DEPLOYMENT_TARGET.
Possible improvements
Both the standard library and some parts of the compiler would be simplified via this proposal:
- Signifigant improvements to Apple filesystem API usages, due to the addition of many standard UNIX functions.
- Simplifying stdlib Apple random code, due to
getentropybeing available on all supported platforms./dev/urandomandSecCopyRandomByteswould no longer be needed. - Simplfying compiler Apple TLS code, due to no longer supporting Apple platforms with no TLS support.
- Architectually guarantee SSE4.1 for macOS
- Adding TLS support for iOS
- Simplifying bootstrap for iOS, soley from the new iOS version.
- Simplifying stdlib Apple clock code, due to the addition of
clock_gettime.
On top of that, it brings some other nicities that could be used for future improvements:
- os_unfair_lock to improve some stdlib internals.
- Misc other unifications from better UNIX compatibility.
A past counterpoint has been that Apple's Swift language supports running on back to macOS 10.9 and iOS 7. However, I'm not of the belief this is a fair standard for a static, 3rd-party language like Rust. Swift is directly supported by Apple and therefore can have more OS-level support for backwards compatibility then any other language. This includes numerous backwards compatibility shims and hot patching of older runtime versions. Since Rust has no underlying runtime provided by the operating system, it should not have the same expectations of extreme backwards compat.
Mentors or Reviewers
@thomcc - ~~reviewer~~ mentor
Process
The main points of the Major Change Process are as follows:
- [x] File an issue describing the proposal.
- [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
cc @rust-lang/compiler @rust-lang/compiler-contributors
@thomcc - reviewer
FYI, while I encouraged @BlackHoleFox to write this and provided feedback on an earlier version, I'm not the right person to review (not compiler reviewer or someone who regularly contributes to compiler/*). I suspect I can mentor though, since the work needed is presumably fairly minor (it's mostly a change to policy and rustc-target, I think).
I asked this in zulip, without any luck, but is there anything that can be done to push this forward? I would like us not to have to worry about these versions in the stdlib anymore, at the very least.
I think we need an FCP for this one, given the public-facing change -- could someone from the compiler team start one? (Or would it be preferred to do that on the PR implementing this change?)
I think we should
@rustbot second
this proposal and then do an FCP on the actual PR.
