Designing NativeBase 3.0: Architecture & Forthcomings
Tags: reactnative, react, ux, ui
Published: 2020-04-24 13:29:07

NativeBase 2.0 was built in 2016 and a lot has changed since then. Design Systems, Design guidelines, the way we write components in React Native. Everything has evolved and now it’s time we revisit and rebuild NativeBase from the ground up.

The line between React & React Native is blurring quickly. Controversial CSS-in-JS is making its way into the mainstream web with styled-components & emotion.

With these advancements in mind, we are considering an overhaul of NativeBase that will not only fit the ever-evolving React ecosystem today but it would also be future-ready (we can only hope so.)

In light of this, we have officially started working on the next major release of the UI Component Library for React Native that will ease our development process further.

**Nativebase 3.0 is now under development.**

Aimed to make development in React Native simpler for the day-to-day dev, NativeBase has gone through two major versions which has guided this library towards sophistication and efficiency. Now, after almost 4 years of the first release and 2.5 years of the second major release, NativeBase 3.0 is on its way to be bigger, better, aesthetically superior and much more flexible.

## A little history:

![NativeBase Timeline](https://dev-to-uploads.s3.amazonaws.com/i/hf8ps8gbr6idid6o1qlf.jpg)

Back in November 2015, when we were introduced to React Native, @sankhadeeproy007 and I built a starter kit as an experiment and called it **‘Native Starter Pro**’. It was our first ever paid React Native template for mobile apps and gathered quite a crowd.

On the back of that, we involved ourselves in multiple projects in React Native, during which we felt the need for a UI Component Library. The sheer lack of a button component sparked an idea and on April 15th, 2016, **NativeBase was born**.

Honestly, NativeBase 1.0 was unpolished but it got the job done and people started to notice. NativeBase 1.0 was heavily inspired by ionic design. We tried to achieve the exact same API that Ionic uses but we realized that it gave away with the ability to customize. So, we decided to make the API easier by arranging components under semantic tags…

...which led us to April 7th, 2017, when NativeBase 2.0 was launched.

NB 2.0 was highly polished on the UI side. We chose to follow Material Design & Ionic Design guidelines specifically and tried to match components with these guidelines to the pixel.

NativeBase 2.0 is by far the most downloaded version in the series’ history, with over **2.9 Million downloads** and **13.7k stars on GitHub**.

## Features of NativeBase 3.0 (so far):

![Building NativeBase 3.0](https://dev-to-uploads.s3.amazonaws.com/i/0vopfuoqcvculepwv2cg.jpg)

One of the aims of NativeBase 3.0 is to give power to devs and brand owners. Today, the boundary between different design systems for different platforms has been partially erased by branding and the need to achieve consistency. Not many apps in the market today follow strict design guidelines, all in the name of branding and consistency & we’ve noticed that.

{% twitter 1251984802359595008 %}

The very first thing that you will notice in Nativebase 3.0 is that we don’t have platform-specific designs. The freedom will lie with the end-user to choose how their design looks on different platforms. We want to make it more customisable so that the user can make it look like an android/iOS app with custom styling.

{% twitter 1251770290155085824 %}

{% twitter 1251835650967506950 %}

To achieve this, Flutter Material is a strong inspiration for us as it has a rich component library and does not have many usage constraints.

{% twitter 1240605404700094464 %}

What we’re debating on right now is that if people like the idea of a unified API for Material & Cupertino guidelines. We would love to know what you think, so reach out to us and let us know on our **Twitter**.

NativeBase 3.0 will also use **styled-system** and **styled-components** to provide utility classes (as supplied by Tailwind CSS) which will be passed as props and not as CSS styles. This will translate into us having a fixed set of rules defined in our theme files and allow us to make **NativeBase available for the web as well (**It’s on the roadmap but the current focus is on the mobile end of it.)

Another reason behind this choice is because of its support for React Native (obviously :)).

NativeBase 2.0 saw the use of React Native Easy Grid or creating rows and columns in a grid. NativeBase 3.0 will retain that, with the addition of usage of <**Stack> and <Inline> components** to enhance this feature.

Well, folks, that’s all the update we have right now on the new NativeBase. We want to take this moment to thank you all for your continued support and love. It is what drives us to be better and is the real force behind NativeBase 3.0.

Stay tuned with us for more updates as NativeBase progresses.

Follow us on **Twitter** to get constant updates on the status of NativeBase.

Also, if you have time, check out our **livestream** where @sankhadeeproy007, @hanykumar and I discuss the forthcomings and NativeBase of the past below.

{% youtube qHNb0rTSSJA %}

Also, stay tuned for more livestreams to come.

I want to give a big shout out to @digvijayw for helping me write this article right from the beginning when it was a vague idea in my head.