You may be able to use proguard to shrink the final APK size, but your mileage may vary and it might also break your app, so use it with care. It also depends on what assets, etc. you put into your app.
1 Like
Thank you , mmm I understand I need to optimize and compress my assets and resources before uploading them to the project to use them.
but is there any way to shrink and compress it after the build or in the building process that’s easy not super complicated.
Why and what app size are we talking about?
My apps have a size between 45 and 96 MB (Android) and 120-170 MB (iOS) and so far no one has complained in the past 6 years.
I prefer to have all (media) files in the app package (assets) so that the user cannot easily access them outside the app (without a rooted device).
Btw, there is no way to compress media files without losing quality.
There’s huge difference between app inventor app size and other like thunkable and kodular , and I saw same apps with same functionality for example basic apps with less size than mine that’s why i’m asking , " google play index smaller apps first " that’s the reason of my question.
App Inventor’s primary goal is educational in nature–most of our users will never publish an app through Google Play. Therefore, optimizing apps for that scenario isn’t a high priority for us. If you’re concerned, I’d be interested in knowing how your app size compares to those of your potential competitors given that you are concerned with the ranking by size.
@Diego or @Conor might be willing to share more about how Kodular accomplishes smaller app sizes.
2 Likes
I just exported a new, blank project in both AI2 and Kodular, the former was ~3.3MB whilst the latter was ~4.7MB. This isn’t surprising since Kodular has many more components and libraries, but we integrated ProGuard which I suppose reduces the final size of the APK slightly. Our companion, which includes all libraries (the biggest being Google Play Services & Firebase) is ~24.8MB which, in my opinion, is still quite small.
For reference the MIT companion is 16 MB.
1 Like
Humm, I would like to see how ProGuard behaves in native AI sources, as we aren’t comparing under equal conditions.
I’ll give it a try by this week. Build appinventor sources and add the ProGuard changes made into Kodular, and see how big Companion and Blank App are.
In comparing with kodular or thunkable still app inventor gives u the smallest size but for example if we build a normal basic app on each and via android studio or another tool the size isn’t comparable I can guide you through a lot of basic apps published on google play and see for your self the size differences even they have same basic functionalities and results.
Just ran this test. These were the results:
- MIT App Inventor Companion (w/out ProGuard): 15.7 KB
- MIT App Inventor Companion (w/ ProGuard): 15.2 KB
There’s no much difference. However, I tested with the configuration we use at Kodular. Probably there is a more optime configuration that can reduce the size even more.
Ciao ewpatton,
mi sento di contraddirti dato che dal 2017 le mie app le ho pubblicate tutte su Google Play; altrimenti che senso avrebbe tenerle solo per me e non farle conoscere anche al mondo intero?
Saluti
Nicola
Evan said
If you are able just like me to publish to Google Play that doesn't mean other users have this opportunity. A developer account costs 25 dollars which is, i think, to much for a lot of users. Or they never have the need for that because they just have to use AI for schoolprojects.
In effetti sono troppi se qualcuno non ne ha l’esigenza.
MIT App Inventor 2 is primarily educational since it started. Otherwise it will include monetization components and probably charge its users some fee.
If you want to make commercial apps, you will be better working with any of the other distros like Kodular, Thunkable, Block2Code, etc. Or go with more professional platforms like Android Studio or similars.
2 Likes
I'm not saying that you can't or shouldn't publish your apps made with App Inventor on Google Play. We do know that some people build apps for themselves or for dissemination to friends/family outside of Google Play. We also know that people build apps for Google Play. We don't know the distribution of these groups. But here are some numbers:
- We have 10.7 million UserData objects
- We have 5.6 million UserFileData objects
- Of the latter, a sampling of 2000 objects showed that about 70% are android.keystore files (needed for compiling apps)
So we can say that probably about 3.9 million people have compiled their apps with App Inventor or roughly 36.5% of the users. Of course, only some subset of those will publish them in Google Play. I doubt that there are 3.9 million apps in Google Play that are attributable to App Inventor. This article puts the total number of apps in the store at 2.9 million.
1 Like
Back to the Original Topic to reduce the final APK build size, it would be great to have a APK with an optimized size created by the compiler that puts into the app only the components / libraries / classes / etc that are really needed.
Maybe there is a way to implement such a thing into the AI compiler: it would be enough to compile only the components the app dev inserted into the app it self.
@Diego is already working on that, see here
Taifun
Trying to push the limits! Snippets, Tutorials and Extensions from Pura Vida Apps by 
Taifun.
2 Likes
As @Taifun pointed out, I have been working on adding Android App Bundles to App Inventor. This new format allows Play Store to deliver an APK with only the needed screen density configuration, native binaries and languages (when available). In other words: instead of delivering an universal APK (what happens now), they will deliver only the necessary files to run in the device. For MIT App Inventor Companion, the final APK was reduced by 40% when generating from an AAB, and after installing its size is 25% (quite huge actually).
However, as you can imagine, it works only for Play Store, as they know the device specs and they pick the correct APK for it. You can manually create a specific APK from the AAB without Play Store, but you will have to create all possible combinations to make sure all devices are supported.
Talking about libraries, they are already optimized. Only the needed libraries are added to the exported package. Components have the @UsesLibraries annotation that specifies which libraries do they require. If a library is not required by any component in the App Inventor project, it won't be added to the output.
You can easily see this with the MIT App Inventor Companion and a blank project. If you export a blank project, you'll see it's 2-3MB, but if you export Companion you will see it's around 15MB. This size is because ALL possible libraries are added (and other stuff too).
For example, if you export a blank project and open it, you won't find Twitter libraries or their packages. If you open the Companion, you will find them.
And talking about classes, the theory says it "can" be optimized, but it will not optimize the overall build procedure. Right now, to run the buildserver you execute ant RunLocalBuildServer, which will check for a file called AndroidRuntime.jar. If not found, it will start generating the runtime library implementing components. This JAR file contains ALL App Inventor components, or "classes", for all components. So yes, apps always contain the code for all components, even without using them.
But this is done for a reason: compiling the AndroidRuntime.jar takes time, so to optimize build time only one AndroidRuntime.jar is compiled before launching the buildserver. This AndroidRuntime.jar is then used in all build requests in all apps, as it is not needed to build it over and over.
To "optimize" it, an AndroidRuntime.jar would need to be compiled on each build request, and it will increase build time quite a lot. And also, removing those needed classes won't make a huge difference, just a matter of a very few kilobytes. So, as a summary, that small gain in size does not balance for a huge time increase in build times.
5 Likes
Hi @Diego, Thanks for your very useful clarifications.
Nevertheless if we want to to make AI a more efficient and optimized software that returns optimized apps, the optimization of the resulting compiled file IMHO is still something that has to be achieved.
For testing purposes I have just created a new empty project and I have downloaded it as aia file and also compiled it, and downloaded it as apk file. I did nothing else.
The aia file is just a little bit more than 900 bytes, 4.00 KB on disk, good enough, nothing to say about it
But I was expecting to have a very little apk file (it's just an empty Screen1 after all). But with my huge surprise it is 3.28 MB. It is more than 2 floppy disks for an empty screen: IMHO it is too much.
For comparison if I make an empty HTML file to simulate the same behavior with a web page the file is 0 bytes . If I make an hta file, an empty dialog are in the worst scenario few rows of code or so.
If I make a empty project in C# it is few KB: for example I have created a Windows 32 bit software for myself that does screenshots and has the possibility to upload the resulting images online by ftp protocol: after compiling it is just 260 kb: pretty good compared with an AI empty screen or so.
I understand the issue of building the basic file over and over again for server / cpu time. But there must be a solution to get rid of all that surplus of memory that is occupied without to be needed: it is an overkill IMHO.
Also maybe that all that unwanted code into the resulting apk file could even be exploited by some malware to do things into smartphones which are not even predictable. So there could be an intrinsic and not needed risk of having a such app into a own device that has unused code, files, libraries, class, jar... etc. that aren't strictly needed.
If those functions are strictly needed the risk is something that we must deal with, necessarly. But if those functions aren't strictly needed that risk is something that can be completely ignored?
Let's think about that issue too.
Thanks in advance.
PS.:
I have already answered here how about the issue can be IMHO faced and solved. But of course better solutions are more than welcome too.
1 Like