Is WordPress Still Relevant? How PWAs or Progressive Web Apps are Changing Websites and Apps

None of that makes WordPress obsolete, and none of it makes native development unnecessary. It does mean the three options overlap more than they used to, and that choosing between them requires understanding what each is actually good at.

WordPress is still relevant — but not for every digital product

WordPress remains one of the best content management systems available. It has a mature editorial workflow, an enormous plugin and theme ecosystem, a large pool of people who already know how to use it, and a publishing model that non-technical teams can run without developer involvement. For a content-heavy site, an editorial publication, a brochure site, or a marketing site that needs frequent copy and campaign changes, it is often the correct answer and the fastest route to a maintainable result.

Where WordPress starts to strain is when the product stops being a set of pages. Once the experience revolves around user accounts, dashboards, permissions, real-time state, transactional workflows and integrations with business systems, you are building an application. WordPress can be pushed into that shape with enough plugins and custom code, but at that point you are maintaining an application inside a publishing tool rather than an application designed as one.

What exactly is a progressive web app?

A progressive web app is a web application built so that browsers can treat it more like an installed application. There is no separate language or runtime involved. It is the same web stack, with a few specific additions:

• A web application — an interface designed around tasks and state rather than around pages of content.
• A web app manifest — a small file describing the app name, icons, theme colours and how it should launch, which is what allows a browser to offer installation.
• A service worker — an optional background script that can intercept network requests, cache assets and data, and enable offline or degraded-connectivity behaviour. What it does depends entirely on how it is written.
• A responsive interface — one codebase that adapts from a phone screen to a desktop window.
• An application shell — the persistent chrome and navigation that loads first and stays in place while content changes.

The word “progressive” matters. Each of these capabilities is layered on top of a site that still works without them. A visitor on an older browser gets the standard web experience; a visitor on a supporting browser gets installation, caching and other enhancements.

How a PWA behaves like both a website and an app

The crossover is easiest to see in behaviour. A PWA is reached through a URL, so it can be linked, shared, bookmarked and — where content is server-rendered or otherwise exposed correctly — crawled and indexed. At the same time, once installed it can appear as an icon on a home screen or desktop, open in a standalone window without browser chrome, retain state between sessions, and load instantly from cache on repeat visits.

A customer portal is a good example. A client receives a link by email, opens it in a browser, signs in, and uses it. If they use it weekly, they install it and thereafter launch it from an icon like any other application. Nothing about the underlying product changed — only the way it is accessed.

How does a progressive web app get installed?

Installation is handled by the browser and operating system, not by an app store, and the behaviour varies by platform:

• On Chromium-based desktop and Android browsers, an install prompt or install button typically appears in the address bar or menu once the app meets the browser’s installability criteria.
• On iOS and iPadOS, installation is done manually through Safari’s Share menu using “Add to Home Screen”. There is no automatic prompt.
• On desktop, an installed PWA gets a shortcut and appears in the taskbar, dock or application launcher.
• Once launched from the icon, the app opens in a standalone window using the display mode declared in the manifest.

Because the criteria, prompts and available features differ between browsers and operating systems, and change over time, installation should be treated as an enhancement rather than a guaranteed entry point. The product must still work well for someone who never installs it.

Can a PWA replace a native mobile app?

Sometimes. If the app is essentially an interface to your own data and services — an account area, a booking tool, a dashboard, a directory, an internal operations app — a well-built PWA can often deliver the same experience without a separate native codebase or app-store release cycle.

It is a weaker fit when the product genuinely depends on deep operating-system integration, advanced hardware or sensor access, sophisticated Bluetooth or peripheral communication, sustained background processing, specialised native APIs, or performance characteristics that only native development reliably delivers. App-store presence itself can also be a strategic requirement — for discovery, procurement or customer expectation — and that alone can justify native or hybrid distribution.

Can a PWA replace a traditional website?

In many product and platform scenarios the PWA becomes the primary web experience, because it is the thing users actually spend time in. But the two are not mutually exclusive. Marketing pages, editorial content, landing pages and search-facing content still need a content architecture designed for discovery, and that content still needs someone to publish it without deploying code.

A common and sensible arrangement is a combined architecture: application experiences delivered as a PWA, with content and marketing handled by a CMS — sometimes WordPress in a headless or conventional role — under a coherent URL and search structure. The decision is not website or app. It is which parts of the experience belong in which layer.

The business benefits of progressive web apps

• One primary application codebase serving desktop and mobile, where the product does not require native capabilities.
• Responsive delivery, so the same experience adapts rather than being rebuilt per device.
• Installability without app-store submission, review queues or per-platform distribution overhead.
• Updates that ship on your own schedule and reach users on next load rather than after a store approval and user update.
• Asset and data caching, which improves the repeat-use experience and provides resilience on poor connections.
• Push notifications on supporting platforms and browsers, where re-engagement matters.
• Direct URL access, which keeps deep linking, sharing and search discovery intact.
• Integration with business systems, because the application layer is yours rather than a plugin surface.
• Less fragmentation between the web experience and the app experience for teams that would otherwise maintain both.

The honest caveat: these are structural advantages, not automatic savings. Whether a PWA reduces cost in a specific project depends on scope, required capabilities and how much of the experience would otherwise be duplicated.

Where WordPress still wins

• Editorial teams that publish regularly and need to work independently of developers.
• Mature publishing workflows — drafts, revisions, scheduling, roles and approvals — available without building them.
• A deep plugin and theme ecosystem that covers common marketing-site requirements out of the box.
• Content-heavy sites where the structure is genuinely pages, categories and archives.
• Straightforward marketing and brochure sites where an application layer would add cost without adding value.
• Familiar CMS administration, which lowers both the training burden and the risk of key-person dependency.

WordPress can also coexist with application architecture rather than being replaced by it. Using it as the content layer behind a separate application front end is a legitimate design, not a compromise.

Where PWA architecture wins

• Platforms and SaaS products with accounts, permissions and recurring use.
• Directories and marketplaces with search, filtering, listings and transactions.
• Membership products and community platforms.
• Dashboards, reporting tools and customer portals.
• Internal business applications used daily by staff.
• Any product where users return frequently and expect an application interface rather than a page.

WordPress vs PWA vs native app

Choosing the right architecture

The decision should start with the problem, not the platform. In practice that means working through a short list before anyone proposes a technology:

1. Who the users are, and how often they will return.
2. The specific use cases and workflows the product must support.
3. How much of the experience is content versus application.
4. Which device capabilities are genuinely required, not merely desirable.
5. How discovery works — search, referral, direct, or inside an existing relationship.
6. Whether accounts, roles and permissions are part of the model.
7. Which business systems the product must integrate with.
8. How often the product and its content will change.
9. How the business model and distribution strategy shape the delivery channel.

Most poor architecture decisions come from reversing that order — selecting the technology first and discovering the requirements afterwards, usually at the point where the chosen tool starts resisting them.

The useful question is no longer “do we need a website or an app?” It is “what experience should our users have, and what architecture supports it best?” Sometimes the answer is WordPress. Sometimes it is a progressive web app. Sometimes it is both, with a native app where the hardware requirements demand one.

That is the starting point for how JMG Group approaches platform architecture — mapping users, workflows and integrations before choosing a stack. Where the outcome is an application experience, we build it as a progressive web app, connected to the business systems and automation behind it, and shaped by product strategy rather than by a preferred tool.