zixflow-reactnative 1.1.2 → 1.1.4

package/android/src/main/java/com/zixflow/reactnative/sdk/messaginginbox/NotificationInboxViewManager.kt

@@ -0,0 +1,30 @@
+package com.zixflow.reactnative.sdk.messaginginbox
+
+import com.facebook.react.module.annotations.ReactModule
+import com.facebook.react.uimanager.SimpleViewManager
+import com.facebook.react.uimanager.ThemedReactContext
+import com.facebook.react.uimanager.ViewManagerDelegate
+import com.facebook.react.viewmanagers.NotificationInboxViewNativeManagerDelegate
+import com.facebook.react.viewmanagers.NotificationInboxViewNativeManagerInterface
+
+/**
+ * View manager for the Visual Notification Inbox message list (the Jist-rendered list,
+ * embeddable in the host's own screen). No props or events; sizing comes from the JS style.
+ */
+@ReactModule(name = NotificationInboxViewManager.NAME)
+class NotificationInboxViewManager :
+    NotificationInboxViewNativeManagerInterface<ReactNotificationInboxView>,
+    SimpleViewManager<ReactNotificationInboxView>() {
+    private val delegate = NotificationInboxViewNativeManagerDelegate(this)
+
+    override fun getName() = NAME
+    override fun getDelegate(): ViewManagerDelegate<ReactNotificationInboxView> = delegate
+
+    override fun createViewInstance(
+        reactContext: ThemedReactContext
+    ): ReactNotificationInboxView = ReactNotificationInboxView(reactContext)
+
+    companion object {
+        internal const val NAME = "NotificationInboxViewNative"
+    }
+}

package/android/src/main/java/com/zixflow/reactnative/sdk/messaginginbox/ReactComposeHostView.kt

@@ -0,0 +1,96 @@
+package com.zixflow.reactnative.sdk.messaginginbox
+
+import android.content.Context
+import android.view.Choreographer
+import android.view.View
+import android.widget.FrameLayout
+import androidx.compose.runtime.Composable
+import androidx.compose.ui.platform.ComposeView
+import com.facebook.react.bridge.WritableMap
+import com.zixflow.reactnative.sdk.extension.sendUIEventToReactJS
+
+/**
+ * Base React Native view that hosts a Jetpack Compose [content] inside a [ComposeView].
+ *
+ * Mirrors the role that the native SDK's `WrapperInlineView` plays for inline in-app
+ * messages, but the Visual Notification Inbox components are plain `@Composable`s, so we
+ * host them directly in a [ComposeView] rather than going through an inline-message wrapper.
+ *
+ * Subclasses provide the composable via [content] and emit events with [emitEvent].
+ *
+ * Layout note: React Native (Yoga) lays this view out, so the [ComposeView] is sized to the
+ * bounds RN assigns. Because RN children measured by native code don't always re-trigger a
+ * layout pass, we schedule a manual measure/layout via the [Choreographer] whenever the view
+ * is attached, matching how other RN-hosted native views keep themselves laid out.
+ */
+abstract class ReactComposeHostView(context: Context) : FrameLayout(context) {
+
+    private val composeView: ComposeView = ComposeView(context).apply {
+        layoutParams = LayoutParams(
+            LayoutParams.MATCH_PARENT,
+            LayoutParams.MATCH_PARENT
+        )
+        setContent { content() }
+    }
+
+    /** The Compose UI hosted by this view. Implemented by each concrete inbox component. */
+    @Composable
+    protected abstract fun content()
+
+    /**
+     * The Compose child is attached here rather than in `init`, gating setup on attachment the same
+     * way [com.zixflow.messaginginapp.ui.core.BaseInlineInAppMessageView] gates its subscription.
+     *
+     * Fabric measures a newly created view before the mount batch's INSERT attaches it to the
+     * window ([com.facebook.react.fabric.mounting.SurfaceMountingManager.updateLayout]), and
+     * `AbstractComposeView.onMeasure` unconditionally creates its composition, which needs a window
+     * to resolve the recomposer. Adding the child in `init` therefore threw
+     * `IllegalStateException: Cannot locate windowRecomposer` during that measure; the mount batch
+     * aborted and the half-mounted hierarchy crashed the host app.
+     */
+    override fun onAttachedToWindow() {
+        super.onAttachedToWindow()
+        if (composeView.parent == null) {
+            addView(composeView)
+        }
+    }
+
+    /**
+     * Dispatches a UI event back to the JS side using the React Native event dispatcher.
+     *
+     * @param eventName name registered in the view manager's
+     *   `getExportedCustomDirectEventTypeConstants`.
+     * @param payload optional event data.
+     */
+    protected fun emitEvent(eventName: String, payload: WritableMap? = null) {
+        sendUIEventToReactJS(eventName = eventName, payload = payload)
+    }
+
+    /**
+     * React Native lays out views off the main Android layout pass, so manually re-run
+     * measure + layout against the bounds RN assigned. Without this, native children of
+     * RN-managed views can render with a zero size.
+     */
+    override fun requestLayout() {
+        super.requestLayout()
+        post(measureAndLayout)
+    }
+
+    private val measureAndLayout = Runnable {
+        // The callback is posted for the next frame, by which point the view may have been detached
+        // (Fabric recycles these). Measuring the Compose child without a window throws, so skip it —
+        // a later attach re-runs layout anyway.
+        if (!isAttachedToWindow) {
+            return@Runnable
+        }
+        measure(
+            MeasureSpec.makeMeasureSpec(width, MeasureSpec.EXACTLY),
+            MeasureSpec.makeMeasureSpec(height, MeasureSpec.EXACTLY)
+        )
+        layout(left, top, right, bottom)
+    }
+
+    private fun View.post(action: Runnable) {
+        Choreographer.getInstance().postFrameCallback { action.run() }
+    }
+}

package/android/src/main/java/com/zixflow/reactnative/sdk/messaginginbox/ReactNotificationInboxBellView.kt

@@ -0,0 +1,48 @@
+package com.zixflow.reactnative.sdk.messaginginbox
+
+import android.content.Context
+import android.view.MotionEvent
+import androidx.compose.runtime.Composable
+import com.facebook.react.bridge.Arguments
+import com.zixflow.messaginginbox.NotificationInboxOverlay
+
+/**
+ * React Native host for the Visual Notification Inbox bell.
+ *
+ * Hosts the native [NotificationInboxOverlay] composable rather than `NotificationInboxBell`: only the
+ * overlay ties the bell to the SDK's own inbox panel, and the wrapper deliberately does not reimplement
+ * panel presentation. Sized to the frame React Native assigns, that composition *is* a bell that opens
+ * the inbox — the component wrappers expose.
+ *
+ * Remote branding still styles the bell (colors, icon). Branding's bell *position* has no effect here:
+ * alignment resolves inside this view's bounds, so the JS host owns placement via `style`.
+ *
+ * [ON_TAP] is observational — the SDK opens the panel itself, so the host has nothing to do in response.
+ */
+class ReactNotificationInboxBellView(context: Context) : ReactComposeHostView(context) {
+    @Composable
+    override fun content() {
+        NotificationInboxOverlay()
+    }
+
+    /**
+     * Reports taps without consuming them.
+     *
+     * `dispatchTouchEvent` rather than `onTouchEvent`: the Compose child consumes the bell tap, so a
+     * parent `onTouchEvent` would never run. Dispatching to super first keeps the gesture flowing to
+     * Compose (which opens the panel); we only observe the outcome. Reporting on ACTION_UP and only
+     * when the touch was consumed approximates "the bell took this tap" rather than firing for taps
+     * that landed on the transparent area around it.
+     */
+    override fun dispatchTouchEvent(event: MotionEvent): Boolean {
+        val handled = super.dispatchTouchEvent(event)
+        if (handled && event.actionMasked == MotionEvent.ACTION_UP) {
+            emitEvent(ON_TAP, Arguments.createMap())
+        }
+        return handled
+    }
+
+    companion object {
+        const val ON_TAP = "onTap"
+    }
+}

package/android/src/main/java/com/zixflow/reactnative/sdk/messaginginbox/ReactNotificationInboxView.kt

@@ -0,0 +1,17 @@
+package com.zixflow.reactnative.sdk.messaginginbox
+
+import android.content.Context
+import androidx.compose.runtime.Composable
+import com.zixflow.messaginginbox.NotificationInboxView
+
+/**
+ * React Native host for the native [NotificationInboxView] composable (the Jist-rendered
+ * message list). Sizing is driven by the JS `style` prop. Message actions are handled by the
+ * existing global InboxEventListener, so this component emits no per-message events.
+ */
+class ReactNotificationInboxView(context: Context) : ReactComposeHostView(context) {
+    @Composable
+    override fun content() {
+        NotificationInboxView()
+    }
+}

package/android/src/main/java/com/zixflow/reactnative/sdk/messagingpush/NativeMessagingPushModule.kt

@@ -23,6 +23,7 @@ import com.zixflow.reactnative.sdk.NativeZixflowMessagingPushSpec
 import com.zixflow.reactnative.sdk.constant.Keys
 import com.zixflow.reactnative.sdk.extension.getTypedValue
 import com.zixflow.reactnative.sdk.extension.takeIfNotBlank
+import com.zixflow.reactnative.sdk.liveactivities.NativeLiveActivitiesModule
 import com.zixflow.reactnative.sdk.util.unsupportedOnAndroid
 import com.zixflow.sdk.Zixflow
 import com.zixflow.sdk.ZixflowBuilder
@@ -257,7 +258,8 @@ class NativeMessagingPushModule(
          */
         internal fun addNativeModuleFromConfig(
             builder: ZixflowBuilder,
-            config: Map<String, Any>
+            config: Map<String, Any>,
+            liveNotificationsConfig: Map<String, Any>? = null,
         ) {
             val androidConfig =
                 config.getTypedValue<Map<String, Any>>(key = "android") ?: emptyMap()
@@ -275,6 +277,14 @@ class NativeMessagingPushModule(
             val module = ModuleMessagingPushFCM(
                 moduleConfig = MessagingPushModuleConfig.Builder().apply {
                     setPushClickBehavior(pushClickBehavior = pushClickBehavior)
+                    // Live Notifications are hosted by the FCM push module, so their config is
+                    // applied to the same MessagingPushModuleConfig.
+                    liveNotificationsConfig?.let { liveConfig ->
+                        NativeLiveActivitiesModule.applyLiveActivitiesConfig(
+                            builder = this,
+                            config = liveConfig,
+                        )
+                    }
                 }.build(),
             )
             builder.addZixflowModule(module)

package/android/src/main/res/values/zixflow_config.xml

@@ -9,5 +9,5 @@
     This will be updated by update-version script with React Native package version
     whenever new version of React Native package is released
     -->
-    <string name="zixflow_react_native_sdk_client_version">1.1.0</string>
+    <string name="zixflow_react_native_sdk_client_version">1.1.4</string>
 </resources>

package/android/zixflow-core.gradle

@@ -1,12 +1,22 @@
 dependencies {
-    api "com.zixflow.com.android:datapipelines:$zixflowAndroidSDKVersion"
-    api "com.zixflow.com.android:messaging-push-fcm:$zixflowAndroidSDKVersion"
-    api "com.zixflow.com.android:messaging-in-app:$zixflowAndroidSDKVersion"
+    api "com.zixflow.android:datapipelines:$zixflowAndroidSDKVersion"
+    api "com.zixflow.android:messaging-push-fcm:$zixflowAndroidSDKVersion"
+    api "com.zixflow.android:messaging-in-app:$zixflowAndroidSDKVersion"
+    // Visual Notification Inbox UI (Compose-based).
+    api "com.zixflow.android:messaging-inbox:$zixflowAndroidSDKVersion"
     // Location module is optional - customers enable it by adding
-    // zixflow_location_enabled=true in their gradle.properties
-    if (project.zixflowLocationEnabled) {
-        api "com.zixflow.com.android:location:$zixflowAndroidSDKVersion"
+    // zixflow_location_enabled=true in their gradle.properties.
+    // Geofence implies Location: enabling geofence pulls in location too.
+    if (project.zixflowLocationEnabled || project.zixflowGeofenceEnabled) {
+        api "com.zixflow.android:location:$zixflowAndroidSDKVersion"
     } else {
-        compileOnly "com.zixflow.com.android:location:$zixflowAndroidSDKVersion"
+        compileOnly "com.zixflow.android:location:$zixflowAndroidSDKVersion"
+    }
+    // Geofence module is optional - customers enable it by adding
+    // zixflow_geofence_enabled=true in their gradle.properties
+    if (project.zixflowGeofenceEnabled) {
+        api "com.zixflow.android:geofence:$zixflowAndroidSDKVersion"
+    } else {
+        compileOnly "com.zixflow.android:geofence:$zixflowAndroidSDKVersion"
     }
 }

package/docs/cocoapods-deployment-target-normalization.md

@@ -0,0 +1,139 @@
+# CocoaPods deployment-target normalization
+
+Xcode validates the deployment target of every generated CocoaPods target, including dependency,
+aggregate, privacy-manifest, and resource-bundle targets. Xcode 27 rejects targets below the build
+range supported by its iOS SDK even when the dependency itself is source-compatible with your app.
+
+The `zixflow-reactnative` package includes an opt-in Podfile helper. It raises low or missing
+generated settings to the greater of React Native's current minimum and iOS 15.0. For React Native
+0.83 that value is iOS 15.1. It also covers integrated application, Notification Service
+Extension, and widget targets, while preserving higher numeric deployment targets. When a target
+setting is absent, the helper resolves its target xcconfig and then the same-named project build
+configuration, preserving a higher inherited app or extension floor. The helper changes local build
+settings in the generated Pods project and CocoaPods-integrated app or extension projects. It does
+not rewrite a podspec or change runtime API availability.
+
+The package owns and tests this copy of the helper because customer Podfiles must be able to load it
+from the installed npm package. When its behavior changes, update the helper, tests, and guidance
+together. It does not depend on a cross-repository source lock or require wrapper copies to remain
+byte-identical.
+
+Zixflow deliberately continues to publish native SDKs that support iOS versions below 15. A
+podspec can therefore correctly declare that lower library minimum even when React Native or the
+application consuming it requires a newer iOS version. CocoaPods carries deployment metadata from
+Zixflow and third-party podspecs into generated build targets, but Xcode 27 no longer accepts
+targets below the iOS SDK's supported build range. Raising every published podspec to iOS 15 would
+unnecessarily drop older applications and would not control metadata from transitive
+dependencies. The helper instead aligns the generated targets with the host application's chosen
+minimum while leaving the packages' published runtime compatibility unchanged.
+This is the supported integration policy for a React Native application that has moved its own
+minimum to the required iOS floor.
+
+> [!WARNING]
+> This is an opt-in build migration. Integrated app and extension targets below the computed floor
+> are raised to that floor. With React Native 0.83, shipping the resulting iOS 15.1 application
+> means users on iOS 15.0 and earlier cannot install subsequent app updates. Adopt the helper only
+> when your product has intentionally moved its application and extension deployment targets.
+
+Resolve the helper through Node so hoisted and monorepo installations work, then call it after
+`react_native_post_install` in the one existing `post_install` block:
+
+```ruby
+def node_resolve(script)
+  Pod::Executable.execute_command('node', ['-p',
+    "require.resolve('#{script}', {paths: [process.argv[1]]})",
+    __dir__
+  ]).strip
+end
+
+customer_io_package_root = File.dirname(node_resolve('zixflow-reactnative/package.json'))
+require File.join(customer_io_package_root, 'ios', 'cocoapods_deployment_target')
+
+customer_io_minimum_ios_version = Zixflow::CocoaPodsDeploymentTarget.maximum(
+  min_ios_version_supported,
+  '15.0'
+)
+
+post_install do |installer|
+  react_native_post_install(
+    installer,
+    config[:reactNativePath],
+    :mac_catalyst_enabled => false
+  )
+
+  Zixflow::CocoaPodsDeploymentTarget.normalize!(
+    installer,
+    minimum_ios_version: customer_io_minimum_ios_version
+  )
+end
+```
+
+Remove the generated `ios/Pods` directory and run `pod install` again. When a target build-setting
+key is absent, the helper resolves the target xcconfig and matching project configuration before
+adding an override. A present target key is authoritative, so lower-precedence xcconfig and project
+values are not inspected. This matches Xcode's treatment of an explicitly empty target value: it
+is missing and must be normalized, rather than inherited from a lower-precedence value. For each
+change, the helper prints a stable project, target, and configuration line with the original
+effective value and final value. It fails the install if the selected effective value is
+non-numeric, such as `$(CUSTOM_IOS_FLOOR)`, because the generated-project audit cannot prove its
+resolved value. A non-numeric value at a lower precedence does not fail when an explicit target
+setting already determines the effective value.
+SDK-, architecture-, or configuration-qualified keys such as
+`IPHONEOS_DEPLOYMENT_TARGET[sdk=iphoneos*]` also fail before mutation at the selected precedence.
+Xcode can choose a qualified key over an unconditional value, so adding a numeric override would
+not prove the effective floor and could lower a higher conditional project setting. Replace the
+selected conditional matrix with one numeric, unconditional deployment target before rerunning the
+helper.
+
+If the helper reports a non-numeric selected value, use the project, target, and configuration in
+the error to locate the authoritative `IPHONEOS_DEPLOYMENT_TARGET`. Replace the macro or inherited
+expression at that precedence with its intended numeric version, then run `pod install` again. For
+a generated Pods target, make that override durably in the Podfile's `post_install` hook before
+calling `Zixflow::CocoaPodsDeploymentTarget.normalize!`, or correct the podspec that supplies the
+expression; do not edit the generated project because the next install replaces it. Do not skip
+that target: continuing with an unresolved expression would leave the generated project outside
+the deterministic audit. The helper validates every selected value before changing any project,
+so this failure does not leave a partially normalized installation.
+
+If an error says a selected xcconfig cannot be read or parsed, repair or remove the reported base
+configuration file reference for the reported project, target, and configuration. Lower-precedence
+xcconfigs are not parsed when the target build-setting key is present. Run the helper in the
+CocoaPods Ruby environment so the public `Xcodeproj::Config` parser is available.
+Synchronized-group xcconfig references are not resolved by that public parser; if the helper
+reports one, replace it with a standard xcconfig file reference, then run `pod install` again.
+These cases fail before any project mutation.
+
+## When the helper is no longer needed
+
+Keep the helper while a supported dependency graph can validly include deployment metadata below
+the host application's minimum. This is expected while Zixflow supports older iOS versions or
+supported third-party pods continue to declare lower minimums. A `platform` declaration in the
+application's Podfile alone does not guarantee that every generated target uses the same value.
+
+The helper becomes unnecessary only when a clean install without it proves that every
+target/configuration in every supported React Native and push-provider graph declares an effective
+numeric deployment target at or above the host application's minimum. That state would normally
+follow an intentional platform-support change across the SDK, wrappers, and relevant dependencies;
+it is not a prerequisite for adopting Xcode 27. Keep the audit in CI after removing the helper so
+a later dependency update cannot silently reintroduce a lower target.
+
+Repository contributors also have a deterministic CI audit under `scripts/` that prints the target,
+matching project, and effective value for every generated target/configuration pair in stable
+order. That audit script is not part of the published npm package. It examines every target in each
+passed project, including non-integrated targets that the normalizer intentionally does not change;
+set those targets to the host minimum explicitly. Pass the `Pods` directory so the audit discovers
+every `.xcodeproj` directly under it, including CocoaPods multi-project output, while ignoring
+unrelated example projects vendored inside downloaded pod sources. It fails if a supplied path is
+missing or contains no projects.
+
+```sh
+cd example
+bundle exec ruby ../scripts/audit_cocoapods_deployment_targets.rb \
+  --minimum 15.1 \
+  ios/Pods \
+  ios/SampleApp.xcodeproj
+```
+
+Keep this audit next to the React Native simulator build and unsigned generic-device archive.
+Passing those checks does not prove real-device push delivery, signed archive export, or App Store
+submission.