Web app vs native app: why Java teams build on webforJ

Your users want an app with its own icon, and your team wants one codebase it can update in a single deploy. Those wishes usually set off the web app vs native app debate.

For a business app, you can have both. Build a web app in Java with webforJ, deploy it once to a server, and let users install it from the browser to their desktop or home screen.

Install a real app

Every app in built with webforJ is installable. The Bookstore app is a good one to try: run it with Java and Maven, open it in Chrome or Edge, and install it to get its book inventory, search and edit forms in their own window.

Web app vs native app: which wins?

The real cost of a native app isn't the first build. It's everything after it. Each operating system needs its own packaging, each release needs to reach each machine, and each fix waits for users to update.

A web app flips that. The code runs on your server, users open a URL, and a fix reaches everyone on the next page load. For internal tools, customer portals, back-office screens and admin dashboards, that matters more than anything a native shell adds.

Here is how the two compare for a typical business app.

Question	Native app	webforJ web app
Where does the code live?	On each device	On your server
How do updates ship?	Installer or store release per platform	Redeploy once
How many UI codebases?	One per platform, or a cross-platform toolkit	One Java codebase
How do users get it?	Download and install	Open a URL, optionally install
Works on any OS with a browser?	Only the platforms you build for	Yes

Should I build a web app or desktop app?

Ask who your users are and what they need on the machine.

If they sit in front of a laptop and use forms, tables, charts and workflows, a web app covers it. If they need a phone, a second screen and a desktop, a web app covers all three with one UI. A desktop-only build locks you to the machines you can ship an installer to.

A desktop app earns its place when the software has to drive hardware directly or run with no network at all. That's a narrow set of products. Most business apps talk to a database and an API anyway, so they already need a connection.

If you are coming from Swing, the same logic holds. Moving the UI to the web keeps your Java skills and removes the per-machine rollout. The Webswing roadmap covers a phased path if you can't move everything at once.

Web or native for a business app?

Our short rule: pick web unless a specific device capability forces you off it.

The usual reasons teams pick native are speed, offline use and a home-screen presence. The last one is solved by installing. The first two deserve a closer look before they decide your architecture.

A webforJ app keeps the UI logic on the server and sends the client only what it needs. The client loads a tiny bootstrap script of about 2.5 kB gzip, then pulls further JavaScript on demand as the app uses a component. The framework also batches server-to-client calls so a burst of UI changes doesn't turn into a burst of network messages. The client/server interaction page explains the model and the one thing to avoid, which is reading values back from the client when an event already carries them.

Offline-first work, such as a tool that must run with no connection for hours, is the case where native still has a real edge. If that is your product, say so up front and choose native for it.

Progressive web app or native?

A progressive web app (PWA) is a web app the browser can install. The PWA vs native Java question comes down to what the installed app can do, and for business screens the answer is almost everything. It gets its own icon, opens in its own window, and it uses a manifest that names it, sets its colors, and lists its icons.

In a typical Java stack, producing that manifest by hand means writing JSON, wiring meta tags, and serving icons yourself. In webforJ you annotate the main app class:

@AppProfile(
  name = "Zyntric Bank",
  shortName = "ZBank",
  description = "Zyntric Bank is a simple banking application built with webforJ",
  screenshots = {
    @AppProfile.Screenshot(
      src = "ws://img/screenshots/s1.jpg",
      sizes = "1080x1920"
    )
  }
)
public class Application extends App {
}

name and shortName are the only required properties. webforJ sets up the meta tags, generates the web app manifest, and serves the icons and screenshots. The display property defaults to STANDALONE, so the installed app opens without browser chrome. The full property list is on the installable apps page.

Installation needs a secure origin, so serve the app over https in production. Browsers allow localhost during development. For a closer look at the user side, see Your Web App Deserves a Spot on the Home Screen.

Where installation works

Support depends on the browser:

• Chromium browsers install any app that ships a manifest on all supported desktop systems.
• Safari 17 and later on macOS can add any web app to the Dock.
• Firefox doesn't install web apps from a manifest on desktop.
• On Android, Chrome, Edge, Firefox, Opera and Samsung Internet support installation.
• On iOS 16.4 and later, installation works from the Share menu in Safari, Chrome, Edge, Firefox and Orion.

Check that list against your user base before you promise an install flow.

Who builds the screens?

The same Java developers who build the backend. A view is a Java class with a route, built from Java components, and its event handlers run on the server.

There is no separate frontend project, no REST layer to keep in sync and no second language for the team to learn. The same developers who own the domain logic own the screen. The architecture overview covers how the pieces fit together.

What native still does better

A fair comparison names the cases where native wins:

• Software that must run fully offline for long periods.
• Products that talk directly to local hardware.
• Apps that depend on a platform store for distribution and billing.

If none of these describe your product, the native route adds cost without a matching gain. For most Java teams shipping business software, the web app is the faster build, the cheaper release and the easier thing to keep current.

Start with a web app today

Generate a project with startforJ, add @AppProfile to your main app class, and open the app on localhost in Chrome or Edge. The install option appears in the browser. The getting started guide walks through the project setup.

Frequently asked questions

Should I build a web app or desktop app for my business software?

Build a web app unless the software has to control local hardware or run offline for long periods. A webforJ web app reaches every device with a browser, deploys once to a server and can be installed to behave like a desktop app.

Is an installed web app as good as a native app for business use?

For forms, tables, dashboards and workflows, yes. An installed webforJ app opens in its own window with its own icon. Native keeps an edge for fully offline work and direct hardware access.

Do I need JavaScript to make a Java web app installable?

No. Adding @AppProfile to your main app class makes webforJ generate the manifest, set the meta tags, and serve the icons. You still need an https origin in production.