Add an isolated Kotlin Multiplatform foundation

[kunal26das]

Summary

Architectural discussion: The maintainer closed this foundation PR and requested discussion #1020 before any upstream KMP integration. This PR is retained as an implementation reference.

Native stacked review: Review this layer in the registered six-PR fork stack.

Introduce a standalone Kotlin Multiplatform build as the foundation of a series evaluating shared Android/iOS library code in React Native. The intended consumers are small native utilities whose decisions are currently implemented separately in Kotlin and Objective-C. Native views and rendering remain platform-owned; there is no Compose dependency.

This base PR establishes the compiler and interop test surface only: JVM, iOS device ARM64, Apple Silicon simulator and Intel simulator targets; pinned Gradle/Kotlin tooling; and a dedicated CI workflow. It adds 14 files and does not connect the module to React Native applications or published artifacts. A test-only arithmetic fixture is enabled explicitly and produces separate artifacts, so it introduces no production API.

The first use case is gradient stop calculations in #58456. Multipart framing #58474 and explicit scroll snap-target selection #58475 are separate dependent proposals. Each use case must justify its own shared boundary, parity coverage and costs.

Why evaluate KMP here?

The candidate Android consumers are already Kotlin. Sharing pure Kotlin could let both platforms use the same implementation and common tests without introducing an Android JNI interface for each utility. That benefit must be weighed against Kotlin/Native's runtime, build, packaging and interop costs. React Native already has a substantial shared C++ foundation, which remains a strong alternative. Algorithms already shared in C++ are excluded from this series.

This PR establishes feasibility of the toolchain, not approval of production adoption. Existing gradient probes measured higher adapter latency and memory/binary costs; those results remain part of the gradient review.

Review order

Foundation #58472 → gradients #58456 → multipart framing #58474 → explicit scroll offsets #58475. #58471 is a separate two-line RNTester dependency fix used by source-build test coverage. Because these contributions originate in a fork, the dependent upstream PRs target main and link their incremental comparisons until prerequisites land.

Changelog:

[INTERNAL] [ADDED] - Add an isolated Kotlin Multiplatform build and compiler interop smoke tests.

Test Plan

From packages/react-native/ReactShared, with JDK 17 and Xcode 26.6 locally:

./gradlew -PreactNativeSharedSmoke=true jvmTest iosSimulatorArm64Test \
  linkDebugFrameworkIosArm64 linkReleaseFrameworkIosArm64 \
  linkDebugFrameworkIosSimulatorArm64 linkReleaseFrameworkIosSimulatorArm64 \
  linkDebugFrameworkIosX64 linkReleaseFrameworkIosX64 --max-workers=2 --console=plain
./scripts/test-apple-smoke.sh
./gradlew jvmJar

• Four common tests passed on each of JVM and ARM64 iOS simulator; zero failures/skips.
• All six Debug/Release frameworks built with their expected architectures.
• Five Objective-C interop cases passed in each of Debug and Release.
• Default JAR contains no classes; the smoke fixture appears only in its opt-in output.
• Wrapper checksum, shell syntax, formatting, and the workflow's nonempty-test assertions checked.

Intel simulator execution is deferred; physical devices were not tested. No application adoption is included in this base PR, so the checks above do not claim application integration or acceptable runtime performance.

[kunal26das]

Maintainers, could you help route this series for review as a GitHub-native stack in react/react-native, if that is compatible with Meta's PR import workflow?

The working example is native stack #7 in my fork. GitHub registers six ordered layers with incremental diffs:

1. KMP foundation — 14 files; isolated toolchain and interop tests, no application integration or Compose.
2. RNTester test dependencies — 1 file.
3. Gradient stop calculations — 38 files, including first-consumer integration and validation.
4. Native multipart bounds fix — 2 files.
5. Shared multipart parsing — 20 files.
6. Explicit scroll snap selection — 13 files.

GitHub currently requires all native-stack branches to be in the same repository. My account cannot push branches upstream. Would a maintainer be willing to publish the six prepared codex/kmp-native-* branches upstream and create/register the corresponding same-repository PRs? Their existing commits can be used directly, retaining these submissions as linked review history; this does not require merging anything into main.

The immediate request is help with review structure. Each use case still needs its own adoption decision: the PRs document parity tests, platform limitations, and measured runtime/build costs, including results that favor native implementations. If an architectural proposal should come first, please point me to the preferred process before proceeding with upstream hosting.

[javache]

This requires a larger discussion in https://github.com/react-native-community/discussions-and-proposals first, not in the context of a PR. Please start a discussion there first.

Adopting KMP is a major technical change and has large downstream impact on anyone integrating it (including Meta), React Native's current technical strategy is to use C++ and JS for cross-platform logic, not KMP.

[kunal26das]

Thanks for clarifying. I have opened the architectural discussion in the requested repository, following its long-form discussion template. It starts from the C++/JS strategy and covers downstream obligations, unfavorable benchmark results, alternatives, and the evidence needed before considering a core change.

The three KMP consumer PRs are now drafts, and the stack-hosting reminders are paused. The fork remains an experimental reference. The two independent native fixes remain separate from the KMP decision.