I remember sitting in a meeting in 2018, listening to a project manager explain why we needed a Progressive Web App. He sold it as the “silver bullet” that would kill the App Store. I laughed. We all laughed. Back then, a PWA was basically a bookmark that occasionally worked offline if the wind was blowing in the right direction and you sacrificed a goat to the Safari gods.

Fast forward to January 2026.

I’m not laughing anymore. I’m actually deleting my Xcode projects. Well, most of them.

Look, I’ve been a native purist for a decade. I loved Swift. I tolerated Kotlin. I despised JavaScript bridges. But the shift we’ve seen over the last eighteen months—specifically since the EU’s Digital Markets Act finally forced Apple to stop crippling WebKit—has changed the math. The gap between “web” and “native” hasn’t just narrowed; for 95% of business use cases, it’s vanished.

The iOS Wall Finally Crumbled

Let’s address the elephant in the room immediately. For years, iOS was the graveyard of PWA ambition. You could build the slickest web app in the world, and Safari would treat it like a second-class citizen. No push notifications, constant storage eviction, no background sync. It was brutal.

That changed last year. Since iOS 19 opened up browser engine entitlements, we can finally use Blink-based rendering on iPhones if we want to. But even stock Safari has surrendered. Web Push actually works reliably now—not the “it works if the user adds it to home screen and prays” version from 2023, but actual, reliable push.

I tested this last week on a client project. We ripped out the native iOS wrapper. The PWA installation flow on iOS is still a bit hidden (Apple will be Apple), but once installed, the persistent storage actually persists. I left the app dormant for two weeks, opened it up, and my local SQLite database was still there. No eviction. That used to be a pipe dream.

Local-First is the New Offline-First

The term “Offline First” always annoyed me. It implied offline was an error state you handled gracefully. In 2026, we’re building Local First.

With the maturity of the Origin Private File System (OPFS) and synchronous access handles, we aren’t messing around with IndexedDB’s awkward async API for heavy lifting anymore. We’re running full SQLite instances via WebAssembly, directly on the user’s device, with performance that rivals native CoreData.

Here is the kind of setup I’m running in production right now. It uses the File System Access API to let the user open a local file, edit it, and save it back without ever uploading it to a server. Privacy by default, zero latency.

// The 'old' way was uploading to a server.
// The 2026 way is direct handle manipulation.

let fileHandle;

async function openFile() {
  try {
    // Show the file picker
    [fileHandle] = await window.showOpenFilePicker({
      types: [{
        description: 'Text Files',
        accept: { 'text/plain': ['.txt', '.md'] },
      }],
    });

    const file = await fileHandle.getFile();
    const contents = await file.text();
    
    document.getElementById('editor').value = contents;
    console.log("File opened directly from disk. No server required.");
    
  } catch (err) {
    // User cancelled or browser doesn't support it (rare in 2026)
    console.error("File access denied:", err);
  }
}

async function saveFile() {
  if (!fileHandle) return;
  
  // Create a writable stream to the file
  const writable = await fileHandle.createWritable();
  
  // Write the contents
  await writable.write(document.getElementById('editor').value);
  
  // Close the file
  await writable.close();
  console.log("Saved directly to disk.");
}

This code runs on Chrome, Edge, and yes, even Safari (mostly). Three years ago, you needed Electron for this. Now it’s just a web standard.

View Transitions Killed the “Jank”

The biggest tell that an app was a website used to be the navigation. Click a link -> white flash -> new page loads. It felt cheap.

The View Transitions API fixed this. If you aren’t using this, you’re wrong. It allows you to animate the DOM state changes so it looks exactly like a native view controller push/pop. I spent an afternoon implementing this on a product catalog, and the client couldn’t tell it was a website. They literally asked me, “When did you upload the new native build?”

I didn’t. I just added a few lines of CSS.

But What About the App Store?

This is the last argument native defenders cling to: “Users only look for apps in the Store.”

Fine. Put it in the store. Trusted Web Activities (TWA) for Android and tools like PWABuilder have made this trivial. You can wrap your PWA and ship it to the Play Store, Microsoft Store, and even the App Store (with some caveats and a Mac to sign it). You get the discoverability of the store, but you maintain one codebase. You push an update to your server, and the “app” updates instantly. No review queues. No waiting 48 hours for Apple to approve a typo fix.

When Should You Still Go Native?

I’m not a zealot. There are still times I reach for Swift or Rust.

• High-fidelity 3D Games: WebGPU is incredible, and it’s basically standard now, but if you’re building the next GTA, you need bare metal access.
• Obscure Hardware Access: If you need to talk to a proprietary medical device via a custom Bluetooth profile that doesn’t adhere to standard GATT, the Web Bluetooth API might still flake out on you.
• Background Geofencing: The web can do background sync, but persistent, low-power geofencing monitoring 24/7 is still an OS-level privilege that browsers handle conservatively to save battery.

But for your dashboard? Your e-commerce site? Your social network? Your project management tool? Native is overkill. It’s vanity.

The Service Worker: Still Misunderstood

Most devs I interview still treat the Service Worker like a glorified cache config. They copy-paste a Workbox recipe and call it a day. That’s a waste.

In 2026, your Service Worker should be handling logic. It should be managing background syncs for when the user comes back online after a tunnel. It should be handling push payloads and decrypting them locally. It’s a separate thread; use it.

Here is a snippet I use to handle background sync. This saved my bacon on a logistics app where drivers were constantly losing signal.

// Inside your Service Worker

self.addEventListener('sync', (event) => {
  if (event.tag === 'sync-orders') {
    event.waitUntil(syncOrders());
  }
});

async function syncOrders() {
  // Access IndexedDB directly from SW
  const db = await openDB('logistics-db');
  const offlineOrders = await db.getAll('outbox');
  
  if (offlineOrders.length === 0) return;

  for (const order of offlineOrders) {
    try {
      const response = await fetch('/api/orders', {
        method: 'POST',
        body: JSON.stringify(order),
        headers: { 'Content-Type': 'application/json' }
      });
      
      if (response.ok) {
        // Only delete if server confirmed
        await db.delete('outbox', order.id);
        
        // Notify the client page to update UI
        const clients = await self.clients.matchAll();
        clients.forEach(client => {
          client.postMessage({ type: 'ORDER_SYNCED', id: order.id });
        });
      }
    } catch (error) {
      console.error('Sync failed for order', order.id, error);
      // Keep it in outbox for next retry
    }
  }
}

This runs in the background. The user can close the tab, lock the phone, put it in their pocket. As soon as the radio reconnects, the browser wakes up the worker and flushes the queue. It just works.

The Verdict

I wasted years maintaining three codebases—Web, iOS, and Android—for products that were essentially lists of data. I dealt with certificate expiration, provisioning profiles, Gradle build errors, and App Store rejections because a screenshot had the wrong pixel density.

Stop doing it. The capabilities are here. The performance is here. The browser wars have cooled into a detente that actually benefits us for once. If you’re starting a project today, default to PWA. If you hit a hard wall, you can always wrap it later. But I’m willing to bet you won’t hit that wall.