In-App Messaging not running on capacitor for iOS

[DCGoD]

Bug report

CHECKLIST

• [x ] I have read the issue reporting guidelines

• [x] I confirm this is a suspected bug or issue that will affect other users

• [x] I have reproduced the issue using the example project or provided the necessary information to reproduce the issue.

• [x] I have read the documentation thoroughly and it does not help solve my issue.

• [x] I have checked that no similar issues (open or closed) already exist.

Current behavior:

Install the non CLI plugin normally then attempt to run using capacitor in Xcode. Using Cordova, IAM will fire up fine and execute normally as long as a non-cli build is used, which is expected. Has anyone successfully gotten Capacitor for iOS to work with this though? I have been successful with manually adding everything and modding for Android but still can't get iOS to actually use all of the frameworks yet. I know this isn't generally supported but where else can we even ask this question? Capacitor is heavily pushed now and unfortunately Firebase-X is still the only solution so here we are.

It's a clean project

Expected behavior:

In-App Messaging should load fine

Steps to reproduce:

Install the non CLI plugin normally for iOS then attempt to run using capacitor in Xcode

Screenshots

Environment information

• Cordova CLI version
  • cordova -v
  • 10.0.0
• Cordova platform version
  • cordova platform ls Installed platforms: android 9.0.0 ios 6.2.0 Available platforms: browser ^6.0.0 electron ^1.0.0 osx ^6.0.0
• Plugins & versions installed in project (including this plugin)
  • cordova plugin ls
• Dev machine OS and version, e.g.
  • OSX
    • sw_vers
  • Windows 10
    • winver

Runtime issue

• Device details
  • e.g. iPhone X, Samsung Galaxy S8, iPhone X Simulator, Pixel XL Emulator
• OS details
  • e.g. iOS 12.2, Android 9.0

Android build issue:

• Node JS version
  • node -v
• Gradle version
  • ls platforms/android/.gradle
• Target Android SDK version
  • android:targetSdkVersion in AndroidManifest.xml
• Android SDK details
  • sdkmanager --list | sed -e '/Available Packages/q'

iOS build issue:

• Node JS version
  • node -v
• XCode version

Related code:

insert any relevant code here such as plugin API calls / input parameters

Console output

console output

``` // Paste any relevant JS/native console output here ```

**Other information:**

[dpa99c]

This is a Cordova plugin and Capacitor is not a supported environment for it due to differences in the project structures and build systems. Therefore any issues you may have with integrating this plugin with Capacitor are out of scope here.

[DCGoD]

I do understand and have posted that. However, unfortunately, the ionic team pushes this as the Firebase plugin to use for Capacitor and here we are. Neither wants to acknowledge one another and nothing is getting done. Have you let the ionic team know to stop pushing this plugin since it's not compatible with Capacitor? That may at least mitigate some of the issues people are running into. I appreciate the plugin for sure and this specific plugin is the only reason I can't convert over 10+ ionic projects over to capacitor. All my other Cordova plugins works great. Again, thanks for the hard work and the response. ;-)

[dpa99c]

I find Ionic's claim that Capacitor works seamlessly with Cordova plugins to be a bit of a marketing ploy to encourage developers to move over from Cordova to Capacitor. Let's not forget that Cordova is maintained by a collection of commercially uninterested developers whereas Capacitor is very much a proprietary product of Ionic from which they make money. While it may be the case that simple Cordova plugins will work with Capacitor, more complex plugins such as this one or cordova-diagnostic-plugin (one of my others) will not work as they leverage Cordova-specific functionality such as hook scripts and plugin variables which are not supported by Capacitor.

I also find it bold of Ionic to suggest it is the responsibility of open-source Cordova plugin developers such as myself - who don't benefit commercially from their open-source work - to ensure their plugins work with an entirely different development framework than that for which they were designed, for the benefit of Ionic. It's a bit like Apple saying it's the responsibility of Android app developers to fix their Android apps because they crash when run in an emulated mode on an iPhone.

[DCGoD]

I have to be honest here, I completely agree with you @dpa99c. As much as I like the idea of Capacitor, unless they take on the responsibility of actually creating non-enterprise solutions to issues such as Firebase, it's destined to never catch the traction they expect.

My main issue with this plugin is the inability to use Firebase In App Messaging when in CLI mode. So if I have to manually bust out Xcode to do a build for iOS anyway, then Capacitor would be nice to switch to for other benefits. However, I am currently stuck in the middle with products right now. Either use the CLI build with Fastlane / CI and lose some Firebase-X features or build it all manually and get all features. If IAM was fixed in the CLI builds, I would gladly just stick with Cordova knowing I don't see both projects solving this issue anytime soon. Capacitor 3RC fix it all? haha, not likely.

[discovermoi]

I find Ionic's claim that Capacitor works seamlessly with Cordova plugins to be a bit of a marketing ploy to encourage developers to move over from Cordova to Capacitor. Let's not forget that Cordova is maintained by a collection of commercially uninterested developers whereas Capacitor is very much a proprietary product of Ionic from which they make money. While it may be the case that simple Cordova plugins will work with Capacitor, more complex plugins such as this one or cordova-diagnostic-plugin (one of my others) will not work as they leverage Cordova-specific functionality such as hook scripts and plugin variables which are not supported by Capacitor.

I also find it bold of Ionic to suggest it is the responsibility of open-source Cordova plugin developers such as myself - who don't benefit commercially from their open-source work - to ensure their plugins work with an entirely different development framework than that for which they were designed, for the benefit of Ionic. It's a bit like Apple saying it's the responsibility of Android app developers to fix their Android apps because they crash when run in an emulated mode on an iPhone.

[discovermoi]

Well,, w(e)ho are the victims,.? those who rely on these plugin systems that get into these tussles..