Which confirms what we wanted with the sole responseĪll you then need to do is remove the Universal Mints.app/Contents/MacOS/Mints and rename Mints2 to Mints. Lipo -archs Mints.app/Contents/MacOS/Mints2 Then check the supported architectures again: If you wanted to strip the Intel executable instead, use x86_64 instead of arm64 in that command.
Lipo -remove arm64 Mints.app/Contents/MacOS/Mints -output Mints.app/Contents/MacOS/Mints2
#Monolingual mac el capitan code
Let’s remove the arm64 code and save the stripped executable to a new file, with In this case, only two are supported, as shown in the response Lipo -archs Mints.app/Contents/MacOS/Mints Apps almost invariably also contain dylibs, in /Contents/Frameworks, which can also be Universal Binaries, but here I’ll ignore them.īefore stripping Universal Binaries, confirm which architectures that Mach-O file supports using a command like More complex apps will contain Mach-O binaries in other locations, such as helper apps. It consists of one Mach-O executable binary which is located in its standard folder Contents/MacOS/Mints within the app. As a test, I chose one of my own Universal Apps, Mints, which has a simple structure. I’m sure that someone is already building a utility to do this, but for the moment I’ll use the command tool lipo, which is designed for this and related tasks with Mach-O files. Is it feasible with today’s Universal Apps and modern security protection? Will tampering with Universal Binaries break code signatures and notarization, and cause mayhem? At the time I was critical of this stripping, but users did it all the same. As executable code is often only a small part of total application size, the storage space which they gained often simply wasn’t worth the effort. With Catalina and Big Sur, security has changed beyond all recognition: although they can still run unsigned code, that’s now the exception to the rule that all executable code has to be signed, and normally notarized too.ĭuring that last transition, many users stripped their Universal Binaries, either of PowerPC or Intel code, according to the architecture of their Macs at the time. So the whole of the last transition, with its Universal Binaries, was completed before code signing became prevalent or enforced.
#Monolingual mac el capitan mac os x
The following year, in Mac OS X 10.5, code signing was introduced, and it was first checked by Gatekeeper as late as 2012, in Mac OS X 10.8.
This article looks at what is involved in stripping a Universal App so that it only runs on one architecture, and whether this is feasible or breaks their signature.Īpple’s last processor transition started in 2006, when Intel Macs became available. No sooner do we get an improvement like Universal Apps, which run native seamlessly on both Intel and Apple Silicon Macs, than users want to remove executable code from them, and make them Intel- or ARM-only.
0 kommentar(er)
