Build Signing with EAS

[00:00:00]
>> Kadi Kraman: The last two topics that I wanted to cover, we're obviously going for the heaviest topics last. But this is something that is really important to understand as a native mobile developer, especially coming from the web. And the reason I wanted to just cover it briefly, at least shallowly, is because you don't know what you don't know.

[00:00:22]
And this is giving you an idea of what build signing is and how it works, so that if this is the first time you're hearing about it at least you know what's to Google next. In order for any apps to be installable on a physical device they need to be signed.

[00:00:38]
So build signing is a security mechanism and the idea is, well, the goal is to protect users from potentially malicious applications. Both iOS and Android have build signing, but the process is completely different between both of them. On Android, builds are signed using an Android keystore. So this is a cryptographic container for your keys.

[00:01:04]
The keystore can be created on a Mac, Windows, or Linux. And actually, if we look at our Android build.gradle, we can see a keystore. So build.gradle is here. And if we look at the build config.
>> Kadi Kraman: There you go, so there is a debug keystore here. So this is the keystone necessary to run this Android app on an Android device.

[00:01:38]
So if you plugged your android phone into your computer you could run this on your android phone. So it would build up a apk and you can also run it on an emulator because of this reason. By the way we talk about like debug keystores and upload keystores and production keystores release keystore.

[00:01:57]
And when I first got started I thought they were like different types of keystores but they're not, it's like having a production API key and dev API key. They're the same kind of thing it's just one you should keep more safe than the other. So for the release build you'd usually create a separate keystore and we call it the upload keystore.

[00:02:19]
So, originally, you would have a release keystore for your release build, and then that's the one that you sign the build that you upload to Google Play, and then you would always need to sign with the same keystore. And a couple of years ago, Google actually migrated off it, and they managed Google Managed Build Signing.

[00:02:39]
You can opt out of it, but you shouldn't. The reason that this is really handy is because previously, if you for some reason, lost this keystore. So say that you had someone build your app ages ago, and they've left the company, and they were the only ones that had the keystore, and you wiped their computer.

[00:02:59]
There is no way to publish an update for that app. So for that reason, well, there are probably more reasons, but that was the main reason that I think Google actually decided to take on the build signing. So now the actual production keys are managed by Google. So you still need a keystone but we call it the upload keystore because it is the keystore that Google validates that this app came from you.

[00:03:26]
So you still sign it, but it is not the keystore used when signing a build delivered through Google play to the user's device, so that's what that means. So nowadays if you use Google Manage build signing and you lose your upload keystore. Then you have to contact customer support, but it is possible to get this keystore reset so you won't lose your app forever.

[00:03:51]
On iOS, things are much more complicated. I think I was several years into my React Native developer journey before I felt that I really understand build signing on iOS. And these days, I can write this down from memory, but I've had many goals of trying to explain how it works because there's just so many bits and it It feels unnecessarily complex.

[00:04:21]
The main thing you need to know is that there are three types of builds for iOS. There is a development build, an ad hoc build, and a production build. So here is a graphic that I created to try to illustrate the things that exist. So you will have an app ID.

[00:04:46]
So this is something that we set up. We had to choose our app ID when we run pre-build for the first time. And an app ID is a unique identifier for your app. And it's usually like get reverse domain, but you can call you can do it whatever, but it needs to be globally unique.

[00:05:05]
And all these provisioning profiles that you generate are tied to your app ID. So you can't sign a different build, a build with a different app ID using This app's provisioning profiles. So we have three provisioning profiles and they correspond to the three types of builds that you can do.

[00:05:30]
The first one is the development build. And the development build, you can only do it via Xcode. So if I open Xcode and I open, so it's open existing project and code, plantly. So if you ever need to open a React Native project in Xcode, the best thing to do is you just select the whole iOS folder.

[00:05:57]
Don't try to like figure out which file to open, open the whole iOS folder and then it opens it correctly. So here, if we go to the signing capabilities, but you do need to log in, and then if you can log into any Apple ID account, it doesn't need to be delivered account.

[00:06:19]
And then you get access to this personal team and with this personal team you can do a limited amount of development builds via Xcode and that's the only way you can do it. It is restricted for example you can't use push notifications with it so if you add push notifications to your app you need to do a development build with A developer account, so it is still limited.

[00:06:46]
>> Kadi Kraman: Right, so that is the development build. The ad hoc build allows installing on specific iOS devices that need to be registered on the App Store Connect. So you can have, I think, up to 100 iOS devices at any one time. And devices have this UDID, which you can get if you plug your phone in and look at the phone settings, the stats in finder, you can find your udid and you basically this.

[00:07:19]
The devices by UDID will be tied to this ad hoc certificate and they use it to sign your build, and then that build can be installed on those particular devices. So for the ad hoc build, we use the distribution certificate so these all go together, so there we go.

[00:07:40]
So for development, so the one with Xcode, we use the development certificate and development provisioning profile. And then for both ad hoc and distribution builds, so these are the builds that are installable stand alone without Xcode, you can download a bundle and install the regular device. Those Both use the distribution signing certificate.

[00:08:03]
If you do use the EAS CLI, I mentioned that it handles bill signing for you and it is pretty magical. Let me just show you how it works.
>> Kadi Kraman: So, one thing to note that unless I add the simulator true, all builds, built using the ESCLI, including the development build, are using the ad hoc certificate.

[00:08:39]
Forget. This means that in order to build an iOS build with EAS that runs on your device, you do need an Apple developer account. And this is because you need Xcode to build it, so it's very difficult to do on the cloud. And again, this is why when you're doing development locally.

[00:08:59]
You don't have to have a developer account. It is handy to be able to have your local development environment set up so you don't need an apple developer account. So let's do a preview build. So we have ES already set up. So if I do eas build Profile preview and platform iOS.

[00:09:28]
Before I trigger this, so preview build will be this one. It needs a distribution certificate and the ad hoc provisioning profile. So if I run this, it actually prompts me to log into my Apple developer account.
>> Kadi Kraman: And so something I did cuz I've never run this before, it actually registered my bundle identifier on App Store Connect for me.

[00:09:58]
So now if I If I go back to Certificates and Identifiers, then there you go. So we actually have our new plantly identifier. So this is a prerequisite to being able to generate any certificates, because they are tied against this app ID. And now this is asking if I want to reuse a distribution certificate that I already have.

[00:10:27]
So this is, again, something to bear in mind. So usually each account should only have one distribution certificate. So even if you have ten apps on your Apple developer account, for distribution they should use the same certificate.
>> Kadi Kraman: And now it's asking me want to reuse it? So let's say yes.

[00:10:51]
Okay, so this is an ad hoc build, and as I mentioned, you need to specifically say which devices you want to include in it. So I've registered a bunch of devices already. If you haven't, this will also prompt you to register new devices. So you can do it via QR code or you can manually pass in a, Serial number.

[00:11:24]
>> Kadi Kraman: So now this has created my ad hoc provisioning profile.
>> Kadi Kraman: And if I go here,
>> Kadi Kraman: So,
>> Kadi Kraman: Okay, so I think it's not here until we've built.
>> Kadi Kraman: There it is. Okay, so this is the one that was created. Another thing to bear in mind is that when you use specific services on Apple.

[00:12:06]
So if you build an app and you need to add what's a common one here? I think like push notifications, like on maps I think there is push Yeah, get push notifications, those are enabled by default, sign in by Apple. So these are like specific, we call them capabilities.

[00:12:30]
Then these are registered in your app identifier and you need to rebuild your app with the provisioning profile that's been updated since these were changed. It's a bit tedious, if you're using eas you shouldn't update this manually ever. And the great thing is that the next time you build, if you add a new library or new capability, the next time you build, it'll automatically CLI will say we've synced your capabilities, so we'll do it automatically, which is great.

[00:13:02]
And just to call that, so I've used the cloud builds, but if you put--local at the end of any eas build command, it will run on your local machine, so it will do exactly the same thing if. Will do the credentials, it will ask me to log into my Apple account and it will, there you go, it actually syncs capabilities.

[00:13:27]
So I'm going to say reuse the profile instead of register new devices and what is this saying? I don't have fastlane available. Android might probably work, let me try Android.
>> Kadi Kraman: So if you do have your native build environment set up, so there we go. So these you can see that these steps are the same as you would use on eas.

[00:13:54]
So you do have your local build environment set up. You can use the eas build commands to manage your credentials and then run on your local machine and not on the cloud. So you'll be paying anything for it because for eas all the CLI tools are completely free, the only thing you pay for is the build time.

[00:14:15]
So if you're building on your local machine or you can use this to build on your own infrastructure if you can't use eas, then go for it.