UI Kitten: runtime theming for React Native apps

The multi-brand theming problem UI Kitten targets

Most React Native component libraries treat theme as a build-time decision. You pick colors, wire them through StyleSheet objects or a context provider, and changing them means a rebuild. UI Kitten takes a different position: the README states that themes can be changed at runtime, with no need to reload the application. That single property defines the audience. If you ship one app with one palette, the theming machinery is overhead you carry for nothing. If you ship a white-label product, a client-facing app with a light and dark mode toggle, or an internal tool that has to match a customer's brand colors, runtime switching is the feature you would otherwise build yourself.

The library is based on Eva Design System, and the README describes the goal as consistency and scalability in the design and development process. Eva supplies the token layer: colors, typography and spacing are defined as a design system rather than scattered across components. UI Kitten is the React Native rendering of that system. The README lists 25+ general-purpose components, SVG Eva Icons support with 480+ icons, and Light and modern Dark themes as the shipped defaults, plus the ability to create your own.

That framing has a consequence worth stating plainly. UI Kitten is opinionated about appearance in a way that unopinionated primitives are not. You get a coherent look immediately, and you give up some freedom in how each control is composed. The trade is deliberate.

How the theming and component layers fit together

The repository is a Yarn workspace monorepo. The package.json declares workspaces under src/* and docs, and the root package is marked private with version 5.3.1, so the root is a build and tooling shell rather than the published artifact. The published packages live in the src subdirectories, which is why the release feed shows scoped names like @ui-kitten/processor, @ui-kitten/moment and @ui-kitten/metro-config rather than a single package.

The build pipeline is Gulp-based. The scripts block defines build as gulp build, parse-docs as gulp parse-docs, and publish-packages as gulp publish-packages. Documentation is generated from the source tree: view-docs runs the showcases app, parses docs from it, then starts the docs site. This is a documentation-as-code arrangement where component examples in src/showcases double as the snippets published to the documentation site.

The runtime theming itself is not described in the README beyond the claim that it works without a reload. What the README does establish is the dependency shape: the root declares react 18.1.0 and react-native 0.70.6, and the dev dependencies include @eva-design/eva and @eva-design/material at ^2.2.0. The presence of two Eva packages points at the intended extension path: themes are data, and a theme can be swapped by supplying different data rather than recompiling components. The README does not document the mapping API, the theme provider component, or what happens to component state during a swap. For those details it points to the documentation site.

A separate package, @ui-kitten/metro-config, appears in the release feed. The README does not explain it, but its name and the metro toolchain in React Native suggest it handles asset or bundler configuration for the library. Treat that as an inference from the package name, not a documented guarantee.

Starting a project with the UI Kitten template

The README gives two scaffolding commands. The first initializes a JavaScript project, the second a TypeScript one. Both use the React Native CLI's template flag, so the template is fetched at init time rather than installed afterward.

npx react-native init MyApp --template @ui-kitten/template-js

npx react-native init MyApp --template @ui-kitten/template-ts

Run one of these in an empty directory. The README states this sets up a new React Native application configured with UI Kitten, so the theme provider and the Eva dependency should already be wired when the command finishes. Pick the TypeScript variant if you want the component props typed; the repository itself is TypeScript, so the types are first-class rather than a separate definitions package.

The README also says to refer to the documentation for other options to start, which is the honest signal that the template is one path among several. If you already have an app, the template is not the route; you would add the packages to an existing project instead, and the README does not spell out that procedure.

For a working reference rather than a blank scaffold, the README points at Kitten Tricks, a starter kit it describes as having over 40 screens in dark and light themes. That is the closest thing to a live demonstration of runtime theming in the project's own documentation, and it is a separate repository from the library.

One practical note on versions. The root package.json pins react-native 0.70.6, while the newest published packages in the release feed are 6.0.0-beta.1 builds dated 2026-08-07. The README does not reconcile those numbers. Check which version the template installs before you build on top of it.

Where UI Kitten stops being the right tool

The component count is the first boundary. 25+ general-purpose components covers buttons, inputs, layout and the usual primitives, but it is not a catalog of every widget a mobile app needs. Date pickers, charting, complex data tables and platform-specific pickers are not in the README's list. The release feed does show an @ui-kitten/moment package, which suggests date handling has some first-party support, but the README does not document its scope, so do not plan around it without checking the docs.

Mixing libraries is the second boundary, and it is the one teams hit in practice. Every third-party React Native component you add brings its own styling approach. If it does not read Eva tokens, it will not follow a runtime theme swap, and you end up with a screen where half the controls change color and half do not. The README's answer to this is to construct the interface from UI Kitten components following Eva specifications. That is a real constraint, not a suggestion: the theming guarantee only extends as far as the components that honor it.

Runtime theming also carries a cost the README does not discuss. Swapping theme data at runtime means components must subscribe to theme changes and re-render. On a screen with many UI Kitten components, that is a broad re-render pass. The README makes no performance claim in either direction, and nothing in the repository provides a benchmark, so the honest position is that you should measure it on your own screen composition before assuming the swap is free.

Finally, the maintenance picture. The repository is not archived, and the last push was on 2026-09-11, so work is happening. But the published packages at the top of the release feed are beta builds. If your project cannot absorb a beta dependency, you are on the 5.x line and should confirm which version the template resolves to.

React Native Paper and Tamagui as different answers

The alternatives people search for alongside UI Kitten are React Native Paper and Tamagui, and they differ from it in ways that matter more than component counts.

React Native Paper follows Material Design rather than Eva. The practical difference is where theming lives. Paper's theming is a React context of colors and typography that components read, which is a similar mechanism, but the visual language is Google's. If your product already looks Material, Paper removes a translation step that UI Kitten adds. If you need to match a non-Material brand, UI Kitten's design-system-first structure gives you a token layer to redefine, while Paper gives you a theme object to override.

Tamagui takes a compiler-first approach. It optimizes styling at build time and targets both React Native and web from one codebase, which is a different problem statement than UI Kitten's. UI Kitten is mobile-only per its README, which describes cross-platform mobile applications. If you need a shared component layer across web and native, that requirement alone rules UI Kitten out, and no amount of theme flexibility compensates.

The honest summary: UI Kitten's distinguishing claim is runtime theme switching without an app reload, on top of a named design system. If neither runtime switching nor Eva matters to you, the choice comes down to which visual language and component set fits your screens, and the alternatives are at least as reasonable.

Licence, maintenance and what an upgrade costs

The repository is MIT licensed, and the README repeats that under a License heading pointing at LICENSE.txt. The root package.json also declares MIT. For most teams this is the permissive case: you can use the library in commercial and closed-source apps. MIT does not grant trademark rights, so the Akveo and Eva Design System names are not yours to use in your product branding. That is a general property of permissive licences, not legal advice; run it past your own counsel if branding matters.

Upgrade cost is the more concrete question. The version numbers in the repository do not line up: the root package.json says 5.3.1, the newest published packages are 6.0.0-beta.1 dated 2026-08-07, and the README says nothing about migration. The repository does carry a CHANGELOG.md at the top level, and the bump-version script runs conventional-changelog against it, so changelog entries are generated from commit messages. That is where to look for breaking changes, because the README will not tell you.

The monorepo structure shapes upgrade mechanics. Because the library publishes multiple scoped packages, a major bump can move several of them at once. The release feed shows @ui-kitten/processor, @ui-kitten/moment and @ui-kitten/metro-config all at 6.0.0-beta.1 within seconds of each other, which is what a coordinated multi-package release looks like. Expect to update more than one dependency line when you move major versions.

There is no documented deprecation policy and no stated support window for older majors. The README does not address it. If you need a library with a published long-term support commitment, that is a gap to weigh before adopting.

Editorial conclusion

Adopt UI Kitten when runtime theme switching and a small, consistent component set matter more than breadth of third-party widgets, and check the version you install against the 6.0.0-beta.1 packages before committing. Skip it if your app depends on community component libraries that ship their own styling, since mixing them with Eva theming means maintaining two token systems. Before writing screens, verify on a device that theme changes apply without a reload and that the @ui-kitten/template-ts output matches your React Native version.

Frequently asked questions

Official sources

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