Blog

Moving a Nativefier web app to Pake

How it works · October 17, 2026 · 5 min read

Nativefier was archived on September 29, 2023, and its maintainers favor a browser's own install feature for most people. If you want a separate app anyway, rebuild it in Pake from the start URL and settings as a new app, because options and sign-ins do not carry over.

Decide whether to move at all

The original Nativefier repository was archived by its owner on September 29, 2023 and is read-only; the README starts with "Nativefier is unmaintained". The announcement issue gives the reasoning. Nativefier was built before browsers could install a website as an app, and the author says that when you just want an app for a website, the browser's feature should be strongly preferred, because browsers update themselves and receive security fixes. For a custom app to distribute, the author points to using Electron directly. A maintainer replied the same day that they use the browser options themselves for the security updates.

Security updates are the practical reason to look at your old app. Nativefier wraps pages in Electron, and the latest release listed on GitHub, v52.0.0, updates to Electron 25.7. Electron's release timeline says only the three latest stable major versions are supported, and GitHub listed Electron v44.9.0 as the latest release when this was checked on 18 October 2026. An app built with Nativefier is therefore running a Chromium far behind the supported lines, and Electron's security guide asks you to always use the latest available version. Opening only your own pages does not give an old engine its missing security updates. Before signing in to a sensitive service, switch to a maintained client.

So there are three reasonable moves: install the site from your browser, rebuild it in Pake, or build on Electron yourself. The Mac guide and Windows guide cover the browser route. This post covers Pake.

What changes

Nativefier uses Electron. Pake uses Tauri and the platform's web view: WKWebView on macOS, WebView2 on Windows and WebKitGTK on Linux. Tauri's webview reference explains these platform differences, and Tauri vs Electron goes through what they mean for a wrapped site. A different engine can change site behavior; it is not evidence that every site will become faster or use less memory.

One difference is easy to miss. Nativefier's documentation says it uses a preset user agent that masquerades as a regular Google Chrome browser by default, so some sites do not report the browser as unsupported. Pake's default user agent is Safari on a Mac and Chrome on Windows. If your old app depended on a Chrome-looking identity on a Mac, set User agent under Advanced, and read the user agent guide first.

Record the old app's settings

Write down the start URL, name, window size, icon and any injected styles or scripts. If you still have the original nativefier command, it is the best record, since each option on it maps to something below. Nativefier also has an --upgrade option that extracts options from an existing app, but it upgrades inside Nativefier, so it keeps you on Electron.

Rebuild a small version first

Keep the old app installed while you test the replacement. For the desktop app, paste the URL into Create and use a temporary distinct name. For the CLI, install the required tools, then build a basic version:

pake https://example.com --name example-pake

Open it and test sign-in, navigation, uploads, downloads and the page you use most. Add customizations only after that baseline works, so a broken script does not hide a site compatibility problem.

Translate settings by behavior

Read the CLI options for exact flags rather than pasting a Nativefier command into Pake, since defaults differ by operating system. For example, Hide on close is on by default on Mac and off on Windows.

Two Nativefier options have no counterpart in Pake's documented options. --widevine switches to a Widevine-enabled Electron build for DRM video, and Nativefier's own notes say some sites still refuse to play and need extra signing. Pake documents no such switch, so test any site that depends on DRM playback before you move. --counter keeps a badge count on the macOS Dock icon for pages that put a count like "(3)" in the title, and you should check whether you rely on it.

Move over after checking the account

Pake does not import the old Electron profile. Sign in again, verify the account and any site-managed documents, and keep the old app until you are satisfied. If you want to carry only the settings between two computers later, Pake's .pake files hold name, address, window options, user agent, link rule, CSS, JavaScript and icon, and never sign-ins; see Moving web apps to another computer.

If Google or another provider refuses embedded login, follow the sign-in guide; changing wrappers is not a promise that the provider will accept the new one, and Google's policy covers embedded user-agents in general.

When to stay or go elsewhere

Stay on the Nativefier app a little longer if it works, you only open pages you trust, and you depend on --widevine or the Dock counter. Plan a replacement, because the engine will not get fixes. If you need Chromium everywhere, extensions, or Node access, Electron itself is the route the Nativefier author recommends. If you only want an icon for a site you already use, the browser install is simplest.

FAQ

Does my Nativefier app stop working?

Archiving the repository does not itself stop installed apps from running, but there will be no new releases or fixes.

Can Pake import my Nativefier app?

No. Recreate it from the URL and the settings above. Sign-ins and browser data do not transfer.

Will the Pake version be smaller or faster?

Not something this post can promise. A different engine changes behavior, so measure the app you build, as described in Tauri vs Electron.