Bumble's Code Signing and Distributing Swift Applications
Original post Code Signing and Distributing Swift Applications
Article Summary
The Badoo iOS team learned the hard way: adopting Swift in 2015 meant navigating undocumented code signing nightmares that crashed enterprise apps at runtime. Here's what broke and how they fixed it.
When Badoo (now Bumble) started integrating Swift into their iOS apps, they hit critical distribution issues that Apple's tooling didn't handle automatically. This 2017 post documents three major problems with code signing and IPA packaging that broke their enterprise builds and App Store submissions.
Key Takeaways
- Swift apps embed runtime frameworks that need independent code signing before app signing
- Enterprise certificates require Organizational Unit field or embedded frameworks crash on load
- Command-line builds missing SwiftSupport folder get rejected by App Store validation
- Re-signing scripts must handle Frameworks folder and dylibs with proper certificate chains
Early Swift adoption required manual scripting workarounds for code signing embedded frameworks, fixing enterprise certificate fields, and packaging SwiftSupport folders that Xcode's CLI tools omitted.
Continue reading
What This Article Covers
Badoo's re-signing scripts didn't handle Swift's embedded dylibs in the Frameworks folder. This caused runtime crashes whenever enterprise builds were modified after compilation.
The team updated their bash scripts to find all .dylib files from the XcodeDefault.xctoolchain and re-sign them. Then they signed the application bundle using the codesign tool.
Enterprise certificate deployments started working once they added the Organizational Unit field requirement. This fixed the OS-level rejection crashes that had been preventing app installation on devices.
This page summarizes “Code Signing and Distributing Swift Applications” by Bumble, published Feb 23, 2017. All credit for the original work goes to the authors.
