cd /path/to/YourApp
pod install
xcodebuild -workspace YourApp.xcworkspace -scheme YourApp -configuration Debug build

nm -gU \
  ~/Library/Developer/Xcode/DerivedData/YourApp-*/Build/Products/Debug-iphonesimulator/YourApp.app/YourApp \
| grep CLS ``` You usually do not need to inspect every symbol. The important part is whether the same library or object appears through two integration paths. ## Fix The Usual Crashlytics Conflict If your project uses CocoaPods, let CocoaPods own the Crashlytics integration. Remove manual framework references from the project settings and keep dependency declaration in the `Podfile` only. A typical legacy `Podfile` looked like this: ```ruby platform :ios, '11.0' use_frameworks! target 'YourApp' do pod 'Fabric' pod 'Crashlytics' end ``` After changing the dependency configuration, reinstall pods and clean the build outputs. ```sh cd /path/to/YourApp pod deintegrate pod install rm -rf ~/Library/Developer/Xcode/DerivedData ``` Then open the workspace, not the project file. Building the `.xcodeproj` while using pods can produce missing or duplicated dependency behavior because the generated pods targets are not resolved the same way. ## Check Build Phases Carefully Open the app target and inspect these areas: - '`Build Phases` and `Link Binary With Libraries`' - '`Build Settings` and `Other Linker Flags`' - any legacy run script phases related to Fabric upload tools If you see both a pod-generated framework and a manually added framework for Crashlytics, remove the manual one. The same applies to leftover `libPods-...a` and direct framework entries that represent the same dependency graph. A safe rule is simple: one package manager, one integration path. ## Example Of A Clean Migration Many projects that hit this problem were partially migrated. This is a safer sequence: ```sh # 1. Remove manual framework references in Xcode # 2. Keep Crashlytics only in Podfile # 3. Reinstall pods pod deintegrate pod install # 4. Clear build artifacts rm -rf ~/Library/Developer/Xcode/DerivedData # 5. Build the workspace open YourApp.xcworkspace ``` If the issue persists, compare target membership. A framework added to both the app target and an embedded internal framework target can also produce duplicate symbol output if the same code is statically linked twice. ## Common Pitfalls The most common mistake is cleaning the project but not removing `DerivedData`. `Product` and `Clean Build Folder` helps, but stale beta build outputs can still survive outside the project directory. Another problem is assuming the linker error is a compiler bug. Xcode 10 beta 5 changed build behavior enough to expose misconfigured projects, but the actual cause is usually dependency duplication. Treat the error as a build graph problem, not a Swift or Objective-C syntax issue. A third mistake is mixing old Fabric instructions with newer pod-based setups. If your team copied steps from multiple guides over time, review the project file line by line. Linker errors often disappear only after removing the redundant integration completely. ## Summary - Duplicate symbol errors happen at link time, not compile time. - Crashlytics conflicts usually come from manual linking plus CocoaPods. - Inspect the symbol paths in the linker output to find the duplicate source. - Remove redundant framework entries, reinstall pods, and clear `DerivedData`. - Build the `.xcworkspace` when using CocoaPods.