Android - Why are notifications not working in the background or killed state?
Ensure that the MoEngage SDK is initialised in the main thread in the Android Native application class.
Sample code for initialisation - GitHub
Android - Why are callbacks not working in the background or killed state?
MoEngage callbacks must be registered in your app.js or app.ts, and after setting them up, you must call the MoEngage Plugin’s initialize () method. Read more about it here
Sample code for callbacks - GitHub
Android - Why are inapp/nudge deep links not working?
MoEngage SDK doesn’t handle in-app redirections by default except for rich landing pages; please refer to the documentation here. You must implement in-app click callback methods in your app.ts or app.js and call the moengage plugin initialise() method after you register for callbacks. In these callbacks, you will have to write code to extract navigation information and handle the redirection according to your preference. Callback documentation is given here.
Sample code for inapp/nudge callbacks - GitHub
Android - Why are inapp/nudge callbacks not working?
Refer to this documentation to set up inapp callbacks. Additionally, you must register the callbacks in your application’s app.js or app.ts, and after setting them up, you must call the MoEngage Plugin’s initialize () method.
Sample code for inapp/nudge callbacks - GitHub
Android - What is MoEDebuggerActivity?
The MoEngage SDK bundles the native MoEngage Android SDK, so your Android build includes MoEDebuggerActivity, a component that supports on-device SDK debugging. Refer to What is MoEDebuggerActivity? to understand what it does.
To remove it from your app, add the following to your Android project’s AndroidManifest.xml:
iOS - Why does the build fail with “Unsupported Swift Architecture” or “framework not found”?
Errors such as Unsupported Swift Architecture, framework 'MoEngageKMMConditionEvaluator' not found, and framework 'MoEngageRichNotification' not found usually mean that your Xcode project excludes the arm64 architecture or builds for architectures that the MoEngage iOS SDK doesn’t ship.
First, check the post_install hook in your Podfile for lines that set EXCLUDED_ARCHS or ONLY_ACTIVE_ARCH. This hook runs on every pod install and overrides the values you set in Xcode. To apply the correct settings to all Pods targets, use the following hook:
Next, open ios/YourApp.xcworkspace in Xcode, not the .xcodeproj. In the Project Navigator, select your app project and apply the following settings to every target, including the app target and the notification service and content extensions. Then select the Pods project and repeat these settings for its targets:
- Excluded Architectures (
EXCLUDED_ARCHS): Remove arm64 from this list. iPhone and iPad devices and Apple silicon simulators require arm64, and MoEngage iOS SDK v10.x.x and above ship only arm64 slices.
- Build Active Architecture Only (
ONLY_ACTIVE_ARCH): Set this to Yes so that Xcode builds only for the architecture of the selected device or simulator.
- Architectures (
ARCHS): Set this to ARCHS_STANDARD, or add arm64 to the list.
After you change these settings, select Product > Clean Build Folder in Xcode, run pod install from the ios directory, and build again.
Don’t set MoEngageKMMConditionEvaluator to Do Not Embed. This clears the framework-not-found error, but the framework evaluates trigger conditions for trigger-based in-app messages and push campaigns. Without it, those campaigns aren’t displayed.
If the build fails on arm64 in your CI pipeline but succeeds in Xcode on your machine, check the Xcode version on the build agent. Build agents often run an older version. Update the agent to a current stable version of Xcode, and at minimum to the version you build with locally.
Refer to Configuring Project for Architecture Compatibility for the full architecture configuration procedure, including Intel-based Mac limitations.
iOS - Why does the build fail with “Use of undeclared identifier ‘MoEngageInitializer’”?
This error occurs when the MoEngage import in ios/YourApp/AppDelegate.m or AppDelegate.mm is inside or after the #if RCT_NEW_ARCH_ENABLED block. If your app doesn’t use the React Native new architecture, this condition is false and the compiler skips the import, so MoEngageInitializer is never declared.
Move the import above the #if RCT_NEW_ARCH_ENABLED block:
Errors such as 'ReactNativeMoEngage/MoEngageInitializer.h' file not found after a plugin upgrade have two common causes:
- The header name changed across plugin versions. Older plugin versions use
MOReactInitializer.h and current versions use MoEngageInitializer.h. Update the import in ios/YourApp/AppDelegate.m or AppDelegate.mm to match the version you installed. Refer to iOS initialization for the current import and initialization code.
- The target can’t resolve the header path. In Build Settings for the
ReactNativeMoEngage target, check that $(inherited) is present in both Header Search Paths and Library Search Paths so that the target picks up the paths generated by CocoaPods. Also check that the ReactNativeMoEngage pod is listed in the Pods project after you run pod install. If the pod is missing, the install didn’t link the plugin.
To re-link the plugin after upgrading, run the following commands from your project root:
Then clean the build folder in Xcode and build again.
iOS (SPM) - Why does the build fail with a package not found error after adding or updating a dependency?
React Native’s SPM autolinking doesn’t run automatically. Navigate to the ios directory and run npx react-native spm again to regenerate the autolinking graph.
Run this command after a fresh clone, after resetting node_modules, and after any dependency change. Unlike CocoaPods, npx react-native run-ios doesn’t run it for you.
iOS (SPM) - Why does the app keep building against a stale version of the SDK?
In Xcode, select Product > Clean Build Folder, then File > Packages > Reset Package Caches. If the build still uses the old version, quit Xcode, delete ~/Library/Developer/Xcode/DerivedData, and run npx react-native spm again from the ios directory.
iOS (SPM) - Why does the build fail with a minimum deployment target error?
SPM requires a minimum deployment target of iOS 15.0, because React Native’s generated SPM packages require iOS 15. Open ios/<YourApp>.xcodeproj in Xcode, select the app target, and set General > Minimum Deployments to 15.0. Repeat this for any notification extension targets. The platform :ios line in the Podfile no longer applies under SPM. If your app must support iOS 13 or 14, use CocoaPods instead.
iOS (SPM) - Why does Xcode fail to resolve packages with a version conflict on apple-sdk?
The MoEngage React Native plugin already brings in the MoEngage iOS SDK (apple-sdk), including MoEngageRichNotification, at an exact version. This error means apple-sdk was also added to the Xcode project at a different version.
- If you use the extension integrator tool, remove the separately added
apple-sdk package in Xcode under Package Dependencies. You don’t need it.
- If your own extension code imports
MoEngageRichNotification, set the separately added apple-sdk package’s Dependency Rule to Exact Version, using the version the plugin uses. Update it every time you upgrade the MoEngage React Native packages.