Getting Square's iOS Build Ready for Apple Silicon with Bazel
Article Summary
Jerry Marino from Square reveals how they got their massive iOS codebase (1000+ modules) running on M1 Macs without waiting for every dependency to update. The clever workaround? Converting device binaries to run on the simulator.
When Apple Silicon launched, Square faced a dilemma: their Bazel-based iOS build system relied on hundreds of binary dependencies that weren't M1-ready. Rather than wait months for updates or settle for Rosetta 2's performance hit, the team engineered an interim solution that patches device binaries to work natively on the M1 simulator.
Key Takeaways
- Bazel query helped triage 1000+ modules and map updates to team owners
- Device arm64 binaries patched to run on M1 simulator using vtool and arm64-to-sim
- Bazel aspects automatically convert dependencies without blocking developer workflow
- Solution bridges gap while xcframework migration completes across company
Square leveraged Bazel's extensibility to automatically patch incompatible dependencies, enabling M1 simulator development months before all dependencies were officially updated.
About This Article
Square's iOS build had over 1,000 modules mixing Objective-C and Swift. When Apple Silicon arrived, the simulator needed arm64 architecture, but their binary dependencies were still packaged as fat binaries with x86_64 slices. This meant nothing worked.
Jerry Marino's team built a middleman abstraction in Bazel. It runs the find_imports aspect to automatically patch device binaries, using vtool for dynamic libraries and arm64-to-sim for static archives. This let developers run the app natively on M1 simulators without waiting for xcframework updates.
Developers could build and run Square on M1 simulators right away while the company finished migrating dependencies to xcframework. This saved months of blocked development time and let teams work on the long-tail binary dependency updates in parallel.
