Some might ask if it matters. I would say it matters, its the first thing many look at, what does it produce, does it produce 70 mb Electron like app or good application.
For example then stand alone C# macOS application with no external dependencies is 7-8 mb, the move to Desktop Controls sadly put Xojo nearly double that.
48 mb for Console Linux Arm Application for example is not reasonable code app size no matter what framework you use.
I know its hard to unwind the problem with creeping application sizes, since the architecture of Xojo is not built well for real compiling and dead stripping. But Xojo could for example set them selfs goals like “If new IDE compiles bigger apps than previous ones then find something to optimize before releasing” which would be reasonable way to at least stop the everlasting size increase even if it does not unwind it.
I filed bug report on the libCalendarControl.dylib few days ago. I think that one is doing something very wrong. The libCalendarControl is built in plugin and plugins in Xojo dont normally behave like that to get them selfs added to the app no matter what.
(My guess its probably in the Main entry doing REALGetClassRef on something defined inside of it self. (which of course would tell Xojo to then always include it)
I’ve always wondered why the entire gui lib is used while some apps just use a part of it actually. I’d like to see the app tiny and only provide what is coded to be added to it. So that it’s much more portable, get a better overview of the actual code running (security) and have less anti-virus blocks for no reason. And that’s what i’d expect, but is not the case currently.
Console apps you usually need to boot as fast as possible since console apps are in general used for automations and such tihngs. And Linux Arm then we are talking about Raspberry PI boards…
well why would there be additional code in the executable? is it malware? is it bloatware? What it’s purpose? why is it added in the first place? why isn’t it stripped after?
There are more questions to ask to it than “just leave it”. There is way more potential in having a tiny executable that’s fast.
Yikes, that alone is enought to not use any recent release
lol, the main concern is about END USERS not wanting a bloated app. And that is proven to be the one of the first things users look at.
Are you really saying that it takes the same time reading 48 MB than 8mb ???
Bigger apps are ACTUALLY slower to start. Less atractive to customers, No one wants to wait the extra minutes to download, allways wondering why a 100Mb app if it does the same than one of 10Mb.
And if gou have a serious bussiness you need to also look for Server costs to storage and deploy apps. Bottle necks during opdating process, etc, etc.
However at end of the day Xojo is a framework app, so I sort of would not expect it to compete with that.
In my opinion (thats just my opinion others may differ of course), then the Xojo 2021 app size on macOS for Desktop was very reasonable for framework App like Xojo.
Then it was on par with if you make C# app for example and much better than Electron App of course.
Thats as high expectation as I would have for it in a good world.
Spotify engineer Bruno Rocha (he’s really cool) gave a talk on how they found App Size affects their downloads, and what you can do (with other languages to reduce that).
85% of the connected world doesn’t have super fast internet, and/or pays a high price for internet access, and have limited hardware to run apps. Spotify found that the more they increased the size of their app, the less downloads they got. They have a whole team dedicated to keeping app size down.
From my pwn personal tests, when I converted a helper to Objective-C last year, it went from being about 14MB downto 200kb. It was so fast that it did it’s job, before the Xojo version had even loaded.
I’m preparing the marketing material for my first converted SwiftUI app, it’s currently 1/8th of the file size (I shall call him, Mini Me) of the Xojo made version (and includes more functionality), it opens in what feels like the blink of an eye, compared to the 1 or 2 seconds for the Xojo version, and as a bonus, it’s going to reduce the bandwidth on my site, which is going to save me money, especially as I convert more apps.
Have you checked Tauri? It uses the OSes native browser, so it doesn’t need Chromium.
Addendum: The Mac App Store displays the archive size of the application to the end customer. If you were comparing two apps that seemed like they did the thing you need, one is 1.5 MB, while t’other is 16 MB, which one are you most likely to download first?
Prove it, if you can. Modern computers are so flippin’ fast, with such huge file caches and speedy SSDs, that I honestly wonder if there’s a meaningful difference between reading 8MB and 48MB.
According to the Wikipedia, as of 2020, consumer SSDs had read speeds of about 6.7GB/second. So to read 48MB, you’re looking at .007 seconds. 8MB will take .0012 seconds - and those numbers are undoubtedly smaller in 2024. I may be going out on a limb here but I’m going to say that there are no human beings who can perceive that difference.
Yeah, I’m not going to make the argument that Objective-C/Swift/etc apps aren’t smaller and faster in some ways than their Xojo counterparts. I’ll confine my argument to differing app sizes within the same development framework.
As does the iOS store. However, you really have to scroll to see it - around 1-2 pages on the Mac, and a screen or two on my iPhone. It’s obviously not considered a selling point by the designers of the various App Stores.
Personally, the size of the app doesn’t matter to me; or, at least it’s not a deciding factor. More important are the price and features; the phone has essentially endless space and a wide pipe when on WiFi. When was the last time I downloaded an app when not connected to Wifi…?
Optimizing such small apps is optimizing the 20 side of 80/20. It does not matter at all if an app is 1 or 15 MB. Downloading the XCode with 10 GB is annoying. Anything less and I don’t care.
Ironically, the app size doesn’t seem to matter at all when starting an app on macOS. The time for the malware scan makes a bigger difference. See Mac app launches slowed by malware scan
I’ll confine my argument to differing app sizes within the same development framework.