it will be great if there will be any options to help reducing app size because just simple app size take 24Mb and thats a lot
I don't really know if this is doable, but currently the Expo SDK always ships with GoogleMaps / Segment / Branch ... and maybe other libs later (like Intercom?)
Not increasing too much the SDK size by including every lib out there is a concern, yet the more libs are included the more usecases would be covered.
I think it would be nice if some SDK libs were opt-in. The Expo client's purpose is mostly to provide a good DX so it could embed all plugins, while the standalone apps could allow to remove some unused native code.
The plugins would only be "official ones" to reference in expo config, and not done by random users, otherwise the Expo client wouldn't have the code to run the all the apps. Allowing custom plugins, leads for me to a quite messy experience (based on experience with Phonegap Developer App, which is the Cordova equivalent of Expo client): people needing custom plugins could simply detach.
The expo client should remain large and include as many api. It should be possible to reduce the size of the final application. If you split the SDK into separate npm modules, then this will allow you to manage the size and also allow them to be used in applications without expo
I was searching for similar stuff. Wanted to use an expo module for a non-expo project.
@Sergey Khomyakov: Why not build a tailored client for every plugin, if you got expo package file, and native plugins implemented
Could you guys have a try on this suggestion? It claims that can reduce 86% of the size, and make the package into just 7MB.
https://medium.com/@aswinmohanme/how-i-reduced-the-size-of-my-react-native-app-by-86-27be72bba640
Seems like one way to go is to implement native plugins and then split sdk into the core and other optional modules.
Expo client can still include all of the plugins, but standalone application should be able to specify which one it needs.
we've been working on refactoring expo sdk such that we can pick which apis we want to include/exclude, this is in a good spot now and our next step is to migrate all of our apis to this architecture, and then we need to add support for this to our build service. no eta yet but this is well underway
this is a tradeoff of using expo right now, but we plan on addressing it.
why does this happen? we include a lot of apis so that you can use them without having to deal with configuring the native dependencies in your app, and you can push over the air updates without fear of it breaking due to mismatched native / js versions. like in a web browser, apis are there and just work.
the app size remains relatively constant as your app grows, it may only change by a couple megabytes at most because the only thing that changes is the size of your app javascript (although when we make it possible to bundle assets in standalone rather than cache on load, that will change a bit, but it's under your control).
one thing that we will likely do is remove all sdk versions except for the one that your app is using when you build a standalone app. the expo client includes 6 or so sdk versions (at the time of writing) and your standalone app may not need them all. this is not straightforward to do, however, from an engineering perspective, but we hear you loud and clear and will get to this.
@Brent Vatne: This would be very helpful for simple apps. Thank you!