Unable to archive on XCode 12

[camdengilliam]

When trying to archive a RN iOS build with the Iterable RN SDK as a dependency in XCode 12, the archive process fails:

Undefined symbols for architecture arm64:
 "Swift._ArrayBuffer._copyContents(initializing: Swift.UnsafeMutableBufferPointer<A>) -> (Swift.IndexingIterator<Swift._ArrayBuffer<A>>, Swift.Int)", referenced from:
   generic specialization <Swift._ArrayBuffer<IterableSDK.InboxMessageViewModel>> of Swift._copyCollectionToContiguousArray<A where A: Swift.Collection>(A) -> Swift.ContiguousArray<A.Element> in libIterable-iOS-SDK.a(InboxViewControllerViewModel.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Note, we are able to run the app in Debug mode.

Environment:

xcode - 12.0.1
build target - iOS 11

[roninopf]

Hi @camdengilliam, we just released 1.0.15; can you try that and see if it fixes this? We saw this same error on the native side and fixed it there; it's now been updated in 1.0.15 which points to our latest iOS SDK release (2 days ago as of writing).

[bhandanyan-nomad]

Also experiencing this issue. Just tried v1.0.15 and the error persists.

xcode 12.0.1
build target - ios 12.0

[bradherman]

Same happening here

[bradherman]

Also updated my project and packages and now seeing this when pod installing:

[!] CocoaPods could not find compatible versions for pod "Iterable-iOS-SDK":
  In Podfile:
    Iterable-React-Native-SDK (from `../node_modules/@iterable/react-native-sdk`) was resolved to 1.0.15, which depends on
      Iterable-iOS-SDK (~> 6.2.13)

    Iterable-iOS-SDK

Specs satisfying the `Iterable-iOS-SDK, Iterable-iOS-SDK (~> 6.2.13)` dependency were found, but they required a higher minimum deployment target.

[roninopf]

Thanks for the feedback, clearly more investigation/fixing is required.

@bradherman can you open a new issue with that error? It looks like a separate error since dependencies should be the same as they have been for a long time.

[camdengilliam]

Hi @camdengilliam, we just released 1.0.15; can you try that and see if it fixes this? We saw this same error on the native side and fixed it there; it's now been updated in 1.0.15 which points to our latest iOS SDK release (2 days ago as of writing).

I can confirm that 1.0.15 is also not working for me - the same error persists.

[bradherman]

@roninopf... I deleted my node_modules folder, derived data folder, updated all packages in package.json, deintegrated pods, and then reinstalled them and that error cleared up. Still unable to compile/archive for release though. Builds for test devices, but archive fails with the same error others are seeing.

[bradherman]

@roninopf... any update on this? happy to help debug further if you need output from XCode or anything

[camdengilliam]

@roninopf... any update on this? happy to help debug further if you need output from XCode or anything

+1

[bhandanyan-nomad]

@roninopf... any update on this? happy to help debug further if you need output from XCode or anything

+1

+1

[roninopf]

@roninopf... any update on this? happy to help debug further if you need output from XCode or anything

@bradherman Thanks for the note; yes it's something we're working on right now. And yes, please do pass along Xcode output!

EDIT: As well as anyone else; the more debug reports, the better!

Apologies for the delay on the fix. We know this is an important fix.

[alex-a-pereira]

Thanks for being on top of this guys. I'm also seeing the same error message that OP posted - tried to remove node_modules, clear all caches, pod deintegrate, and re-install node modules/pods. like OP I'm able to make a debug build on my iphone with no problem, but trying to archive fails for the same reason.

I'm using xcode 12.1 and OSX 10.15.7 if that's helpful at all. Let me know if there's any more info you'd need!

Here's the command that it failed on (the step is Link MY_PROJECT (arm64)):

Ld /Users/MY_USER/Library/Developer/Xcode/DerivedData/MY_PROJECT_NAME-gatdiupzcbeitrcrvuukggznzjse/Build/Intermediates.noindex/ArchiveIntermediates/MY_PROJECT_NAME/IntermediateBuildFilesPath/MY_PROJECT_NAME.build/Release-iphoneos/MY_PROJECT_NAME.build/Objects-normal/arm64/Binary/MY_PROJECT_NAME normal arm64 (in target 'MY_PROJECT_NAME' from project 'MY_PROJECT_NAME')

with error printed to console of:

Showing Recent Messages
Undefined symbol: Swift._ArrayBuffer._copyContents(initializing: Swift.UnsafeMutableBufferPointer<A>) -> (Swift.IndexingIterator<Swift._ArrayBuffer<A>>, Swift.Int)

[nicksnietka]

+1

[alex-a-pereira]

Additionally I've attempted to downgrade xcode to 11.7, and roll back iterable SDK to 1.0.12. Unfortunately I'm getting the same compile error as described above ^^

Should note that we haven't had a successful archive yet - we've just started attempting last week. So I can't confirm if xcode 12 or iterable-rn-sdk 1.0.12 or 1.0.15 is what's causing the issue

[roninopf]

Hi all, thanks for your extreme patience; to give an update, we've identified that the issue is in the configuration of the iOS SDK not being a static library. We're continuing to work on this (of course), and we'll post about it when we have more updates or a new release.

Thank you again for your patience and constructive replies!

[roninopf]

Hi again everybody! While we're still working on making the iOS SDK compatible, we do have a POSSIBLE workaround depending on what dependencies you're currently using.

We've figured out why this issue came to be; in 0.63, React Native introduced some new libraries that are turned on by default in the Podfile, but block the usage of use_frameworks!. Turns out, our SDK needs this in the Podfile for it to work, but at the same time, Flipper (the newly included library) can't have it on. We completely missed this.

So, if you're using Flipper actively during development, you can leave it on, but for archiving, comment it out, add use_frameworks!, run pod install, and then archive. We've been able to confirm this leads to a built archive in our test project.

We'll continue to leave this issue report open until a more permanent fix is completed, but I very much hope this will unblock releasing for many of you.

[blackbing]

+1

[blackbing]

@roninopf I received error message if I turn off flipper and set use_frameworks!

[!] Unable to integrate the following embedded targets with their respective host targets (a host target is a "parent" target which embeds a "child" target like a framework or extension):

- App (false) and notificationServiceExtension (true) do not both set use_frameworks!.

still not work.

[roninopf]

@blackbing Can you post what the Podfile looks like? Feel free to make a request through a CSM if you don't want to share it publicly.

[blackbing]

@roninopf ok, here is our Podfile

platform :ios, '11.0'
require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'


target 'verybuy' do
  config = use_native_modules!
  use_react_native!(:path => config["reactNativePath"])

  pod 'SensorsAnalyticsSDK', '2.0.2'

  pod 'FirebaseInAppMessagingDisplay', :path => '../node_modules/firebase-inappmessaging-custom-display'
  # Enables Flipper.
  #
  # Note that if you have use_frameworks! enabled, Flipper will not work and
  # you should disable these next few lines.
  # use_flipper!
end

target 'notificationServiceExtension' do
  pod 'Firebase/Messaging'
  pod 'Iterable-iOS-AppExtensions'
end

post_install do |installer|
  # flipper_post_install(installer)
  # Fix 'protobuf/Any.pbobjc.h' file not found #6803
  # https://github.com/protocolbuffers/protobuf/issues/6803#issuecomment-565606351
  system('cd Pods/Headers/Public; ln -s Protobuf protobuf')

  installer.pods_project.targets.each do |target|
    
    # Because: https://github.com/luggit/react-native-config/issues/365
    if target.name == 'react-native-config'
      phase = target.project.new(Xcodeproj::Project::Object::PBXShellScriptBuildPhase)
      phase.shell_script = "cd ../../"\
      " && RNC_ROOT=./node_modules/react-native-config/"\
      " && export SYMROOT=$RNC_ROOT/ios/ReactNativeConfig"\
      " && ruby $RNC_ROOT/ios/ReactNativeConfig/BuildDotenvConfig.ruby"
      
      target.build_phases << phase
      target.build_phases.move(phase,0)
    end
 
  end
end

[robotnoises]

Hi all, so we have static dependencies (Firebase). Am I understanding correctly that the use of static libraries means we can't use the workaround?

[bradherman]

How's this coming along? We've been paying thousands of dollars a month for a product we can't use

[rnike]

We have the same issue here, also using Firebase

[roninopf]

Hi all, I apologize for the delays in fixing this. We think we have a fix which is as follows:

• open the iOS project/workspace project file
• select the application target on the left side of the project filee
• go to the Build Settings tab
• toggle Levels on
• search for Library Search Paths
• double click the project level text box that applies to both build configurations
• remove "$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)" (NOTE: not the .../lib/swift/... entry; that's the one that's needed!)

We've tested this on our minimal project that reproduced this issue, and archiving was successful, with the default React Native 0.63 project (and a blank Swift file and bridging header).

Please let us know if this works, and if this does NOT work, please file a ticket with your CSM so we can diagnose your specific setup.

Lastly, I'd like to add my personal apology; I was the primary driver of trying to solve this issue, and any delays were purely on me, not anyone else at Iterable.

[camdengilliam]

Hi all, I apologize for the delays in fixing this. We think we have a fix which is as follows:

• open the iOS project/workspace project file
• select the application target on the left side of the project filee
• go to the Build Settings tab
• toggle Levels on
• search for Library Search Paths
• double click the project level text box that applies to both build configurations
• remove "$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)" (NOTE: not the .../lib/swift/... entry; that's the one that's needed!)

We've tested this on our minimal project that reproduced this issue, and archiving was successful, with the default React Native 0.63 project (and a blank Swift file and bridging header).

Please let us know if this works, and if this does NOT work, please file a ticket with your CSM so we can diagnose your specific setup.

Lastly, I'd like to add my personal apology; I was the primary driver of trying to solve this issue, and any delays were purely on me, not anyone else at Iterable.

Thanks for tracking this down! I will post back here if this solution works for me.

[rnike]

@roninopf The solution works for us, we finally can complete our task upgrading React Native, thanks a lot.

[kknd113]

@roninopf Thanks for the solution it works for us
@camdengilliam Thanks for raising the issue

Perhaps this workaround should be temporarily included in iterable react native sdk doc?

[roninopf]

@roninopf Thanks for the solution it works for us
@camdengilliam Thanks for raising the issue

Perhaps this workaround should be temporarily included in iterable react native sdk doc?

Definitely, I'm planning on adding all of our relevant findings on RN to our docs soon, including this. We're also thinking it might actually not be temporary due to how RN projects get setup.

[roninopf]

Hi all, we've gotten our support article updated for this specific issue, so with that, I'll be closing this issue. I've been gathering more info on different setups and how to resolve them, so, over time, you'll see more instructions on how to fix possible errors that arise from certain setups.

As always, if you have any questions for us, please feel free to file a ticket with your CSM (especially if it's an issue/question specific to your configuration, as it's easier to communicate and diagnose that way), or report them here.

[TuanDuongNguyen]

Hi all, I apologize for the delays in fixing this. We think we have a fix which is as follows:

• open the iOS project/workspace project file
• select the application target on the left side of the project filee
• go to the Build Settings tab
• toggle Levels on
• search for Library Search Paths
• double click the project level text box that applies to both build configurations
• remove "$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)" (NOTE: not the .../lib/swift/... entry; that's the one that's needed!)

We've tested this on our minimal project that reproduced this issue, and archiving was successful, with the default React Native 0.63 project (and a blank Swift file and bridging header).

Please let us know if this works, and if this does NOT work, please file a ticket with your CSM so we can diagnose your specific setup.

Lastly, I'd like to add my personal apology; I was the primary driver of trying to solve this issue, and any delays were purely on me, not anyone else at Iterable.

it's not working for me, Xcode 12.5

[Zestpond]

Hi all, I apologize for the delays in fixing this. We think we have a fix which is as follows:

• open the iOS project/workspace project file
• select the application target on the left side of the project filee
• go to the Build Settings tab
• toggle Levels on
• search for Library Search Paths
• double click the project level text box that applies to both build configurations
• remove "$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)" (NOTE: not the .../lib/swift/... entry; that's the one that's needed!)

We've tested this on our minimal project that reproduced this issue, and archiving was successful, with the default React Native 0.63 project (and a blank Swift file and bridging header).

Please let us know if this works, and if this does NOT work, please file a ticket with your CSM so we can diagnose your specific setup.

Lastly, I'd like to add my personal apology; I was the primary driver of trying to solve this issue, and any delays were purely on me, not anyone else at Iterable.

Thanks, worked for me