Why is the framework size so big (2.8 MB)?

[nickasd]

After adding Sparkle and exporting it in Xcode, my app's size has grown by 2.8 MB. MyApp.app/Contents/Frameworks/Sparkle.framework/Versions/B contains Sparkle (856 KB), Autoupdate (693 KB), Resources (542 KB), XPCServices (382 KB), Updater (291 KB) and _CodeSignature (44 KB). It's hard to believe that a "simple" update framework would need such a large amount of code. My main app's executable is 5.5 MB, so 1/3 of the app consists of Sparkle now. Can someone explain why so much code is needed?

[zorgiepoo]

It actually used to be 2x bigger than this prior to 2.4 which did a bunch of size optimizations (e.g. #2305) and this is where it ended up. As you figured, it's code size and resources. Sparkle handles tasks that other updaters may not handle: a built in UI, many localizations, sandboxing (XPC services), launchd helpers needed for proper handling of authenticated updates and sandboxing (Autoupdate, Updater), and some more bits (eg. small delta updates, scheduling). Code sharing between these binaries via shared dylib is not feasible when I tried because it may increase friction of integrating Sparkle with respect to library validation stuff. Obviously all the binaries are universal binaries.

From your app's build if you want to shave some size you can remove unused localizations and unused XPC Services in a post phase script. That may shave off up to ~800 KB depending on what you need.

If you're able to build Sparkle from source yourself you can disable various knobs in ConfigCommon.xcconfig. Disabling everything can get to a roughly 1.5 MB build, which is what I do for one of my non-sandboxed apps that uses a custom UI. (edit: found a small issue #2707)

Any improvements on reducing the framework size are welcome to be reviewed on this front.

[nickasd]

Thanks for your insights. I had a look at the source code, and I have to admit that I'm not used to reading Objective-C code anymore, so I don't know if I'm a good candidate for finding optimizations (which seem to be the main reason for the big size decrease in 2.4). Could it even be that Objective-C needs more knowledge about possible optimizations than Swift does (and that a Swift codebase would automatically make the executable smaller)?

I was still able to find an optimization regarding the string resources. When changing the project's "Strings File Output Encoding" build setting from the default UTF-16 to binary, the Resources folder shrinks from 542 KB to 349 KB. Is that something that could be useful?

[zorgiepoo]

The language based optimizations are mostly micro-based optimizations. The biggest reduction was from stripping debug symbols. Some style of Obj-C coding does generate some baggage that Swift does not (e.g. encourages direct method/ivars/structs). If I wanted to micro-optimize further in that direction I'd go to C, not really Swift.

I was still able to find an optimization regarding the string resources. When changing the project's "Strings File Output Encoding" build setting from the default UTF-16 to binary, the Resources folder shrinks from 542 KB to 349 KB. Is that something that could be useful?

This seems like it could be worth doing.

[nickasd]

Thanks, I opened #2712.