Share gradient stop calculations with Kotlin Multiplatform - #3
Open
kunal26das wants to merge 2 commits into
Open
Share gradient stop calculations with Kotlin Multiplatform#3kunal26das wants to merge 2 commits into
kunal26das wants to merge 2 commits into
Conversation
kunal26das
added this pull request to stack #7
September 10, 2026 21:26
This was referenced Sep 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Architectural discussion: Discussion #1020 is the current venue for evaluating architectural fit and downstream costs. This fork stack is an experimental implementation reference; upstream KMP integration is awaiting architectural agreement.
Share CSS gradient stop positioning and transition-hint calculations between Android and iOS using the Kotlin Multiplatform foundation in upstream #58472. This is the first use case in a series; multipart framing upstream #58474 and explicit scroll snap-target selection upstream #58475 are separate proposals.
This native fork PR mirrors the upstream gradient calculations submission as layer 3 of six. This layer is based on RNTester dependencies. The registered fork stack uses dependent PR bases, so this PR shows its incremental diff.
Stack order: Foundation → RNTester dependencies → Gradients → Native multipart bounds → Shared multipart parsing → Scroll offsets.
This mirror retains the exact validated source of the upstream submission. The results below keep their original scope and provenance; restacking is not a new test run.
Android embeds the shared JVM code in its existing ReactAndroid AAR. iOS source builds opt in with
RCT_USE_KMP=1during CocoaPods installation. The common implementation takes stop positions and color-presence flags and returns positions, source color indices and interpolation weights. Native color interpolation, geometry, drawing and precision choices remain in the adapters. There is no Compose dependency or JavaScript API change.This first consumer also establishes packaging and integration checks: actual Maven/npm consumers, shrinking, source applications, independent Kotlin framework coexistence, and repeatable cost probes. Catalyst keeps its native fallback. Full React Native core SwiftPM and published Apple prebuilt integration remain guarded; the separate XCFramework/SwiftPM consumer is a distribution experiment.
Feasibility and alternatives
The benefit is one Kotlin implementation and common tests for calculations otherwise maintained in Kotlin and Objective-C++. Android calls it directly without a new JNI interface. C++ is a strong alternative because the Apple adapter already uses C++ data types and React Native already ships a shared C++ runtime. This proposal does not establish that KMP is the preferred implementation.
The measured gradient bridge adds cost, including its conversions:
Each platform uses matched native/KMP inputs; hint inputs differ between platforms. These are simulator/emulator measurements, not app startup, frame time, installed size or physical-device results. Footprint snapshots are not allocation or leak measurements. Broader adoption needs an accepted performance budget and representative application/device evidence. Catalyst fallback also means the experiment does not eliminate every native copy.
Changelog:
[GENERAL] [CHANGED] - Share gradient stop calculations using Kotlin Multiplatform on Android and opt-in iOS source builds.
Test Plan
Base: upstream
f109c0af8693b58e0716b77b0b7c0c2299fc0a0e. Local toolchain: JDK 17, Kotlin 2.4.20, Xcode 26.6/iOS 26.5. CI selects Xcode 26.4.1.The common algorithms, native adapters and JVM packaging retain their previously validated implementations. Hosted-test runtime ownership is now established in this first consumer: full-pod sibling tests resolve shared classes through the actual application host, including projects without optional
TestTargetIDmetadata. Standalone tests and tests hosted by a non-KMP app retain their own runtime. The application runner also rejects a second shared runtime in hosted test binaries.Previously completed gradient-layer validation on unchanged algorithm and adapter sources, from
packages/react-native/ReactShared:Hosted-runtime review checks executed at upstream revision
9e28d94bf595:Previously executed on the identical production implementation, using the checked-in runners documented in
ReactShared/README.md:Intel simulator execution remains deferred; physical-device execution and complete React Native core SwiftPM/prebuilt adoption are outstanding. The mirrored upstream PR’s hosted CI needs upstream approval; these local passes do not claim that approval or completed CI on the new fork PR.