Android: how to handle large build sizes?

I am having a app which includes about 500MB of images, required for documentation purposes. The app is meant to be download and working offline, so off- and side loading is not really a solution.

How can I mitigate the issue that the final build is larger than 150MB? I saw some ppl recommending splitting the apk into multiple, but
a) this would lead into a separate download (but I might be fine with this, as this requires connectivity only at this time) and
b) is this we can archieve with Capacitor?

/heiko

Hi
can you put the images on a server which you download after install and save on the filesystem using a filesystem plugin?

So basically deferring the download of the static assets - either on demand or all at once after isntallation of the app

Like with many games and so on.

Hello Heiko,

did you use the --prod flag when compiling your app? This reduces the bundle size by quite a lot.

Are you currently using Cordova? I can confirm, that Capacitor has a smaller bundle size.

Regards,
Marius

Could be an option. The only thing I am not so keen is having iOS and Android specific code, as Apple doesn’t like the idea of sideloading content. They got very picky in the past. But this could be manageable somehow.

Are you, by any chance, aware of a plug in that supports ZIP decompression?

/heiko

I am using Capacitor, but the bundle size of the app itself is not the challenge, it’s the 500MB of images who have to be in there as it is a reference app… can’t compress them down to below 150MB in total :see_no_evil::joy:

If you use Capacitor plugins it is pretty unlikely you need to touch native specific code yourself, so not sure if I understand your worry.

I have no experience with zip/unzipping in capacitor. Obviously you can do this in Javascript itself - but maybe better do it then in a webworker.

If you can’t compress the images (because they are compressed on their own), then zip isn’t really necessary right?

The current state of the app is accepted by Apple (already submitted and in the store) and Apple requires content to be in the bundle (or delivered via Apple’s CDN, but this is not supported by Capacitor or Cordova at the moment)

For Android I would have to add code to check if it runs on Android and then handle the images differently (downloading on launch / after install, different paths for displaying).

It’s not about the compression, I just want to download one single file and over hundreds, if not a thousand :wink:

Yeah, I am already looking around for some lightweight JS libs

Does this all make sense? :thinking:

Definitely it makes sense.

A consideration for a big file download - maybe better to split or even in individual files and send hashes over to check? This way you also create a way to resume a broken download due to connection failures.

As to apple - I have no experience with that. Although there are apps like games that allow for in-app downloads of maps, skins and so on. I wonder how that would be different. Anyway, I haven’t been there.

Hope others can chip in

Yep, that’s usually achived via Apples or Googles ODR mechanism. So the content is delivered by Apples (or Google) Content Network (aka On Demand Ressources). This way they make sure that the submission is still compliant the the store rules.

1 Like