I was lucky in life that I started very early with coding and a bit of design. My first computer language was QBasic. Back then, we had an early version of Photoshop and CorelDraw, and there I was on the overlap of design and code. Right after I graduated in 2011 as an engineer, I started a product studio called GeekyAnts.

We are very active in the developer community of React, React Native, and sometimes Flutter. At the same time, we are doing a lot of UX/UI design using tools like Figma.

Now we stand at the intersection of design and code, which is a big part of design systems. We are currently building a design system for a popular leader in its industry. That is helping us explore fresh ideas and experiment.

We also believe that communities will play a major role in the maturing of the design system ecosystem. Our recent Design System meet-up was a start towards this direction. If we can achieve what we did for the React Native community, we will have something magical in our hands.

In 2016 React Native was released for Android, and we jumped right in. After some research, we built a UI component library called NativeBase, which is the most significant open-source contribution by GeekyAnts.

We used to call it the Bootstrap of React Native back then because it was the missing piece in the React Native community. There was no component library, so we built one, but lately, it has evolved into more of an ecosystem. And now, NativeBase is supported on web platforms as well.

Right now, we are moving in a direction that makes it more of a base layer that people can use to build their design system, and it includes an entirely replaceable theme that can be customized.

We have 2-3 developers working on the codebase full-time and ensuring all the issues are resolved. Apart from that, we have 1 designer and 1 architect who are involved part-time after the release of v3. They primarily ensure that all changes and merge requests follow our guidelines.

The team also makes sure that support queries on our Discord server get addressed in a small time window. And then we have someone responsible for building out the community as well. Because, what is an open-sourced project without a thriving community?

At this point, new feature development is not the main priority, and most of our focus goes into interacting with our users and making sure they’re happy. For example, our last sprint was focused on performance enhancements. Along with that, we do general maintenance of the library, and it’s a part that goes forever. It means that people can get bored of it, so we keep shuffling people to let them work on new challenges.

In NativeBase, we must follow specific design guidelines, best practices, and a particular coding style. We’re trying to involve more external teams and encourage them to create pull requests, but we don’t get many new components built since there is a long checklist they would have to go through.

We’re trying to get a lot more contribution guidelines in place. I mean detailed guidelines and a roadmap which is a complex task. Doing that is more manageable when working on an open-source project driven by a company, but we want NativeBase to stay a community project.

Growing people within this team is problematic because it's focused on a small piece of the company's overall focus. For example, people working in the NativeBase team wouldn't have enough exposure to topics like state management or handling API calls.

At GeekyAnts, your career might start as an intern, and then we have 3 levels going from software engineer to principal engineer. To help our employees grow, we mix and match them across different teams and help them learn full stack development to ensure they can work across multiple domains.

Totally. React Native market sizing is much smaller than React and web, and you’re targetting a very specific audience in the end. So we’re looking outside of the React Native ecosystem and are building another tool that helps you build design systems, which allows defining the core system parts and then generates a website of the system for a specific brand.

We’re also experimenting with different types of outputs for it. For example, we are experimenting with generating a Figma component library with these tools, and later we’ll be able to have other types of output as well.

This means there are many more topics to work on when growing outside the component library itself.

Since we’re building across platforms, we couldn’t just implement the UI library. Instead, we had to go deeper and create a cross-platform accessibility library to handle all the complexity of working with components like dropdowns and its focus management. To address that, we’ve built a library called React Native Aria, which brings React Aria package functionality to native platforms.

It’s more or less acceptable for us since React Native addresses many platform-related challenges. We have a few places where we would write conditionals based on the platform. Still, they are not many since development principles started converging more over the last few years, and many applications look the same across all 3 platforms.

I can talk about a specific technical issue we've faced in v2 of NativeBase. We tried to implement an API close to vanilla CSS in React Native, including how style cascades work on the web. So, for instance, if you're applying a style like font-family on the wrapper component, it would trickle down to every element inside it.

Once the engine for the feature was built, the runtime overhead of calculating all those styles was huge since we were running this operation for every single element on the screen, and performance dropped severely.

We have fixed this issue in v3 and at the same time realized how people around us were already talking about how CSS cascading effect doesn't apply smoothly to native code. To fix this, we had to rewrite our styling model, and we've moved most of the style computations to the build time.

In our case, we haven’t seen a lot of people switching from v2 to v3 since there was a 1-1,5 year gap between these major releases. We’re still supporting some parts of v2, but new people using our library are just jumping to v3 directly.

If you talk about achievements in terms of numbers, this is the largest open source project that we’ve ever done. We’re close to 18,000 stars and around 60,000 weekly downloads on NPM, which is 7% of the overall React Native downloads. That means that 7 applications out of 100 built with React Native are using NativeBase. That’s pretty exciting!

Apart from that, we have the largest React Native meetup group in the world here in Bangalore. We host meetups almost every month and see people joining from large organizations and product companies using React Native and really like what we have built. So that feels really good.

Besides local communities, we connected to many people we would’ve never met otherwise. I think that’s the magic of the technology that connects people because we’ve all picked the same tech stack.

I think it would be the education part because design systems are built on an intersection of multiple teams. Designers and developers can’t pitch for funding the design system separately, and the person pitching needs to have exposure to all of its platforms and problems.

For example, we’re working with the design system of one of the largest companies in the world. The person who made it possible in that company had a good idea of both design and code. He worked on building a UI library there, so he had more chances at successfully pitching for this project in a vast organization.

We currently have a very limited number of people with experience in all design system aspects that could do this kind of work. That’s the missing piece and the hardest problem, I would say.

I think it’s very subjective, and there is no single answer. There are multiple factors, like the size of the company or the type of work they’re doing. For example, a company that does a back-office management solution differs from that deep into consumer marketing.

But one answer I really like is the one I heard from Sid in a design system meetup a few weeks back. He talked about a mood board experiment that companies should run when starting with design systems. Get all the primary decision-makers in the room, ask them what you want people to think when they hear about the company, and write them down on the board.

Arrange these words, and they become your central piece. That’s the starting point for choosing typography, colors reflecting that identity, and so on. Of course, for some companies, parts of it might already be well defined compared to those just starting. But we want to have these words so we can still go back to the mood board when we start defining our design systems end to end and refer to them later in the process.