Community hub
0 subscribers8 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Universal binary.
Nothing was collected or created yet.
Universal binary
View on Wikipediafrom Wikipedia
| Mac transition to Intel processors |
|---|
 |
The universal binary format is a format for executable files that run natively either on both PowerPC-based and x86-based Macs or on both Intel 64-based and ARM64-based Macs. The format originated on NeXTStep as "Multi-Architecture Binaries", and the concept is more generally known as a fat binary, as seen on Power Macintosh.
With the release of Mac OS X Snow Leopard, and before that, since the move to 64-bit architectures in general, some software publishers such as Mozilla[1] have used the term "universal" to refer to a fat binary that includes builds for both i386 (32-bit Intel) and x86_64 systems. The same mechanism that is used to select between the PowerPC or Intel builds of an application is also used to select between the 32-bit or 64-bit builds of either PowerPC or Intel architectures.
Apple, however, continued to require native compatibility with both PowerPC and Intel in order to grant third-party software publishers permission to use Apple's trademarks related to universal binaries.[2] Apple does not specify whether or not such third-party software publishers must (or should) bundle separate builds for all architectures.
Universal binaries were introduced into Mac OS at the 2005 Apple Worldwide Developers Conference as a means to ease the transition from the existing PowerPC architecture to systems based on Intel processors, which began shipping in 2006. Universal binaries typically include both PowerPC and x86 versions of a compiled application. The operating system detects a universal binary by its header, and executes the appropriate section for the architecture in use. This allows the application to run natively on any supported architecture, with no negative performance impact beyond an increase in the storage space taken up by the larger binary.
Starting with Mac OS X Snow Leopard, only Intel-based Macs are supported, so software that specifically depends upon capabilities present only in Mac OS X 10.6 or newer will only run on Intel-based Macs and therefore does not require Intel/PPC fat binaries. Additionally, starting with OS X Lion, only 64-bit Intel Macs are supported, so software that specifically depends on new features in OS X 10.7 or newer will only run on 64-bit processors and therefore does not require 32-bit/64-bit fat binaries.[3][4] Fat binaries would only be necessary for software that is designed to have backward compatibility with older versions of Mac OS X running on older hardware.
The new Universal 2 binary format was introduced at the 2020 Worldwide Developers Conference.[5] Universal 2 allows applications to run on both Intel x86-64-based and ARM64-based Macintosh computers, to enable the transition to Apple silicon.
Motivation
[edit]There are two general alternative solutions. The first is to simply provide two separate binaries, one compiled for the x86 architecture and one for the PowerPC architecture. However, this can be confusing to software users unfamiliar with the difference between the two, although the confusion can be remedied through improved documentation, or the use of hybrid CDs. The other alternative is to rely on emulation of one architecture by a system running the other architecture. This approach results in lower performance, and is generally regarded an interim solution to be used only until universal binaries or specifically compiled binaries are available as with Rosetta.
Universal binaries are larger than single-platform binaries, because multiple copies of the compiled code must be stored. However, because some non-executable resources are shared by the two architectures, the size of the resulting universal binary can be, and usually is, smaller than the combined sizes of two individual binaries. They also do not require extra RAM because only one of those two copies is loaded for execution.
History
[edit]The concept of a universal binary originated with "Multi-Architecture Binaries" in NeXTSTEP, the main architectural foundation of Mac OS X. NeXTSTEP supports universal binaries so that one executable image can run on multiple architectures, including Motorola's m68k, Intel's x86, Sun Microsystems's SPARC, and Hewlett-Packard's PA-RISC. NeXTSTEP and macOS use Mach-O archive as the binary format underlying the universal binary.
Apple previously used a similar technique during the transition from 68k processors to PowerPC in the mid-1990s. These dual-platform executables are called fat binaries, referring to their larger file size.
Apple's Xcode 2.1 supports the creation of these files, a new feature in that release. A simple application developed with processor-independence in mind might require very few changes to compile as a universal binary, but a complex application designed to take advantage of architecture-specific features might require substantial modification. Applications originally built using other development tools might require additional modification. These reasons have been given for the delay between the introduction of Intel-based Macintosh computers and the availability of third-party applications in universal binary format. Apple's delivery of Intel-based computers several months ahead of their previously announced schedule is another factor in this gap.
Apple's Xcode 2.4 takes the concept of universal binaries even further, by allowing four-architecture binaries to be created (32- and 64-bit for both Intel and PowerPC), therefore allowing a single executable to take full advantage of the CPU capabilities of any Mac OS X machine.
Universal applications
[edit]Many software developers have provided universal binary updates for their products since the 2005 WWDC. As of December 2008, Apple's website listed more than 7,500 Universal applications.[6]
On April 16, 2007, Adobe Systems announced the release of Adobe Creative Suite 3, the first version of the application suite in the Universal Binary format.[7]
From 2006 to 2010, many Mac OS X applications were ported to Universal Binary format, including QuarkXPress, Apple's own Final Cut Studio, Adobe Creative Suite, Microsoft Office 2008, and Shockwave Player with version 11 - after that time most were made Intel-only apps. Non-Universal 32-bit PowerPC programs will run on Intel Macs running Mac OS X 10.4, 10.5, and 10.6 (in most cases), but with non-optimal performance, since they must be translated on-the-fly by Rosetta; they will not run on Mac OS X 10.7 Lion and later as Rosetta is no longer part of the OS.
iOS
[edit]Apple has used the same binary format as Universal Binaries for iOS applications by default on multiple occasions of architectural co-existence: around 2010 during the armv6-armv7-armv7s transition and around 2016 during the armv7-arm64 transition. The App Store automatically thins the binaries. No trade names were derived for this practice, as it is only a concern of the developer.[8]
Universal 2
[edit]| Mac transition to Apple silicon |
|---|
 |
On June 22, 2020, Apple announced a two-year permanent transition from Intel x86-64-based processors to ARM64-based Apple silicon beginning with macOS Big Sur in late 2020.[9] To aid in this transition, a new Universal 2 binary was introduced to enable applications to be run on either x86-64-based processors or ARM64-based processors.[5]
Tools
[edit]The main tool for handling (creating or splitting) universal binaries is the lipo command found in Xcode. The file command on macOS and several other Unix-like systems can identify Mach-O universal binaries and report architecture support.[10] Snow Leopard's System Profiler provides this information on the Applications tab.
See also
[edit]References
[edit]- ^ "Firefox 4 for Mac OS X: Under the Hood". November 10, 2010. Retrieved March 3, 2017.
- ^ "Mac OS X Universal Logo: Guidelines for Mac OS X Universal Logo Licenses" (PDF). Apple Inc. June 2007. Retrieved October 18, 2013.
- ^ "Mac OS X: 64-bit kernel frequently asked questions". Apple Inc. October 4, 2012. Retrieved October 18, 2013.
- ^ "Does Mac OS X 10.7 "Lion" run on Macs with a 32-bit EFI? How does the performance of Mac OS X 10.7 "Lion" compare to Mac OS X 10.6 "Snow Leopard" in "real-world" tests? @ EveryMac.com". everymac.com. Kyle Media. Retrieved October 6, 2017.
- ^ a b Axon, Samuel (June 22, 2020). "This is Apple's roadmap for moving the first Macs away from Intel". Ars Technica. Retrieved June 23, 2020.
- ^ "Macintosh Products Guide: Universal Applications". Apple Computer. Retrieved December 22, 2008.
- ^ "Adobe Ships Creative Suite 3". Adobe Systems. April 16, 2007. Archived from the original on July 8, 2012. Retrieved October 18, 2013.
- ^ "lipo - iOS fat binaries and thinning out". Stack Overflow.
- ^ Amadeo, Ron (June 22, 2020). "Apple announces macOS 11, "Big Sur," with an emphasis on design". Ars Technica. Retrieved June 23, 2020.
- ^ stany (September 6, 2005). "Mac OS X: Trimming fat from Mach-O fat files". theconsultant.net. Retrieved October 18, 2013.
External links
[edit]- Apple Developer Transition Resource Center
- Apple Universal Binary Programming Guidelines
- Apple Universal Binary Introduction
Universal binary
View on Grokipediafrom Grokipedia
A universal binary is an executable file format developed by Apple Inc. for its macOS and iOS operating systems, containing multiple versions of compiled machine code targeted at different central processing unit (CPU) architectures within a single file, enabling native execution on diverse hardware without emulation for supported platforms.[1] This format leverages the Mach-O executable structure with a "fat binary" header that encapsulates binaries for architectures such as PowerPC, Intel x86, and Apple Silicon ARM, allowing the operating system to automatically select and load the appropriate version at runtime.[2]
Apple introduced universal binaries in June 2005 during the announcement of its transition from PowerPC to Intel processors, with the first implementation appearing in Mac OS X 10.4.4 (Tiger) to facilitate developer compatibility and smooth software adoption across the architectural shift.[3][4] The format was designed to simplify binary distribution by permitting a single application package to support both legacy and new hardware, complemented by the Rosetta emulation layer for running unsupported binaries during the PowerPC-to-Intel migration.[5] In 2020, Apple revived and extended the universal binary approach—now termed Universal 2—for the shift from Intel to its custom Apple Silicon (ARM-based) processors, starting with macOS Big Sur, to ensure broad compatibility for apps on both Intel-based and Apple Silicon Macs.[6][7]
Universal binaries maintain the same file extensions and outward appearance as single-architecture executables, such as Mach-O binaries or app bundles, but internally embed multiple architectures using tools like Xcode's lipo utility for merging during compilation.[8] This approach has been pivotal in Apple's hardware transitions, reducing developer overhead, enhancing performance by prioritizing native code execution, and supporting features like Rosetta 2 for translating Intel binaries on Apple Silicon when no native version is available.[9] Developers are encouraged to build universal binaries to maximize reach across Apple's ecosystem, with the format remaining a cornerstone of cross-architecture software deployment as of macOS Sonoma and later releases.[2]
are: x86_64 arm64", helping to verify that all intended slices are present and correctly merged.[35]
The
Fundamentals
Definition and purpose
A universal binary is a single executable file that encapsulates multiple Mach-O binaries, each compiled for distinct CPU architectures such as x86_64 for Intel processors and arm64 for Apple Silicon, enabling the operating system to automatically select and execute the appropriate variant at runtime based on the host hardware.[2][8] The primary purpose of a universal binary is to streamline software distribution within Apple's ecosystem by consolidating architecture-specific variants into one file, thereby eliminating the need for developers or users to manage separate builds or downloads for different hardware platforms.[2][6] Key benefits include enhanced backward compatibility, simplified application updates across diverse hardware, and facilitated support during transitional periods, such as the shift from Intel to Apple Silicon processors. For instance, a universal binary allows a single macOS application package to run natively on both Intel-based Macs and Apple Silicon Macs without requiring user intervention or emulation layers like Rosetta.[2][9]Architecture compatibility
Universal binaries enable cross-architecture execution by encapsulating multiple architecture-specific executable images, known as "slices," within a single file container. This allows the same binary to run natively on different processor types without requiring separate distributions. Primarily, universal binaries support 64-bit (x86_64) for Intel-based systems and, historically, 32-bit (i386) variants, ARM64 (arm64) for Apple Silicon, and historically PowerPC (PPC and PPC64) for older Macintosh hardware.[2][10] Each slice is segmented by unique architecture identifiers embedded in the binary's header, ensuring precise mapping to the target CPU.[10] At runtime on macOS and iOS, the dynamic linker (dyld) examines the host system's CPU architecture and parses the universal binary's header to select and load the appropriate slice. This process occurs transparently during application launch, prioritizing the native architecture for optimal performance. If no matching slice is found, dyld fails to load the binary, preventing execution.[10] Universal binaries also accommodate thin binaries, which contain only a single architecture slice, by treating them as a special case of the universal format with just one entry. Developers can wrap thin binaries in universal containers using tools like lipo for broader compatibility. During architecture transitions, such as from Intel to Apple Silicon, fallback mechanisms like Rosetta 2 enable emulation of x86_64 code on ARM64 hardware, allowing universal binaries with Intel slices to run via translation when native ARM64 slices are unavailable.[2][9] This ensures seamless operation across generations, though native execution remains preferred for efficiency.[6]Historical development
Origins in Mac OS X
In 2005, Apple announced its transition from PowerPC to Intel processors, creating the need for a binary format that could support both architectures to facilitate a smooth migration for developers and users over a two-year period.[11] The shift was driven by performance improvements and broader hardware compatibility, with Apple committing to begin shipping Intel-based Macs in 2006 and completing the transition by the end of 2007.[11] Universal binaries were first implemented in the Mac OS X 10.4.4 update, released on January 10, 2006, as an evolution of the "fat binaries" concept originally developed for multi-architecture support in NeXTSTEP.[3][12] NeXTSTEP's fat binaries, first appearing in version 3.1 in 1993, allowed a single executable to contain code for multiple processor types, such as Motorola 68000 and Intel x86, enabling seamless operation across hardware platforms.[12] This heritage informed Apple's approach, adapting the Mach-O file format to bundle PowerPC and Intel code within one file for easier deployment during the processor switch. A pivotal moment came during Steve Jobs' keynote at the 2005 Worldwide Developers Conference on June 6, where he revealed universal binaries as the key mechanism for running software compiled for Intel on PowerPC systems and vice versa, ensuring compatibility throughout the transition.[3] Jobs emphasized that "one binary works on both PowerPC and Intel architecture," highlighting how this format would allow developers to target both user bases without separate builds.[3] Initially, universal binaries supported only PowerPC (PPC) and x86 architectures, focusing on 32-bit code to address the immediate needs of the Intel shift.[3] Developer tools like Xcode 2.1, released alongside the announcement, integrated universal binary creation directly into the build process, allowing developers to generate dual-architecture executables with minimal effort.[13] This early implementation prioritized migration ease over broader multi-architecture expansion.[3]Introduction of universal applications
In Mac OS X 10.5 Leopard, released on October 26, 2007, universal binaries became the standard format for the operating system itself, marking the first time an OS X release shipped as a universal binary capable of installation on both PowerPC and Intel-based Macintosh computers from a single DVD.[14] This rollout unified separate architecture-specific builds, streamlining distribution and supporting Apple's ongoing transition from PowerPC to Intel processors that began in 2005. Apple actively encouraged third-party developers to adopt universal binaries to ensure broad compatibility across the user base, providing guidelines and tools to facilitate the process.[15] Developers merged architecture-specific binaries using the lipo command-line tool, which combined executable files for PowerPC and Intel into a single universal file without altering the underlying codebases.[2] This approach minimized development overhead, allowing applications to run natively on either hardware by selecting the appropriate slice at runtime. By late 2008, adoption was widespread, with Apple documenting over 7,500 universal applications available, reflecting strong developer compliance as the Intel transition progressed. The tool's integration into Xcode further simplified building universal binaries as the default for new projects. The introduction of universal binaries in Leopard had significant ecosystem benefits, enabling seamless software upgrades for users regardless of their hardware architecture and reducing fragmentation during the transition period. Apple's own software suites, such as iLife '08 and iWork '08 released alongside Leopard, were built as universal binaries, setting an example for compatibility in creative and productivity tools. This push facilitated a smooth user experience, with applications performing optimally on both old and new systems without needing separate downloads or installations. By 2008, the majority of active macOS applications had transitioned to universal format, completing the practical shift away from PowerPC-specific development. PowerPC support was fully phased out with the release of Mac OS X 10.6 Snow Leopard on August 28, 2009, which dropped compatibility for the architecture entirely, focusing exclusively on Intel processors.[16]Adoption in iOS
In iOS development, universal binaries have been used since the iPhone SDK 2.0 (2008) to include both ARM slices for physical devices and x86_64 slices for the simulator on Intel-based Macs, enabling efficient testing workflows.[17] This fat binary approach supported code reuse across development environments without recompilation. Note that "universal apps" in iOS, introduced with iOS 4 in June 2010, refer to a single binary compatible with both iPhone and iPad devices (sharing the same ARM architecture but with UI optimizations), distinct from multi-architecture universal binaries.[18] A significant advancement for architecture support occurred with iOS 7 in 2013, introducing arm64 binaries for 64-bit devices, building on earlier 32-bit ARM support. iOS 11 in September 2017 mandated 64-bit compatibility, dropping 32-bit apps from the App Store and requiring arm64 binaries for all submissions.[2] This ensured performance consistency across Apple's ARM-based devices. Later, Mac Catalyst (introduced in macOS Catalina 10.15, 2019) allowed iOS apps to run on macOS, with universal binaries facilitating cross-platform deployment by including both ARM and x86_64 slices.[19] In Apple's shared ecosystem, universal binaries promote code reuse by allowing applications to be compiled once for various ARM variants, supporting deployment across iPhone, iPad, and compatible macOS environments under a unified architecture.[6] For instance, developers can target multiple ARM-based devices with a single build process, reducing maintenance overhead while optimizing for hardware differences like processor cores or memory configurations.[20] With the transition to Apple Silicon, Xcode 12 (2020) introduced arm64 simulator support, allowing universal binaries to include arm64 device, arm64 simulator, and x86_64 simulator slices for comprehensive testing on both Intel and Apple Silicon development machines.[21]Evolution to Universal 2
At the 2020 Worldwide Developers Conference (WWDC), Apple announced Universal 2 binaries as part of the transition to Apple silicon for Macs, debuting with macOS Big Sur (version 11.0) and Xcode 12. These binaries support both x86_64 (Intel) and arm64 (Apple silicon) architectures within a single file, enabling developers to create applications that run natively across all modern Mac hardware without modification.[20] Universal 2 enhances performance by allowing native execution on Apple silicon, leveraging the unified memory architecture and optimized frameworks like Metal for faster launches and better efficiency compared to translated code. For legacy Intel applications, Rosetta 2 provides binary translation, enabling unmodified x86_64 apps—including those with plug-ins—to run seamlessly on Apple silicon Macs with near-native performance. This dual-support model addresses the original universal binary format's limitations by incorporating metadata in the Info.plist file, such as the LSArchitecturePriority key to specify preferred architectures and LSRequiresNativeExecution to enforce native runs, which improves architecture detection at launch. Additionally, Universal 2 binaries offer enhanced simulator support, including both x86_64 and arm64 slices for testing iOS and macOS apps natively on Apple silicon development machines.[20][2] Apple outlined a two-year transition period beginning with the first Apple silicon Mac shipments at the end of 2020, aiming for full ecosystem compatibility by the end of 2022, coinciding with macOS Ventura's release. By this point, all new Mac hardware was Apple silicon-based, and Universal 2 became the standard for cross-architecture distribution in the Mac App Store, where only one binary per app is permitted, necessitating universal formats for broad compatibility. Adoption accelerated rapidly, with the majority of top Mac App Store apps supporting Universal 2 by 2023, driven by developer tools in Xcode that simplify building and testing multi-architecture binaries. This evolution built on iOS's long-standing arm64 focus, enabling seamless app portability across Apple's ARM-based platforms.[20][2]Technical implementation
File format structure
A universal binary, also known as a fat binary, encapsulates multiple architecture-specific Mach-O binaries within a single file using a wrapper structure that begins with a fat header. This fat header is defined by thestruct fat_header in the Mach-O format, consisting of two 32-bit unsigned integer fields: magic, which holds the value 0xcafebabe in big-endian byte order to identify the file as a universal binary (validated against the constant FAT_MAGIC), and nfat_arch, indicating the number of architecture slices contained within the file.[22]
Following the fat header is an array of fat_arch structures (or fat_arch_64 for files exceeding 4 GB per slice or offsets beyond 4 GB), one for each architecture slice. Each fat_arch structure includes five 32-bit fields in big-endian order: cputype (specifying the CPU type, such as CPU_TYPE_X86_64 for 64-bit Intel processors), cpusubtype (a machine-specific subtype), offset (the byte offset from the start of the file to the beginning of the corresponding thin binary), size (the byte length of the thin binary), and align (the alignment requirement as a power of 2, ensuring proper memory placement). The location of a specific architecture slice is determined by its offset value relative to the file base (typically 0), allowing the loader to jump directly to the embedded binary.[23][24]
The embedding mechanism concatenates the individual thin Mach-O binaries sequentially after the header array, ordered as specified by the fat_arch entries, without any compression or additional encoding. This results in a straightforward layout where the total file size is the sum of the header overhead plus the sizes of all embedded slices, enabling efficient extraction of the appropriate binary at runtime based on the host architecture.[25][26]
The file size overhead introduced by the universal wrapper is minimal, typically less than 1% for binaries of practical size, as the fat header adds 8 bytes and each fat_arch entry adds 20 bytes (or 32 bytes for 64-bit variants), regardless of the number of architectures beyond the first. Tools such as otool are required to inspect and disassemble these structures, with commands like otool -f displaying the fat header and architecture details to verify the embedded slices.[27]
Integration with Mach-O
Universal binaries integrate seamlessly with the Mach-O executable format by encapsulating multiple independent Mach-O files, known as slices, within a single fat binary wrapper. Each slice constitutes a complete, self-contained Mach-O file customized for a specific architecture, including its own mach_header (or mach_header_64 for 64-bit), load commands, segments, sections, and symbol tables. This structure allows the binary to maintain architecture-specific optimizations, such as instruction sets and alignment requirements, while sharing common elements like the fat header for multi-architecture identification.[28] The parsing process begins with the dynamic linker, dyld, which examines the fat header—identified by the magic number 0xCAFEBABE—to determine the number of slices and their offsets, sizes, and alignments via fat_arch structures. Dyld then selects the slice matching the host CPU type and subtype, skipping to its offset where it encounters the Mach-O header's magic number, such as 0xfeedface for 32-bit big-endian, 0xcefaedfe for 32-bit little-endian, 0xfeedfacf for 64-bit big-endian, and 0xcffaedfe for 64-bit little-endian. From there, dyld interprets the load commands, such as LC_SEGMENT or LC_SEGMENT_64, to map segments into virtual memory; for instance, the __TEXT segment (read-only, containing executable code in the __text section and constants in __const) is loaded with execute permissions, while the __DATA segment (read-write, holding initialized data in __data and uninitialized in __bss) receives write permissions, enabling copy-on-write sharing across processes.[28][10] Support for cross-architecture linking in universal binaries extends to dynamic shared libraries (.dylib files), where each slice preserves its own symbol and relocation information in the __LINKEDIT segment. During runtime, dyld resolves undefined symbols from the executable's slice against the corresponding architecture-specific slice in the library, using two-level namespace resolution (library name plus symbol name) to avoid conflicts and enable architecture-tailored optimizations, such as vector instructions unique to PowerPC or x86. This per-slice resolution ensures compatibility and performance without requiring separate library builds per architecture.[10][28] The fat binary extension of the Mach-O format builds directly on the original design from NeXTSTEP, where multi-architecture support was rudimentary, and was significantly enhanced in 2005 to accommodate Apple's shift from PowerPC to Intel processors through new load commands and fat header mechanisms that simplified the transition for developers and users alike.[10][28]Multi-architecture support mechanisms
Universal binaries employ runtime mechanisms to automatically select and execute the appropriate architecture-specific code slice based on the host system's CPU. During process execution, the macOS kernel parses the fat header of the universal binary and identifies the slice that matches the current CPU type and subtype most closely, loading only that Mach-O executable into memory while ignoring others.[29] If no compatible slice is found, the system typically terminates the launch with an error such as "bad CPU type in executable," resulting in a crash; however, on Apple Silicon Macs, if an arm64 slice is absent but an x86_64 slice exists, the kernel invokes Rosetta 2 for dynamic binary translation to enable execution.[30] User-space applications can query the host architecture using system calls like sysctlbyname("hw.machine") or the uname function to adapt behavior dynamically, though this is distinct from the kernel's automatic slice selection. For integration with the Mach-O format, the dynamic linker dyld further processes the loaded slice, handling dependencies and relocations specific to the selected architecture. In development environments like Xcode, conditional compilation directives enable architecture-specific code paths within a single source base. Swift and Objective-C support #if arch directives, such as #if arch(arm64) or #if arch(x86_64), allowing developers to include or exclude code blocks during compilation for each target architecture, ensuring optimal performance and compatibility without runtime checks. Builds for simulators versus physical devices often incorporate universal slices to accommodate varying host architectures; for instance, iOS framework builds combine arm64 device slices with arm64 or x86_64 simulator slices, facilitating testing across development machines. Optimization techniques in universal binary creation include per-architecture dead code elimination, where the compiler removes unused functions and data during separate builds for each slice, minimizing the overall file size compared to monolithic binaries.[2] This approach also supports hybrid applications that integrate native code slices with translated execution via Rosetta, allowing seamless fallback on mismatched hardware without full recompilation. In Universal 2 binaries, which support both x86_64 and arm64 architectures, additional mechanisms enhance security through arm64e slices that incorporate pointer authentication codes (PACs) to protect against pointer manipulation attacks, ensuring authenticated execution across compatible Apple Silicon systems.[31]Creation and usage tools
Building universal binaries
Developers create universal binaries using Apple's Xcode integrated development environment, which automates the compilation and linking process for multiple architectures. In Xcode 12 and later versions, released in 2020, the tool defaults to building Universal 2 binaries for release configurations by including both x86_64 and arm64 architectures in the standard ARCHS build setting for macOS projects.[6] This default behavior ensures that archived apps for distribution are universal without additional configuration, while debug builds target only the host machine's architecture to speed up iteration.[2] Xcode issues warnings for projects that produce non-universal binaries when targeting macOS, prompting developers to enable multi-architecture support.[6] To configure a project for universal output, developers set the Architectures build setting to include multiple targets, such as ARCHS = "x86_64 arm64", either through the Xcode project editor or by modifying the build configuration files.[32] For automated universal binaries, archiving the project via Product > Archive in Xcode merges the architecture-specific binaries during the export process, producing a single fat binary suitable for both Intel-based and Apple silicon Macs.[2] This process compiles source files separately for each architecture—once for x86_64 and once for arm64—before linking them into the final executable.[2] As of November 2025, Apple announced that macOS 27 will discontinue support for Intel processors, meaning future universal binaries may only need to target arm64 for native execution on Apple Silicon.[33] For manual creation or when working outside Xcode, such as with custom build scripts, the lipo command-line tool merges thin binaries into a universal one. The primary syntax islipo -create -output universal_binary thin_x86_64_binary thin_arm64_binary, where thin binaries are architecture-specific executables or libraries built individually using compiler flags like -arch x86_64 or -arch arm64.[2] For example, developers might compile separate binaries with clang -arch x86_64 -o app_x86_64 source.c and [clang](/page/Clang) -arch arm64 -o app_arm64 source.c, then combine them via lipo.[2]
Best practices emphasize thorough testing on diverse hardware to ensure compatibility, including running the app on both Intel Macs (using Rosetta 2 for arm64 code) and Apple silicon devices to identify architecture-specific issues.[6] For code that varies by architecture, use conditional compilation directives in source files, such as #if arch(arm64) in Swift or #if TARGET_CPU_ARM64 in Objective-C, to include platform-specific implementations without relying solely on build flags.[2] Additionally, when building for iOS or multi-platform frameworks, leverage XCFramework bundles created with xcodebuild -create-xcframework to package binaries for both device (arm64) and simulator (x86_64 or arm64) architectures, ensuring seamless integration across deployment targets.[17]
Inspecting and analyzing binaries
Inspecting universal binaries involves using command-line utilities provided by Apple to examine their structure, verify architectures, and ensure integrity, particularly after compilation or for debugging purposes. These tools allow developers to confirm the presence of multiple architecture slices within a single file, inspect headers, symbols, and debug information, and validate signatures without needing to extract or run the binary.[2] Thefile command offers a quick way to detect architectures in Mach-O binaries, including universal ones. Running file <binary> outputs details such as "Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]", identifying if the file is thin (single architecture) or universal (multi-architecture).[34]
For more detailed architecture listing, the lipo utility's -info option enumerates supported architectures in a universal binary. The command lipo -info <binary> produces output like "Architectures in the fat file: otool command provides in-depth inspection of the fat header and contents. Using otool -f <binary> displays the fat header structure, including the magic number (0xcafebabe for universal binaries), number of architectures, and offsets/sizes for each slice, such as "fat_arch: cputype CPU_TYPE_X86_64 (6), cpusubtype CPU_SUBTYPE_X86_64_ALL (3), filetype OBJTYPE_EXECUTABLE (1)". This reveals the binary's multi-architecture layout at a low level.[25]
To analyze symbols across slices, the nm utility inspects the symbol table for each architecture. For universal binaries, specify the architecture with nm -arch x86_64 <binary> or nm -arch arm64 <binary> to list undefined, defined, and common symbols, such as function names and their types (e.g., 'T' for text section), enabling per-slice symbol comparison without extraction.[8]
Disassembly workflows utilize otool -tv for code review, which disassembles the text section into assembly instructions. In universal binaries, append -arch <architecture> (e.g., otool -tv -arch arm64 <binary>) to target a specific slice, producing output like ARM64 instructions for functions, facilitating architecture-specific code verification and optimization checks.[36]
Debugging often involves dwarfdump to examine DWARF debug information, distinguishing thin from universal binaries by parsing sections across slices. The command dwarfdump --arch=all <binary> outputs debug entries for all architectures if universal, or a single set if thin, revealing compilation units, variables, and line numbers; this helps identify inconsistencies in debug data between slices.[8]
For signed universal applications, Apple's pkgutil and codesign tools extend inspection to ensure integrity. pkgutil --check-signature <package> verifies signatures on installer packages containing universal binaries, flagging issues like expired certificates across components. Similarly, codesign -dv <binary> displays verbose details on the code signature, confirming that all slices are uniformly signed and untampered, with output including the signing authority and hash algorithms used.[36][37]
Common analysis workflows combine these tools: start with lipo -info to list architectures, use otool -f for header details, then otool -tv -arch <arch> or nm -arch <arch> for code and symbol review per slice. During App Store validation, mismatched slices—such as an executable supporting arm64 but a library only x86_64—can cause rejection; developers mitigate this by running lipo -info on all bundle binaries to ensure architectural consistency before submission.[38]