Raise minimum supported Apple OS versions #104385
Conversation
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
T-bootstrap
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
These commits modify compiler targets. |
thomcc
added
the
needs-fcp
BlackHoleFox
changed the title
BlackHoleFox
changed the title
|
@rfcbot fcp merge |
|
Team member @petrochenkov has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
petrochenkov
added
S-waiting-on-team
inquisitivecrystal
added
the
relnotes
|
The relevant MCP has some discussion of not matching Swift's support for macOS 10.9+, but it doesn't have discussion of Python 3 and Julia both supporting that same level. Can we have more discussion of the differences in Rust's story vs. those languages? Is there something that's uniquely hard about what we're doing, or want to do, that makes keeping support for longer more difficult? It seems to me that Julia at least should be in a relatively similar position to our standard library. Looking at the MCP, it seems like we're justifying the increase for iOS due to usage statistics -- I'd be curious to see similar statistics for macOS. My own sense is that people much more readily update to new iOS versions (and new phone hardware in general) in comparison to the macOS market, which can be retained for much longer. Not raising a concern here yet, but I personally don't think we ought to be moving the version up for macOS without a clearer story around what Python 3 and Julia are doing in this space. I think this for me is mostly about looking forward to the next bump -- it seems fairly clear we'll be able to write a similar list of desired APIs for some future macOS version (or, say, because we want to drop x86_64 macOS support) -- I think something stronger than just a set of desired APIs would be good. I think we should also see a post like https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html for this to pre-announce the change. @rfcbot concern needs-blog-post |
|
A thing to note is that not all devices are capable of upgrading to a certain release; so bumping the minimum version makes it impossible to run software built with Rust on those. To summarize: Going above iOS 7.0 drops support for:
Going above iOS 9.0 drops support for:
Going above macOS 10.11 drops support for:
Going above tvOS 7.0 drops support for:
This change concretely affects me as iOS maintainer of So looking at the above data, perhaps it would make sense to only bump the versions to at a maximum of macOS 10.11 and iOS 9.0 (and some version of tvOS that matches that)? |
The change will block you from using future Rust versions, but you can continue using older Rust, of course.
If you're interested, new hardware might be worth a grant from the foundation, although the application window just closed for this period of project grants. Financial hardship grants are always open. |
|
That was my actually technically grounded arguments, now for an opinion: I don't think we should raise the OS version above that which is offered by other languages (with the exception of the C-family of languages), simply because I fear that it may be used as an argument for choosing another language over Rust. So that would mean we should (attempt to) support macOS 10.9, iOS 7.0, watchOS 2.0 and tvOS 9.0, and support those for at least as long as Swift does. This is speaking even as the developer of a Rust interface to Objective ( But yeah, I get it, it's tough to support old devices, and I don't actually know how much of a hazzle it is for you, so no hard feelings whatever you decide. |
|
Previous discussion: https://rust-lang.zulipchat.com/#narrow/stream/233931-xxx/topic/Raise.20minimum.20supported.20macOS.20and.20iOS.20ver.E2.80.A6.20compiler-team.23556
I personally find this pretty convincing. @rustbot second |
This comment was marked as resolved.
This comment was marked as resolved.
|
I'm gonna reply to @madsmtm's comments first since I'm a bit tired from work and Swift/devices is something easier for me to talk about, then try to answer around @Mark-Simulacrum's comments:
This is something that I was aware of when writing up and the MCP and hopefully something I didn't take too lightly because I used to be in the group that could only work with really old Apple devices. Looking at them in a rough order, while I can't find any hard numbers/graphs for models themselves:
Wikipedia says that its last update was iOS 9 (3.5 years ago). The phone itself is 11 years old as of last month. Rehashing some things I noted in the MCP, iOS 9 is currently the minimum you're allowed to submit apps/updates with as of earlier this year. XCode 13 (whats now required) is also the last thing to support the armv7 target. Given Apple's cadence of ~2 XCodes per minimum version raise...
...which makes me fairly sure iOS 9 will no longer work for new submissions in a year or two from now. Even if we did consider keeping it, we would end up with a dead target pretty quickly. If you look through the most downloaded iOS apps (best way I could get an idea of what "the ecosystem" tracks for minimum app versions but I'm open to other suggestions) almost all of them support iOS 10 or higher, with the exceptions of:
The above definitely doesn't cover the apps everyone uses but it shows a pretty clear trend: The apps with the largest documented number of users are comfortable raising their minimum versions beyond the baseline and games usually follow the minimum. All of the above applies to the other devices stated too. With that, I think that I feel fine saying we won't be hurting the chances of Rust adoption on iOS with this proposal as it stands.
tvOS development seems to be a fairly uncommon thing compared to iOS and we currently don't support it all of the way (#103503) as well. I looked at the top ~15 downloaded tvOS apps and they're all within tvOS 10+. For fun I checked the app's I've personally ran into and Hidive is the only one with a minimum of tvOS 9+. This is obviously not conclusive though.
Similar to the section on the MCP, I don't think that this is a fair assumption to put on a third-party language with no runtime. Apple has put in an insane amount of work to continue support for Swift and Objective-C to be compatible as far back as it is. They're able to build workarounds etc into the frameworks that ship with the system. Rust, obviously, can't do that. Looking at Swift alone, I should call out that anything below macOS 10.14 requires you to bundle a copy of the Swift runtime with your app. If Rust supported a compatibility runtime, I would be more inclined to keep more versions supported but we just don't have the same resources and design Apple does. To reply with an opinion for your own, I really don't think anyone is still writing new "native" apps that are interested in targeting these very outdated versions so I don't think this will hurt Rust's adoption.
@madsmtm something that may be of interest to you as the
imo this would be a big boost for anything that uses |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Blogpost (rust-lang/blog.rust-lang.org#1140) has been updated with a 1.74 release date, its ready for more (final?) reviews and hopefully publishing. |
|
Finished benchmarking commit (42ca6e4): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 629.123s -> 630.937s (0.29%) |
Drop `armv7-apple-ios` target support ... as rust-lang/rust#104385 removed the target.
…omcc Remove Apple RNG fallbacks and simplify implementation Now that we have [higher Apple platform requirements](rust-lang#104385), the RNG code can be simplified a lot. Since `getentropy` still doesn't look to be usable outside macOS this implementation: - Removes any macOS fallback paths and unconditionally links to `getentropy` - Minimizes the implementation for everything else (iOS, watchOS, etc). `CCRandomGenerateBytes` was added in iOS 8 which means that we can use it now. It and `SecRandomCopyBytes` have the exact same functionality, but the former has a simpler API and no longer requires libstd to link to `Security.framework` for one function. Its also available in all the other target's SDKs. Why care about `getentropy` then though on macOS? Well, its still much more performant. Benchmarking shows it runs at ~2x the speed of `CCRandomGenerateBytes`, which makes sense since it directly pulls from the kernel vs going through its own generator etc. Semi-related to a previous, but reverted, attempt at improving this logic in rust-lang#101011
The versions supported by Rust was updated in rust-lang/rust#104385 to: - macOS: 10.12 Sierra - iOS: 10.0 - tvOS: 10.0 - watchOS: 5.0 Additionally, the armv7-apple-ios target was removed. Finally, since v1.0.84 of `cc` (has been yanked, but 1.0.85 will include it as well), there is much better support for specifying the deployment target for Apple targets, so I've removed the corresponding code from objc-sys.
Pkgsrc changes: * Remove NetBSD-8 support (embedded LLVm requires newer C++ than what is in -8; it's conceivable that this could still build with an external LLVM) * undo powerpc 9.0 file naming tweak, since we no longer support -8. * Remove patch to LLVM for powerpc now included by upstream. * Minor adjustments, checksum changes etc. Upstream changes: Version 1.74.1 (2023-12-07) =========================== - [Resolved spurious STATUS_ACCESS_VIOLATIONs in LLVM] (rust-lang/rust#118464) - [Clarify guarantees for std::mem::discriminant] (rust-lang/rust#118006) - [Fix some subtyping-related regressions] (rust-lang/rust#116415) Version 1.74.0 (2023-11-16) ========================== Language -------- - [Codify that `std::mem::Discriminant<T>` does not depend on any lifetimes in T] (rust-lang/rust#104299) - [Replace `private_in_public` lint with `private_interfaces` and `private_bounds` per RFC 2145] (rust-lang/rust#113126) Read more in [RFC 2145](https://rust-lang.github.io/rfcs/2145-type-privacy.html). - [Allow explicit `#[repr(Rust)]`] (rust-lang/rust#114201) - [closure field capturing: don't depend on alignment of packed fields] (rust-lang/rust#115315) - [Enable MIR-based drop-tracking for `async` blocks] (rust-lang/rust#107421) Compiler -------- - [stabilize combining +bundle and +whole-archive link modifiers] (rust-lang/rust#113301) - [Stabilize `PATH` option for `--print KIND=PATH`] (rust-lang/rust#114183) - [Enable ASAN/LSAN/TSAN for `*-apple-ios-macabi`] (rust-lang/rust#115644) - [Promote loongarch64-unknown-none* to Tier 2] (rust-lang/rust#115368) - [Add `i686-pc-windows-gnullvm` as a tier 3 target] (rust-lang/rust#115687) Libraries --------- - [Implement `From<OwnedFd/Handle>` for ChildStdin/out/err] (rust-lang/rust#98704) - [Implement `From<{&,&mut} [T; N]>` for `Vec<T>` where `T: Clone`] (rust-lang/rust#111278) - [impl Step for IP addresses] (rust-lang/rust#113748) - [Implement `From<[T; N]>` for `Rc<[T]>` and `Arc<[T]>`] (rust-lang/rust#114041) - [`impl TryFrom<char> for u16`] (rust-lang/rust#114065) - [Stabilize `io_error_other` feature] (rust-lang/rust#115453) - [Stabilize the `Saturating` type] (rust-lang/rust#115477) - [Stabilize const_transmute_copy] (rust-lang/rust#115520) Stabilized APIs --------------- - [`core::num::Saturating`] (https://doc.rust-lang.org/stable/std/num/struct.Saturating.html) - [`impl From<io::Stdout> for std::process::Stdio`] (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStdout%3E-for-Stdio) - [`impl From<io::Stderr> for std::process::Stdio`] (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio) - [`impl From<OwnedHandle> for std::process::Child{Stdin, Stdout, Stderr}`] (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio) - [`impl From<OwnedFd> for std::process::Child{Stdin, Stdout, Stderr}`] (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio) - [`std::ffi::OsString::from_encoded_bytes_unchecked`] (https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.from_encoded_bytes_unchecked) - [`std::ffi::OsString::into_encoded_bytes`] (https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.into_encoded_bytes) - [`std::ffi::OsStr::from_encoded_bytes_unchecked`] (https://doc.rust-lang.org/stable/std/ffi/struct.OsStr.html#method.from_encoded_bytes_unchecked) - [`std::ffi::OsStr::as_encoded_bytes`] (https://doc.rust-lang.org/stable/std/ffi/struct.OsStr.html#method.as_encoded_bytes) - [`std::io::Error::other`] (https://doc.rust-lang.org/stable/std/io/struct.Error.html#method.other) - [`impl TryFrom<char> for u16`] (https://doc.rust-lang.org/stable/std/primitive.u16.html#impl-TryFrom%3Cchar%3E-for-u16) - [`impl<T: Clone, const N: usize> From<&[T; N]> for Vec<T>`] (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#impl-From%3C%26%5BT;+N%5D%3E-for-Vec%3CT,+Global%3E) - [`impl<T: Clone, const N: usize> From<&mut [T; N]> for Vec<T>`] (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#impl-From%3C%26mut+%5BT;+N%5D%3E-for-Vec%3CT,+Global%3E) - [`impl<T, const N: usize> From<[T; N]> for Arc<[T]>`] (https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#impl-From%3C%5BT;+N%5D%3E-for-Arc%3C%5BT%5D,+Global%3E) - [`impl<T, const N: usize> From<[T; N]> for Rc<[T]>`] (https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#impl-From%3C%5BT;+N%5D%3E-for-Rc%3C%5BT%5D,+Global%3E) These APIs are now stable in const contexts: - [`core::mem::transmute_copy`] (https://doc.rust-lang.org/beta/std/mem/fn.transmute_copy.html) - [`str::is_ascii`] (https://doc.rust-lang.org/beta/std/primitive.str.html#method.is_ascii) - [`[u8]::is_ascii`] (https://doc.rust-lang.org/beta/std/primitive.slice.html#method.is_ascii) Cargo ----- - [fix: Set MSRV for internal packages] (rust-lang/cargo#12381) - [config: merge lists in precedence order] (rust-lang/cargo#12515) - [fix(update): Clarify meaning of --aggressive as --recursive] (rust-lang/cargo#12544) - [fix(update): Make `-p` more convenient by being positional] (rust-lang/cargo#12545) - [feat(help): Add styling to help output ] (rust-lang/cargo#12578) - [feat(pkgid): Allow incomplete versions when unambigious] (rust-lang/cargo#12614) - [feat: stabilize credential-process and registry-auth] (rust-lang/cargo#12649) - [feat(cli): Add '-n' to dry-run] (rust-lang/cargo#12660) - [Add support for `target.'cfg(..)'.linker`] (rust-lang/cargo#12535) - [Stabilize `--keep-going`] (rust-lang/cargo#12568) - [feat: Stabilize lints] (rust-lang/cargo#12648) Rustdoc ------- - [Add warning block support in rustdoc] (rust-lang/rust#106561) - [Accept additional user-defined syntax classes in fenced code blocks] (rust-lang/rust#110800) - [rustdoc-search: add support for type parameters] (rust-lang/rust#112725) - [rustdoc: show inner enum and struct in type definition for concrete type] (rust-lang/rust#114855) Compatibility Notes ------------------- - [Raise minimum supported Apple OS versions] (rust-lang/rust#104385) - [make Cell::swap panic if the Cells partially overlap] (rust-lang/rust#114795) - [Reject invalid crate names in `--extern`] (rust-lang/rust#116001) - [Don't resolve generic impls that may be shadowed by dyn built-in impls] (rust-lang/rust#114941) Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. None this cycle.
The versions supported by Rust was updated in rust-lang/rust#104385 to: - macOS: 10.12 Sierra - iOS: 10.0 - tvOS: 10.0 - watchOS: 5.0 Additionally, the armv7-apple-ios target was removed. Finally, since v1.0.84 of `cc` (has been yanked, but 1.0.85 will include it as well), there is much better support for specifying the deployment target for Apple targets, so I've removed the corresponding code from objc-sys.
This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (rust-lang/compiler-team#556).
As of this PR, rustc and the stdlib now support these versions as the baseline:
In addition to everything this breaks indirectly, these changes also erase the
armv7-apple-iostarget (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing.Per comment, this requires a FCP to merge. cc @wesleywiser.