Built App sizes

Thank you Sam for taking your valuable time to think about this.
Still, it’s very quiet from Xojo Inc side. This thread is very intersting and should be taken seriously for sure.

App size is important! Not a gimmick.


even though you can use the dy libs on multiple xojo apps by changing the “MyApp Libs” folder to “Libs” it’s not what it’s used for, and that could be a simple setting.

I mean the libs currently only bloat the software, nothing more. They are not actually used to improve sharability. Ofcourse i understand the use of plugins and dylibs, i just mean by this there is room for improvement. And maybe the “Xojo Libraries” feature would finally solve such case ? who knows, what even that roadmap feature will be, no target or direction is ever shown or talked about.

Maybe now i the chance to get some well earned great improvments, in speed, less cluttering, smaller apps etc.

1 Like

“Just not added” is the point I’ve been trying to make. These “dynamic libraries” are not real libraries, they are just monolithic lumps of code.


I’d love if Xojo would allow me to mark classes to be strippable from their stub code. For some plugins the stub code is bigger than the actual plugin code in C++ (including the class declarations). See #21099

If someone has a Xojo app, which suffers under lots of plugins from MBS added, we could look into reducing the number of plugins added by Xojo. We got a blog post about it: Using dash if to reduce app size by referencing less plugins

If you see a Mac app including Windows plugin parts, you can do a lot with #if or variant properties to avoid the Xojo compiler including them.

1 Like

Yep, a real one looks like this:

Monolithic containers of books; but much harder to move around.


Yes they are 99% of the time not used as shared dynamic libraries. More like external code buckets per project.

It’s all a little relative. If the app is a full GUI app doing enterprise database lookup or whatever, the abstraction provided by the framework and the development time it saves is worth 48MB or a 100MB even.

On the other hand Xojo attempts to be all things to all people. For a small helper app that may be called iterratively and blocks the processor while it loads into RAM, 48MB is hardly acceptable. On an low powered SoC like the Raspberry Pi Zero it’s close to being unviable.

Interestingly I have just finished a Raspberry Pi project that runs as a systemd service. I rejected Xojo very early on due to the huge executable. Other frameworks are available that offer selective linking.

I looked into some compiler & linker switches for gcc and I was able to reduce the linux plugins a bit in size. Total we get 30 MB smaller for all our plugins.

Also if anyone has a cross platform app using MBS Plugins, we could look together to reduce the app size and later publish results as a case study.


Here is report for 2024r1:

First off then I expected something terrible…

But then I started filling in the numbers and first two targets had actually reduced (does not matter how little as long as its reducing or not increasing then its going right way even if slow)

Windows and Linux did not get the same reduction except Windows Arm Console did for some reason.

So over all better than expected actual reduction on 3 targets and increase on the others less than I expected.


Great work here Björn and many thanks for capturing and sharing.

it would be interesting to know if the Unicode libraries could be compiled smaller.
Like Xojo only imports some functions and not all. So if some functions could be commented out for the unicode libraries, maybe some tables are no longer needed and a few MB could be saved.

1 Like

I made two issues:
Switch to built-in ICU libraries when you switch to Require Windows 10

Reduce size of unicode libraries by skipping parts


I would say use built in ones also on Linux, that would help battle down the size for the tiny boards that really need smaller apps.

1 Like

I have now fully converted one of my bigger projects to API2
Tedious to do and took me about 4 days.

To my big surprise, the app size is now up from 98MB to 153MB. WTF??

Not good at all… and very disappointed.
I am very probably going back to the API1 version. Smaller app size is important to me.


It would be interesting to have both versions of the built apps to inspect.
Maybe Xojo now includes some extra stuff?

Or create Universal Binaries automatically (by default) when API2 is used ?

Do you use the HTML-Control?

I compared the UB versions. Both (original API1 and API2 mixed version and API2 only) compiled with 2024R1

I did a lot effort to convert it to API2 thinking it would be smaller (no API1 libs anymore). But it’s almost doubled the size. Just not good and in short … I wasted 4 days doing the conversion.

1 Like

No HTML control was used in that project.

1 Like

With the DesktopHTMLViewer on Windows, the bloat would be much higher than shown here.