Skip to content

Removing language files and Intel code from Mac apps

Should you remove language files on a Mac, or strip Intel code from apps? What they are, why it breaks signatures, and what it really saves.

Apps and uninstalling · Published · 20 min read
Top view old fashioned wooden cabinet drawers filled with vintage letterpress in light printing house
Photo: Erik Mclean on Pexels

You can remove language files on a Mac by deleting the translation folders inside apps, and some tools still offer to do it, along with stripping out the Intel code that Apple silicon Macs don't run.

On a Mac today it's rarely worth doing. It changes signed apps, which can stop them opening or updating, and it saves less than people expect.

On one Mac we measured, every app's translations other than English came to about 1.2 GB, and the Intel code inside universal apps to about 5.5 GB. The same Mac's own app caches took 3.6 GB, and its developer data more than 100 GB.

The apps with the most translations were Apple's own Pages, Numbers and GarageBand, which you shouldn't change at all. Apps that are part of macOS can't be changed, because they live on a sealed system volume. And the next update of any app installs a complete new copy, translations and Intel code included.

If an app shows the wrong language, choose its language in System Settings › General › Language & Region instead. If you need space, remove whole apps you don't use, and look at caches, downloaded models and media before you trim anything inside an app.

What language files and Intel code are

A Mac app is a folder that Finder shows as one item, called a bundle. Inside are the app's code, its images and sounds, and its text in every language it supports. Two kinds of content in there are what slimming tools go after.

What is an .lproj folder?

Apple's bundle documentation says localized resources go in language-specific folders inside the app, each named after a language and ending in .lproj, such as en.lproj, de.lproj or ja.lproj. Each holds that language's strings, and sometimes images, sounds or interface files that differ by language.

macOS shows the app in the first language in your list that the app supports. The folders for other languages sit unused, which is why they look like easy savings.

Why do apps ship every language?

Because one download serves everyone. Apple's localization documentation describes adapting an app for people who speak many languages and download it from different App Store territories. A Mac app does that by carrying every translation it has, so it can switch when you change your settings.

That's also why translations aren't waste in the way a stale cache is. Change your Mac's language, or hand the Mac to someone else, and the app is ready without a new download.

What is a universal binary?

A universal app contains executable code for both Apple silicon and Intel-based Macs. Apple's developer documentation says it runs natively on both, because it holds code for both architectures. On an Apple silicon Mac, the Intel part is never used, unless you ask macOS to open the app with Rosetta.

Apple asks developers to make everything universal: apps, extensions, plug-ins, frameworks, libraries, command-line tools and background services. So the Intel code isn't in one place; it's spread through every piece of compiled code in the bundle.

What about an Intel-based Mac?

The same app carries Apple silicon code it never runs there. Stripping it has the same risks, and one more: when you move to an Apple silicon Mac, Migration Assistant copies the trimmed app, which can then run only through Rosetta on the new Mac until you download it again.

Is it different for apps you build yourself?

Yes, because there you're the developer. Apple's documentation says Xcode builds a universal binary for release by default, using its standard architectures. Building only for the architecture you need is a build setting, and the result is signed properly, which no after-the-fact trim can match.

How can you tell what an app contains?

Select the app in Finder and choose File › Get Info. Apple's support article says the Kind line reads Application (Universal), Application (Apple silicon) or Application (Intel). Only universal apps have Intel code to strip, and Intel-only apps need all of theirs.

To see an app's languages, Control-click it, choose Show Package Contents, then open Contents and Resources. Look, but don't change anything there.

Part of the appWhere it isWhat it's for
Translations.lproj folders in Contents/ResourcesThe app's text in each language
Base resourcesBase.lprojInterface files shared by every language
Apple silicon codeInside each executableRuns natively on M-series Macs
Intel codeInside each executable, beside the Apple silicon codeRuns on Intel Macs, or under Rosetta
The code signature_CodeSignature in Contents, and in each executableProves none of the above has changed

The tools that strip apps, then and now

Slimming apps is old advice from a time when disks were small and apps carried code for two processor families, PowerPC and Intel. The tools that did it are worth knowing, partly because some are still around.

Why did slimming apps make sense once?

Disks were smaller, and apps carried code for two processor families: PowerPC and Intel. Removing a processor's code could shrink an app considerably, and macOS's own languages were still on a volume you could write to.

Two of those have changed for good: macOS's files are sealed, and apps are signed, so a change that once went unnoticed now matters. The savings have shrunk too, now that no app needs PowerPC code.

Monolingual

Monolingual is a free, open-source app under the GNU General Public License that removes language files, and can also remove architectures. Its project site lists versions going back to Mac OS X 10.4, and it has been rewritten for today's Macs: version 2.0, released in October 2026, requires macOS 27 on Apple silicon.

By default it removes the languages that aren't in your Language & Region list. It needs an administrator, and a helper you allow in Login Items & Extensions.

Its README warns that once files are removed, the only way to get them back is to reinstall. Version 2.0 no longer lets you select English, because removing it breaks a macOS installation beyond repair.

Xslimmer and older cleaners

Xslimmer, from LateNiteSoft, removed the PowerPC or Intel code from universal apps, and later language files too. Its last release came out in 2013, and it's no longer developed. Several all-in-one cleaners of that era offered the same, and some still do.

CleanMyMac

MacPaw's CleanMyMac lists Language Files and Universal Binaries among the groups it removes as system junk, and its help calls language files safe to remove. It also notes that after an app updates, the removed code can return, and keeps returning until the developer drops one of the two processor types.

Pearcleaner

Pearcleaner, a free source-available uninstaller, can prune an app's translations while keeping your preferred languages, and strip unneeded architectures. Its source moves pruned translations to the Trash. Before thinning, it warns that the operation modifies an app's code, that some apps may have problems or fail to launch, and that you should back up first.

ToolLanguagesIntel codeCurrent?
MonolingualYesYesVersion 2.0.2, October 2026, macOS 27 only
XslimmerYesYesDiscontinued; last release 2013
CleanMyMacYesYesYes, with a note that updates bring code back
PearcleanerYesYesOn hold since late 2025

The comparison of the best app uninstallers covers Pearcleaner and CleanMyMac as uninstallers, which is the job they're more useful for.

A stack of old encyclopedias and dictionaries on a neutral background.
Every app carries its own small library of translations, most of which you'll never open. Photo: Arturo A on Pexels

Why changing an app breaks its code signature

Every app from a known developer is signed. The signature is how macOS knows the app is the one its developer shipped, and it's the main reason slimming apps has become a poor trade.

What does a code signature cover?

Apple's code signing guide says the signature starts with a seal: a set of hashes of the bundle's parts, including its executables, its resources and its Info.plist. The signatures for resources are kept in a file inside the bundle, and the code for each architecture is signed separately.

Apple describes the purpose plainly: the system can detect even the smallest change since the app was signed, whether a malicious attacker made it or a file was corrupted. Deleting a language folder is exactly such a change, as far as the seal can tell.

What happens when macOS notices?

Apple's support article on opening apps safely says that if macOS detects software has been modified or damaged, it tells you the app can't be opened, because it might be broken, corrupted or tampered with. Gatekeeper's job is to make sure only trusted software runs, and an altered app is no longer the trusted one.

Whether a trimmed app trips this depends on what was removed, how, and when macOS checks. That uncertainty is the problem: you find out when the app refuses to open.

Does removing Intel code break the signature too?

Not necessarily by itself, since Apple's guide says the code for each architecture is signed separately. But it rewrites every executable in the bundle, which is riskier than deleting a folder of text. Pearcleaner's own warning says some apps may have issues or fail to launch after thinning, and recommends a backup first.

Even when the app opens, you've changed something its developer never tested. Plug-ins, helpers and frameworks inside the bundle may check each other, and an app that runs today can fail on a feature you use next month.

Why do some apps refuse to update or ask to be reinstalled?

Because they check themselves. Monolingual's FAQ describes Adobe apps with a self-heal feature that refuses to launch when certain files are missing, translations included, and an old Office updater that found no valid copy of Office to update after its files were changed.

Monolingual's answer is to exclude those apps, and it keeps a blocklist of apps it won't process. That's how the tool's own author handles the risk: by not touching the apps most likely to break.

What you changeWhat can go wrongHow you'd notice
Delete an app's translationsThe seal no longer matchesThe app can't be opened
Strip an app's Intel codeCode rewritten in a way its developer never testedThe app or a helper fails to launch
Trim a suite such as Adobe'sIts self-check finds files missingIt asks to be reinstalled
Trim an app its updater checksThe updater can't match the installed copyUpdates fail or redownload in full
Trim macOS's own filesNot possible on a sealed system volumeNothing happens, or the tool refuses
Three white envelopes sealed with red wax are creatively displayed on a wooden table, suggesting a vintage theme.
A code signature works like a wax seal: it can't tell a harmless change from a harmful one. Photo: Raymond Petrik on Pexels

Apps you can't, or shouldn't, change

Some apps are out of reach entirely. Others can technically be changed, but they're the worst candidates.

Can you remove macOS's own language files?

No. Since macOS Catalina, macOS has run from a read-only system volume, and Apple's security guide says the system volume has been cryptographically sealed since macOS Big Sur. The kernel refuses system content without a valid signature from Apple, and a seal that fails at startup stops the Mac and asks you to reinstall macOS.

So Mail, Safari, Music and the other apps that come with macOS keep every language. That's where most of the old savings were, years ago, and it's closed for good.

What about Apple's App Store apps?

Pages, Numbers, Keynote, GarageBand and iMovie aren't part of macOS; they come from the App Store, and on the Mac we measured they carried the most translations of any apps. They're also signed by Apple and updated through the App Store, so they're poor candidates for the same reasons as any other app.

GarageBand's real weight is outside the app anyway. The post on the GarageBand and Logic sound library explains how to remove instruments and loops you don't use, which can free far more than its translations.

What about other App Store apps?

They're signed too, and updated through the App Store. MacPaw notes that the App Store edition of CleanMyMac can't remove the main files of App Store apps at all, because of the restrictions on it.

For iPhone and iPad apps on a Mac with Apple silicon, the App Store already does the trimming. Apple's developer documentation says the App Store selects the resources that best fit a Mac and removes the others, to make a streamlined installation.

Do apps need permission to change other apps?

Yes. In System Settings › Privacy & Security, Apple's App Management setting allows apps to update or delete other apps on your Mac. A slimming tool needs it, and if you'd rather it couldn't touch your apps, that's where to say no.

Updates put everything back

Even when trimming works, it doesn't last. The next update undoes it, and sometimes costs you a bigger download.

Why does an update restore the files?

Because an update installs the version the developer built, with its translations and Intel code. MacPaw's own help says the code CleanMyMac removes can return after an app updates, and keeps returning while the developer ships both kinds.

Can trimming make updates bigger?

It can. Many apps update with Sparkle, which can download a small patch, called a delta update, that changes only what's different from the version you have. Sparkle's documentation says that whenever a delta update fails to install, Sparkle falls back to downloading the full update.

Sparkle also verifies a checksum to make sure the patched app came out right. A patch built for the app as its developer shipped it is unlikely to produce that result on a trimmed copy, so the full download is what you get.

So how long does the saving last?

Until each app's next update, which for browsers and chat apps can be weeks. To keep the space, you'd have to trim again after every update, taking the same risk each time for the same gigabyte.

How much removing language files on a Mac really saves

Here's one Mac with Apple silicon, measured in October 2026: 32 apps in its Applications folder, plus the apps inside a few folders there, using 29.2 GB in all. We measured only, and changed nothing.

Trimming apps against other space on one Mac
  • Translations other than English, all apps1.2 GB
  • Intel code in universal apps5.5 GB
  • App caches in your Library3.6 GB · Safe
  • Docker Desktop's disk image30.5 GB · Usually safe
  • Developer data in your Library133 GB

Measured read-only on one developer's Mac with Apple silicon in October 2026, with Finder-style decimal gigabytes. The Intel figure is the size of the Intel code in 1,757 universal files under Applications. Your Mac's numbers will differ.

Where were the translations?

The three apps with the most were Apple's Pages, Numbers and GarageBand, with about 0.2, 0.18 and 0.14 GB of languages other than English. Next came web browsers, at about 0.1 GB each. The English and shared Base folders together took less than 0.1 GB.

So the largest savings were in apps you shouldn't change, and the apps you could change offered tens of megabytes each. Across all of them, translations were about 4 percent of the space apps took.

What about the Intel code?

It was a larger share: about 5.5 GB, roughly as much as the Apple silicon code beside it. The largest amounts were in a video editor, a web browser and Xcode: large apps full of helpers and frameworks, all of which update often.

How does that compare with the alternatives?

What you could removeSpace on this MacWhat it costs
Translations in appsAbout 1.2 GBSignature risk; returns with updates
Intel code in appsAbout 5.5 GBSignature risk; loses Rosetta and Intel Macs; returns
App cachesAbout 3.6 GBApps rebuild them; nothing lost
One unused large app, wholeIts full sizeDownload it again if you need it
Docker's disk imageAbout 30 GBImages and containers, unless you rebuild them
Developer dataMore than 100 GBVaries; much of it rebuilds

The post on clearing cache on a Mac goes through the caches, and the guide to developer disk space through the large developer folders.

Rosetta 2, Intel code and the translation cache

Stripping Intel code assumes you'll never need it. On an Apple silicon Mac, Rosetta is the reason you might.

What does Rosetta do?

Apple describes Rosetta as working in the background to translate apps made for Intel processors so they run on Apple silicon. You don't open it; macOS starts it when an Intel-only app or tool runs, and asks you to install it the first time if it isn't installed.

Why might you want an app's Intel code?

Some universal apps have Open using Rosetta in their Get Info window. Apple says it makes the app open as an Intel app, so it can load plug-ins and extensions that exist only for Intel. Apps with older plug-ins rely on it.

Strip an app's Intel code and that option goes, along with the ability to copy the app to an Intel-based Mac and run it there.

Does stripping one app's Intel code affect others?

It can. Monolingual's README warns not to strip the system frameworks while you still run Intel apps, because Rosetta needs the Intel code in the frameworks those apps use. Frameworks inside an app are shared by its plug-ins and helpers in the same way, so the effect isn't always confined to what you trimmed.

How do you find the apps that still need Rosetta?

Select an app and choose File › Get Info: Application (Intel) means it runs only through Rosetta, and Apple's advice is to update it. The Applications list in Storage settings shows each app's kind as well, which makes Intel-only apps easy to spot across the whole Mac.

Check with each developer for an Apple silicon or universal version. After macOS 27, Apple says, general-purpose Rosetta goes away, so those apps are the ones to sort out first.

Where is the translation cache, and can you delete it?

Rosetta keeps translated copies of Intel apps and tools so they open faster next time. The catalog's entry for Rosetta's translation cache places it in /private/var/db/oah, a folder macOS manages and System Integrity Protection keeps other apps out of. It's Managed by macOS.

It grows only when you use software made for Intel-based Macs, and updating those apps to Apple silicon versions keeps it from growing. If it were cleared, Intel apps would open more slowly the next time while Rosetta translated them again.

The post on system caches on a Mac puts it beside the other caches macOS keeps for itself.

What has Apple said about Rosetta's future?

Apple's support article says Rosetta works on Apple silicon Macs running macOS 27 or earlier, and that starting with macOS 28 it will be limited to certain older, unmaintained games that rely on Intel-based frameworks. Apple's developer documentation says the same: general-purpose Rosetta through macOS 27, then a subset aimed at those games.

That changes the case for Intel-only apps, which will need replacing. It doesn't make stripping universal apps worthwhile: developers decide when to drop Intel code, and an update from them removes it properly, signature and all.

Crafted 'Wow' word with cutout letters, scissors, and paper for artistic projects.
Trimming an app by hand saves a little and risks the whole app; its developer can do it properly. Photo: alleksana on Pexels

Choose an app's language instead

If the reason you want language files gone is an app showing the wrong language, there's a setting for that, and it changes nothing inside the app.

How do you set the language for one app?

  1. Choose Apple menu › System Settings, click General, then Language & Region. You may need to scroll down.
  2. Under Applications, click the add button.
  3. Choose the app and the language from the pop-up menus, then click Add.
  4. If the app is open, quit it and open it again to see the change.

To change it later, select the app and choose another language. To undo it, select the app and click the remove button, and the app uses the default language again, Apple's guide says.

How does macOS choose an app's language?

From Preferred Languages in the same settings. Apple says those are the languages you want shown in macOS and in apps, and that if the primary language isn't supported, the next one in the list is used. Languages below the line in that list aren't fully supported by macOS, but may be supported by other apps.

Why does an app ignore the language you chose?

Because it can only show the translations it ships. Apple's guide says that if the primary language isn't supported, the next language in your list is used. If an app has no translation for your language, no setting adds one, which is one more reason to leave its translations alone.

Does a language you don't use cost anything?

Only its space inside each app, which is the 1.2 GB above, spread across every app. Unused translations just sit on the disk: removing them frees space, and doesn't make an app or the Mac faster.

Better ways to get the space

Trimming apps is the smallest, riskiest saving on most Macs. These come first.

Remove whole apps you don't use

System Settings › General › Storage lists your apps with their sizes and when you last opened them, as the post on Mac storage categories describes. Removing one large unused app frees all of it, not 4 percent, and you can download it again if you need it.

Use the developer's uninstaller when there is one. The guide to uninstalling Microsoft Office, for example, shows how much of a suite lives outside its apps. If an app refuses to go, the post on apps that won't delete has every reason and fix.

Which apps are worth removing first?

Sort the Storage list by size, then look at when you last opened each app. Full macOS installers in Applications, apps you tried once, and old versions kept beside new ones are the usual finds. Each is gigabytes, not megabytes, and none needs anything inside it changed.

Clear caches, not code

App caches are rebuilt by the apps that made them and lose nothing, which is why the catalog rates your app caches as Safe. On the Mac above, they took three times the space of every app's translations.

Look at models, media and developer data

Local AI models, virtual machines, container images, iPhone backups and video libraries are usually measured in tens of gigabytes. Each is managed by its own app or command, which is where to remove it.

Compress or move what you keep

Files you need but rarely open can be compressed or moved to an external drive. The post on compressing files on a Mac explains what compression saves and what it doesn't.

A worked example

Say a 256 GB Mac is nearly full, and a slimming tool offers to remove 1.2 GB of translations and 5.5 GB of Intel code, as it would on the Mac measured above. That's 6.7 GB, at the price of changing dozens of signed apps, and most of it returns within weeks as those apps update.

On the same Mac, emptying app caches would free 3.6 GB with nothing lost, and removing one unused large app frees all of it. If Docker or developer data is there too, either dwarfs everything a slimming tool can reach.

What if you already trimmed an app?

If it opens and updates, you can leave it: its next update brings back a complete copy. If it won't open, delete it and install it again from the App Store or its developer's website. The post on "junk files" on a Mac explains why tools still offer this and how to read their groups.

Mistakes to avoid

  • Removing English or Base folders. Monolingual's FAQ names removed English files as the likely cause when it left macOS unusable.
  • Trimming suites that check themselves. Monolingual's FAQ describes Adobe's self-check and an Office updater that both failed after trimming.
  • Stripping Intel code from apps with older plug-ins. Open using Rosetta stops working.
  • Running a tool that deletes permanently without a backup. Monolingual's README says reinstalling is the only way back.
  • Trimming again after every update. The risk repeats; the saving doesn't grow.

How the app does it

Wombit shows what's using your storage and explains every item in plain language. It scans the whole disk or any folder, reading only names, sizes and dates, and file names and paths never leave your Mac.

Its Applications section lists every app with its size, the size of what it has left around the Mac and when you last opened it, so you can see which whole apps are worth removing. Uninstalling an app moves it and its leftovers to the Trash, where Undo and Put Back work.

Rosetta's translation cache is Managed by macOS: the app explains what it is and how macOS manages it, and never moves it. Your app caches are Safe and start checked in Cleanup.

  • /private/var/db/oah

    Rosetta translation cache

    Translated copies of apps and tools made for Intel-based Macs, which Rosetta keeps so they open faster next time.

    Managed by macOS · Explained only: never removed

  • ~/Library/Caches/*

    App caches

    Data that apps and macOS services keep so they can load things faster. Apps create it again when they need it.

    Safe · Moves it to the Trash

The analyzer and every explanation are free. Cleanup and the uninstaller are PRO, one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.

Frequently asked questions

Is it safe to remove language files from Mac apps?

It's rarely worth the risk. Deleting an app's .lproj folders changes a signed app, and macOS can then refuse to open it. Some apps check their own files and ask to be reinstalled, and the next update brings the translations back anyway.

How much space do language files take on a Mac?

Less than most people expect. On one Mac measured in October 2026, every app's translations other than English came to about 1.2 GB, about 4 percent of the space its apps used. Its app caches alone took 3.6 GB.

Can I remove macOS's own language files?

No. Since macOS Catalina, macOS runs from a read-only system volume, and since Big Sur it's cryptographically sealed. Apps that come with macOS, such as Mail and Safari, keep every language, and tools can't change them.

Should I remove Intel code from universal apps on Apple silicon?

Usually not. It changes every executable in the app, which can stop it launching, and updates put the code back. You also lose Open using Rosetta for older plug-ins, and the ability to copy the app to an Intel-based Mac.

Does Monolingual still work on current Macs?

Yes. Monolingual 2.0, released in October 2026, requires macOS 27 on a Mac with Apple silicon. It no longer lets you remove English, and its README warns that removed files come back only by reinstalling.

Can I delete the Rosetta translation cache?

No, and you don't need to. Rosetta keeps translated copies of Intel apps in a folder macOS manages and System Integrity Protection guards. It grows only when you use Intel software, so updating those apps to Apple silicon versions keeps it small.

Is Rosetta going away?

Mostly. Apple says Rosetta works on Apple silicon Macs running macOS 27 or earlier, and that from macOS 28 it will be limited to certain older, unmaintained games that rely on Intel-based frameworks. Intel-only apps will need Apple silicon versions.

How do I change the language of just one app on a Mac?

Open System Settings › General › Language & Region, click the add button under Applications, and choose the app and a language. Quit and reopen the app to see the change. Nothing inside the app is changed.

Sources

  1. Using Intel-based apps on a Mac with Apple silicon · Apple
  2. Change the language your Mac uses · Apple
  3. Safely open apps on your Mac · Apple
  4. Code Signing Guide: About Code Signing · Apple Developer
  5. Monolingual FAQ · Monolingual
  6. Discover system junk cleanup list · MacPaw