HTML to App Offline HTML to native macOS apps
Launching soon for macOS

Turn a local HTML project into a Mac app.

HTML to App packages a self-contained HTML file or folder into a standalone macOS app through one guided desktop workflow. It is built for offline tools, viewers, internal utilities, and other local-first projects that should live on disk instead of behind a hosted URL.

Request early access Get launch updates See documentation Ask the HTML to App GPT

The Mac App Store listing is not live yet. Early-access and launch-update requests go straight to [email protected].

Generated HTML to App demo running as a standalone macOS app window

Actual exported app

Concrete example: local image viewer

  • Source A local folder with index.html, bundled assets, and no server-side dependency.
  • Build choices Embed content, register image files and folders from Finder, and leave network permissions off.
  • Result A standalone .app bundle that opens selected files in JavaScript through the built-in bridge.
Primary use case Package self-contained local HTML into a focused macOS app without turning it into a hosted product.
macOS compatibility Both the HTML to App builder and the generated HTML apps it exports work on macOS 10.12 and newer.
Safety model Sandboxed output, explicit permissions, and no telemetry in the builder app.
Native bridge Finder-opened files and folders arrive in JavaScript instead of needing a custom native glue layer.

Launch, pricing, and release path

The App Store page is not live yet, but the launch path, pricing model, and release expectations should still be clear before buyers commit.

Launch CTA

Request early access now

If you already have a project in mind, send the source type and intended app behavior now so you can get launch updates or fit confirmation before the App Store release.

Request early access Get updates

Pricing

One-time purchase model

  • HTML to App is positioned as a one-time purchase for the macOS builder app.
  • The launch plan is a no-subscription, no-in-app-purchase model.
  • Final launch price, update policy, and trial availability still need to be published before release.
Ask a pricing question

Trust

Release-ready output and direct support

HTML to App is from the same independent developer behind Parall and DockLock Pro. Generated bundles fit into a normal macOS release flow, and rollout questions go through direct email support.

Visit Parall Visit DockLock Pro Contact support

Best fit, and not a fit

HTML to App is deliberately narrow software. It works best when the project is local-first, Mac-specific, and meant to behave like a real desktop utility.

Best fit

  • Package internal tools, local viewers, and offline utilities for macOS.
  • Turn static-site output from tools like Astro, Hugo, or Eleventy into a desktop app shell.
  • Build file or folder handlers that open content from Finder and pass it into JavaScript.
  • Ship a standard .app bundle that you can sign or notarize in your own release pipeline.

Not a fit

  • Server-backed web apps that only make sense when connected to hosted backend infrastructure.
  • Remote-site wrappers where the main goal is opening an online URL inside a thin shell.
  • Apps that need broad arbitrary save-back access outside the opened file or folder scope without explicit user-approved flows.
  • Teams that need a full cross-platform desktop framework or a custom native shell from the start.

How the export works

The workflow is short on purpose: choose the local source, set the Mac-specific behavior, then export the final bundle.

Start from local HTML

Choose a single HTML file or a folder with an index entry point. The best fit is self-contained HTML, CSS, JavaScript, images, and media linked by relative paths.

Set the Mac behavior

Name the app, choose the icon, decide whether content is embedded or read from the original folder, and opt into Finder handlers or permissions only when needed.

Export the .app bundle

Save a standalone macOS app, then move it into your own signing, notarization, testing, or release flow.

Finder input arrives in JavaScript

This is one of the most concrete technical advantages: launch items show up in your page without you writing a custom native bridge first.

Bridge API

Read startup items from window.HTMLToApp.launchItems and listen for later opens with htmltoapp-open. Editor-role builds also expose window.HTMLToApp.fs for scoped write-back inside the opened item. 

const launchItems = (window.HTMLToApp && window.HTMLToApp.launchItems) || [];

window.addEventListener("htmltoapp-open", (event) => {
  const detail = event.detail || {};
  handleLaunchItems(detail.items || [], !!detail.replaceExisting);
});
Read full bridge docs See example projects

What your page receives

  • Files and folders opened from Finder can be delivered into the running app.
  • Each item includes the original path plus loadable URLs for media or folder listings.
  • Editor-role apps can also read and write inside the opened file or folder tree.
  • The same handling pattern works for startup items and later open events.
  • You keep the UI in HTML, CSS, and JavaScript instead of building the first integration in Swift or Objective-C.

Compatibility and deployment

Here is what is already confirmed about compatibility and what should still be validated before a production rollout.

Compatibility today

  • Both HTML to App and the generated HTML apps it exports work on macOS 10.12 and newer.
  • The cleanest results come from self-contained local HTML projects linked by relative paths.
  • The builder works offline, and generated bundles only touch the network when your own HTML asks them to.
  • Generated apps stay sandboxed and do not gain broad file-system access by default.

Deployment expectations

  • The export is a standard .app bundle that fits into your own signing and notarization flow.
  • Finder handlers plus camera, microphone, or location access are opt-in per build.
  • If you need confirmation for a specific macOS release or hardware rollout, contact support before production use.

How it compares

HTML to App is not trying to replace every desktop-app approach. It is for the narrower case of packaging a local HTML project into a focused Mac utility.

Electron or Tauri

Best when: Use those when you need a broader cross-platform desktop stack or deeper runtime customization.

Why HTML to App: Use HTML to App when the job is specifically packaging a self-contained local HTML project as a focused Mac app with less setup.

Custom WKWebView shell

Best when: Build the native shell yourself when you want full control over the AppKit or WebKit layer and are prepared to maintain it.

Why HTML to App: Use HTML to App when you want packaging, Finder registration, launch-item bridging, and permission scoping in one guided builder.

Automator or Shortcuts

Best when: Those are strong when the goal is workflow automation instead of shipping a desktop app bundle.

Why HTML to App: Use HTML to App when the end result should behave like a branded app in Finder, the Dock, and Launch Services.

Builder walkthrough

These are the current production screens, organized around the decision each step helps you make.

HTML to App onboarding screen with product overview, how it works, and project requirements

Step 1

Confirm project fit

Start with a clear requirements screen so you know whether the project is self-contained enough for a clean local export before you configure anything else.