I have an app with a few thousand users and growing. A complaint of my users and something that I see reflected in the metrics is that the app takes a really long time to open, especially with a bad internet connection. I’ve noticed sometimes a few seconds pass before my logo even shows up on the loading screen with the spinner.
Are there any plans to fix this or is it just a react native thing? Will detaching give me the ability to speed this up?
Also interested in this. Been quite a pain point
I have an app with a few thousand users and growing. A complaint of my users and something that I see reflected in the metrics is that the app takes a really long time to open, especially with a bad internet connection.
do you find this is the case more on ios than android recently? we switched over android to check for a new manifest / js bundle in the background, but haven’t done this yet for ios.
another contributing factor is assets: if you use the AppLoading api, the splash screen remains visible until you’re done executing whatever code you need to check that your assets are cached (or actually caching them if they changed). we’re currently working on bundling assets inside of standalone apps and hope to land a first version of this for sdk 23, if all goes well.
I’ve noticed sometimes a few seconds pass before my logo even shows up on the loading screen with the spinner.
you can switch from the loading api in app.json to splash in sdk22 and this will resolve the issue for you. we will deploy sdk22 later today. check out our staging docs on splash screen here: https://staging.docs.expo.io/versions/latest/guides/splash-screens.html
I’ll do some testing and get back to you on that.
I’m going to switch over to the splash api and see if that helps. Thanks for help
I notice the same issue as well. There is 3-6 second delay on the splash screen (default to white) on iOS before it loads the icon and spinner.
On android, it loads quickly as a native app would. I have yet to analyze the network request via proxy as I think on iOS, it downloads the bundle each time the app loads regardless of current local store bundle revision is already up to date.
hey @jchum - i’d recommend changing to the new splash api, there will be no white screen anymore or spinner. see more info: https://docs.expo.io/versions/latest/guides/splash-screens.html
@jchum Your hypothesis is right – currently (circa SDK 22) on Android, standalone apps use the last cached version of the project and look for updates in the background, which will be applied the next time the app is launched. On iOS, standalone apps currently look for new updates when launched and fall back to the cached version if there is a network issue.
The Android behavior is newer and more reliable for end users so we’re looking in that direction for iOS. Plus it’s easier to think about one type of loading behavior instead of several.
@ide As it stands, the load time for iOS users is anywhere between 10-15 seconds, half of which goes to the app downloading the JS bundle. I’ve been testing on AT&T (San Francisco). I’d imagine that this is more painful on lackluster mobile connection. I’m looking into delink the code for iOS, but unclear if this will bundle the JS within the app binary (ipa) so it by passes the OTA bundle updates.
I could then use Android to continue to iterate and test quickly, then go to a weekly release cadence for iOS if my assumption is correct that the standalone IPA file will have all the necessary JS assets when it launches.
Is there any plans to resolve this on the next SDK release? It’s a bad first time user experience as well as subsequent loads. I’m still getting a lot of feedback from users that the app loads very slow and that’s from just about 300 users. And those are the ones vocal enough to give me feedback.
There are plans to make iOS’s loading behavior more similar to Android’s for several reasons but not in the next SDK.
@notbrent, Android got a litte bit better but its still not really fast.
On iOS the two Expo apps I have in Testflight are extremely slow to start.
The change to bundle assets inside standalone app would be most welcome.
Its hard to explain to users why quite smallish (Expo) apps have almost twice the (cold) startup time than iOS Safari.
I’m building a standalone app and it seems the app takes quite a while to open, even after the first time. I disabled AppLoading code so that there is nothing blocking there. And I tried it several times in a row, so there are no new app updates to be downloaded. And I’m using the new Splash API not the old Loading one. About 3-4 seconds on a fast WiFi or LTE connection each time I close and re-open the app.
Is there any way to log or show what exactly is happening while the splash screen is up? Does just checking if there’s a new app updates consume this much time?
I will try setting isRemoteJSEnabled to false and see if that helps.
you should try the configuring this for ios: https://docs.expo.io/versions/latest/guides/configuration.html#loadjsinbackgroundexperimental
Thanks a lot! Will try that!
With loadJSInBackgroundExperimental = false on my standalone app: I’m down to roughly 7-10 seconds launch time for iPhone 6 and 3-4 seconds launch time for iPhone 7. Ideally looking to cut the iPhone 6 launch time in half.
Any recommendations for improving this further? Should I be looking into making the js bundle size smaller? Removing large npm dependencies? etc?
It’s not clear how much time is spent downloading and parsing your bundle vs. rendering the initial screen. If you have an intensive initial view hierarchy, that could further slow down your start time – I’d try to simplify and render just a simple screen with “Hello” to see the cost of getting to that point.
If you do have a large JS bundle, then that’d affect download times as well. It’s not clear if that’s actually impacting you – you’ll have to investigate that yourself. Generally removing large dependencies could help but I suspect there are a lot of “it depends” answers here that are specific to each app.
render less on your initial mount. just render one piece of text and notice that it is much quicker. don’t block loading with AppLoading at all if you want. then work up from there, adding pieces until you are content with the balance of initial content shown to the user and speed to start the app
loadJSInBackgroundExperimental would work if I just publish the app at expo server, or do I need to upload the app again to app store?
thanks, will give it a go tomorrow