react-native-intune 0.1.0-alpha.1

package/LICENSE

@@ -0,0 +1,27 @@
+MIT License
+
+Copyright (c) 2026 Artashes Bayazetyan and react-native-intune contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+---
+
+This licence covers the code in this repository only. It does not cover the
+Microsoft Intune App SDK, which this project wraps and does not include. See
+NOTICE for what belongs to Microsoft and under which terms.

package/NOTICE

@@ -0,0 +1,49 @@
+# NOTICE
+
+`react-native-intune` is MIT licensed (see LICENSE) and covers **only the code in this
+repository**. It wraps Microsoft software that it neither includes nor relicenses.
+
+## The Microsoft Intune App SDK is not part of this package
+
+The SDK is Microsoft's, distributed under Microsoft's own licence terms, and is **not
+included in this repository or in the published npm tarball**.
+
+`vendor/` is gitignored and excluded from `package.json`'s `files`. `scripts/fetch-sdks.mjs`
+downloads the pinned version at install time, from Microsoft's own releases, verifying a
+recorded sha256 per artifact. Nothing about that arrangement grants anyone rights they did
+not already have from Microsoft.
+
+Using this package therefore means accepting Microsoft's terms for the SDK. They arrive
+alongside the download:
+
+| File | What it covers |
+|---|---|
+| `vendor/ios/Microsoft License Terms Intune App SDK for iOS.pdf` | the iOS SDK |
+| `vendor/android/Microsoft License Terms Intune App SDK for Android.pdf` | the Android SDK |
+| `vendor/ios/REDIST.txt` | which iOS binaries may be redistributed in *your* app |
+| `vendor/ios/ThirdPartyNotices.txt` | the SDK's own third-party attributions |
+
+Read `REDIST.txt` before shipping: it names the frameworks you are permitted to
+redistribute inside an application, which is a narrower permission than redistributing the
+SDK itself. This project relies on that permission and does not extend it.
+
+## Microsoft Authentication Library (MSAL)
+
+MSAL is a declared dependency rather than a vendored one — the pod on iOS, the Gradle
+artifact on Android — and is fetched from public registries in the normal way. It is
+Microsoft's, under the MIT licence, Copyright (c) Microsoft Corporation.
+
+The version is pinned in `sdk-versions.json`. The reason is in SPEC §3.1: the Intune SDK
+does not carry its own MSAL, it drives the application's, so two MSAL versions in one
+binary is a failure nobody debugs quickly.
+
+## Trademarks
+
+Microsoft, Intune, Microsoft Entra, Microsoft 365 and Azure are trademarks of the
+Microsoft group of companies. They appear here only to describe what this package
+integrates with.
+
+**This project is not affiliated with, endorsed by, or supported by Microsoft.** Microsoft
+publishes no React Native support for the Intune App SDK, which is why this package exists
+and why a meaningful part of its behaviour was established by reading the SDK's own headers
+and running it on real devices rather than from documentation.

package/README.md

@@ -0,0 +1,164 @@
+# react-native-intune
+
+Microsoft Intune app protection for React Native — **app-level data protection, not device
+management.** MSAL with broker support is included, so sign-in and enrollment work without
+a second SDK.
+
+**[Documentation](https://bayazetyan.github.io/react-native-intune/)** ·
+[Getting started](https://bayazetyan.github.io/react-native-intune/docs/getting-started) ·
+[Traps](https://bayazetyan.github.io/react-native-intune/docs/notes/traps) ·
+[API reference](https://bayazetyan.github.io/react-native-intune/docs/reference)
+
+> **Status: pre-alpha.** Implemented and verified on real devices against a real tenant,
+> but not released. Expect breaking changes until 1.0.
+
+*Not affiliated with, endorsed by, or sponsored by Microsoft. Microsoft, Intune and Entra
+are trademarks of the Microsoft group of companies.*
+
+## What it does
+
+An IT administrator in any customer tenant can target your app from their Intune console
+and enforce an App Protection Policy on it: a PIN or biometric unlock, copy-paste
+restrictions between managed and unmanaged apps, screenshot blocking, save-as and open-from
+restrictions, encryption at rest, conditional launch rules, and a selective wipe that
+removes corporate data and leaves personal data alone.
+
+**The device does not need to be enrolled in Intune.** That is the point of MAM — the
+boundary is drawn around one app, and the employee's phone stays theirs.
+
+## What it is not
+
+It cannot do device management, and no configuration changes that: the SDK runs inside your
+app's sandbox.
+
+| | |
+|---|---|
+| App-level PIN, copy-paste, screenshots, selective wipe | ✅ This library |
+| Full device wipe, device passcode, disk encryption | ❌ The customer's MDM |
+| Per-app VPN, network inspection, kiosk mode, inventory | ❌ The customer's MDM |
+
+If someone asks whether this gives them "Intune device control", the answer is no. It makes
+your app a first-class Intune-managed app; their MDM handles the device.
+
+## Licensing — read before installing
+
+**This library is MIT. The Microsoft Intune App SDK is not, and is not included here.**
+
+The SDK is downloaded from Microsoft's own repositories by `fetch-sdks`. It is never
+committed to this repository and never published in the npm package. Microsoft's terms
+apply to it, they are separate from ours, and **reviewing and accepting them is your
+responsibility**:
+
+- [Intune App SDK for iOS](https://github.com/msintuneappsdk/ms-intune-app-sdk-ios)
+- [Intune App SDK for Android](https://github.com/microsoftconnect/ms-intune-app-sdk-android)
+
+[`NOTICE`](./NOTICE) is the full statement.
+
+## Requirements
+
+| | |
+|---|---|
+| React Native | 0.74+, **New Architecture required** |
+| iOS | **17.0+, Xcode 26+** — MAM SDK 21.x is built against them |
+| Android | minSdk 24, Java 17, Gradle 8.11.1 / AGP 8.9.1 / Kotlin 2.1.21 |
+| On the device | Company Portal on Android; Authenticator or Company Portal on iOS |
+| In the tenant | An Entra app registration with the Intune MAM API permission granted |
+
+## Install
+
+```bash
+npm install react-native-intune
+npx react-native-intune fetch-sdks     # accepts Microsoft's terms, downloads the SDKs
+```
+
+Installing the package is the short part. **Most of this integration is changes to your own
+app project** — `Info.plist`, entitlements, `AndroidManifest.xml`, your app module's
+`build.gradle`, your `Application` class — and autolinking does not touch any of them.
+
+**Expo:** add the config plugin and run `expo prebuild`. Nearly everything is applied for
+you, including the `MAMApplication` change.
+
+```json
+{ "expo": { "plugins": [["react-native-intune", { "androidSignatureHash": "…" }]] } }
+```
+
+**Bare React Native:** two commands, then a short manual remainder.
+
+```bash
+npx react-native-intune doctor   # reports what is missing, changes nothing
+npx react-native-intune setup    # applies what it can, shows a diff first
+```
+
+Then follow [iOS setup](https://bayazetyan.github.io/react-native-intune/docs/setup/ios) or
+[Android setup](https://bayazetyan.github.io/react-native-intune/docs/setup/android).
+
+> **Three of those steps fail silently when missed** — the app builds, runs, and protects
+> nothing while everyone believes protection is in place. The setup guides mark which, and
+> `doctor` finds them.
+
+## Quick start
+
+```ts
+import Intune, { EnrollmentStatus } from 'react-native-intune';
+
+// Per-tenant, from your own backend — one build serves many customers.
+await Intune.configure({
+  clientId: cfg.aadClientId,
+  tenantId: cfg.aadTenantId,
+  authority: cfg.aadAuthority,
+  redirectUri: cfg.aadRedirectUri,
+});
+
+const { enrollment } = await Intune.signInAndEnroll();
+
+// Only 'failed' means block.
+if (enrollment.status === EnrollmentStatus.Failed) {
+  blockCorporateData();
+}
+```
+
+## Enrollment outcomes
+
+`enroll()` **resolves** for every outcome — a failure is data, not an exception. It rejects
+only for programming errors.
+
+| Status | What your app must do |
+|---|---|
+| `succeeded` | Continue. Policy is in force |
+| `notTargeted` | **Continue.** Nobody has aimed a policy at this app yet |
+| `notLicensed` | **Continue.** The employee has no Intune licence and is still a legitimate employee |
+| `failed` | Block access to corporate data until it succeeds |
+| `pending` · `authorizationNeeded` · `wrongUser` · `companyPortalRequired` | Handle it — see the reference |
+| `unenrolled` · `unenrollmentFailed` · `unknown` | Reset states, and one to treat conservatively |
+
+> **The most common integration bug in libraries like this one** is treating anything that
+> is not `succeeded` as "block the user". That breaks every customer with staff who have no
+> Intune licence, and every pilot where the policy has not been targeted yet — while the app
+> reports itself as secure. `notLicensed` and `notTargeted` mean the opposite of `failed`,
+> and that distinction is prescribed by Microsoft rather than invented here.
+
+[All eleven outcomes, and what to do with each](https://bayazetyan.github.io/react-native-intune/docs/guides/enrollment-outcomes)
+
+## Where the rest is
+
+| | |
+|---|---|
+| [Traps and field notes](https://bayazetyan.github.io/react-native-intune/docs/notes/traps) | 23 things that each cost somebody a day and are in no Microsoft documentation |
+| [Authentication](https://bayazetyan.github.io/react-native-intune/docs/guides/authentication) | The broker, MSAL, and using your own instead |
+| [Reconcile at launch](https://bayazetyan.github.io/react-native-intune/docs/guides/reconcile-at-launch) | The pattern to drive enrollment from, and why not from lifecycle hooks |
+| [Reset and wipe](https://bayazetyan.github.io/react-native-intune/docs/guides/reset-and-wipe) | One code path, several callers, and a process that may not survive it |
+| [Troubleshooting](https://bayazetyan.github.io/react-native-intune/docs/troubleshooting) | The seven checks worth doing before opening an issue |
+| [API reference](https://bayazetyan.github.io/react-native-intune/docs/reference) | Generated from the source |
+
+## Contributing
+
+[How to contribute](https://bayazetyan.github.io/react-native-intune/docs/contributing/).
+In short: nothing builds until you accept Microsoft's terms and run `fetch-sdks`, `vendor/`
+is never committed, and a pull request touching native code states which platform was
+actually run, on which device, against which tenant. Enrollment paths cannot be verified by
+unit tests and CI does not pretend otherwise.
+
+## License
+
+MIT — see [`LICENSE`](./LICENSE). It covers this library's code and not the Microsoft Intune
+App SDK; [`NOTICE`](./NOTICE) says what belongs to whom.

package/RNIntune.podspec

@@ -0,0 +1,69 @@
+require "json"
+
+package = JSON.parse(File.read(File.join(__dir__, "package.json")))
+
+# The Microsoft SDKs are fetched, never committed (SPEC §2.1). Fail here with an
+# instruction rather than letting the linker fail 200 lines deep.
+vendor_ios = File.join(__dir__, "vendor", "ios")
+unless File.directory?(vendor_ios) && !Dir.glob(File.join(vendor_ios, "*.xcframework")).empty?
+  raise "[react-native-intune] The Microsoft Intune App SDK is missing from vendor/ios. " \
+        "Run `yarn fetch-sdks` (or `node node_modules/react-native-intune/scripts/fetch-sdks.mjs`) " \
+        "and then `pod install` again."
+end
+
+Pod::Spec.new do |s|
+  s.name         = "RNIntune"
+  s.version      = package["version"]
+  s.summary      = package["description"]
+  s.homepage     = package["homepage"]
+  s.license      = package["license"]
+  s.authors      = package["author"]
+
+  # Deliberately NOT min_ios_version_supported. Intune App SDK 21.8.0 is built with
+  # `minos 17.0` (verified with otool on IntuneMAMSwift.framework), so a host app on
+  # React Native's floor of 15.1 cannot link it. Supporting iOS 16 means pinning SDK
+  # 20.x, which Microsoft maintains for high-priority security fixes only.
+  s.platforms    = { :ios => "17.0" }
+  s.source       = { :git => "https://github.com/bayazetyan/react-native-intune.git", :tag => "#{s.version}" }
+
+  # No .swift and no .cpp on purpose — see SPEC §5.1.1 for the language split.
+  s.source_files = "ios/**/*.{h,m,mm}"
+  s.private_header_files = "ios/**/*.h"
+
+  # IntuneMAMTelemetry is a separate product in 21.x and must be linked explicitly.
+  s.vendored_frameworks = [
+    "vendor/ios/IntuneMAMSwift.xcframework",
+    "vendor/ios/IntuneMAMSwiftStub.xcframework",
+    "vendor/ios/IntuneMAMTelemetry.xcframework"
+  ]
+
+  # Not optional. Carries PinViewController, the blur/policy/diagnostics/MTD-compliance
+  # screens and 28 localizations. Without it the SDK's UI cannot render — and that
+  # failure shows up at runtime, not at build time.
+  s.resources = ["vendor/ios/IntuneMAMResources.bundle"]
+
+  # Keeps IntuneMAMConfigurator (and Microsoft's licence files) in the installed pod so
+  # the consumer can call the configurator from an Xcode build phase.
+  s.preserve_paths = "vendor/**/*"
+
+  s.frameworks = "MessageUI", "Security", "CoreServices", "SystemConfiguration",
+                 "ImageIO", "LocalAuthentication", "AudioToolbox", "QuartzCore",
+                 "WebKit", "MetricKit"
+  s.libraries  = "sqlite3", "c++"
+
+  # Required, and not only by our own auth layer. The Intune SDK does not carry its own
+  # MSAL — it drives the app's. Without this pod even loginAndEnrollAccount:, where the
+  # SDK runs the whole sign-in itself, fails with "Failed to instantiate MSALAuthority /
+  # Ensure the appropriate version of ADAL is included in the application" (observed on
+  # device, 2026-09-04). Version pinned in sdk-versions.json -> toolchain.msal_ios.
+  s.dependency "MSAL", "2.15.0"
+
+  s.pod_target_xcconfig = {
+    "STRIP_SWIFT_SYMBOLS" => "NO",
+    "ENABLE_BITCODE"      => "NO"
+  }
+
+  # RN 0.74+ helper: wires Codegen and the New Architecture dependencies. Do not
+  # hand-roll React-Core / folly deps or RCT_NEW_ARCH_ENABLED flags.
+  install_modules_dependencies(s)
+end

package/android/build.gradle

@@ -0,0 +1,152 @@
+buildscript {
+  // The MAM SDK compatibility matrix (SPEC §6.1) is tested as whole rows, not as a
+  // mix. The pinned Android tag in sdk-lock.json is 12.4.0, so this is the 12.0.0
+  // row: Android 16 (compileSdk 36), Gradle 8.11.1, AGP 8.9.1, Kotlin 2.1.21, Java 17.
+  // Mirrored in sdk-versions.json -> toolchain.requires; change both together.
+  ext.Intune = [
+    kotlinVersion: "2.1.21",
+    minSdkVersion: 24,
+    compileSdkVersion: 36
+  ]
+
+  ext.getExtOrDefault = { prop ->
+    if (rootProject.ext.has(prop)) {
+      return rootProject.ext.get(prop)
+    }
+
+    return Intune[prop]
+  }
+
+  repositories {
+    google()
+    // Not jcenter(), which Microsoft's docs still reference — it is read-only/retired.
+    mavenCentral()
+  }
+
+  dependencies {
+    classpath "com.android.tools.build:gradle:8.9.1"
+    // noinspection DifferentKotlinGradleVersion
+    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:${getExtOrDefault('kotlinVersion')}"
+  }
+}
+
+
+apply plugin: "com.android.library"
+apply plugin: "kotlin-android"
+
+apply plugin: "com.facebook.react"
+
+// The MAM Gradle plugin ("com.microsoft.intune.mam") is deliberately NOT applied here.
+// It rewrites bytecode across the whole application and every one of its dependencies,
+// so it belongs in the consumer's app module. Applying it in this library would rewrite
+// only the library, build successfully, and protect nothing — the worst kind of failure.
+
+android {
+  namespace "com.reactnativeintune"
+
+  compileSdkVersion getExtOrDefault("compileSdkVersion")
+
+  defaultConfig {
+    minSdkVersion getExtOrDefault("minSdkVersion")
+
+    // Shipped to consumers, because a release build with R8 fails without them and only
+    // a release build does — debug and unminified release both succeed, so an app finds
+    // out when it ships. See the file for what each rule is for.
+    consumerProguardFiles "consumer-rules.pro"
+  }
+
+  compileOptions {
+    sourceCompatibility JavaVersion.VERSION_17
+    targetCompatibility JavaVersion.VERSION_17
+  }
+
+  kotlinOptions {
+    jvmTarget = "17"
+  }
+}
+
+// Fetched by scripts/fetch-sdks.mjs into a gitignored vendor/ (SPEC §2.1).
+//
+// Resolved from projectDir, NOT rootDir. SPEC §12.3 and TODO.md both write
+// "$rootDir/../vendor/...", but when this library is autolinked, rootDir is the
+// *consumer app's* android/ directory — that path would point at <app>/vendor and
+// never resolve. projectDir is this library's own android/ folder, so ../vendor is
+// the package root where fetch-sdks writes.
+def mamAar = file("$projectDir/../vendor/android/Microsoft.Intune.MAM.SDK.aar")
+
+// Parallel to the raise in RNIntune.podspec: fail with an instruction rather than an
+// unresolved-symbol error deep in the Kotlin compile. Scoped to graphs that actually
+// compile this library, so `clean` and unrelated tasks are not blocked by a missing
+// download.
+gradle.taskGraph.whenReady { graph ->
+  if (mamAar.exists()) return
+  def compiling = graph.allTasks.any {
+    it.project == project && it.name.startsWith("compile")
+  }
+  if (compiling) {
+    throw new GradleException(
+      "[react-native-intune] The Microsoft Intune App SDK is missing from vendor/android.\n" +
+      "  Expected: ${mamAar}\n" +
+      "  Run: node node_modules/react-native-intune/scripts/fetch-sdks.mjs"
+    )
+  }
+}
+
+/**
+ * Disable AAR packaging for this library, with a message that says why.
+ *
+ * `./gradlew assembleDebug` from a consumer's android/ directory assembles every module,
+ * including this one, and `:react-native-intune:bundleDebugAar` then fails with "Direct
+ * local .aar file dependencies are not supported when building an AAR". People run that
+ * command, and the error names our library, so it reads as our bug.
+ *
+ * It is not a workaround for a problem we could otherwise solve. AGP's own message says
+ * the AAR "would be broken because the classes and Android resources from any local .aar
+ * file dependencies would not be packaged" — so the output being skipped is an output
+ * that could never have been correct. The MAM SDK is distributed as a file from
+ * Microsoft's GitHub, not from Maven Central, so there is no coordinate to depend on
+ * instead.
+ *
+ * Nothing is lost: autolinking consumes this library as a Gradle *project*, so its AAR is
+ * never built for a consumer. `:app:assembleDebug` was always the working form; now the
+ * root form works too.
+ */
+tasks.configureEach { task ->
+  if (task.name ==~ /bundle.*Aar/) {
+    task.enabled = false
+    task.doFirst {
+      logger.lifecycle(
+        "[react-native-intune] Skipping ${task.name}: this library depends on the MAM " +
+        "SDK as a local .aar, so AGP cannot package a valid AAR for it. Consumers " +
+        "autolink it as a Gradle project and never need one."
+      )
+    }
+  }
+}
+
+dependencies {
+  implementation "com.facebook.react:react-android"
+
+  implementation files(mamAar)
+
+  // MSAL. Mirrored in sdk-versions.json -> toolchain.msal_android; change both together.
+  //
+  // Unlike iOS, Microsoft states no required version for Android — the SDK guide says
+  // only "integrate MSAL". So this pin is ours, for reproducibility rather than
+  // compatibility, and it is exact for the same reason the iOS one is: two MSAL versions
+  // in one binary is a failure mode nobody debugs quickly.
+  //
+  // mavenCentral, never jcenter — Microsoft's own docs still say jcenter in places and it
+  // has been read-only for years (CLAUDE.md, Android gotchas).
+  // `display-mask` is excluded deliberately. MSAL depends on it for dual-screen Surface
+  // Duo layout, and it is published only to Microsoft's own Azure DevOps feed, not Maven
+  // Central. MSAL's README tells apps to add that feed — but repositories are declared by
+  // the *consumer's* settings.gradle, so a library cannot add one, and requiring every
+  // consumer to trust an extra feed is a poor trade for dual-screen support.
+  //
+  // [verify] whether MSAL degrades cleanly without it, or throws at sign-in on a real
+  // device. If it throws, the fallback is documenting the feed for consumers.
+  implementation("com.microsoft.identity.client:msal:8.4.2") {
+    exclude group: "com.microsoft.device.display"
+  }
+}

package/android/consumer-rules.pro

@@ -0,0 +1,28 @@
+# ProGuard/R8 rules shipped to consumers of this library.
+#
+# Wired through `consumerProguardFiles`, so an app that enables minification gets them
+# without having to discover any of this. It shipped broken otherwise: a release build
+# with R8 fails outright, and only a release build — every debug build and the unminified
+# release both succeed, so this is invisible until someone ships.
+#
+# All three entries are `-dontwarn`, not `-keep`. Nothing here is called at runtime on the
+# paths this module uses; the classes are referenced from code branches that never execute,
+# and R8 refuses to finish while it cannot resolve a reference it can see.
+
+# `nimbus-jose-jwt`, MSAL's JWT library, has optional support for BouncyCastle and Google
+# Tink and references both unconditionally. Neither is a declared dependency of MSAL, and
+# MSAL's own AAR ships no ProGuard rules at all — verified by unpacking it — so the gap
+# lands on whoever brings MSAL in. That is us.
+-dontwarn org.bouncycastle.**
+-dontwarn com.google.crypto.tink.**
+
+# `com.microsoft.device.display:display-mask` is excluded from the MSAL dependency on
+# purpose (SPEC §6.1.2): it is published only to Microsoft's own Azure DevOps feed and a
+# library cannot add a repository on its consumers' behalf. MSAL references it from
+# `DualScreenActivity.getHinge`, for Surface Duo dual-screen layout, which is a path this
+# module never takes.
+#
+# This is the cost of that exclusion, and it only appeared here — sign-in and enrollment
+# both work without the artifact, so the `[verify]` note in §6.1.2 was answered by a
+# release build rather than by a device.
+-dontwarn com.microsoft.device.display.**

package/android/src/main/AndroidManifest.xml

@@ -0,0 +1,2 @@
+<manifest xmlns:android="http://schemas.android.com/apk/res/android">
+</manifest>