react-native-date-picker

react-native-date-picker wraps the platform-native date/time picker widgets on iOS and Android behind a single React Native component, so apps get the look, feel, and performance users already expect on each platform instead of a JS-rendered approximation. It supports three modes — date, time, and datetime — and can be rendered inline in a view or opened as a built-in modal with confirm/cancel handling.

The library ships native code for both React Native’s old and new architectures (Fabric + TurboModules, supported since RN 0.71 and library version 4.3.0), with separate oldarch/newarch Java sources and codegen’d native specs bridging the JS and native layers. Locale-aware ordering and 12/24-hour formatting, per-platform theming (light/dark/auto), minute intervals, and date range boundaries are all handled through this native bridge rather than reimplemented in JS.

What You Get

• A single <DatePicker /> component that renders genuine native pickers on both iOS and Android
• Three selection modes: date, time, and datetime, switchable via a mode prop
• Modal and inline usage, with confirm/cancel callbacks for the modal variant
• Locale-driven field ordering and 12/24-hour formatting, plus explicit theme control (light/dark/auto)
• Support for both React Native’s old and new architecture (Fabric/TurboModules), so it works across a wide range of RN versions

Common Use Cases

• Booking and scheduling forms that need a native-feeling date or time selector
• Profile/settings screens collecting a birthdate or reminder time
• Inline calendar-style pickers embedded directly in a screen instead of a popup
• Apps supporting many locales that need correct date ordering and am/pm conventions without extra i18n work

Under The Hood

Architecture The component is a thin JS dispatcher (src/index.js) that selects a platform implementation (DatePickerAndroid.js / DatePickerIOS.js) via Platform.select, normalizes props (color resolution, theme defaults, validation via propChecker.js), and forwards them to a native host component obtained through getNativeComponent/getNativeModule in src/modules.js. Native rendering lives in android/src/main/java/com/henninghall/date_picker (a PickerView built from wheel-based UIManager/Wheels classes) and ios/RNDatePickerManager.mm, with src/fabric/RNDatePickerNativeComponent.ts and codegen config in package.json generating the TurboModule/Fabric specs that bridge JS calls to native code; separate src/newarch and src/oldarch Java packages let the same JS layer target either React Native architecture.

Tech Stack The JS/TS layer is plain JavaScript with JSDoc typings plus a hand-written index.d.ts, built against react-native >=0.64 and react >=17 as peer dependencies. The Android native side is Java (Gradle-built), the iOS side is Objective-C/Objective-C++ (CocoaPods via react-native-date-picker.podspec), and RN’s codegen tooling generates the new-architecture bridging code from the codegenConfig block. Babel and TypeScript (5.x) handle JS transpilation and type-checking.

Code Quality The repo runs a substantial CI matrix (10 GitHub Actions workflows) covering Android/iOS builds, Android/iOS end-to-end tests via Maestro (.maestro/*.yml), JS unit tests (Jest, e.g. colorConversions.test.js), linting (ESLint + @react-native/eslint-config), and TypeScript type-checking on every PR and push. Four pinned example apps (examples/Rn069 through Rn073) exercise the library against different React Native versions to catch upgrade regressions, though the native Java/Objective-C code itself relies on the Maestro E2E suite rather than native unit tests for coverage.

API Design The public API is a single component with a flat, well-documented prop list (typed in index.d.ts with inline doc comments) covering mode, locale, theming, and modal behavior, so most consumers only need date, onDateChange, and optionally modal/open/onConfirm/onCancel to get started — the library front-loads sane defaults (auto theme, datetime mode, 1-minute interval) so no configuration is required for the common case.