---
title: Installation
description: Quick start guide for installing and running on React Native.
---

## 1. Install from npmjs.com

Install the package at the root of your React Native project with [npm](https://www.npmjs.com/) or [Yarn](https://yarnpkg.com/):

```bash
# Using npm
npm install --save react-native-notify-kit

# Using Yarn
yarn add react-native-notify-kit
```

## 2. Configuration Changes

### 2a. Android API versions

The library keeps `minSdk = 24` (Android 7.0) and `targetSdk = 35`. Its **compile SDK baseline and fallback are 35**. During configuration it reads `rootProject.ext.compileSdkVersion` and uses the higher of that value and 35. For example, host values 35, 36 and 37 select library compile SDKs 35, 36 and 37; host 34 selects library 35 without changing the host. This does not make an app with compile SDK 34 build-compatible with dependencies that require 35.

For a conventional React Native host, expose the SDK selected for your app before the library is evaluated:

```gradle
buildscript {
  ext {
    compileSdkVersion = 35 // Use a higher SDK when your app/toolchain requires it.
    targetSdkVersion = 35
    minSdkVersion = 24
    // Other host properties...
  }
  // Other buildscript configuration...
}
```

Positive integer API levels in the 32-bit integer range, decimal strings such as `"36"`, and stable identifiers such as `"android-36"` are accepted. Numeric values must be exactly integral; fractions are never truncated. A missing property silently selects 35. Present but unusable values (including `null`, booleans, previews and overflow) select 35 with a diagnostic warning. SDK installation, AGP and compilation errors still fail the build.

This convention does not discover SDK values held only in the app's Android DSL, version catalogs, convention plugins or preview configuration. Non-standard hosts must expose a usable `rootProject.ext.compileSdkVersion` before this module is evaluated to select a higher SDK. The library does not mutate host properties or require SDK 37. It explicitly sets `aarMetadata.minCompileSdk = 35` to preserve the dependency baseline even with [AGP 9, which otherwise defaults the AAR consumer minimum to the compile SDK](https://developer.android.com/build/releases/agp-9-0-0-release-notes#behavior-changes). Compiling with 37 does not by itself require consumers to compile with 37; dependencies may impose their own minimums.

The repository's React Native 0.85.3 bare smoke app is configured with `compileSdkVersion = 36`, `targetSdkVersion = 36`, and Gradle wrapper 9.3.1. These are the smoke target's values, not universal consumer requirements. Separate RN 0.88/SDK 37 build and selected device checks are described in [Environment Support](/react-native/environment-support#react-native-088-validation); they do not establish full RN 0.88 support.

### 2b. Gradle versions

Android API 35 and the published AAR metadata of WorkManager 2.11.1 require **AGP 8.6.0 or newer**. AGP 8.6 requires **Gradle 8.7 or newer**. This is a lower bound for that baseline, not a guarantee for every React Native/Gradle/AGP combination.

Higher inherited SDKs require newer tools: API 36 requires AGP 8.9.1 or newer; API 37 requires AGP 9.1.1 or newer. Select the matching Gradle version from the [official Android compatibility tables](https://developer.android.com/build/releases/about-agp), and satisfy your React Native template and dependency requirements as well. Neither AGP 8.2.2 nor an unspecified Gradle 8.x is a supported universal baseline. The library does not update the consumer's AGP, Gradle wrapper or Kotlin version.

The legacy standalone classpath declaration is aligned to AGP 8.6.0, but `packages/react-native/android` is **not a complete supported standalone build**: its settings do not wire the required plugins or a consumer `:app` project. Validate the module through a configured React Native consumer; changing this declaration alone does not establish standalone support.

### 2c. Java version

The library is compiled with Java 17 (`sourceCompatibility = VERSION_17`, `targetCompatibility = VERSION_17`). Android builds require JDK 17 or newer. JDK 17 and JDK 21 are the validated baselines. Newer JDK versions are not blocked by NotifyKit, but compatibility depends on the consumer Android toolchain: Gradle, Android Gradle Plugin, Kotlin, React Native, and Expo/EAS build images where applicable. JDK 8 and 11 are **not** supported.

For contributors running the library's Robolectric 4.17 tests, API 36/37 simulations require a JDK 21 test JVM; the Java/Kotlin targets remain 17. See [Android Unit Test Toolchain](/react-native/environment-support#android-unit-test-toolchain) for the API 24 default and JDK 17 test selection. This is separate from consumer build and Android runtime requirements.

### 2d. React Native and New Architecture

- **React Native**: `>=0.73` (peer dependency).
- **New Architecture**: required. The bridge is a TurboModule; the library does not support the old bridge. Ensure `newArchEnabled=true` in `android/gradle.properties` and `RCT_NEW_ARCH_ENABLED=1` in your iOS build environment (enabled by default in RN 0.76+).
- **Current development target**: React Native 0.85.3.

### 2e. iOS deployment target

The iOS pod targets **iOS 15.1+** (`RNNotifee.podspec`). Make sure your app's iOS deployment target is 15.1 or higher.

## 3. Autolinking with React Native

React Native 0.60+ provides [autolinking](https://github.com/react-native-community/cli/blob/master/docs/autolinking.md), so no further manual linking is required. Rebuild your project after install:

```bash
# For iOS
cd ios/ && pod install --repo-update
npx react-native run-ios

# For Android
npx react-native run-android
```

## 4. Optional: iOS Notification Service Extension

If you plan to use FCM with remote push, you'll also want a Notification Service Extension (NSE) on iOS so rich payloads (attachments, interruption level, custom actions) render correctly when the app is in the background or killed.

The library ships a CLI command that scaffolds the target for you:

```bash
npx react-native-notify-kit init-nse
```

This patches your `.pbxproj` and `Podfile` automatically and generates a `NotifyKitNSE` target using `NotifeeExtensionHelper` for push enrichment. See [FCM Mode](/fcm-mode) for the full setup and server payload details.

## Miscellaneous

### Expo Support

The library works with Expo via the bare workflow or custom-dev-client (not Expo Go — notifications require native code).

For Android local scheduled triggers, Expo CNG/prebuild projects receive NotifyKit's library
manifest entries through the normal Android manifest merge. That includes
`android.permission.RECEIVE_BOOT_COMPLETED`, `android.permission.SCHEDULE_EXACT_ALARM`,
`app.notifee.core.RebootBroadcastReceiver`, `app.notifee.core.NotificationAlarmReceiver`, and
`io.invertase.notifee.NotifeeInitProvider`. You normally do not need a custom Expo config plugin
for reboot recovery. A custom boot-receiver plugin can be risky if it replaces the library's
receiver declaration or intent filters instead of preserving the merged entries. When diagnosing
scheduled trigger recovery, inspect the final merged manifest generated by the Android build, not
only `app.json`, `app.config.js`, or `android/app/src/main/AndroidManifest.xml`.

Override the Android SDK versions through `expo-build-properties` when your Expo SDK and React Native template require it:

```bash
npx expo install expo-build-properties
```

Then in your `app.json` / `app.config.js`, keep values at or above the library baseline and use newer values when required by your Expo SDK:

```js
{
  "name": "my app",
  "plugins": [
    [
      "expo-build-properties",
      {
        "android": {
          "compileSdkVersion": 35,
          "targetSdkVersion": 35,
          "minSdkVersion": 24
        }
      }
    ]
  ]
}
```

Run `npx expo prebuild` and rebuild your app as described in the ["Adding custom native code"](https://docs.expo.dev/workflow/customizing/) guide.

For EAS Build, use an image that ships a supported JDK, preferably one of the validated baselines (JDK 17 or JDK 21). In `eas.json`:

```json
{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "android": {
        "image": "latest"
      }
    }
  }
}
```

`"image": "latest"` resolves to the current Ubuntu image with JDK 17 as of Expo SDK 50+. See the [EAS Build server infrastructure docs](https://docs.expo.dev/build-reference/infrastructure/) for the full list of images.