Use of undeclared identifier 'IterableAPI' when using Expo 45 and React 0.68.2

[diegorochawebdg]

After updating my app to use Expo 45/React 0.68.2, I have a lot of warnings from my Iterable imports and usage:

There are no information o docs about another way to import these files or troubleshoot when using new versions.

[shamilovtim]

This package is indeed incompatible with React Native 0.68 (Expo has nothing to do with it)

Related: https://github.com/Iterable/swift-sdk/issues/563. Could you please provide headers ASAP?

[shamilovtim]

@roninopf sorry for the ping but his has stopped us in our tracks and blocked several important features in our app. do you have an ETA for providing objective-c headers for us?

[roninopf]

@shamilovtim It's no worry, next time, you can get our attention faster with a ticket with your CSM!

I'll be immediately switching focus to fix this, I appreciate pointing out what exactly is missing here, it's already a good help to fixing this.

[roninopf]

@diegorochawebdg @shamilovtim Have you tried running with the recently released RN 0.69? I've tested on brand new RN projects with our SDK added, and it's working fine on 0.69 now, while the issue on 0.68 is still present. Would upgrading the base RN version be a good solution to this particular issue?

[shamilovtim]

@diegorochawebdg @shamilovtim Have you tried running with the recently released RN 0.69? I've tested on brand new RN projects with our SDK added, and it's working fine on 0.69 now, while the issue on 0.68 is still present. Would upgrading the base RN version be a good solution to this particular issue?

I don't think it's a React Native 0.68 vs 0.69 thing? My understanding is that Objective-C modules are simply incompatible with C++. The issue should still be present on 0.69 if your AppDelegate is a C++ file called AppDelegate.mm.

[roninopf]

If that was true, shouldn't have this been a problem since the very start? I just tested again on separate RN projects, and 0.69 is running fine, while I also still have the repro on 0.68. I haven't been able to look at what details changed between the RN versions, but it seems that there is a viable fix for this currently, that's all I'm suggesting.

[shamilovtim]

shouldn't have this been a problem since the very start

C++ integration into AppDelegate was added to (public) react native as of 0.68

I just tested again on separate RN projects, and 0.69 is running fine

Can you confirm AppDelegate is a .mm file?

[roninopf]

Can you confirm AppDelegate is a .mm file?

Yep, newly created projects on both 0.68 and 0.69 make AppDelegate.mm files.

[sregg]

I'm seeing the same problem after upgrading from 0.67 to 0.69. @shamilovtim did you find any workaround or do we have to wait for Iterable to expose the header files?

[shamilovtim]

I'm seeing the same problem after upgrading from 0.67 to 0.69.

@shamilovtim did you find any workaround or do we have to wait for Iterable to expose the header files?

We have to wait for them. C++ in the AppDelegate is not useable for us until they expose the headers.

[roninopf]

Still continuing to work on this, but it looks like something with placing the headers in the right spot is messed up and/or not enabled. This is a note for our team: the IterableSDK-Swift.h file generated with our framework has all the correct bindings for Objective-C, so once we figure out how to expose that to the new RN architecture, that should solve this.

[bobbravo2]

@roninopf wanted to see if we had an update / suggested workaround -- our team is leveraging this SDK -- and this is blocking an upgrade for us. Thanks in advance for any help / workarounds / things we might help test!

[awkpagong]

Same issue here. Is there any update? We would really like to be able to upgrade RN to 0.68.2 but we are unable to do so without this fix from Iterable.

[vbabenkoru]

Have you tried enabling modules in the Xcode project? See example here.

[shamilovtim]

Have you tried enabling modules in the Xcode project? See example here.

Yeah, that doesn't work. The incompatibility is a hard blocker, there is no choice but to provide the headers outside of a module.

[vbabenkoru]

@shamilovtim This fixes the issue in my test project. Are you sure you've added -fcxx-modules to Other C++ Flags for your app target for both Debug and Release?

[shamilovtim]

Yeah I've added that flag before. It causes compile incompatibilities with other unrelated packages. We don't use that flag in RN projects for that reason.

[huynhtastic]

Any update with this? This blocks our upgrade to any newer react-native versions, and we'd really like to be able to do so.

[spylefkaditis]

Is there any version of iterable that works with 0.68.2?

[vbabenkoru]

While we're still working on a solution that would work for everyone, we can suggest a workaround: you can create an Objective-C class that contains code that makes calls to the Iterable SDK, and use that class from the Objective-C++-based AppDelegate. The issue is that importing Swift modules is impossible in Objective-C++, and RN has switched to Objective-C++ for the AppDelegate, making Iterable SDK inaccessible from the AppDelegate directly. However, if you move the code interacting with the Iterable SDK to a separate Objective-C file, that should work as a way to work around the issue.

[vbabenkoru]

I've created a Gist with an implementation of this workaround you could use: https://gist.github.com/vbabenkoru/8518092ddd2500a3dda3c3e5bef36649

[shamilovtim]

In the past I've been able to get podspecs to spit out Swift headers for other SDKs. Here's an example of how I got a vendor's project to provide the headers:

diff --git a/node_modules/medallia-digital-rn/medallia-digital-rn.podspec b/node_modules/medallia-digital-rn/medallia-digital-rn.podspec
index ceaa514..5ba0ab0 100644
--- a/node_modules/medallia-digital-rn/medallia-digital-rn.podspec
+++ b/node_modules/medallia-digital-rn/medallia-digital-rn.podspec
@@ -10,12 +10,14 @@ Pod::Spec.new do |s|
   s.license      = package["license"]
   s.authors      = package["author"]
 
-  s.platforms    = { :ios => "9.0" }
+  s.platforms    = { :ios => "11.0" }
   s.source       = { :git => "https://github.com/avivMedallia/medallia-digital-rn.git", :tag => "#{s.version}" }
 
   
-  s.source_files = "ios/**/*.{h,m,mm}"
+  s.source_files = "ios/**/*.{h,m,mm,swift}"
   
-
-  s.dependency "React"
+  s.cocoapods_version = '>= 1.10.1'
+  s.vendored_frameworks = 'MedalliaDigitalSDK.xcframework'
+  s.pod_target_xcconfig = { 'DEFINES_MODULE' => 'YES' }
+  s.dependency "React-Core"
 end

I setup the dependent frameworks as vendored_frameworks, added swift to the source files, and added DEFINES_MODULE' => 'YES' . I think I tried this for Iterable but it didn't work but you might give it a shot.

[vbabenkoru]

Another, simpler workaround. I've generated the Objective-C compatibility header and posted it as a Gist here: https://gist.github.com/vbabenkoru/830bb645c50cc016dd0be158eff07dd8 Steps:

• Download the file above and add this IterableSDK-Swift.h file to your project
• Replace this line in your AppDelegate: @import IterableSDK; with #import "IterableSDK-Swift.h"

[vbabenkoru]

@shamilovtim Which libraries were having issues when using -fcxx-modules? We're trying to reproduce that issue in our test project.

[shamilovtim]

@shamilovtim Which libraries were having issues when using -fcxx-modules? We're trying to reproduce that issue in our test project.

Generally speaking we use a lot of libraries here at Shipt but some major (well known) ones are: react-navigation, react-native-screens, expo, react-native-reanimated, react-native-mmkv. My memory is fuzzy but I seem to remember that flag caused major compatibility issues. If I remember correctly there were so many issues that the flag was not even in a possibility to try to fix or use.

I'll see if I can circle back on this sometime in the next couple of weeks.

[vbabenkoru]

@shamilovtim Thank you! While the workarounds posted above work fine, we're still looking with a perfect long-term solution without workarounds. Looks like in the last few releases RN has fixed a few issues related to Swift/Objective-C++ code in recent versions, but I'm not sure if that fixes all the various mutually-exclusive compatibility issues introduced in RN 0.68...