react-native-notify-kit 10.4.0 - Expo CNG support for development builds

[marcocrupi]

Hi everyone,

I’m happy to share that react-native-notify-kit now includes official Expo CNG / prebuild support for development builds.

This release is an important step for the project because it makes NotifyKit much easier to use in modern Expo apps that rely on native modules and generated native projects.

What’s new

Expo CNG / prebuild support

react-native-notify-kit now supports Expo CNG / prebuild / development builds.

Expo Go is not supported, because NotifyKit requires native modules and native notification capabilities.

iOS FCM Mode Notification Service Extension automation

On iOS, the config plugin can generate and wire the Notification Service Extension required by NotifyKit FCM Mode.

This includes the extension target, generated files, Podfile integration, EAS app extension configuration, and native project wiring during prebuild.

This removes a large amount of manual Xcode setup for Expo development-build apps.

Android foreground service config plugin

On Android, the config plugin now supports explicit foreground service manifest configuration.

For example, Expo apps can configure NotifyKit’s foreground service type through app.config.ts, instead of manually editing generated native files.

The shortService path was validated at runtime on a physical Android device.

Android Expo FCM smoke validation

The Expo smoke app now validates Android FCM Mode using data-only Firebase messages, RNFirebase, and notifee.handleFcmMessage.

The validation covered:

• FCM registration
• foreground delivery
• background delivery
• background notification tap
• killed best-effort behavior, excluding force-stop

Better Expo smoke coverage

The Expo smoke app now includes stronger runtime markers and validation paths for Android and iOS, including foreground/background events, FCM delivery, tap observability, and foreground service runtime checks.

What this release does not claim

This release does not add Expo Go support.

It also does not claim that every advanced Android capability is automatically configured. Exact alarms, full-screen intents, additional foreground service types, and Google Play policy-sensitive options remain explicit app-level concerns and future work.

Firebase and RNFirebase setup remain the responsibility of the app. NotifyKit integrates with that setup, but does not own it.

Why this matters

expo-notifications remains the simplest Expo-first solution for many apps.

react-native-notify-kit is aimed at apps that need more advanced native notification capabilities, direct FCM control, iOS Notification Service Extensions, Android foreground services, rich notifications, persistent notifications, and a Notifee-compatible API.

In short:

Use expo-notifications when you want the simplest Expo notification setup.

Use react-native-notify-kit when your Expo CNG app needs more native notification power.

Thanks to everyone following the project and testing the fork. Feedback from real Expo apps will be extremely useful for shaping the next releases.

[rabbihossain]

I have upgraded my project from sdk 53 to expo sdk 55.
I have used your recent expo CNG instruction and wrote the configs in app.json. [added the plugins section of app.json below. ]

"plugins": [
      "expo-font",
      "@react-native-firebase/app",
      "@react-native-firebase/messaging",
      [
        "expo-build-properties",
        {
          "ios": {
            "useFrameworks": "static"
          }
        }
      ],
      [
        "expo-image-picker",
        {
          "photosPermission": "The app accesses your photos to let you share them with your friends.",
          "cameraPermission": "The app accesses your camera to let you share them with your friends"
        }
      ],
      [
        "expo-tracking-transparency",
        {
          "userTrackingPermission": "We need your permission to track in order to show you more relevant products and offers."
        }
      ],
      "expo-sqlite",
      [
        "react-native-fbsdk-next",
        {
          "appID": "1503040187419396",
          "clientToken": "004bdfbde818aa5497e167008993dfbe",
          "displayName": "Shajgoj",
          "advertiserIDCollectionEnabled": false,
          "autoLogAppEventsEnabled": false,
          "isAutoInitEnabled": true,
          "iosUserTrackingPermission": "This identifier will be used to deliver personalized ads to you."
        }
      ],
      [
        "expo-splash-screen",
        {
          "image": "./assets/icons/adaptive-icon.png",
          "backgroundColor": "#000000",
          "imageWidth": 220
        }
      ],
      "expo-image",
      ["expo-asset", { "assets": ["./assets/icons/ic_stat_name.png"] }],
      "react-native-quick-crypto",
      [
        "react-native-notify-kit",
        {
          "ios": {
            "notificationServiceExtension": true
          }
        }
      ]
    ]

If I run npx expo prebuild --clean && then run npx expo run:ios, I can run the app on my local machine running xcode 26.4.

If I run npx eas build, expo's cloud eas build failes with Fastlane error . Error. messsage like this

 Compiling react-native-notify-kit Pods/RNNotifee » NotifeeApiModule.mm 
 ❌  (node_modules/react-native-notify-kit/ios/RNNotifee/NotifeeApiModule.h:21:9)
 
   19 | #import <NotifeeSpec/NotifeeSpec.h>
   20 | #import <React/RCTEventEmitter.h>
   21 | #import "NotifeeCore.h"|         ^ 'NotifeeCore.h' file not found
   22 | 
   23 | @interface NotifeeApiModule : RCTEventEmitter <NativeNotifeeModuleSpec, NotifeeCoreDelegate>
   24 | Compiling react-native-notify-kit Pods/RNNotifee » RNNotifee-dummy.m

What am I missing here in this configs? Or is this a bug, I am not sure. I am using the latest firebase libraries and also latest version of this .

[marcocrupi]

Hi,

thanks again for testing this with precompiled modules enabled. That second error was very useful.

I investigated it and found another NotifyKit-side header visibility issue, similar to the one fixed in 10.4.1, but in a different file.

In 10.4.1, NotifeeApiModule.mm still had this import:

#import "NotifeeCore+UNUserNotificationCenter.h"

That can work when building from source because the local CocoaPods/Xcode header search paths are more permissive, but it can fail with Expo/EAS precompiled modules where the header layout is stricter.

I released react-native-notify-kit@10.4.2 with a fix for this:

#import "../NotifeeCore/NotifeeCore+UNUserNotificationCenter.h"

So both reported header visibility issues are now addressed:

1. NotifeeCore.h missing from NotifeeApiModule.h - fixed in 10.4.1
2. NotifeeCore+UNUserNotificationCenter.h missing from NotifeeApiModule.mm - fixed in 10.4.2

10.4.2 also includes a fix for the NotifyKitNSE version metadata issue you reported. The generated extension now mirrors the parent Expo app version/build metadata instead of staying on 1.0.

I also hardened the Expo iOS NSE Podfile integration so the generated NotifyKitNSE target mirrors the host app use_frameworks! linkage. For example, if the host app uses:

{
  "ios": {
    "useFrameworks": "static"
  }
}

the generated NotifyKitNSE target now uses static framework linkage as well.

I validated 10.4.2 locally with:

• Expo CNG
• RNFirebase app + messaging
• ios.useFrameworks: "static"
• NotifyKit NSE enabled
• EXPO_USE_PRECOMPILED_MODULES=1
• clean iOS prebuild
• CocoaPods install
• physical iPhone build/install

I did not run an EAS iOS cloud build on my side yet, so your EAS result is still very valuable.

Could you please try react-native-notify-kit@10.4.2 with precompiled modules enabled and without the buildReactNativeFromSource workaround?

The most useful test would be your original EAS config, with:

• EXPO_USE_PRECOMPILED_MODULES not disabled
• buildReactNativeFromSource removed or set back to default
• your existing ios.useFrameworks: "static" config

If it still fails, please send the new first error. If the build gets past RNNotifee, that would confirm the NotifyKit header visibility path is fixed.

[rabbihossain]

The most useful test would be your original EAS config, with:

• EXPO_USE_PRECOMPILED_MODULES not disabled
• buildReactNativeFromSource removed or set back to default
• your existing ios.useFrameworks: "static" config

Did exactly this and the EAS build was successfull.

[marcocrupi]

Great, thank you for confirming this.

That is very useful feedback.

So, for your setup, react-native-notify-kit@10.4.2 now works with:

• Expo SDK 55
• EAS iOS cloud build
• precompiled modules enabled
• buildReactNativeFromSource removed / default
• ios.useFrameworks: "static"
• RNFirebase
• NotifyKit NSE enabled

This confirms that the two NotifyKit-side iOS header visibility issues reported in this thread are fixed:

1. NotifeeCore.h missing from NotifeeApiModule.h, fixed in 10.4.1
2. NotifeeCore+UNUserNotificationCenter.h missing from NotifeeApiModule.mm, fixed in 10.4.2

It also confirms that the EAS precompiled-modules path no longer requires the buildReactNativeFromSource workaround for this NotifyKit issue.

Thanks again for testing this on a real production Expo/RNFirebase setup. This helped harden the Expo CNG support a lot.

If you still see the NotifyKitNSE version notice or any runtime issue with FCM/NSE behavior, feel free to send the exact warning/log and I will look into that separately.

[rabbihossain]

Also can you confirm why I cannot run npx expo prebuild. I always have to prebuild using npx expo prebuild --clean . Is this error happens by design or need something to be changed in the config plugin you created.

Error: [ios.dangerous]: withIosDangerousBaseMod: [react-native-notify-kit] Refusing to overwrite existing app-path/ios/NotifyKitNSE/Info.plist. Delete it or make it match the generated NotifyKit NSE template.
Error: [ios.dangerous]: withIosDangerousBaseMod: [react-native-notify-kit] Refusing to overwrite existing app-path/ios/NotifyKitNSE/Info.plist. Delete it or make it match the generated NotifyKit NSE template.
    at writeFileIfMissingOrIdentical (app-path/node_modules/react-native-notify-kit/plugin/build/ios/withNotifyKitIosNseFiles.js:101:13)
    at writeNotifyKitIosNseFiles (app-path/node_modules/react-native-notify-kit/plugin/build/ios/withNotifyKitIosNseFiles.js:52:3)
    at app-path/node_modules/react-native-notify-kit/plugin/build/ios/withNotifyKitIosNseFiles.js:27:7
    at action (app-path/node_modules/@expo/config-plugins/build/plugins/withMod.js:199:29)
    at interceptingMod (app-path/node_modules/@expo/config-plugins/build/plugins/withMod.js:104:27)
    at action (app-path/node_modules/@expo/config-plugins/build/plugins/withMod.js:204:14)
    at async interceptingMod (app-path/node_modules/@expo/config-plugins/build/plugins/withMod.js:104:21)
    at async action (app-path/node_modules/@expo/config-plugins/build/plugins/createBaseMod.js:60:21)
    at async interceptingMod (app-path/node_modules/@expo/config-plugins/build/plugins/withMod.js:104:21)
    at async evalModsAsync (app-path/node_modules/@expo/config-plugins/build/plugins/mod-compiler.js:206:25)

[marcocrupi]

Thanks for the report.

This is a different issue from the EAS/precompiled-modules build failure.

npx expo prebuild is incremental and reuses the existing ios/ directory, while:

npx expo prebuild --clean

regenerates the native project from scratch.

The NotifyKit config plugin intentionally refuses to overwrite existing NSE files when they do not match the generated template, because blindly overwriting native files could destroy manual changes.

In 10.4.2, NotifyKit already allows the generated NotifyKitNSE/Info.plist to be updated when the only difference is the generated version/build metadata. So if you still hit this error, your existing:

ios/NotifyKitNSE/Info.plist

probably differs in another way, for example formatting, key order, missing newline, an older template shape, or a custom native change.

For now, the safe workaround is to delete only the generated NSE folder and run prebuild again:

rm -rf ios/NotifyKitNSE
npx expo prebuild --platform ios

Or, if your native iOS folder is fully generated and you do not keep manual native changes there, using:

npx expo prebuild --clean

is also fine.

Could you please share your current:

ios/NotifyKitNSE/Info.plist

That will help me understand whether this is a harmless old/generated plist that NotifyKit can migrate automatically, or whether it contains custom native changes that the plugin should continue to protect.

If it is only a formatting/old-template case, I can improve the plugin so normal incremental npx expo prebuild handles it more gracefully without requiring --clean.