I upgraded to SDK34 successfully but after uploading the new APK to Google Play Store I get this warning:
Warning:
Users that have the APK with version code 6 may need to accept the android.permission.WRITE_CONTACTS permission, which may result in them not upgrading to this version of the app.
And an error related to that You can't edit this app until you create a new app release declaring sensitive permissions.
That stops me for updating my APK.
I set "permissions": [] in my app.json but it doesn’t change anything.
Anyone else with the same issue? Is there a workaround without ejecting the app?
Thanks - is there somewhere other than this thread that we can track this issue? It’s currently a blocker for a critical bug-fix for us, and ejecting is an unappealing option.
However, AAB size (and individual APK sizes) have suddenly blown out. With no changes, yesterday’s sizes were:
11.8 to 12.7 (from 28.9MB total .aab size)
and today’s are:
22.5 to 24.1 (from 48.2MB total .aab size)
The Play Console now warns about the significant size increase. Any insights?
It looks like the apk size increase is expected, now that facedetector being included in SDK34 apps — facedetector was being (erroneously) excluded from SDK33* Android apks, as well as any SDK34 apks built before yesterday’s fix.
*facedetector will still be excluded from SDK33 builds, so we recommend upgrading to SDK34.
You can use the bare workflow to choose what modules to include or exclude. But with the managed workflow today, the application contains the base Expo SDK. (We are also looking at offering some module exclusion for our business customers as part of paid plans for the future.)
@jess@charliecruzan I’m not sure what other plans the team has to monetize, but I’d recommend against forcing free users to have huge apps. I love Expo, but reading is a bit worrisome.
I’d understand if FaceDetector was 1MB, but it increased the size of my app by nearly 70%, on top of the 40% jump from 64 bit support.
I hope if the team goes this route (which I really don’t think is advisable in general) that it won’t mean forced inclusion of a single module that’s as large or large than the size of my entire app when I was using Expo 31.
Edit:
Just to comment on why I don’t think it’s a good idea in general, I myself personally agonized for a long time over how to implement freemium before I finally had anything to show for it. I think it’s really important that users never feel they’re paying for something that seems like it should be included. I think paying to slim down the app is not awful, but also not great as far as how users will feel about having to pay for that.
Don’t get me wrong, I know you provide a valuable service and deserve to be paid, I just think from dozens of hours spent on this issue myself that that might not be a good direction. As I mentioned though, there’s a big difference between paying to optimize the last 10%, and paying to get your app down to a reasonable size in the first place. If it feels like an optional optimization and not something users need, then everything I wrote is probably moot.
Hi @slapbox, sorry if I wasn’t clear. To address your main points of concern:
You can exclude facedetector, or any other module, already today, using the Bare workflow. In our Managed workflow, we try to serve the interests of the broad majority of our developer users, but we understand that there will always be custom use cases for various projects. We’re also investing in increased feature parity between Bare and Managed down the line. Both are available for free.
The facedetector module was a part of SDKs through SDK32, accidentally excluded from SDK33, and restored in SDK34. Aside from 64-bit support, which is now required for new Play Store submissions, this largely maintains app sizes overall.
I’m using App Bundle on Android to help, but there’s still a huge size difference between SDK 33 and SDK 34.
SDK 33: 15.3 MB
SDK 34: 22.3 to 23.7 MB
This is a 45.7% increase in app bundle size due to an Expo API that I haven’t heard of and don’t use.
There is research that notes decreased install rates for large app sizes in the majority world (i.e., higher population countries with different network and device constraints). I would highly recommend that you help us all out. I’d be happy to pay money for pro features, but you should give your free users sensible defaults.
I think it’s a tradeoff between app size and out of the box features. Free users will also not want to eject to add basic features either, so “sensible defaults” depend on who you ask. I personally haven’t needed the face detector, so I would like a way to remove it (and maybe other things) without ejecting.
I suspect the size problem is a combination of the switch to 64 bit and the face detector. SDK 32 had the face detector, but not AABs or 64 bit support. SDK 33 had 64 bit support, but no face detector. SDK 34 has 64 bit support and the face detector. So both together pushed up the size.
By the way, when you’re measuring the sizes, are you measuring the AAB size or the size of the resulting APK when installing it on a device?
It seems to me that the Expo team is well aware of the problems with app size, and it seems they are working on it or at least thinking about it.
In the mean time, free users have the option of ejecting in order to exclude things we don’t need.
@jess thanks for your response. I think I get all the plans, I just hope that FaceDetector will be able to be removed in the managed workflow since it’s nearly doubling app sizes. I do plan to use AAB and I expect that to help, but FaceDetector is absolutely enormous and that concerns me as someone who plans to continue to use Managed for the foreseeable future.
My mobile app (apk) is now approaching the size of my desktop app installer which is tremendously more robust than my mobile app.
I do have a related question on this though, which is, does a larger AAB necessarily mean more code loaded into memory? Is FaceDetector loaded into memory whether it’s used or not, or only downloaded to the disk, but never loaded into memory? Startup time is already pretty long for my particular app and reading 16mb from disk at startup alone would be a problem.
The only thing I don’t want to see is users being forced to pay or abandon the managed workflow just to bring their installer down to a reasonable size. Like I said, paying to optimize and bring 2-3mb of modules off the installer would be one thing, but if FaceDetector ends up being one of those modules, Expo is immediately going to stop being such an enormously attractive offering to developers.
Honestly, I think you’d see more support for making FaceDetector support paid than you would for making the option to remove it paid.
Just to be clear, FaceDetector sticking around and being unremovable for a while is totally fine, I just sincerely hope we won’t have to upgrade to exclude it in the coming months, since it is truly enormous.
With the increase in size caused by face detector and using app bundles, your app should still be at the same size (or even get smaller). I didn’t check exact values for this sdk, but in sdk33 without face detector expo init app apk/aab had 16 MB, but with app bundles, a user had to download 10-11 MB depending on the platform.
In face detector java and js code weight is insignificant, most of the size comes from native code(*.so files) and neural nets(stored as assets). I’m not sure about *.so files, but assets are loaded only when needed.