callstack/react-native-slider for React Native value selection

The single-value control exposed by @react-native-community/slider

@react-native-community/slider addresses a small but common interface problem: accepting one numeric value from a bounded range in a React Native application. It is intended for settings such as playback position, volume, intensity, or other values that fit between a minimum and maximum. The component does not present a list, text entry field, or pair of handles. Its core abstraction is selection of one value from a continuous or stepped interval.

The package adapts React Native code across four documented platforms: iOS, Android, Windows, and Web. Its repository description identifies the native controls behind the first two platforms as Slider on iOS and SeekBar on Android. That distinction matters because the package presents one component API while preserving familiar platform controls and several platform-specific capabilities.

The component supports programmatic positioning through `value`, continuous drag notifications through `onValueChange`, and interaction boundaries through `onSlidingStart` and `onSlidingComplete`. It is not a controlled component. The README explicitly says that the value does not need to be updated during dragging and that changing `value` programmatically does not trigger an event. This design can simplify basic screen code, but it also means an application should not expect the prop to behave like the live value state of an ordinary controlled form input.

How the shared React Native component reaches native implementations

The architecture is a platform bridge rather than a slider drawn entirely from React primitives. Callstack describes the package as a React Native component exposing `Slider` from iOS and `SeekBar` from Android, while the README also documents Windows and web support. This gives an application a shared JavaScript import and prop vocabulary without requiring each screen to select and render a separate platform package.

The repository layout separates the publishable package from its examples. The top-level `package/` directory is the library itself, while `example/`, `example-web/`, and the `example` platform directories provide integration examples. The root `package.json` scripts also distinguish launching the native example, the Android build, the iOS build, and the Windows build. Those scripts are repository development commands, not commands that a consuming application should automatically run.

Some behavior is shared, but the property table makes the boundaries visible. `minimumValue`, `maximumValue`, `step`, `disabled`, `inverted`, and the sliding callbacks are part of the broader API. Other options are limited by platform. `tapToSeek` applies only on iOS and has no effect on Android or Windows. `vertical` is documented only for Windows. `thumbTintColor` is listed for Android, while `thumbSize` covers Android, iOS, and Web. Consequently, cross-platform code needs to treat the import as portable without assuming that every prop changes every native presentation identically.

Installing @react-native-community/slider and rendering the first value

The README directs developers to install the package from the root of an existing React Native application. Yarn and npm are both documented, so either command below follows the project's published installation guidance.

yarn add @react-native-community/slider

The equivalent documented npm command is:

npm install @react-native-community/slider --save

For iOS, the package documentation also requires CocoaPods installation by running the following command in the application project:

npx pod-install

After installation, import the default export and render a bounded slider. This is the README's basic example, with its values and formatting preserved:

import Slider from '@react-native-community/slider';

<Slider
  style={{width: 200, height: 40}}
  minimumValue={0}
  maximumValue={1}
  minimumTrackTintColor="#FFFFFF"
  maximumTrackTintColor="#000000"
  thumbSize={32}
/>

The component starts with the documented defaults of `minimumValue` equal to 0 and `maximumValue` equal to 1, although both are shown explicitly in the example. `thumbSize` was introduced in version 5.2.0, while version 5.2.1 addressed `thumbImage` behavior on React Native 0.84. Consumers using either feature should select a release that includes the relevant fix rather than assuming every 5.x release behaves identically.

React Native version requirements and release upgrade choices

Version selection is the first concrete compatibility boundary. The compatibility table states that `@react-native-community/slider` 5.0.0 requires React Native `>=0.76`, 4.5.1 requires `>=0.69`, 4.3.0 requires `>=0.64`, and 4.x releases generally require `>=0.60`, with `>=0.62` on Windows. Releases in the 3.1.x and 2.x lines are listed as requiring `>= 0.60`. Version 1.x is associated with React Native versions `<= 0.59`.

This makes the library's major version relevant during application upgrades. Moving an application to React Native 0.76 or later does not by itself select the correct slider release, but it rules out older compatibility ranges documented in the table. Teams upgrading both packages must check the exact compatibility row rather than relying only on the current npm release.

Upgrade cost also varies by target platform. Native iOS use includes a CocoaPods setup step, so package installation alone does not complete that integration. Changes to visual props can require platform-specific verification: `thumbSize` is documented for Android, iOS, and Web, but not Windows, while `thumbImage` can interact with Android's `thumbTintColor`. The README warns that setting both can prevent the image from displaying correctly.

The repository was not archived, and its last push was on 2026-10-15. The recorded releases also include v5.2.0 on 2026-04-03 and v5.1.2 on 2026-01-14. These facts indicate recent repository activity, but the documentation does not define a formal support window or promise compatibility with future React Native releases.

Interaction limits that can affect React Native screen code

The clearest limitation is the absence of controlled-component semantics. According to the README, `value` is write-only and represents the thumb position from the application side. Entering it once can establish the initial position, but changing it programmatically does not trigger a callback. During a drag, the application does not have to update `value` continuously. This can remove one common source of feedback loops, although it also means screen state and callback reporting must be designed around the documented event model.

The interaction limits provide only one lower and one upper bound through `minimumValue` and `maximumValue`. The README does not document a second thumb or multi-range output, so the package is the wrong tool for a lower and upper bound that must be selected together. `lowerLimit` and `upperLimit` can constrain user movement on Android, iOS, and Web, but the listed API still describes selection of a single value.

Platform parity has further edges. Tapping the track to seek works on iOS when `tapToSeek` is enabled, but it has no effect on Android or Windows. Vertical orientation is documented for Windows only. Maximum and minimum track images are documented as iOS properties. An interface that relies on the same image assets or input gesture across all four platforms cannot be inferred from the shared component name.

A related visual constraint appears on Android: `thumbTintColor` overrides `thumbImage`, and the README warns that supplying both may cause the image to render incorrectly. This is a concrete reason to test the exact prop combination used by a screen rather than assuming that every custom thumb option composes cleanly.

MIT licensing and the alternative of native platform controls

The repository declares the MIT license. That identifier is relevant when reviewing whether the package's licensing terms fit an application's distribution model, but this repository excerpt does not include the full license text or provide legal interpretation. Package consumers should review `LICENSE.md` and any dependency terms themselves.

The main alternative is to use the platform's native slider directly in each application layer. That approach uses `Slider` on iOS and `SeekBar` on Android rather than a shared React Native package. Its advantage is direct access to native behavior and platform conventions. Its cost is cross-platform divergence: the application must manage separate imports, implementations, styling, and possibly separate platform tests.

`@react-native-community/slider` takes the opposite approach. A screen imports one component, while the package maps shared props to the supported platform controls. It also adds a documented web path and keeps several concepts such as minimum value, maximum value, steps, disabled state, and sliding callbacks in one API. The trade-off is that genuinely native work, including pod installation and platform-specific prop behavior, remains part of the integration rather than disappearing behind the shared import.

Editorial conclusion

Adopt this package when a React Native application needs a conventional single-value slider and can accept its platform differences. Do not choose it for multi-range selection or workflows requiring controlled updates during dragging. Verify React Native compatibility first, then confirm that the relevant iOS, Android, Windows, or web props behave as required before adoption.

Frequently asked questions

Official sources

1. callstack/react-native-slider on GitHub
2. Issues
3. License: MIT
4. README
5. Releases