Stripping the Intel half saves 16 MB of a 421 MB app
Measured with lipo on a real Mac. Half the executable is Intel code, and the executable is a small fraction of what the app occupies.
A universal binary contains two complete builds, one for Apple Silicon and one for Intel, and on an Apple Silicon Mac you will never run the second. Removing it with lipo is a well known trick, and the saving is far smaller than the description suggests.
Look inside one yourself
# Which architectures are in there
lipo -archs /Applications/Numbers.app/Contents/MacOS/Numbers
# What each slice weighs
for a in $(lipo -archs /Applications/Numbers.app/Contents/MacOS/Numbers); do
lipo -thin $a /Applications/Numbers.app/Contents/MacOS/Numbers -output /tmp/slice_$a
ls -lh /tmp/slice_$a | awk -v a=$a '{print a, $5}'
rm -f /tmp/slice_$a
done
# And what the whole bundle weighs, for comparison
du -sh /Applications/Numbers.appA second measurement on the same machine: the ProtonVPN executable was 76.5 MB, split 39.3 MB Intel and 37.2 MB Apple Silicon. The ratio is consistent, roughly half and half, and the conclusion is the same each time because the executable is not where an application's size lives.
Where the size actually is
| Part of a bundle | Typical share |
|---|---|
| Media, artwork and sounds | Often more than half |
| Embedded frameworks and libraries | Large, and frequently universal too |
| Language files | Up to 40 percent of some Apple apps |
| The main executable | Frequently under 10 percent |
The language folders in that table are measured in language files across your apps, and they are usually the larger of the two by a wide margin.
What it breaks
- The code signature. Rewriting the executable invalidates it, and a hardened app may refuse to launch or be blocked at startup.
- Updates. A patch update applied to a modified bundle can fail in ways that are hard to read.
- Rosetta compatibility for plugins. An app that loads an Intel plugin needs its Intel side, and audio and design apps do this more than most.
- Nothing goes to the Trash, because the file is rewritten in place rather than moved.
Frameworks inside the bundle are usually universal as well, so stripping only the main executable leaves most of the duplicate code in place, and stripping everything multiplies the risk without changing the order of magnitude of the saving.
For a real reduction in the Applications folder, remove an application you do not use. The Applications folder ranks them, and are Mac cleaner apps safe covers why this particular trick keeps being advertised.
Common questions
Should I strip Intel code from apps on Apple Silicon?
Rarely. Measured on a Mac in September 2026, removing the Intel slice from Numbers would save about 16 MB from a 421 MB app, and it invalidates the code signature.
How do I see the architectures in a Mac app?
Run lipo -archs against the executable inside Contents/MacOS. To weigh each side, extract them with lipo -thin and compare the files.
Why is an app so large if the executable is small?
Because media, artwork, embedded frameworks and language files dominate a bundle. The main executable is frequently under ten percent of the total.
Does removing the Intel slice break anything?
It invalidates the signature, can cause updates to fail, and removes Rosetta support for Intel plugins, which matters in audio and design applications.