[BartoszKlonowski]

This release brings the Slider to Material Design 3 on Android, and SwiftUI on iOS.
Web and Windows are soon to follow.

The package moves to @callstack/slider, Android moves to Kotlin, Compose and Material 3, iOS moves to a 15.1 deployment target with SwiftUI. The example app loses its outdated screens and gains a README walking through the scenarios it keeps.

The old implementation wrapped the platform's control — AppCompatSeekBar on Android, UISlider on iOS — and reached whatever the control did not support by patching the wrapper: step markers rendered in JavaScript beside a native view whose width had to be measured first, a thumb tinted transparent so an overlay could stand in for it.
That ceiling is what this release removes. Both platforms are now built on the declarative toolkit of their own, so the features below live in the Slider itself rather than around it, and the JS layer shrinks to the parts that are only to provide the support for the feature, not the feature itself.

What the rewrite buys

• Custom pieces are native children, not overlays. A thumb, a track or a stepMarkers component is mounted as a child of the Slider and placed in RNCSliderShadowNode::layout — thumbs centred on their value, step markers hung off the track, a custom track stretched to its length. The native view then moves those frames as the value changes, without asking JS for a relayout on every frame of a drag. Each host is pointerEvents="none", so a custom thumb never steals the drag from the Slider.
• Both variants, one geometry. A single-thumb and a ranged Slider run through the same travel, snapping, hitbox and marker code — one RNCSliderGeometry on iOS, one set of track helpers on Android — the ranged variant only adding a second thumb. That is what let ranged mode come with the same behaviour on both platforms, rather than an approximation of it. That fixes Flicker on Initial Render Android #733
• Props describe intent, not implementation. The codegen contract now carries what the Slider should do (ranged, step, orientation, lowerLimit, stepMarkers), and each platform decides how. Defaults are declared once, as CodegenTypes.WithDefault, so JS, Kotlin, Swift and C++ cannot disagree about them.
• Events leave the bridge only when someone listens. All value and sliding handlers are codegen DirectEventHandlers, and JS passes a handler down only when one was given, so an idle Slider sends nothing across the bridge. The old onRNCSliderValueChange and onChange, both bubbling, are gone along with the re-emitting of values they relied on.
• Decimal values stay decimal. Snapping rounds to the nearest multiple of the step at the decimal place the step is actually written at — in Kotlin, Swift and JS alike — so a step of 0.1 reports 0.3, not 0.30000000000000004. JS, iOS and Android agree on how many steps a range holds, including the last one when the step does not divide it evenly.
• RTL follows the platform settings on both Android and iOS. Track fractions, thumb placement and marker positions are computed, matching how Material 3 and SwiftUI lays its own track out, rather than through a transform.
• Screen readers talk to the platform's control. On iOS a thumb is an adjustable element reporting its value as a percentage, with increment and decrement handled natively; on Android the Compose slider brings its own semantics. A ranged slider exposes its two thumbs separately either way, which the single control behind v5 could not.
• Slider in a native container stack Which fixes iOS: Slider sometimes does not mount at full width #745

What is included:

• Ranged Slider support, closes Range slider #269, closes Multi-thumb option #25
• disabled on both platforms, drawn in the platform's own off state, taking no touch, tap, drag or keyboard and reporting nothing of its own — while the props keep saying where its thumbs stand
• Custom styles for both track and the thumb, closes Add thumbStyle & trackStyle #40, closes Styling the slider #254, closes Add option to allow customization of the thickness of the slider bar #85,
• Track can be an image when used the custom track, closes Implement trackImage for Android #151,
• Custom component replacing the whole track, with the three track colours (minimumTrackColor, middleRangeTrackColor, maximumTrackColor) for those who only need a recolour, closes Android: Tint color inconsistency #84,
• stepMarkers for the steps below the track — true for the built-in ones, a component for custom ones, closes Allow step marker styling #741
• stepMarkers are fully native, avoiding JS-based workarounds, fixes Thumb and steps are not aligned #689,
• step snapping, for single and ranged Sliders alike, including fractional steps, closes Step between 0 and 1 produces floating point rounding errors #742
• lowerLimit and upperLimit, limiting where a thumb can be dragged while the track still spans the full range
• orientation accepting "horizontal" or "vertical", replacing the Windows-only vertical boolean, closes Unable to create Vertical Slider #196
• onSlidingStart and onSlidingComplete as native events, fired on grab and release regardless of whether the value moved, closes Support native events #99
• onLeftValueChange and onRightValueChange, reporting each thumb of a ranged Slider on its own
• Tap anywhere on the track to move a thumb there, on iOS — always on, so tapToSeek no longer needs a prop. A hold on the track picks the nearest thumb up and drags it along, the same read done slowly
• Liquid glass thumb on iOS 26, with the grow-and-turn-clear hold of the system Slider, and the native layout of the thumb it needs to sit correctly