[Solved] Can we remove the Chromebook Libraries from the Thunkable APK exports please?

Questions about Thunkable
,
1

Hi Thunk team;

Thunkable is leaving in ABIs which don’t serve much of a purpose. The main two are x86_64 (18.6Mb) and x86 (16.4Mb) are for desktops (Chromebooks) which Thunkable doesn’t really target.

Clearly it’s a problem as shown in this post: [Solved] Unoptimized APK How To fix this issue

Removing those libraries would greatly reduce the size of Thunkable apps with only a small loss in supporting the few Chromebooks that exist. At the moment I’m having to use ‘APK Editor Studio’ to remove those libraries.

The x86 and x86_64 libraries only cover 341 (laptop) devices. but armeabi-v7a and arm64-v8a include 16,151 devices (numbers from Play Console Device Catalogue). Removing that 34+ Megabytes* for Chromebooks would make a significant difference to the app size.

Is it possible we can remove those Libraries?

Cheers,

Eric.

*After APK export the difference is smaller - my example APK went from 37.6Mb to 26.7Mb.

(more info about ABIs here: https://developer.android.com/ndk/guides/abis)

3 Likes
2

Actually after having done more reading it looks like armeabi-v7a covers most of arm64-v8a, so I got the above APK down from 37Mb to just 20Mb.

This is a great way to reduce APK size to a minimum with relatively little impact, especially if you’re targeting specific users - for example if you’re creating apps for internal business use and using a managed play store.

(But, if you’re doing a general release, or want to target tablet devices, perhaps don’t remove the other libraries…)

2 Likes
3

Hi @hdawc,

Thanks for posting about this. Unfortunately I can’t promise any immediate major reduction in app size as there is no silver bullet. But, I do want to go into a bit more detail about this issue.

First off, I do believe we want a universal apk experience (at the moment at least), even at the expense of apk size, in order to provide the simplest experience for the most users. For example, @jose pointed out that the most performant emulator requires the x86 instructions, and the emulator is used by a lot of people testing their apps. Additionally, I think we would like to support Chromebooks too even though it’s not a primary focus.

As for the 32 bit instructions for both armeabi-v7a and x86 I’d love to get rid of those as soon as it makes sense from a device support perspective. That’s a bit of a subjective line, but we’ll be watching for a good time to cut that fat, likely following the lead of Expo and React Native. Definitely reach out if you seem movement there!

We’ll certainly consider splitting APKs and providing multiple downloads but need to do a careful analysis of benefits vs costs of that additional complexity for our users. Longer term we hope Android App Bundle support will solve these issues by allowing Google to deliver the smallest possible APK automatically. I hope the managed play stores for internal business apps that you speak of can and will support Android App Bundle too but definitely let us know if you don’t see them ever providing support. I can’t provide a timeline as to when we’ll support Android App Bundle as it’s a big undertaking, but it’s definitely on our radar. Our companion app is no different from user’s app’s so we face the same warning from Google when publishing (which we do often) and are keen to remove it, but it will take some time.

FYI, the next version of our app will be a few megs smaller due to using a more efficient version of Expo. Someday we hope to be able to provide smaller builds by cutting out Thunkable code that your app doesn’t use but my guess is this would come after Android App Bundle support as it would rely on some additional support in Expo and React Native to make it more feasible.

Another development specific to Android coming down from React Native that will help with both app size and speed is Hermes. We’re excited about switching to it but don’t think it’s quite ready for us to take the plunge.

Bottom line there is a lot of things on the horizon to reduce app size but unfortunately no easy or quick fixes to provide a big drop in size without consequences. Definite keep engaging with us here and we’ll try to be as transparent as possible as to our progress.

Regards,
Mike

6 Likes
4

Hi @mike,

Many thanks for this informative reply, appreciate the news about Android App Bundle as well.

Looking forward to a brighter future with Thunkable, because now I’m seeing many other (no-code) app builder solutions (like adalo who already have Stripe, but is not as versatile as Thunk, or even the more manual AppGyver), I’m hoping app size and in-app payments doesn’t become the reason I have to move :confused:

Nonetheless looking forward to what Thunkable does next! :smiley:

1 Like
5

I’m looking forward to seeing this too!

I’m always interested to know whether or not you’ve had any complaints from your users about a 34 MB app @hdawc? I fully appreciate the point you’re making, but I think that with the average phone now having 1,000s of MB of storage this is not as “big” an issue as it was 10 years ago.

1 Like
6

Heya,

I’ve not had complaints from users, one client mentioned it, but Google is pushing smaller app sizes as well as instant apps, and with many app builders on the market, and with Kotlin and Flutter now in more competition, internal app development is becoming more popular, and easier, for smaller companies, even more so for those with existing web developers…

So when a business is looking at creating an app, doing it in house with Flutter, or other App SaaS might seem a better option when compared to Thunkable due to app size, which obviously you’d want to avoid. So I think keeping those APK sizes as small as reasonably possible, would be a sensible goal as, it will probably be important for the majority of Thunkable users (especially business users), though I appreciate there is a reason for that app size, as well considering the huge convenience of Thunkable!

Yes, the average phone might have a lot of storage, but it’s not really about that. It’s (network) data usage, and there are plenty of people, who can’t or won’t want to use (what might be) precious data, on an oversized app. Sure, people can download it via WiFi, but that’s not the point. A full re-download is required even for a minor update, as well as the obvious major update (Major Update :guardsman:) , which could end up costing users 100s of MB on just one app if it’s updated several times a month.
On that note, I’m working on setting up an app, and being able to change UI through an API Dashboard, then when users open the app, it’s changed without an update. Though that’s on the back-burner.

I feel the ideal principle should be to not have a large APK if it’s not needed, and so Thunkable could potentially remove unused code automatically. Or at least with options the user can specify depending on their self-stated level of Thunkable knowledge (e.g. “Advanced” users could opt to remove things). For now I use APK Editor Studio to do some ‘cleaning’).

Interesting to see Thunk uses React, I was wondering what it’s built on (I’m considering learning Flutter for more complex apps or using in-app payment). But I do hope Hermes comes into action soon, as it looks exactly like the solution that’s needed! :+1:

Lastly, considering I struggle to develop tablet apps using Thunkable due to no landscape view, I even wonder if more than 15% of Thunk users are targeting any kind of tablet at all…? May I suggest looking into adding a switch to change between a mobile/ tablet view in the Designer. I need to create a Kitchen Display Screen soon, and am already dreading the headaches just due to this :confused:

Thanks so much for your responses, even though there are other solutions out there, they’re usually really basic (i.e. no blocks/ logic) or just have the same features (or less!) for 5x the cost (usually due to their overzealous marketing!). So thank you to all the staff, and I sincerely hope to continue building with Thunkable! :blush: :+1:

Cheers,

Eric.

1 Like