> Apple controlling the hardware makes it way easier though.

I'm not sure that's really relevant.

Rather:

* apple has resources, lots

* apple wants to promote the use of swift, making it easier and more convenient is a good way to do that, binary dependencies reduce the complexity of the build process because you don't need to build dependencies

* apple has a vibrant ecosystem of small closed-source shops, binary-only distribution is useful for those, as well as for themselves

* promoting binary and eventually dynamically linked dependencies might mean the ability to dedup' on-system dependencies

I believe what they meant was that Apple needs to support less hardware variations. Compilers frequently have a host of flags that depend on CPU features which can potentially make the code behave slightly differently. If cargo was to implement this, they need to compile each package many times (with different configs) more than apple need to do so for Swift.

And yes of course it is given that apple's resources is vast to say the least.

> I believe what they meant was that Apple needs to support less hardware variations.

I understand that very well. My point is that they wouldn’t be doing it regardless if they didn’t want to, and if they really want to (for reasons I outlined) they have the resources to make it happen essentially regardless of the constraints or hardware breadth.

Apple also took a multi-year effort of designing a stable ABI for Swift as means to enable exactly this scenario.

The stable ABI was so Apple could ship Swift in the system. The fact that it enabled binary dependencies was more of a freebie.