Going from Xojo 2021r2.1 to Xojo 2024r3.1, the size of one compiled app has increased by 50%.
With zero code changes, the main executable gets a big bump in file size and I notice a few more included libraries that I’m not using. Such as gZip.
Are there any new tricks (or old ones) that I don’t know about which can help reduce complied application size?
I’ve now built several apps and it appears to depend on the size of the project. For instance App Wrapper 4 goes from 90 MB (2021r2.1) to 108 MB (2024r3.1). Which is only ~ 20% larger.
I’d still like to know of a way to make the application sizes similar or even better, smaller than before.
Can these not simply be removed, @Sam_Rowlands ?
Yes, using “AppWrapper”. 
Beatrix W. pointed me to ImageOptim to reduce picture file sizes, which is very helpful if a large amount of pictures is included in the project.
Even the compiled application can be dragged onto ImageOptim to reduce its file size.
With 25 
, after 9 months, no action or answer, for ONE single part of this problem of extra fat in apps.
https://tracker.xojo.com/xojoinc/xojo/-/issues/75632
Also 9 years “pending”:
See also use built in ICU on Windows 10
Most of the weight gets added to the main executable file, as for the additional libraries, it depends if Xojo loads them when needed or loads them at launch time. A bit surprised to see 'em considering I’m not using 'em.
Hmmm. It does seem to me the this dynamic linking business only really works if you’re using the library version that the OS version on that machine came with. Otherwise you have to supply your own and it sits there taking up disk space, along with all the others.
Bring back static linking - that’s wot I say.
William closed it to favor this one:
I notice #1 on the Roadmap is
Xojo Libraries - Portions of protected Xojo code that are easily shared between projects and developers.
Roadmap — Xojo documentation
I wonder if this would be a natural time to also clean up the dependencies on older OS libraries ?
I don’t think there’s a need to drop support for more reliable/stable operating systems. The problem is that large unused libraries aren’t being stripped.
I’ll highlight a chunk from the original post:
Also of note, the bug that Rick linked:
#75362 - Chart classes are never stripped
Keep in mind that there may be internal framework requirements. For instance, the web framework uses the gzip plugin to compress and decompress http streams.
Compiling with non-default optimization switched on can make the main file somewhat larger.
I’ve not changed that or anything else, I simply built my apps with the new version of Xojo and noticed a file size increase.
I suspect what is happening is that Xojo isn’t stripping at a method, property or constant level, only object level.
As the app class references folderitem, folderitem gets included and anything the folderitem references is also included, including the zip extends. Doesn’t matter if you use folderitem, zip functions or access the app class or not.
There’s enough feature requests for Xojo to do a better job at code stripping, but getting their attention on the matter is a different challenge.
I was hoping to find a trick or two I could to make the application size smaller myself, but I don’t think I can.
lol… Yes you can, but have you tried it? Does your application even launch?
Compressing images is useful, but with Xojo made apps, most of the weight is either the compiled application or the Xojo framework (which has also grown in size).
I even wrote an app (that has since been deprecated) to compress ICNS files to save on disk space.
Think what he’s getting at. Is if the app doesn’t us any depends from the gZip frame work it shouldn’t be included in the compiled app. Which I agree.
I do understand. My point was that your code isn’t the only thing that creates those dependencies. For instance, just using a String in your project, means that libicu is required, but even if you don’t physically use a String in your code, the Xojo framework always does.
The big one for me is HTMLviewer under Windows. It’s a very useful control I’d like to use more often, but man, that extra 100MB is hard to stomach. There must be a better way.
Can you embed IE in a DesktopOLEContainer?
The answer to HTMLViewer bloat on Windows is here (using the WebView2 system, which is Windows’ new (ish) Edge browser replacement for the old IE11 engine)…
https://tracker.xojo.com/xojoinc/xojo/-/issues/59961
In lieu of that, I find that the MBS WebView2 plugin is a great substitute for now:
https://www.monkeybreadsoftware.net/topic-webview2.shtml
WebView2 is present on Windows 11, may or not be present on Windows 10, it’s almost always absent in prior versions.
For windows, when Xojo adds the option to compile apps to include WebView2, the Xojo startup routine should look for the presence of it, if not found request the user to download and install one from: https://developer.microsoft.com/microsoft-edge/webview2/ and quit until finding one.
Logically being able to build a version with an embedded Chrome Engine (CEF) is a must to avoid use cases when WebView2 is broken for unknown reasons on the user machine.