@kindly-ai/react-native 0.1.1 → 0.1.2

package/KindlyReactNative.podspec

@@ -64,5 +64,22 @@ Pod::Spec.new do |s|
 
   s.swift_version = "5.0"
 
+  # DEFINES_MODULE = YES tells Xcode to produce a proper clang module for
+  # this pod, which:
+  #   - generates `KindlyReactNative-Swift.h` at the canonical module path
+  #     (`<KindlyReactNative/KindlyReactNative-Swift.h>`) so our .mm's
+  #     defensive `#if __has_include(<KindlyReactNative/...>)` import works
+  #   - matches what React-Core.podspec and most well-behaved RN libs do
+  #     (`s.pod_target_xcconfig "DEFINES_MODULE" => "YES"`)
+  #
+  # Without this, customer environments that pass `-fmodules` strictly,
+  # use `use_frameworks!`, or have non-standard pod build configurations
+  # may fail with `'KindlyReactNative-Swift.h' file not found` (reported
+  # by Scandic 2026-06 via Kevin Lärkfors). The defensive include guard
+  # in KindlyReactNative.mm is still kept as a second line of defence.
+  s.pod_target_xcconfig = {
+    "DEFINES_MODULE" => "YES"
+  }
+
   install_modules_dependencies(s)
 end

package/android/build.gradle

@@ -84,6 +84,26 @@ android {
 
   kotlinOptions {
     jvmTarget = "17"
+
+    // The bundled Kindly AAR (ai.kindly:sdk:1.0.x) is compiled with
+    // Kotlin 2.3.20 (lockstep with kindly-ai/sdk-chat-android-sources).
+    // Customer apps frequently still ship with an older Kotlin compiler
+    // (RN 0.85 ships 2.2.x by default; some apps stay on 2.1.x). When
+    // those compilers read the AAR's 2.3.0 metadata they bail with:
+    //   "Module was compiled with an incompatible version of Kotlin.
+    //    The binary version of its metadata is 2.3.0, expected version
+    //    is 2.1.0."
+    // (reported by Scandic 2026-06 — `:kindly-ai_react-native:compileDebugKotlin FAILED`).
+    //
+    // -Xskip-metadata-version-check tells THIS module's compile step to
+    // ignore the version mismatch when reading dependencies. We don't
+    // re-expose any Kindly types in our public API surface (customer
+    // apps interact via TS/TurboModule, never directly importing
+    // `no.kindly.chatsdk.chat.*`), so the metadata in OUR compiled
+    // output is whatever the customer's compiler emits — fully
+    // forward-compatible with their app code. Customer needs no Kotlin
+    // bump on their side.
+    freeCompilerArgs += ["-Xskip-metadata-version-check"]
   }
 
   lint {

package/ios/KindlyReactNative.mm

@@ -29,7 +29,21 @@
 
 // Auto-generated header that exposes Swift classes to ObjC. Filename derives
 // from the pod name (KindlyReactNative.podspec → KindlyReactNative-Swift.h).
-#import "KindlyReactNative-Swift.h"
+//
+// Use the defensive `__has_include` pattern: try the module-qualified path
+// first (which works when the pod is built as a clang module, with
+// `DEFINES_MODULE = YES` set in the podspec — see Scandic 2026-06), then
+// fall back to the local-path form. The bare `#import "Foo-Swift.h"` form
+// the scaffold ships fails in customer environments that don't set up the
+// header search paths exactly the way `create-react-native-library` expects
+// (use_frameworks!, certain Xcode/CocoaPods version combos, etc.).
+#if __has_include(<KindlyReactNative/KindlyReactNative-Swift.h>)
+  #import <KindlyReactNative/KindlyReactNative-Swift.h>
+#elif __has_include("KindlyReactNative-Swift.h")
+  #import "KindlyReactNative-Swift.h"
+#else
+  #error "KindlyReactNative-Swift.h not found. Ensure DEFINES_MODULE=YES is set in KindlyReactNative.podspec's pod_target_xcconfig and that pod install ran cleanly."
+#endif
 
 // Protocol conformance is declared internally so it doesn't leak into the
 // public header (which Swift consumes via the module umbrella).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kindly-ai/react-native",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Kindly chat SDK for React Native",
   "main": "./lib/module/index.js",
   "types": "./lib/typescript/src/index.d.ts",