It's not more, it's 100% on your friend, I'm afraid. One is not supposed to jump to the newest version every time simply because one can. Updating the minimum supported Rust version is a breaking change that should not be done lightly.
This is not the majority sentiment, for better or for worse. The project stopped releasing "what version of Rust do you use most" in the survey results in 2020 (which is a shame, imho) the vast, vast majority of folks use the latest stable, and very few use a previous version of stable. I have no real reason to believe this overall trend has changed since then.
This is especially true for an application, which this project seems to be. Libraries may have more of a reason to explicitly lag behind the latest, but there's not really a good reason to bother if nobody else is going to depend on your code.
And God forbid you fall behind on React Native major releases in a project. I think the Expo project's solution to this is for all of the native configuration be done via plugins and cross-platform config[0]. Otherwise you'll be dealing with large diffs of native Android/iOS code that would have even native mobile devs tread carefully.
[0] https://docs.expo.dev/workflow/prebuild/#sensible-upgrades
Someone should tell that to Rust library devs, because from what I understand, their packaging ecosystem pretty much always assumes that all libraries are running on the latest version of Rust.
There's no "commonly used versions" or LTS builds for Rust, so it seems that every packaging maintainer just supports the latest and everyone is up shitcreek if a new version changes and hard breaks code for older Rust. With how micropackage oriented Rust is, you practically can only jump to the newest version if you want your builds to keep working since I doubt you'll be using stdlib-only Rust.
Compare and contrast every (anecdotal) Rust users favorite bugbear, Python, where if you're building a library, it's pretty commonly assumed that you can follow one of the two major deprecation points for Python versions (end of bugfixes or end of security updates), which means most major libraries usually follow one of the two for the internal features (and therefore lowest version) they use.
The bytecode would only ever work with the VM that it's been compiled against I think, which sounds to me like the real issue here...?
I don't think you'd have this issue if you'd fetch your rust dependencies via git and then build them locally.
And pre building for every version is expensive, which is likely why the rust ecosystem doesn't really do it right now.
And I doubt it's gonna change unless a MAMA (Microsoft, Apple, Meta, Alphabet) company "embraces" it... The EEE style
Rust does not have a VM, and doesn't use bytecode.
That being said, it could in theory serve them as binary code, which yes, would then mean that it would need to be stored per version and per architecture both, which would be quite a lot more than the source that's stored now.
Why? As I see, requiring a higher minor version of your dependency including the compiler is not a breaking change (and does not warrant a major version bump wrt semver), as there should be no problem in bumping the minor version of any dependency, even if it's used for different packages.