AIR

Adobe AIR - the Adobe Integrated Runtime - is not a programming language. It is a cross-platform application runtime, first released in February 2008, that took the languages web developers already knew and let them ship the results as installable software. An AIR application is written in ActionScript 3 with optional MXML markup, or in plain HTML, CSS and JavaScript, or in a mixture of both; the runtime supplies a Flash Player execution engine, an embedded WebKit browser, a filesystem, a local SQLite database, native windowing and, later, access to cameras, microphones, accelerometers and the GPU. It appears in language encyclopedias mostly because for several years it defined what “web technologies” meant when they escaped the browser.

It is also one of the more unusual survival stories in this collection. Flash Player, the technology AIR was built on, reached end of life at the end of 2020 and was actively disabled in browsers. AIR did not die with it. Adobe handed the runtime to HARMAN International, which turned it into a commercially licensed product and is still shipping releases in 2026.

History and Origins

AIR grew out of a problem Adobe had after acquiring Macromedia in 2005. Flash was on nearly every desktop in the world, and Flex gave it a serious application framework, but everything it produced lived inside a browser tab - no filesystem, no window of its own, no presence when the browser was closed. Meanwhile Ajax had made the same argument from the other direction: rich applications in HTML and JavaScript, equally trapped.

Adobe’s answer, developed under the codename Apollo, was to package the two engines together into a desktop runtime. A public preview with an SDK and a Flex extension appeared on 19 March 2007, followed by beta 2 on 1 October 2007 and beta 3 on 12 December 2007. Version 1.0 shipped as Adobe AIR on 25 February 2008, with runtimes for Windows, Mac OS X and Linux.

The pitch, made most visibly by Adobe’s then-CTO Kevin Lynch, was that the web should extend beyond the browser: developers should not have to learn Cocoa, Win32 and GTK to put an application on someone’s desk. It was, in retrospect, the same argument Electron would later win with - made five years earlier, with a proprietary runtime and a plugin-derived engine.

Design Philosophy

Two languages, one runtime. AIR’s defining decision was to support both application models rather than pick one. An ActionScript/Flex application and an HTML/JavaScript application are both first-class AIR applications, they share the same security sandboxes and APIs, and they can call into each other - HTML content can be embedded in a Flash-based application via the HTMLLoader class, and JavaScript in the application sandbox can reach the AIR APIs directly.

Elevated privileges, sandboxed content. Code shipped inside the application package runs in the application sandbox with access to the filesystem, the network and native process launching. Remote content loaded at runtime stays in a restricted sandbox with browser-like rules. This split is what made AIR a desktop platform rather than a browser with a chrome-less window, and it is also the reason AIR applications were code-signed from version 1.0 onward.

Write once, package many. The same source could be packaged as a Windows .exe installer, a macOS bundle, an Android .apk or - after the 2.6 SDK - an iOS .ipa. Native extensions, added in AIR 3, provided the escape hatch: platform-specific C, Java or Objective-C code exposed to ActionScript through a defined interface, for the cases where the common denominator was not enough.

Key Features

A minimal AIR application is an application descriptor plus code. The descriptor is XML:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

<application xmlns="http://ns.adobe.com/air/application/51.0">
  <id>dev.codearchaeology.hello</id>
  <versionNumber>1.0.0</versionNumber>
  <filename>Hello</filename>
  <initialWindow>
    <content>Hello.swf</content>
    <visible>true</visible>
    <width>400</width>
    <height>300</height>
  </initialWindow>
</application>

The ActionScript 3 side looks like any Flash application, with the AIR-only classes layered on top:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

package {
    import flash.display.Sprite;
    import flash.filesystem.File;
    import flash.filesystem.FileStream;
    import flash.filesystem.FileMode;

    public class Hello extends Sprite {
        public function Hello() {
            var f:File = File.documentsDirectory.resolvePath("hello.txt");
            var stream:FileStream = new FileStream();
            stream.open(f, FileMode.WRITE);
            stream.writeUTFBytes("Hello, World!");
            stream.close();
        }
    }
}

That flash.filesystem package is the whole point: it does not exist in the browser Flash Player. The AIR-specific surface includes, among others:

Evolution

Two of these deserve elaboration.

The Linux retreat (2011). AIR 2.6 was the last version with a desktop Linux runtime. Adobe’s stated reasoning was the small share of AIR installations on Linux against the cost of maintaining the port, and it pointed developers toward AIR for TV and Android - both of which are Linux underneath. It was an early, well-remembered entry in a longer pattern of Adobe withdrawing Linux clients.

The version-number jump (2014). AIR went from 4 to 13 with the April 2014 release, skipping the intervening numbers entirely, so that AIR and Flash Player - which share a large amount of code - would carry the same version number. Adobe announced the plan in December 2013. The effect is that AIR version numbers after 2014 measure quarters elapsed rather than anything about the technology.

A note on performance claims. When Adobe launched Flash Player 11 and AIR 3 in 2011, its marketing described the new Stage3D pipeline as delivering rendering performance up to 1,000 times faster than Flash Player 10 and AIR 2. That figure compared GPU-accelerated Stage3D rendering against the previous software rasterizer on unspecified content and hardware, and Adobe did not publish a methodology, workload or baseline configuration. The direction was real - moving 2D and 3D rasterization onto the GPU is a large win, and it is what made Flash-authored games viable on mobile - but the specific multiplier should be read as a marketing figure, not a benchmark result.

The HARMAN Era

In June 2019 Adobe announced that ongoing support and development of AIR would move to HARMAN International (a Samsung subsidiary), with Adobe supporting the existing product through the end of 2020. Version 32 was the last version Adobe released. HARMAN carried the 33.x line forward on a commercial basis and, over subsequent releases, restored Android runtime work - including 64-bit device support and current Play Store requirements - that Adobe had stopped.

The commercial model changed with the handover. HARMAN licenses the SDK by subscription rather than charging for end-user runtimes, with a free tier for hobbyists and developers under a US$50,000 annual revenue threshold, whose applications display a HARMAN/Adobe splash screen at startup, and paid tiers above that which add support and additional platform targets. Runtimes remain free for end users.

Because platform targets have moved under both Adobe and HARMAN - desktop Linux dropped in 2011 and later reappearing in commercial tiers, Android stopping and restarting, BlackBerry Tablet OS supported and then abandoned - do not treat any historical platform list, including this one, as current. Check HARMAN’s own documentation for the specific SDK version you intend to use.

Current Relevance

AIR in 2026 is a maintenance platform with a real, paying, invisible user base.

The visible consumer applications are gone. TweetDeck was rewritten for the web, the BBC retired iPlayer Desktop, eBay and Pandora abandoned their AIR clients years ago. Nothing new is being started on AIR; a developer choosing a cross-platform toolkit today reaches for Electron, Tauri, Flutter or React Native, all of which do what AIR did with an open runtime and a living ecosystem.

What remains is a long tail of shipping commercial software written in ActionScript over fifteen-plus years - games, kiosk and point-of-sale front ends, digital signage, training and simulation systems, internal enterprise tools - where a rewrite costs more than a subscription. That is precisely the business HARMAN bought, and it explains the release cadence: the 51.3 series shipped through the first half of 2026 - 51.3.1.1 in February, 51.3.3.2 in July - keeping the runtime working against new OS versions, new signing requirements and new app-store rules rather than adding language features.

Encyclopedic listings marking AIR dormant are reading the ecosystem correctly and the software incorrectly. There is no community, no new adoption and no forward design work - but the runtime is under active, funded maintenance.

Why It Matters

AIR is worth studying for two reasons, neither of them technical.

The first is that AIR was right and lost anyway. Its core thesis - that application developers should be able to use HTML, CSS and JavaScript to build installable desktop and mobile software - is now simply how a large share of desktop software gets built. Slack, VS Code, Discord and Figma’s desktop client are the descendants of the argument Adobe was making in 2007. AIR made that argument first and comprehensively, and it lost because the runtime was proprietary, the engine was tied to a plugin the industry decided to kill, and the tooling cost money. Electron won with a worse pitch and better licensing.

The second is that it shows what happens to a platform after its foundation is demolished. Flash Player was end-of-lifed with a countdown clock and actively blocked by browsers - one of the most deliberate technology shutdowns ever attempted. The runtime built on top of it survived, because captive runtime packaging meant AIR applications never depended on a browser plugin, and because enough of the installed base had no economical exit. A technology can be culturally dead, commercially unavailable to newcomers, and still be worth paying an engineering team to maintain. AIR is the clearest case of that in this encyclopedia.

For anyone maintaining ActionScript code today, AIR is not a historical curiosity. It is the supported path, and it still ships.