Ionic Framework: a Web Components UI toolkit for iOS, Android and the web

What Ionic Framework solves, and who it is aimed at

Building the same product for iOS, Android and the browser usually means maintaining three codebases, or accepting a lowest-common-denominator web view. Ionic Framework takes the second path deliberately: the README describes it as "an open source app development toolkit for building modern, fast, top-quality cross-platform native and Progressive Web Apps from a single codebase with JavaScript and the Web." The output is a web application that is packaged for app stores or served as a PWA, with UI components styled to match each platform.

The intended user is a web developer. If you write Angular, React or Vue today, the toolkit adds a component layer rather than a new language. That is the main dividing line against alternatives that compile a different language to native binaries.

The repository is a monorepo. The README lists four published packages: @ionic/core, @ionic/angular, @ionic/vue and @ionic/react. Each has its own README under core/ or packages/. The root package.json is explicitly private and exists to run build scripts, with lerna and semver as devDependencies and an engines field requiring Node >= 16. So the thing you install into an app is never the repository root; it is one of the four packages.

How the Web Components architecture maps to Angular, React and Vue

The README states that Ionic is based on Web Components, and that this "enables significant performance, usability, and feature improvements alongside support for popular web frameworks like Angular, React, and Vue." That sentence is the whole architecture in miniature. The components are custom elements defined by the platform, not framework-specific widgets. The Angular, React and Vue packages exist to bind those elements into each framework's rendering and lifecycle model.

The practical consequence is that @ionic/core is the substrate. The framework packages are adapters. A bug in component behaviour should be reproducible against core; a bug in how a component interacts with React state or Angular change detection belongs to the adapter package. When you file an issue, that distinction decides which README you should have read first.

It also explains the versioning you see in the release list. v9.0.1 and v9.0.0 landed on 2026-08-26 and 2026-08-19, and v8.8.19 shipped on 2026-08-19 as well. A major line and a maintenance line moving in the same week is normal for a project that has to keep four packages aligned.

What the README does not do is explain how the adapters handle framework-specific concerns such as server-side rendering or form integration. For that you have to go to the per-package READMEs, which the root README links but does not summarise.

Getting a first Ionic Framework project running

The README contains no install commands. It says: "Start a new project by following our documentation," and its Quickstart link points to ionicframework.com/docs/intro/cli. The commands below are the ones that documentation page presents; check it before running them, because CLI flags change between majors.

Install the CLI globally, then scaffold a project. The CLI prompts for a framework, which is where you choose Angular, React or Vue.

npm install -g @ionic/cli
ionic start

If you would rather not scaffold a new project, the README's packages table gives the packages to add to an existing app. For Angular that is @ionic/angular; for Vue, @ionic/vue; for React, @ionic/react; and for framework-agnostic use, @ionic/core.

npm install @ionic/core

The root package.json requires Node >= 16 and lists lerna and semver as devDependencies, but that applies to building the monorepo itself, not to consuming the published packages.

For a worked example, the README points at three conference apps, one each for Angular, React and Vue, described as "a full featured Ionic app" and "the perfect starting point for learning and building your own app." Reading one of those repositories is a faster way to see component usage in context than reading the component docs in isolation.

Where Ionic Framework is the wrong choice

The toolkit renders UI. It is not a native runtime, and the README makes no claim that it is. If your product depends on background location, custom Bluetooth protocols, on-device machine learning or heavy media processing, the web layer will need a native plugin or a native shell behind it, and you are now maintaining two stacks instead of one. That is the point where the single-codebase argument weakens.

There is a second cost that the README does not discuss: major version migrations. The README links migration guides for v7 to v8, v6 to v7, v5 to v6, v4 to v5 and v3 to v4. Five consecutive majors each needing a written guide tells you the upgrade path is real work, not a version bump. The repository also carries a BREAKING.md file and a BREAKING_ARCHIVE/ directory, which is a further signal that breaking changes are tracked as a first-class concern.

Finally, the README is silent on rollback. There is no documented procedure for reverting a release or pinning a package set across the four packages if one adapter regresses. If you run Ionic in production, that gap is yours to fill with your own lockfile discipline.

Ionic Framework compared with React Native

The comparison people search for most often is against React Native, and the difference is structural rather than cosmetic. Ionic Framework renders Web Components inside a web view and ships the same bundle to the browser and to app stores. React Native renders platform-native views through a JavaScript bridge and produces an app, not a website.

That changes what you get for free. With Ionic, the PWA is not a separate build target; the README's own framing puts "native and Progressive Web Apps" in the same sentence, from the same codebase. With React Native, a browser build is a different project.

It also changes what you give up. Native view rendering is why React Native apps feel closer to platform conventions in areas the web does not reach, such as gesture handling at the system level. Ionic's answer is per-platform styling of its own components, which is a visual and interaction match, not a native view tree.

A secondary difference is framework lock-in. React Native is React only. Ionic Framework publishes adapters for Angular, React and Vue, so a team already standardised on Angular or Vue does not have to change frameworks to adopt it.

Maintenance status, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-08-26, the same day v9.0.1 was released. Three releases appear in the recent list: v9.0.1 and v9.0.0 on 2026-08-26 and 2026-08-19, and v8.8.19 on 2026-08-19. Two lines receiving releases within a week of each other is the pattern you want if you are on the previous major and not ready to move.

The licence is MIT, per the LICENSE file and the README's licence link. MIT is permissive: it allows commercial use, modification and redistribution with the copyright notice and permission notice preserved. That is a statement about the licence text, not legal advice about your product. Note that the licence covers the framework code; the Ionic name and logo are a separate question the README does not address.

Upgrade cost is the real ongoing expense. Budget for reading the migration guide for each major you cross, and for checking the per-package READMEs, because the four packages can move independently even when the version numbers look aligned. The BREAKING.md file at the repository root is the place to look before you start.

Editorial conclusion

Adopt Ionic Framework when your team already writes Angular, React or Vue and you want one codebase that ships to browsers and to app stores without learning Dart or Swift first. Do not adopt it when you need deep native modules, background execution or heavy on-device computation, because the toolkit renders UI and does not replace native code. Before committing, verify two things: that your target framework package (@ionic/angular, @ionic/react or @ionic/vue) matches the version you plan to run, and that you have read the migration guide for the major version you are moving from, since the README lists separate guides for v7 to v8, v6 to v7, v5 to v6, v4 to v5 and v3 to v4.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes