FTWA turns websites into frameless apps with your own browser

A launcher generator, not an application runtime

Free The Web Apps, shortened to FTWA, describes itself as a utility to free your web apps from their browser's frame, and the project's pitch is that you should not have to wait for a native desktop application, because the frontend developers have already done the work. The framing in the README is specifically about Linux users waiting for the Arc Browser to be available there.

The important thing to understand is what FTWA does not do. It does not download a web app, run it in an isolated runtime, or package a browser of its own. It generates a launcher that opens the site in the browser you already have, in the mode that hides the tabs, the address bar and the navigation buttons. The result looks like a standalone application in your launcher, and underneath it is a browser window.

The feature list spells out what you get. Native feel, without waiting for native apps. Quick access, because the generated entries show up in the application launcher and in the Rofi, Wofi and dmenu style launchers, and in Spotlight on macOS. Support for extensions, because the apps keep the browser's data, so cookies, storage and extensions all work as they would in a browser tab. And an app store, a gallery of web apps that the project says work especially well in a frameless browser.

The audience is therefore a desktop user, mainly on Linux, who lives in a keyboard driven workflow and wants a single tidy application list instead of a set of browser windows.

Chromium app mode, and a hand-built profile for Firefox

The mechanism is browser launch arguments, and it differs by engine.

For Chromium based browsers, FTWA uses the --app parameter with a URL, which the README describes as similar to kiosk mode. The website is launched without the typical browser interface, so there are no tabs, no address bar and no navigation buttons, and the page looks like an application rather than a document in a browser.

Firefox needs a different approach, and the README explains why in a way that dates the project precisely. The --ssb parameter, the Site Specific Browser mode, provided behaviour similar to --app in Chrome, but it was discontinued in 2021. So FTWA creates a new Firefox profile with custom CSS and settings instead, and the README credits the idea to a specific Reddit comment about what to do once Mozilla removed the feature.

That workaround is worth understanding rather than glossing over. A new profile is a new cookie jar, a new set of preferences and a new visual treatment, and it is the CSS and settings in that profile that strip the browser chrome. It also means the Firefox apps are not simply your main profile in a window, they are a separate installation of your preferences, which is a different set of trade-offs from the Chromium path.

Since the whole thing is a launch command, the tool is only as good as the browser it points at, and the next section is where that shows up.

Three operating systems, three kinds of shortcut

The packaging is per platform, and the README describes each one.

On Linux, choosing Linux as the target makes FTWA generate a shell script that creates a .desktop file and its icons, following the freedesktop.org desktop entry specification. The .desktop file is what makes the app appear in your application launcher and in tools like Rofi, Wofi and dmenu, so the entry, the icon and the launch command are the three things that have to be right.

On Windows, FTWA generates a PowerShell script that downloads the icon, wraps it as an .ico file, and creates a Start Menu .lnk shortcut through WScript.Shell. The shortcut points at the browser executable with the right --app arguments, or with the Firefox profile arguments, and it then shows up in Start Menu search.

On macOS, it creates an .app folder in /Applications containing an icon in .icns format and a bash script that runs the browser command.

The pattern is consistent across all three: a small script, a piece of platform specific packaging, and a pointer back to a browser executable. The scripts are the deliverable, not the applications, and that has a security consequence that the README itself flags later on.

Icons are a separate practical problem, and the README lists three places to find logos: macosicons.com, icon-icons.com and simpleicons.org. The project also asks people to suggest apps they find useful, with a template for the suggestion in the issue tracker.

Installing an app means running a script from a website

The flow is short. You pick your environment options in the settings, then either create your own app in the web form or copy the code for an app from the gallery or the app store, and then you paste that code into a terminal.

The example in the README is a single command that pipes a remote script into a shell.

      sh -ec "$(curl -fsSL 'https://ftwa.mathix.dev/v/excalidraw?os=linux&bw=chrome&path=%2Fusr%2Fbin%2Fgoogle-chrome-stable')"

The parameters in the URL are readable: the app slug, the target operating system, the browser, and the path to the browser executable. The README's own advice is to check the content of a script before running it, which is the right instinct, and it shows how to do that by fetching the same URL without executing it.

      curl -fsSL 'https://ftwa.mathix.dev/v/excalidraw?os=linux&bw=chrome&path=%2Fusr%2Fbin%2Fgoogle-chrome-stable'

The script itself can also be opened in a browser, which is the same idea with more context.

There is one hard requirement in the README that will catch people out. This currently only works if you have a Chromium browser installed, and if you are not using google-chrome you have to either edit the .desktop file to point at your executable or make /usr/bin/google-chrome an alias to your Chromium browser. On a machine with Chromium, Brave or another Chromium derivative, that is the step that decides whether the launcher works.

Removing an app is a matter of deleting the entry, and the README shows where they live.

ls -lAh ~/.local/share/applications
# OR
ls -lAh /usr/share/applications

Remove the ftwa prefixed .desktop file for the app you no longer want, and on macOS move the .app folder to the trash like any other application.

The catalog is generated by scraping, not typed in by hand

The repository makes it clear that the gallery and the app store are produced by tooling rather than curated one entry at a time.

The development dependencies in package.json include puppeteer, which is a headless browser, sharp, which does image processing, and node-html-parser. There is a script at the root called extract-app.cts, and the tree has content/, tags.json and types/ directories. The combination of a headless browser, an HTML parser, an image processor and a content directory says the app metadata and the icons are pulled from the live sites and turned into entries programmatically, which is how a catalog of dozens of apps stays possible for one maintainer.

The rest of the stack is Nuxt. The project depends on nuxt itself, on Nuxt UI for the interface, and on Nuxt Studio for the content editing side, with Tailwind for styling, Tailwind UI referenced in the README as a resource. The @nuxtjs/device package and baseline-browser-mapping and caniuse-lite are there to reason about the user's browser, and the site is deployed through wrangler with a wrangler.toml at the root.

The site itself is a private package named ftwa-website, with the version pinned at 0.0.1 and the package manager set to bun at 1.1.38. That private name matters for a reason: the published artefact of this repository is a website, not a library. The apps that users install are the scripts the site hands them.

  "packageManager": "[email protected]",

Building and running the site with Bun

The developer setup is documented in full, which is unusual and welcome for a project of this size.

bun install

The dev server starts on port 3000, and the --host flag exposes it on the network.

bun run dev
# or
bun run dev --host

A production build and a local preview of it are the other two commands you need, and the README points at the Nuxt deployment documentation for the rest.

bun run build

bun run preview

The package scripts show the whole set, and one of them is worth noticing. The postinstall script runs nuxt prepare, so a fresh install regenerates the framework's type stubs automatically, and the lint scripts are plain eslint with a fix variant.

  "scripts": {
    "build": "nuxt build",
    "dev": "nuxt dev",
    "generate": "nuxt generate",
    "preview": "nuxt preview",
    "postinstall": "nuxt prepare",
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  },

The generate script means the site can be produced as static output, and the tree includes a .claude/ directory and a .vscode/ directory, which suggests the author works with editor and agent tooling in the repository, and renovate.json is there to keep dependencies current.

What the launchers do not give you

The limitation is architectural and worth being blunt about. The generated application is your browser, in a window without a browser frame, pointing at a profile that already has your logins, your cookies and your extensions. That is exactly why the apps work, and it is also why the app is not isolated from anything else your browser can reach.

The second limitation is the delivery mechanism. The thing you install is a shell or PowerShell script fetched over the network from the project's own site, which is why the README tells you to inspect it before running it. The script is short and its purpose is obvious, and the URL parameters make it clear what it will do, but the general pattern of piping a fetched script into a shell is one that deserves the caution, and a site compromise would be a supply chain problem for every user who follows the same copy and paste instruction.

The third limitation is coverage. The whole approach depends on a browser that supports app mode, which is why the Firefox path exists as a workaround and why a non-Chromium browser without the --ssb parameter cannot be covered at all. The README also notes that the Linux flow assumes a Chromium browser is present, with the /usr/bin/google-chrome path baked into the generated file.

The alternative is doing it by hand, which is entirely reasonable: writing a .desktop file that runs your browser with an --app argument takes a couple of minutes, and on a system where you already know your browser path you gain a launcher that contains no fetched script. The difference in approach is that FTWA gives you a catalog, per-OS packaging and a uniform workflow, while the manual route gives you a file you fully understand, at the cost of repeating yourself for every site. What FTWA cannot offer is anything the browser itself does not do, and on macOS, where the operating system already has a web app mode of its own, the value of a generated .app bundle is correspondingly smaller.

Editorial conclusion

FTWA fits a desktop Linux user who works in a tiling window manager and wants a Notion or a drawing tool to appear in the launcher like a normal application. It does not fit anyone who needs isolation from the browser profile, since the generated app reuses the same browser and its data, and the scripts arrive over the network. Before you run one, read the script first as the README advises, and check the path it points at, because a launcher that runs google-chrome is only correct on a machine where that executable exists. The last push was on 2026-04-27, the project publishes no GitHub releases, and the code is GPL-3.0 with an explicit exception for third party icons.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. mathix420/free-the-web-apps on GitHub
4. Project website
5. README