Once upon a time, Adobe AIR promised a dream: write once, run anywhere—on the desktop, using web technologies. For developers who cut their teeth on Flex, AIR was a natural next step: a way to ship polished desktop apps using ActionScript and MXML.
Today, Progressive Web Apps (PWAs) are chasing a similar dream—but with broader reach and fewer dependencies.
Let’s unpack what Adobe AIR got right, where it fell short, and how its ideas echo in today’s web app architecture.
🖥️ Why AIR Felt Revolutionary
Before Electron and before PWAs, AIR let web developers:
-
Access the file system
-
Store data locally
-
Create native installers
-
Run offline
-
Package cross-platform apps (Windows, macOS, even mobile)
It brought the power of desktop to the skills of the web—and that felt like magic in 2008.
Want to build a chat app? A video player? A screen scraper? With AIR, you could. And many of us did.
✅ What AIR Got Right
1. Offline-first Architecture
AIR apps were inherently offline-capable. With local SQLite databases and file system access, they worked seamlessly without the internet—something we still struggle with in modern web apps.
2. Unified Development Model
You could build the UI with Flex (MXML + ActionScript), and power everything with JavaScript-like logic. No context-switching between iOS/Android/Web/Desktop.
3. Native Access, Simplified
Need to read from a file? Save data? Full access. No browser sandboxing. It felt like building native software—without needing to know C++.
4. Packaging & Deployment
The ability to bundle your app and distribute it like traditional software made it easier to monetize, version, and control the user experience.
❌ What Went Wrong
1. Dependency on Flash
When Flash fell out of favor, AIR went with it. Adobe stopped investing, and browser support faded. Despite AIR’s strength, it was shackled to a declining platform.
2. App Store Roadblocks
Getting AIR apps on mobile stores wasn’t as smooth as native solutions. Performance, animations, and OS integration were always a step behind.
3. Developer Lock-In
You had to use Adobe tools, ActionScript, and their ecosystem. No open web standards meant no graceful fallback.
🔄 Enter: Progressive Web Apps
PWAs pick up where AIR left off—but with broader support and no proprietary baggage.
What PWAs do better:
-
Native browser support (no plugins)
-
Installable via browser prompts
-
Offline support via Service Workers
-
Background sync and push notifications
-
Secure (HTTPS required)
And most importantly: they run everywhere—phones, tablets, laptops—without a separate codebase or runtime.
🔍 Lessons PWAs Can Learn from AIR
-
Deep Integration Matters
AIR gave you real desktop power. PWAs are getting close with APIs like File System Access and Web Bluetooth—but there’s still a gap. -
Packaging Still Matters
AIR gave you a tangible .exe or .app to share. PWAs should improve on installability, discoverability, and user trust—especially in business contexts. -
Local Storage Should Be Simpler
IndexedDB is powerful, but clunky. AIR’s SQLite felt intuitive. PWAs need better APIs for structured, offline-first data. -
Desktop UX Still Has a Place
PWAs lean mobile-first. But AIR showed there’s still a strong need for desktop-like UIs. Let’s not forget multi-window, resizable, keyboard-optimized experiences.
🧠 TL;DR: AIR Walked So PWAs Could Run
AIR wasn’t perfect—but it was bold. It empowered web devs to go beyond the browser, and in many ways, it saw the future first.
Today’s PWAs carry the torch—but they still have room to grow into what AIR once was. As modern developers, we can look back to AIR’s strengths—offline-first, native integration, developer control—and bring those ideas into the standards-based web.
Because sometimes, to build the future, you have to learn from the past.
