Apps on the ultimate diet: beyond stripping Universals

In yesterday’s exercise in trying to reduce the size of a Universal App, I showed how you can strip the Mach-O executable in a Universal App so that it supports only one architecture. As I pointed out, I deliberately ignored those dylibs stored in the app’s Contents/Frameworks folder, which is what I consider today.

Application bundles have the following structure within the Contents folder:

_CodeSignature, a folder containing the file CodeResources for signature checks;
CodeResources, a file recording the notarization ticket;
Frameworks, an optional folder containing framework folders and dylibs;
Info.plist, the app’s main Property List;
MacOS, a folder containing the app’s main executable code in a Mach-O binary;
PkgInfo, eight bytes containing the classic type and identifier bytes;
Resources, a folder containing predominantly non-executable resources for the UI, such as interface nibs, icons, and localisations.

The thinning performed using lipo, detailed in the previous article, only tackles the main executable code. What about the frameworks, which can also be Universal?

Many apps contain significant frameworks, and they’re essential in those which have been written in Swift, to provide the ‘glue’ between system calls made using the Swift language and the system itself. You’ll typically see 18 dylibs with names prefaced by libswift in each app which has been built from Swift source code, adding 11.4 MB to the size of every Swift app.

When you build a Universal App which requires a minimum of macOS 11, if it’s written in Swift and uses no custom frameworks, there’s no Frameworks folder generated, and the total size of that is around 11.4 MB smaller than the same app built to support earlier versions of macOS. This is apparently because macOS 11 now incorporates that ‘glue’ in system files, so sharing those frameworks.

If you use third-party command tools written in Swift, you may recall something similar happening back in macOS 10.14.4. Prior to that, command tools built in Swift needed supporting libraries, which made them large. In 10.14.4, those were incorporated into the system by including them in /usr/lib/swift, saving space in each command tool installed.

Look at those Swift frameworks using a utility like ArchiChect, and you’ll see that they’re Intel-only, and aren’t used by Apple Silicon Macs unless the app is run in its Intel version under Rosetta 2. So, if we were to create an ARM64-only version of a Universal App, couldn’t we dispense with those redundant frameworks? Unfortunately not: removing them causes a serious signature error, and macOS won’t allow our superslim ARM64-only app to even launch. This means that the maximum saving available in using lipo to thin a Universal App is half the size of its Mach-O Universal Binaries, nothing more.

I’m now ready to give guidelines on expected app sizes in different situations.

If you have a Universal App which you want to slim by making it work on only one architecture using lipo, you should expect to see a saving of half the size of its Mach-O Universal Binaries, which normally means the executable file in Contents/MacOS. Other contents of the app bundle, including its frameworks, are unlikely to be amenable to lipo‘s thinning, and consequently will remain the same size.

So in the case of Mints, its total size as a Universal App is 17.2 MB, with an executable of 442 KB. A stripped Intel-only version has its executable reduced to 214 KB, and a stripped ARM-only version has an executable of 229 KB. Savings achieved by stripping are little more than 200 KB, or just over 1%.

If you’re a developer, and your Universal App will support versions of macOS prior to Big Sur, then that Universal App is likely to be the same size as its current Intel version, with the addition of the total size of all Mach-O files which will be converted to Universal Binaries (as they effectively double in size). The latter excludes any Swift frameworks, which won’t be added to support the ARM64 architecture. In the case of Mints, that adds around 200 KB, or just over 1%.

If you’re only going to support Big Sur and later versions of macOS, your app won’t require the 11.4 MB of Swift frameworks. In the case of Mints, that far outweighs the 200 KB cost of making it Universal, as dropping the Swift frameworks saves 65% of the app’s original size. For Swift apps whose Intel executables total less than 11 MB, a macOS 11-only Universal App should always be smaller than the original.

Big Sur giveth, and Big Sur taketh away.

7Comments

Add yours

1

David C. on July 31, 2020 at 1:47 pm

Apps include copies of the frameworks they use?

Doesn’t that defeat the purpose of frameworks? I thought they were shared libraries installed and upgraded as a part of the OS, and only *used* by applications. This way we don’t have tons of redundant code and OS updates can fix bugs in all apps that use the updated frameworks.

Sounds like a really bad architecture if each app includes a copy of every framework it uses.

LikeLiked by 1 person
- 2
  
  hoakley on July 31, 2020 at 7:15 pm
  
  Thank you.
  This is quite complex. Custom frameworks are most likely to reside in the app, and I don’t see any issues there. It’s better for the user as it prevents Library folders getting cluttered up.
  The dylibs here are only those for the Swift interfaces, which have remained unstable during the rapid development of the language. Now the ABI is stable, it’s time for those dylibs to stabilise too. I’m not sure this is just happening in 11.0 – it might be the case in 10.15 too, but here it’s most obvious with the ARM64 binary behaviour as I have noted above.
  Howard.
  
  LikeLiked by 1 person
3

Marco on November 13, 2020 at 8:57 am

Thank you, Howard, for your explanations. When there was the transition to Intel, I was a user of XSlimmer, that stripped PPC or Intel code, and also localizations (lproj folders). In a couple posts you convinced me that it is a loss of time to strip universal apps of the code for Intel or for Apple Silicon. However, I still feel that it is still interesting to strip apps of unused localizations. The most convincing example is Google Chrome, that wastes a lot of space, or Apple Pages, Numbers, Keynote, or iMovie. I sometimes do this manually, but it is too time costly. Would it be possible to do this efficiently?

LikeLiked by 1 person
- 4
  
  hoakley on November 13, 2020 at 2:27 pm
  
  Thank you.
  I don’t know any way of stripping localisations, and in this time of stringent signature checks and notarization, even though localised resources shouldn’t be included in the signed parts of code, I wouldn’t recommend tampering with them.
  Howard.
  
  LikeLike
5

Marco on November 16, 2020 at 9:34 am

Oh, you are right, they may fail on the first launch.

LikeLiked by 1 person
6

Steve_I on March 2, 2021 at 7:21 pm

You may be aware of IngmarStein’s Monolingual, an excellent tool for stripping un-needed/wanted localization from applications and MacOS itself. (ingmarstein.github.io/Monolingual) The earliest release of Monolingual was ca. 2003, for Mac OS X 10.2. Take from that a bit of perspective — disk space is not so precious as it once was.

LikeLiked by 1 person
- 7
  
  hoakley on March 2, 2021 at 11:49 pm
  
  Thank you. Yes, I remember it well, and all the troubles it could cause. I’m rather hoping that no bright spark tries that again.
  Howard.
  
  LikeLike

Share this:

Like this:

Related