react-native-ui-datepicker: a date picker you have to style yourself

Unstyled by default, which is the whole point and the whole cost

The feature list leads with the design decision that matters. The component is unstyled by default, every component is minimally styled and fully customizable, and the description in the project description says it allows you to customise the calendar based on your own UI design. The mechanism is a set of props for fine-grained calendar customisation plus the ability to extend the rendered elements with custom components, so a week row or a day cell can be replaced rather than merely restyled. The performance claim in the list is that it re-renders only the elements that actually change, and the size claim is that it is fast and lightweight, with a bundle size badge on the readme. The trade is the one every unstyled component makes. A picker that looks acceptable out of the box saves a day, and a picker that looks like the rest of your product saves a week of arguing about borders and typography. What you give up in the first case is a component that will not match your design system, and what you give up in the second is a large amount of your own time.

Three selection modes with different prop sets

The component supports three selection modes, chosen with the mode prop, and the values are single, range and multiple. Each mode has its own prop list, which is worth knowing before you design your wrapper. Single mode takes a date, an onChange callback that receives an object with a date, a timePicker boolean to enable the time picker, and use12Hours to switch the time picker to a 12-hour format. Range mode takes a startDate and an endDate, an onChange that receives both, a min and a max defining the minimum and maximum allowed nights, and an allowRangeReset flag which, when true, means that tapping any date while a complete range is already selected clears the end date and starts a fresh selection from the tapped date, defaulting to false. Multiple mode takes a dates array, an onChange receiving the dates, a max on the number of days selectable, and a multiRangeMode boolean. The allowRangeReset behaviour is the kind of small decision that is easy to get wrong in a wrapper, since the default means a user who taps a date inside an existing range does not get a new range.

The calendar prop is where the Jalali support lives

The calendar prop takes either gregory or jalali, and that single value switches the entire calendar system, which is the reason the project is worth knowing about beyond a general date picker. The Jalali, or Persian, calendar is a solar calendar with a different year structure, and a picker that offers it without rewriting the date maths is not a small thing. The example in the readme shows how dayjs is used in the enabled and disabled date callbacks, with dayjs called on the date to get the day of the week, and that pattern is how you would filter dates for a Persian calendar too, provided the dayjs instance is configured for the Jalali calendar. Alongside that, the base props include a firstDayOfWeek number from 0 to 6 where 0 is Sunday, minDate and maxDate as the selectable bounds, and enabledDates and disabledDates, each of which accepts either an array of dates or a function returning a boolean for the date, with enabledDates taking precedence over disabledDates. The initialView prop chooses the first screen the picker opens on, with the values day, month, year and time, and month and year props plus their change callbacks let you drive the displayed month and year from outside.

Time zones, localisation and NativeWind

Two of the claims are about correctness rather than presentation. The component handles different time zones without extra work, which matters for anything that stores a date chosen in one zone and displays it in another, and it is easily localizable into any language, which is what makes the Jalali use case work at all. The third is NativeWind compatibility, which is listed as fully compatible, and that matters more than it sounds because a component that emits its own class names cannot be restyled by a utility-first system. The NativeWind approach here is the classNames prop, and the readme's basic usage shows it alongside the styles prop. The default styles are obtained from a useDefaultStyles hook, which returns a style object you can pass straight in or override key by key. So there are two styling routes, a styles object for StyleSheet style objects and classNames for utility classes, and the component works with either or both.

Installing and using it in a project

The install is one command, and the package is on npm:

npm install react-native-ui-datepicker

The usage pattern in the readme is deliberately short. You import the component along with the DateType and the useDefaultStyles helper, keep the selected value in state, and pass it down:

import { useState } from  'react';
import DateTimePicker, { DateType, useDefaultStyles } from 'react-native-ui-datepicker';

export function Calendar() {
  const defaultStyles = useDefaultStyles();
  const [selected, setSelected] = useState<DateType>();

  return (
    <DateTimePicker
      mode="single"
      date={selected}
      onChange={({ date }) =>  setSelected(date)}
      styles={defaultStyles}
    />
  );
}

The shape to notice is that the value lives in your component and the picker is controlled, with the date and the onChange given to it rather than the picker owning the state. The second example shows the props doing real work, with a minimum date set to today and two date filters where the enabled function keeps only Mondays and the disabled function removes weekends, and the note in the table that enabledDates takes precedence over disabledDates. The repository is a standard React Native library shape, with the source in src, a demo application, an example project, a jest configuration and a babel configuration, and the published package ships both the source and the built lib, plus the android and ios directories and the podspec.

The build pipeline, and where the releases sit

The packaging metadata shows a library built with bob, since the prepack script runs bob build, and the published entry points are arranged by module system, with a commonjs main, a module field, a types field pointing at the generated declaration file, and an exports map that distinguishes import from require and carries the types condition. The react-native and source fields point at the source directory, so a consumer bundler can compile the TypeScript directly rather than use the built output, which is a common pattern in the React Native ecosystem. The files array is unusually explicit, listing src, lib, android, ios, cpp and the podspec, and excluding the built example, the ios and android build directories, the gradle wrapper, the local properties file and the test, fixture and mock directories, so the published tarball does not carry the repository's own scaffolding. The release script is release-it, and the release history shows v3.3.0 and v3.2.0 both on 2026-05-20, with v3.1.2 from 2025-03-20 before that, and the last push on 2026-05-20. The two releases on the same day suggest a version bump with a breaking change followed by a fix, and the component is at version 3.3.0 in the metadata,

Editorial conclusion

react-native-ui-datepicker is a good fit for a team whose design system owns its own calendar, because the component ships unstyled and every element is yours to restyle, and for a product that needs range, multiple or Jalali selection, which the platform pickers handle poorly. It is the wrong choice if you want a working picker in an afternoon, because unstyled by default means every visual decision is yours to make and to test, and it is the wrong choice if you are on web only, since the platform picker is free on the web and the trade only makes sense on native. It is also the wrong choice if you need a stable API, since the release history shows recent major-version releases, with v3.3.0 current. Before adopting it, decide whether the time picker is in scope, since the time picker is enabled by a boolean and the range and multiple modes have their own prop sets, and check the first day of week and calendar props against the locales you ship. The project is MIT licensed, the last push was on 2026-05-20, and the current release is v3.3.0 from the same day.

Frequently asked questions

Official sources

1. farhoudshapouran/react-native-ui-datepicker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases