The Present and Future of NativeBase
View more posts
October 3, 2022 3 minute read

The Present and Future of NativeBase

sanket@geekyants.com
Sanket Sahu
Building NativeBase
NativeBase, as it is today, is a result of constant experimentation. The v1 was a UI library where we could drop components into the environment. The second version was inspired by Material Design, where we reskinned components. This version worked quite well. The next version to follow was a game-changer.
The NativeBase v3 solved many issues the React Native community faced in 2018. At that time, most websites looked like cookies made from the same mold. The similarity was due to Bootstrap CSS and Material UI. Tailwind came out at this point with a utility-first design. However, they used units, which resulted in constraints.
We started building the same thing, keeping utility first. But usability and the universal nature of code were also a focus. Chakra UI entered at this point. It sparked a misconception that we were using the same API. That was not the case. We used Styled System internally, which gave us the utility props on components.
Eventually, we launched, and the version took off. Through iterations and bug fixes, we were able to update the library constantly. And in due course, we built React Native ARIA. It bridged multiple gaps and brought universal accessibility for React Native and React.

Today…

NativeBase has 65k weekly downloads, a figure that is double last year’s. We have improved significantly on the quality of the code. As a result, industry juggernauts are using it for their applications. An example is our work with a big restaurant chain currently underway.
We want to keep the momentum going. Continue on the path of making NativeBase the go-to UI and component library for React & React Native. And in the journey, empower the community to write code once and deploy it everywhere. The following is a roadmap of how we plan to achieve it.

The Future of NativeBase

Design systems that align every stakeholder with a click

We are working on making design systems (and website pages) a one-touch affair.
Our main goal, at the moment, is to help companies build their design system. To achieve this, we are working towards making NativeBase a spec. It is currently a component library that ships with its design theme. Once it becomes a spec and we launch the tool, it will make creating a design system effortless even outside the React ecosystem.
In the tool, we are going to use the spec of NativeBase. It will be an editor and help create a design system through inputs like primary color, sizes, different types of fonts, and columns. The tool we are building will accept inputs — primary color, sizes, fonts, etc.— and give out component libraries like NativeBase, Tailwind CSS, and Chakra UI. It will use NativeBase spec to define the actual thing.
 
We will have this tool map to different component libraries. The tool will not necessitate logging in to NativeBase. One can use Chakra UI or Tailwind CSS for web-based component libraries. The tool will also generate a design system website with documentation for each company & brand.
 
Here is a scenario that can happen: For example, consider an enterprise that wants to create a new design system. We will use this tool to create one. We will configure all the colors and other design parameters through minimal inputs. Once done, a button click will generate and ship the following.
  • A component library
  • A website for Design System, including
    • Design Philosophy
    • Design Assets
    • Documentation for component libraries
    • …and everything else that the stakeholder needs.
 
Both will be according to the brand guidelines, from the component library to the tone, look and feel. This will reduce iterations and reduce delivery turnaround time.
That said, the primary goal is to ensure developers, designers, and decision-makers are all on the same page.

Upgrading the ‘build once and deploy everywhere’ concept

One code for all the platforms — this is a philosophy we have always championed. We are looking at building starter kits to keep the momentum steady. For example, we have a starter kit using Solito by Fernando Roho. We are testing all its capabilities, and shortly, we plan to make it a default standard, i.e., Solito+NativeBase.
Expo is also working on universal routing, which is similar to Solito. It can take at least six months or more, but if we get support right from the Expo team, we will also have some integrations with it. We will also go back to the original idea of a no-code tool like BuilderX.

Supporting the Community Remains a Top Priority

NativeBase has always been community first, and that will never change. Our team will continue supporting the latest version of React Native and any new architecture of the future. Additionally, we will make supporting libraries and upgrade them.
We are also working on unifying the APIs for all the platforms. The team is working with Nicolas Gallagher, the creator of React Native for the web. We have sent PRs to React Native and are working on bringing the APIs of web and mobile close to the ecosystem.

Final Thoughts

We plan to keep NativeBase relevant and thriving with a vibrant community. Our team is focussing heavily on optimizing its performance. The results are great, and we are pushing out updates weekly.
It will only get better from here 😊