Apps Genie: Not everything that includes native code requires a config plugin to work in an managed Expo app with custom dev client.

Their installation instructions are basically just:

(so nothing special for Android)

If you look at the iOS build process, you'll see that the iOS build servers automatically run for you during the build process. (See step 10 of the remote steps.)

So there's nothing that requires a config plugin.

If it required changes to or or something like that, then it would need a config plugin, but for there's nothing like that.

You might also want to check out

Michael Wood: oh ok that was a good explanation for me thank you, I get it now. Install always runs and only when extra custom config is needed that's where plugins come into play. Does it mean ANY new package installed requires a rebuild of the dev client or only those having pod install as instructions?

I was able to install fast-image is successfully now!

As far as expo-image I was looking around and I am a bit scared to install it yet :) (too many complaints from others so far) plus was not able to get to the latest version because it said the correct version for my project is 1.0.1 (SDK 48) but there are a few bug fixes in the latest version that I would miss, so I think I would rather wait longer since it seems like a new package to me. But not totally sure yet.

Apps Genie: "Does it mean ANY new package installed requires a rebuild of the dev client"

Yes. The rebuild is about whether or not the package includes native code. Not whether or not it requires extra config.

If you build a dev client and then run , then the old dev client does not contain the native part of . If the JavaScript parts of it try to make a call to the native parts, you will get errors. This is the same reason you can't use the Expo Go app with something like . Expo Go doesn't have the native parts compiled into it.

I'm glad you were able to install .

Yes, is not very old yet. No problem waiting a bit :)

Michael Wood: Understood! I just know one time I was able to add a package and didn't have to rebuild so that means the package must have been pure JS. I guess I need to look at the documentation of each package to see if it has native bits or not (that's how I'll know I need to spend extra time/resources rebuilding).

JS w/o any pod install (+equivalent for android?) = no dev rebuild (until prod)

JS with pod install = need to rebuild dev lient

JS with extra native instructions = rebuild + plugin config

Apps Genie: Yes, if you were able to add a dependency without rebuilding your dev client, then it must have been pure JS.

If it's pure JS, it won't have or directories. But that's not a 100% guarantee, because it might depend on something else that has native code.

If it mentions or React Native autolinking or something like that, then it has native code and would need a rebuild.

If, in addition, it says stuff about changing or or or other native code, then it will probably need a config plugin.

Michael Wood: got it! thank you again for this

aestheticbeast345: Have you tried ?

Michael Wood: I've tried and it had many issues, and the performance was lower than the standard React Native Image component.

Carlos Portela: it is not that this is "difficult" to do, but we will not do it because we do not believe that it is the right decision for expo go. i think it would be good to get used to the dev client workflow because that is our recommended way to work if you want a similar experience to expo go but with your own customizations.

Brent Vatne: I understand, thank you for the reply. I have mixed feelings about this "custom dev client" approach. Yes, it is very cool and flexible, but I personally prefer to "shoot and forget". What used to be so simple becomes kind of a chore now with this approach. Is this the new approach going forward or will you continue to incorporate "selected" modules in the SDK? Back to the actual component, the real solution is for somebody to finally fix the <Image /> component. Thanks!

Cannot agree more with Carlos. The beauty of Expo used to be the plug-and-go experience and the crystal clear documentations, so self-taught programmers like myself can save ourselfs the misary of having to move mountains before setting up the app. Now I and my app are completely at a pause (hope I'm not the only one) because there are a ton of issues to fix and stuff to learn before I can make it work. I'm certainly underqualified to pass judgement on this approach. All I can say is I feel foreign and disappointed with the conclusion here

Brent Vatne: I am currently working my way through a React Native course that uses expo, and I've been shown that fast image is the "only way to go, it's the best"! What tradeoffs are there for going down this 'custom dev client' route? expo go is a phenomenal product, i just start it up and scan the qr, does the workflow change? you said the app store or google play store doesn't have it installed?

Derek McLean: you can learn more here: https://docs.expo.dev/workflow/customizing/

Brent Vatne: great!

Orel Hassid: Same here :). Mosh should be given some credit :)

Orel Hassid: x3

Orel Hassid: the same oh my God!

Sergey King: not inside changelogs :/