Framework7: A Mobile HTML Framework That Ships iOS and Android Looks Without a Native Toolchain

What Framework7 Solves, and Who It Is Actually For

Framework7 is a full-featured HTML framework for building iOS and Android apps, according to its own description. That phrasing matters more than it looks. The project does not compile your code into native widgets. It gives you a component library whose default styling and behaviour imitate the two mobile platforms, and it gives you the JavaScript to drive those components. Your app remains a web app that happens to run inside a mobile shell.

The audience follows from that. If you write Vue, React, Svelte or plain JavaScript and you want an app that looks native on both platforms without maintaining two codebases, this is the intended use. The repository ships separate Babel configurations for React, Vue and Svelte (babel-react.config.js, babel-vue.config.js, babel-svelte.config.js), which tells you the bindings are first-class build targets rather than afterthoughts. The topics list includes cordova and phonegap, so the historical packaging route through a WebView container is part of the project's identity.

It is not for teams that need true native rendering, direct access to every platform API, or predictable performance under heavy computation. Nothing in the repository suggests otherwise.

How the Core, the Bindings and the Build Fit Together

The repository is a monorepo with a src/ directory for the core, a packages/ directory for the published artifacts, and a build/ directory driving Gulp. The root package.json is named framework7-source with version 0.0.0, which is the standard signal that the root is not the published package. The published packages are what you install.

The build scripts show the layering. build-core runs the core build, and the Vue, React and Svelte builds run with CORE_BUILD_ONLY_MODULES=true for development, meaning the core is built as modules and then consumed by the framework-specific packages. There is also a CORE_BUILD_ONLY_UMD=true path for a UMD core build, which is what a script-tag or CDN user would load. That single flag is the clearest evidence that the project supports both a bundler workflow and a plain script include.

The kitchen-sink directory is the other structural fact worth knowing. It contains parallel implementations for core, React, Vue and Svelte, each built with its own command (gulp ks-core, and vite build kitchen-sink/react, kitchen-sink/vue, kitchen-sink/svelte). If you want to see what a component looks like in your framework of choice before installing anything, that is where to look.

Installing Framework7 and Rendering a First View

The README does not carry install instructions; it points to framework7.io as the homepage. The repository does show how the project itself is built, and the published packages are the normal entry point. A typical install pulls the core package from npm:

npm install framework7

If you are using a framework binding, you install the matching package instead. The build scripts name the Vue, React and Svelte targets, and the repository keeps a separate Babel config for each, so the package names follow the framework. The README does not list the exact package names, so check the packages/ directory or the homepage before running the install.

For a plain script include, the UMD core build is the relevant artifact. The build script that produces it is:

npm run build-core:dev

That runs with NODE_ENV=development and CORE_BUILD_ONLY_UMD=true, producing a UMD core build. In the browser, the framework exposes an app constructor; the README does not give a full example, so treat the kitchen-sink core implementation as the reference for initialisation order and required parameters.

The fastest way to see a working app is to build the demo rather than write one from scratch:

npm run build-ks

That chains the core, React, Vue and Svelte kitchen-sink builds. What you should see afterwards is a set of built demo applications under kitchen-sink/, one per framework binding, which you can open and compare against the components you plan to use.

Where Framework7 Stops Being the Right Tool

The central limitation is the one the project's own description implies. Framework7 renders HTML. A component that looks like an iOS picker is still a DOM element styled and scripted to behave like one. When the platform changes a control, or when a user has accessibility settings that the imitation does not honour, the imitation is what you have. The repository does not publish a device or OS support matrix, so there is no documented answer to how far back the platform styling is validated.

Performance is the second boundary. A WebView app carries the WebView's cost. If your workload is scrolling long lists with images, or running continuous computation, the framework does not change that. The repository has no benchmark files, and the README makes no performance claims. Anyone who tells you otherwise is not reading this repository.

Third, the release cadence is real but the maintenance signal is mixed. The last push was on 2026-09-08, and the most recent release listed is v9.1.2 on 2026-07-28, so the project is not archived and is being pushed to. But the README's sponsor table currently includes a large number of casino, follower-purchase and view-bot links. That is a funding arrangement, not a technical defect, and it says nothing about code quality. It does mean the README is not a reliable place to learn what the project is, and you should read the homepage and the kitchen-sink instead.

Framework7 Against Ionic, Quasar and React Native

The comparison people ask about most is Ionic, and the difference is architectural rather than cosmetic. Ionic centres on Web Components and a CLI-driven project structure, and its components are framework-agnostic by design. Framework7 ships a core plus first-party Vue, React and Svelte bindings built from one source tree, with a kitchen-sink implementation for each. If you are already in Vue or Svelte, Framework7's bindings are the closer fit; if you want one component layer shared across several frameworks without a binding, Ionic's model is the more direct answer.

Against React Native, the split is starker. React Native renders native views through a bridge, so a list is a native list. Framework7 renders DOM inside a WebView. That means React Native can reach platform behaviour Framework7 cannot, and Framework7 can reuse web skills, CSS and browser tooling that React Native cannot. Neither is a superset.

Quasar occupies a similar position to Framework7 in that it targets multiple platforms from a Vue codebase, but Quasar's scope extends to desktop and to a build toolchain that generates the project scaffolding. Framework7 leaves more of that to you and gives you the component layer. Flutter is the outlier here: it draws its own widgets with its own renderer rather than using the platform's or the browser's, which is a different bet entirely.

Licence, Upgrade Cost and What the Repository Does Not Tell You

Framework7 is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice, and if you are shipping in a regulated context you should have counsel read the actual file rather than this paragraph.

The README frames funding through Patreon and a backers list, which is worth understanding before you depend on the project. MIT gives you the code; it does not obligate anyone to fix your bug or ship your feature. The version history shows a 9.x line with patch releases in June and July 2026, so the project is on a major version that has been receiving point updates. Upgrading across a major version is the cost to plan for, and the repository keeps a CHANGELOG.md at the root, which is where the breaking changes will be recorded.

What the repository does not give you: a documented support matrix, a stated browser or WebView baseline, migration guides outside the changelog, or any performance data. Those gaps are the ones to close before you commit a release schedule to this framework.

Editorial conclusion

Framework7 fits teams that already write web front ends and want iOS and Android presentation without a native toolchain, especially when Vue, React or Svelte is already in the stack. It is the wrong choice when you need compiled native widgets, heavy background processing, or platform APIs that have no web equivalent. Before committing, open the kitchen-sink demo for the exact components you plan to use and check them on both iOS and Android, since the repository ships the demo but the README does not document a support matrix for older devices.

Frequently asked questions

Official sources

1. framework7io/framework7 on GitHub
2. License: MIT
3. Project website
4. README
5. Releases