Universal 2 is a supply chain problem, not a build flag

A developer who moved a Qt macOS application from an Intel Mac to Apple Silicon has published the dependency arithmetic behind shipping a single universal binary, and the useful part is the ordering: the application is the last component you port, not the first ^[1]. According to the dev.to writeup, published under the handle nehachauhan18, the requirement was one macOS application running natively on both Intel and Apple Silicon, and in practice that became a build and dependency-management problem rather than an application problem ^[2][3].

The starting state was coherent. On the Intel machine, Qt and four third-party libraries were all built for x86_64, the application was x86_64, and the author reports no architecture mismatch: it compiled, linked and ran ^[4][5]. The mismatch arrives only when the application binary is asked to contain both slices, because every native library the application uses must also support the architectures the final application requires ^[6][7]. With an x86_64-only dependency, the linker can still produce the Intel portion of the application and cannot produce the arm64 portion from the same file ^[8]. Making the application universal is not sufficient on its own ^[9].

The remedy in the post is unglamorous: build each third-party library separately for x86_64 and for arm64, then combine the outputs with Apple's lipo tool, which for Mach-O binaries yields what macOS calls a Universal 2 binary ^[10][11][12]. Verification is lipo -info, which should report both x86_64 and arm64 in the fat file ^[13]. Count the work implied by the author's own target graph: five named native components, each needing two architecture-specific builds and one combine step, is ten builds and five lipo invocations before the application itself is touched ^[14][1].

The trap is stopping at the top-level .dylib or .framework. The author notes that a dependency has its own dependencies, and that if Library A is universal while Library B underneath it is x86_64 only, the application can still fail to build or run for arm64, so the entire chain has to be inspected ^[15][16]. Qt made this heavier. Qt itself had to be built for the target architectures, which made the Qt configuration and build a significant part of the migration ^[17][18], and the components involved included Qt WebEngine, Qt WebView, Qt PDF, WebRTC, proprietary codecs, Chromium dependencies and macOS frameworks ^[19]. The author describes this as significantly more complex than a simple C++ application ^[20].

The habit worth stealing is cheap: check the architecture of the binary you are actually linking, with file or lipo -info, and for frameworks inspect the binary inside the bundle rather than the bundle ^[21][22]. The author says this check alone saves a lot of debugging time ^[23]. On Rosetta 2, the post is clear that instruction translation lets Intel applications run on Apple Silicon and is useful for older applications, but does not magically convert an Intel development environment; the published sentence is cut off at that point ^[24][25][26].

What to watch, if you are running this migration: which of your upstream vendors ship Universal 2 artifacts and which hand you x86_64 only, since the second group sets your build calendar ^[6][8]. Audit transitively before you commit, because a universal top-level library over a single-architecture transitive dependency still fails for arm64 ^[15]. And treat the browser-engine and codec components as the long pole rather than an afterthought ^[19][20].