Clarify target platform support

[janhohenheim]

Over the last years, quite a few issues came cropping up specifically on intel macOS. Here's a handful:

• macOS intel with integrated gpu - strange shadows artefacts  #3315
• Intel MacOS memory leak due to wgpu bug #9035
• mesh2d example panics on macOS #10849
• Bevy 0.8.1 3d_shapes example crashes on startup - macOS #6495

When #14054 was reported, @mockersf described it as "one more added to the pile". In short: our Intel macOS support is not too great.

Some of these Intel models are quite old at this point. New versions of macOS still support Intel chips, but limit the features available there. Meanwhile, Intel has recently ended support for the chips running in many Intel macOS machines.

This, in addition to our current handling of issues coming up with Intel macOS, makes the platform today already a secondary priority. We should be honest about this to

• help maintainers prioritize bug reports
• help game developers make an informed choice about whether Bevy can satisfyingly target their audience

There should be a list of supported platforms somewhere, indicating which level of support they can expect.

---

The following was part of the original issue when it was called "Clarify Intel macOS support". Per the comments below, it seems to be generally agreed upon that Intel macOS should be a second-tier supported platform. I'll leave the following here for posteriority.

Given that Intel-based macOS are bound to be fully replaced in the near future, it's worth considering taking a stance here. I see the following possibilities:

• Officially support intel-based macOS. TBH, I'm not sure Bevy even has an official list of supported targets other than a broad "Windows", "iOS", etc.
  • I don't think doing this is worth it.
• Officially drop support for intel-based macOS. This effectively means closing any issues that are only reproducible on intel-based macOS and possibly removing the [target.x86_64-apple-darwin] target from templates and config.tomls.
  • This is my recommendation.
• Leave it as-is: "macOS" is supported, whatever that means. If intel machines cause trouble, open an issue, but it's not a big deal.
  • This is fine, but means I cannot really clean up these old issues mentioned above. Additionally, new versions of Bevy will continue receiving bug reports for Intel-only that will probably not be resolved.

[BD103]

For reference, the latest Intel Mac was in 2019 / 2020, so about 4 years ago.

[Braymatter]

FWIW I feel like there would be an appreciable number of people using the latest intel macs for another 2-4 years, and Bevy should support it for another couple of years.

[BD103]

FWIW I feel like there would be an appreciable number of people using the latest intel macs for another 2-4 years, and Bevy should support it for another couple of years.

I agree, but it's hard to test fixes for the above issues without owning an Intel Mac, which aren't sold anymore. It's really between dropping support for a platform that people are still using or continue supporting it, but not well.

[cart]

My personal vote is for "leave it as is". There is no harm in cataloging this information and making it available to people that encounter the issue and/or are interested in fixing it.

I interpret "leave it as is" as "support isn't a top priority, but lets record the info we can and if fixes are discovered that is great".

[janhohenheim]

@cart that's fair enough. What do you think about making this more explicit? We could have something like the following somewhere.

Tier one support

• Windows 10 and 11
• ARM macOS
• Linux on X11 and Wayland
• etc.

Tier two

• Intel macOS
• etc.

I'm not suggesting changing anything about what is supported, just making it more explicit how the team already thinks and prioritizes these targets. The intentions behind this are:

• Help maintainers prioritize bug reports
• Help game developers make an informed choice about whether Bevy can satisfyingly target their audience

[Elabajaba]

I think we need something like wgpu's supported platforms table.

https://github.com/gfx-rs/wgpu?tab=readme-ov-file#supported-platforms

My personal vote is for "leave it as is". There is no harm in cataloging this information and making it available to people that encounter the issue and/or are interested in fixing it.

I don't agree with this. IMO it makes for a bad first impression and makes bevy look amateurish when we claim to support all these different platforms and backends, but don't have a list of the major caveats when targeting eg. Intel Mac, Android, or GL.

FWIW I feel like there would be an appreciable number of people using the latest intel macs for another 2-4 years, and Bevy should support it for another couple of years.

MacOS gaming, especially for indie games, is just not worth supporting if you're trying to actually make money (it's generally around 1% of sales, though some newer post mortems I've seen have it even lower, and takes up significant development, support, and testing time). If you're lucky the sales will cover the cost of the mac mini and apple developer account that are required to even make mac builds. Adding on to that fact, we've never even had fully working support for it (and some of our intel mac bugs seem to be driver bugs that will never get fixed, as those drivers don't get updates anymore).

[cart]

To be clear, my position is "lets not close out these issues, and we should encourage people to both file them and investigate them".

I'm on board for attempting to encode the details of our platform support somewhere. Phrasing this as a "tier system" is a good idea and I agree that Intel MacOS should probably be in a "second tier" with qualifying text.

For both marketing and "reader attention bandwidth" reasons, that isn't something that should be directly front-and-center (aka directly encoded on the homepage or top-level readme). That is a level of detail and nuance inappropriate for those places. But I'm all for making this information available, encoded somewhere discoverable + link-able.

[janhohenheim]

Great, I'll rename the issue then and remove the X-Contentious label :)