permalink: "/{{ year }}/{{ month }}/{{ day }}/rustc-ios-and-an-m1"
title: "This Week in Glean: rustc, iOS and an M1"
published_date: "2021-04-16 15:00:00 +0100"
layout: post.liquid
data:
route: blog
tags:
- mozilla
- rust
---
(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean.)
All "This Week in Glean" blog posts are listed in the [TWiG index](https://mozilla.github.io/glean/book/appendix/twig.html)
(and on the [Mozilla Data blog](https://blog.mozilla.org/data/category/glean/)).
The default Android emulator isn't usable on M1 hardware yet, but Google is working on a compatible one: [Android M1 emulator preview][android-emulator].
It's usable enough for some testing, but for that part I most often switch back to my Linux Desktop (that has the additional CPU power on top).
## Glean iOS on an M1
Now we're getting to the interesting part: Native iOS development on an M1.
Obviously for Apple this is a priority:
Their new machines should become the main machine people do iOS development on.
Thus Xcode gained `aarch64` support in version 12 long before the hardware was available.
That caused quite some issues with existing tooling, such as the [dependency manager Carthage][carthage silicon issue].
Here's the issue:
* When compiling for iOS hardware you would pick a target named `aarch64-apple-ios`,
because ... iPhones and iPads are ARM-based since forever.
* When compiling for the iOS simulator you would pick a target named `x86_64-apple-ios`,
because conveniently the simulator uses the host's CPU (that's what makes it fast)
So when the compiler saw `x86_64` and `iOS` it knew "Ah, simulator target"
and when it saw `aarch64` and `ios` it knew "Ah, hardware".
And everyone went with this, Xcode happily built both targets and, if asked to, was able to bundle them into one package.
With the introduction of Apple Silicion[^3]
the iOS simulator run on these machines would _also_ be `aarch64`[^4],
and also contain `ios`, but not be for the iOS hardware.
Now Xcode and the compiler will get confused what to put where when building on M1 hardware for both iOS hardware and the host architecture.
So the compiler toolchain gained knowledge of a new thing: `arm64-apple-ios14.0-simulator`,
explicitly marking the simulator target.
The compiler knows from where to pick the libraries and other SDK files when using that target.
You still can't put code compiled for `arm64-apple-ios` and `arm64-apple-ios14.0-simulator` into the same universal binary[^5],
because you can have each architecture only once (the `arm64` part in there).
[^5]: ["Universal Binaries"][apple universal binary] have existed for a long time now and allow for one binary to include the compiled artifacts for multiple targets. It's how there's only one Firefox for Mac download which runs natively on either Mac platform.
