BranchMetrics/ios-branch-deep-linking-attribution

BranchSDK 183 issues running on Xcode 14.3

jordanhbuiltbyhq opened this issue · 6 comments

Describe the bug

Trying to run your app from Xcode 14.3 with BranchSDK integrated causes the build to fail. The issue navigator reveals BranchSDK has 183 issues such as:

  • .../Pods/BranchSDK/BranchSDK/BNCAppleReceipt.h:10:1 use of '@import' in framework header is discouraged, including this header requires -fmodules
  • .../Pods/BranchSDK/BranchSDK/BNCAppleSearchAds.h:10:9 double-quoted include "BNCPreferenceHelper.h" in framework header, expected angle-bracketed instead

Steps to reproduce

  1. Install Xcode 14.3
  2. Install CocoaPods 1.12.1
  3. Add pod 'BranchSDK' to your Podfile
  4. pod install
  5. Click the warning in the sidebar to upgrade to recommended project settings
  6. Run the app

Expected behavior

The build should succeed. Instead, the build fails with 183 issues in BranchSDK. 😅

SDK Version

2.1.2

XCode Version

14.3

Device

Simulator

OS

iOS 16.4

Additional Information/Context

Screenshot 2023-04-19 at 8 16 04 AM

@jordanhbuiltbyhq
I was not able to repro the issue as described on my test apps. However, I suspect it's some build setting that conflicts with the way cocoapods generates the umbrella header.

Does it work without upgrading project settings? If so, could you provide the diff of the build settings or any other suspicious sections?

Also are you upgrading the project settings on the cocoapods generated project or your app project? The cocoapods generated one should be left alone.

Hi @echo-branch. Yes, if you update the Pods to recommended settings this is when the errors occur. If you do not upgrade Pods to the recommended settings, other errors occur with dependencies besides Branch - for example with PipKit specifically the error is File not found: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc/libarclite_iphonesimulator.a). We have always upgraded the Pods project to the recommended settings.

If however you apply all of the recommended settings except for Target 'Branch SDK' - Enable Module Verifier, then the build succeeds. With that, can you determine if this is an issue with BranchSDK or is it an issue with CocoaPods to resolve? Thanks!

@jordanhbuiltbyhq
Ah I see. You really hit an interesting edge case here.

  1. PIPKit is targets an iOS version that's not recommended with Xcode 14.3. iOS 8, this causes a build error.
  2. PIPKit is written in Swift.
  3. BranchSDK is written in Objective-C.
  4. Cocoapods generates an umbrella header for Objective-C libraries that will not pass the module verifier.
  5. Xcode 14.3 sees the issue with PIPKit and recommends updating settings, it aggressively updates all projects. Which breaks the BranchSDK umbrella header generated by Cocoapods.

I get why all parties made the choices they did, but they're incompatible. You can either disable module verifier on BranchSDK, or update the target version on the PIPKit without updating the Pods settings.

I personally would consider using Swift Package Manager for the BranchSDK, it comes with an umbrella header that would pass the module verifier. I know that can be rather disruptive for client build chains though.

On our side, we could could look into providing Cocoapods with more guidance on the umbrella header generation step. We haven't felt a need to do this in past as the default generated one was sufficient.

Thanks for the deep dive! In regards to point 4, this sounds like something CocoaPods ought to resolve on their end to generate code that's compatible with the module verifier (and I suppose also enable the module verifier in their generated project so that Xcode won't warn about upgrading the Pods settings), does that sound right? Can certainly open an issue there to get that ball rolling (if no one else has already).

Good thoughts to move to SPM for Branch. Appreciate your insight!

I believe cocoapods does have the option for us to provide them the guidance necessary to pass that check. We didn't use it as it wasn't enforced by Xcode, and by default it still isn't enabled for ObjC projects. We might need to revisit that choice.

Ahh interesting, okay I'll go ahead and close this ticket. Thanks so much!