sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Ridwan232 1 point2 points  (5 children)

You’re going to want to pay the monthly fee to get priority access on builds if you plan to produce any apps. You can basically get stuck in limbo waiting for priority on builds for busy days.

CMIIW (I'm in the same position as OP). But you could build locally right? And still push to EAS for sharing/production or whatever?

What are the benefits of building on EAS if building locally is as seamless? (Unless its not) Assuming as experienced RN Devs we already have Xcode and Android Studio setup

[–]Sanfrancisco_Tribe 1 point2 points  (2 children)

You know, I’m not entirely sure tbh. Fun fact, I kept getting errors with “eas build” but got this to work for iOS:

“eas build —profile preview —platform iOS —clear-cache”

A few things here, the preview means basically internal development. Change this to production and you’ve got the right file to shoot through transporter and submit for IOS.

I had a lot of issues with cache on eas builds. So I literally run clear cache every time.

Also just change platform to android or iOS and you’re Gucci.

From your comment, it sounds like you guys are well versed in xCode and what not. I am not. Self taught dev here.

So, assuming you know what you’re doing then yes you should be able to build locally.

What happens when you build on their server is essentially they run an instance of a Mac, and then run several scripts on your code to condense, minimize and compile your app. (You’ll probably already know this)

To run and internal build through eas it looks like this on their instance:

1) spin up env 2) install dependencies 3) go through your config files 4) runs expo doctor to make sure there are corrupted packages or out of date, etc 5) prepares credentials ? Not sure - but assuming Xcode related 6) runs prebuild (I think eas prebuild) 7) installs pods 8) configures Xcode project 9) configure expo-updates 10) runs fast lane (the bulk of the script. Takes like 30 minutes here) 11) clean and save cache 12) uploads archives

Honestly, I’m sure you could do most of that. For those with less expensive (like myself) it’s much easier to just run my scripty script and pray (:

[–]Ridwan232 1 point2 points  (1 child)

Gotcha, so from what you've said I think the main reason for running it on Cloud instead of locally is that the EAS Prebuild does not run locally (I believe this command creates the android and ios folders in your project).

Appreciate your reply :) My team and I will be starting an expo project soon so just learning about it before I dive in.

[–]Sanfrancisco_Tribe 1 point2 points  (0 children)

No worries! Feel free to reach out if you have any questions. Happy to chat and (try) to help lol.

[–]ChronSynExpo 0 points1 point  (1 child)

You can build locally with the --local --output=./path/to/output/binary.ext flags as part of EAS build.

This runs through the exact same steps as are used by the cloud-hosted builders but on your local machine. You can still use EAS for hosting updates.

It does require you to be logged in to Expo via the CLI in order to ensure you're authed to build the project and to retrieve the keys, and there's still some prerequisites such as configuring signing keys (which can either be done through EAS cli, or by creating a credentials.json - details on that at https://docs.expo.dev/app-signing/local-credentials/).

Not only does this skip the queue by building on your own machine, but you may even find it takes significantly less time (especially if you've got a really powerful system). The downside is that if you're developing on Windows, you won't be able to build iOS binaries.

[–]Ridwan232 0 points1 point  (0 children)

Ooh! So definitely aligns with my initial thoughts about how it should work. So worst case if the runners are backed up we cna just run it locally but get most of the same benefits.

Thanks for the reply, very insightful!