What is the best practice use case for (calendar) date pickers? Native or custom?

Native looks great on iOS and Android devices, however when we look at non-mobile calendar pickers the browsers vary in design and usability. The requirement is to design a calendar picker that is mobile-first but compatible at larger breakpoints.

Has anyone come across this situation before? How did you approach it? What should I consider?

1 Answer 1


Native controls usually provide a better user experience (more familiar to the user, better platform specific feature support, etc.), but as you noted that varies across platforms.

A few things to keep in mind are:

How and where will this program be used?

If the program is going to be used in a work environment (like order picking in a warehouse) where people are trained how to properly use the software (and it can be running on any number of platforms), then consistency across platforms probably outweighs the UX benefits of native controls.

If the program is to be used by individuals, then using native controls makes the app more predictable and harmonious.

What expectations does the user have from seeing other parts of the app?

Consistency is important. Consistency with the host platform is optimal, but consistency within your own app is essential.

If you are using custom controls everywhere else in the app, then a single native control might feel out of place (and vise versa).

What is the reliability of each option?

If the native control is not reliable, then a custom control becomes the only option (and vise versa).

What are the available development resources, and how often will the user see it?

First of all I am NOT advocating "close enough is good enough", however it is a sad fact of life that most teams have limits on how much time and money can be allocated to a feature. And when that happens we have to make hard choices.

If this control is used frequently or prominently, then it may be worth the development resources to create and maintain the infrastructure required for using native on some platforms and an alternative control on others.

However if only a small percentage of users will ever see this control, then you may decide to apply the development resources to more visible or critical places in the app.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.