Build a custom client app with custom native modules | Voters

Build a custom client app with custom native modules

complete

Adam Perry

From https://github.com/expo/expo/issues/86:
"First off, love what you've done. Expo is fantastic and will tremendously help get React Native in the hands of folks who otherwise would not have access to it. I'd be remiss to not also mention its kickass developer experience. So, high fives all around!
I noticed your tooling for the Expo Client is _very_ close to how AppGyver implements their Scanner. Same kind of concept -- the client already has the native entitlements the SDK expects, local dev environment has a utility to expose a port and QR code, the client QR code scan brings JS in, the app runs, and choirs of angels sing.
I saw that if you detach
 your native projects, it's basically back to "vanilla" React Native dev...which isn't terrible, but the Expo DX is so good that it will definitely feel like a downgrade.
I'm not sure if you guys have considered this, but AppGyver gave a "semi-escape hatch" for their Scanner. Basically, you could build build custom versions of the scanner (in this case, the Expo Client) with whatever custom native libraries they have linked. This would allow someone the latitude of "ejecting" and linking non-SDK libraries, but still have the DX of the AG Scanner.
Now, if I recall, it was definitely a little involved, as you basically had to create a distribution profile for iOS and keystore for Android, upload it to AG's infrastructure, and then have it build your Custom Scanner. I feel like you could even automate that process, since I see the exp
 cmd line utility creates that stuff for me.
Anyway, TL;DR: A custom-built Exponent Client would be an amazing future feature for Expo, as there's definitely a lot of use cases that would require ejecting out of the "vanilla SDK".
Thanks again for your work, and I'm looking forward to using (and hopefully contributing back to) this ecosystem!"

June 28, 2017

Brent Vatne

marked this post as

complete

Pinned

We've released a public feature preview of "Custom Development Clients" via the expo-dev-client package. You can use this in SDK 42 managed apps and more generally in any React Native app. Learn more about it in this post: https://blog.expo.io/introducing-custom-development-clients-5a2c79a9ddf8

Brent Vatne

marked this post as

complete

Evan Bacon

Merged in a post:

Configurable standalone builds

Alex Russell

I'm sure this has been suggested but I am unable to find it.
Put simply, on the road to completely custom native module builds, it'd be good to just be able to set in app.json
 which Expo bits we use or don't use. It doesn' have to be seriously fine-grained, really it's more about which 3rd party bits we do and don't want included.
For example, I don't use Segment, so I'd love to build without it so I don't have to say that I need to use the advertising identifier.
Similarly, for another example, I imagine a bunch of people don't use ART or SVG.
Presumably it'd also make a smaller build, and just generally appease Apple more that there's less code in my bundle that doesn't appear to be touched.

July 1, 2021

Brent Vatne

we are working on something like this. you can learn more in this post: https://blog.expo.io/expo-managed-workflow-in-2021-d1c9b68aa10

Brent Vatne

marked this post as

in progress

Prashant Singh

I'd rather recommend everyone to start with this starter kit https://github.com/codersera-repo/expo-native-starter-kit which let's you run both expo and native module built react-native app together.
You can follow this detailed article and trust me its worth the read. https://codersera.com/blog/running-expo-react-native-together/
After this you should be able to run expo and custom native module built app together. Feel free to reach out to me for any help.

Naga sai Vishnu

Prashant Singh: Seems like this project is not updated in a while. Is this project still relevant with expo SDK 40?

Steve Moretz

Naga sai Vishnu: That's what happens to non official huge libraries eventually :( most of them get abandoned. (I'm not sure about this one though).

Brent Kelly

This is something I'm really interested in. It would be great to have an automated way to produce an Expo Client that also had some extra's (like in house native components). The use-case I'm currently experiencing first hand is multiple new apps being developed at a company in parallel where there are shared native components like custom video players/editors, API's etc and branding (colors, icons etc). As soon as one of those apps need to use an in-house native component it has to eject. The problem is after ejecting the DX plummets and the headaches of React Native upgrades and maintenance begins.
Being able to build and distribute a version of the Expo client that also bundles an in-house SDK would be amazing!
Update
: I've just stumbled upon the "expo init / advanced / experimental (non managed)" feature and it looks like this could solve my problem? I created an advanced (non managed) expo project, built manually in Android Studio and installed the app on an emulator. Then I created a separate managed Expo project and ran "yarn start". The second (managed) project was run perfectly on the first (un managed) app that I installed on my emulator. In theory this means I could add all the custom native modules I desire in the unmanaged project and make use of them in the managed project (effectively creating my own custom Expo Client)? Is that correct?

Mitch Clay

Brent Kelly: did you progress any further with this?

Brent Kelly

Mitch Clay: Pretty much stopped after the prototype I mentioned in my original comment. I just took a look and the experimental option has been replaced with "Bare Workflow" in the CLI so I'll have to try again and see if it works the same. Expo talk about this new workflow here https://blog.expo.io/you-can-now-use-expo-apis-in-any-react-native-app-7c3a93041331 and https://docs.expo.io/versions/v32.0.0/bare/hello-world/

Brent Vatne

Brent Kelly: we're working on custom client builds internally right now. at some point this will allow users to opt-in to including their own libraries

Brent Kelly

Brent Vatne: That's awesome! Can't wait to hear more about it!

Brian Sztamfater

Brent Vatne: That will be a game-changer! Is there an ETA for that? Thanks for all the hard work :-)

Prashant Singh

Brent Kelly: you can try this https://codersera.com/blog/running-expo-react-native-together/

Caner Candan

As you mentioned in your comments, a quick workaround to this would be:
* to remove the existing Expo app in your virtual/physical device, fork https://github.com/expo/expo
* setup your own APIs keys under template-files/keys.json
 (make sure you have the correct version of NDK (r10e)
* follows the instructions about the installation of Node/JS dependencies (see the README),
* add the additionnal native modules that are missing in Expo under the android
 and ios
 files such as react-native-navigation,
* build the new Expo app, e.g. for Android, within the folder android
 by running the command ./run.sh
 and for iOS by using Xcode (see README)
* this will install your new forked version of Expo to your device and from now on you can use the new native module such as RNN in your app without having to detach your Expo environment to ExpoKit or deal with environment-specific files such as android/*
 or ios/*

Gaurav Harchwani

Caner Candan: I tried this but the standalone app is unable to open any experience. I modified the js code and keeping in mind expo trademarks, i removed all the expo brandings. However the iOS standalone build is unable to open any experience like what expo does.

Note: I made the standalone app using exp build:ios.

Alex Russell

I have found, however that this is a duplicate of https://expo.canny.io/feature-requests/p/reducing-app-size (or, at least, what it became). Or at least, it's a duplicate of "SDK plugins?" by our good friend Sébastien Lorber which was merged into that request.

As such, Brent Vatne maybe you want to merge this request in to that one as well? It'd also be worth updating that request's description to include some of the detail from my post here as that one's rather lacking in that regard, but has a bunch of votes and a suggestion that pretty much mirrors my request here from your good self.

Looks like there's really two parts to this request though:

Only ship the Expo SDK for the version of Expo you are using when creating a standalone app. Literally makes no sense to ship older version if they aren't even used by your app's JS code. I imagine this will help a lot.
Make some of the APIs that "ship" with Expo opt-in or opt-out when you create your own standalone build. You mention that it's good to have them there and "just work", so I imagine opt-out would be better, so people who want to reduce size can do so, but people who wan tit to Just Work get that experience. This will also help with things like being able to remove SDKs like Segment that require us to say we use the advertising identifier when we don't (but some dead code shipped would if it wasn't dead).

So as long as you're happy to make "Reducing App Size" cover both parts of this, then I say go ahead and merge, but do update the description if you can.

Sébastien Lorber

Alex Russell: standalone app already ship a single Expo SDK as far as I know, and Expo team is already working on making some dependencies optional. This is needed particularly for stripe payment APIs as Apple refuse to publish Expo apps including Stripe SDK but not using it.

Alex Russell

Sébastien Lorber: Ahh fair enough on the SDK versions - I didn't realise that (though it makes total sense, of course).

Sébastien Lorber

duplicate of https://expo.canny.io/feature-requests/p/native-plugins

Alex Russell

Sébastien Lorber: Actually, as I state in the description, this feature request is simply about being able to configure the native stuff that Expo

already provides

, as a stopgap measure

on the road

to completely configurable native stuff.

Sébastien Lorber

Alex Russell: it is unlikely that expo would allow you to add your own homemade built RN libraries because the Expo client is the same for all users. They can't simply add all Native code out there to it. But it might be possible to build custom clients maybe?

Panagis Alisandratos

Adam Perry It is possible to build the expo client from source, make customizations, and use it on mobile devices just as you would with the original client?

Adam Perry

Panagis Alisandratos: technically, yes, although it can be a little challenging. The https://github.com/expo/expo-dev repository isn't perfectly up to date, but it has a complete setup for building the client app from source. Note that it moves pretty quickly and that we don't make any guarantees about internals being stable. Also, while the code is permissively licensed, please respect Expo copyright and trademarks if you build your own version!

Gaurav Harchwani

Adam Perry: After building custom version of expo client, can we still publish projects to expo and make it work with our own version of expo client with custom native modules?

→