Pumping AIR into the Flash Debate
Back in 2011, I wrote an article about the demise of Flash Player for Mobile. The article, "Flash Into (Not so) Thin AIR," declared that Flash capabilities on mobile devices weren’t dead, but rather had morphed and continued to live on in a new form—the Adobe Integrated Runtime, or AIR—which would continue to be developed.
Despite what I thought was careful wordsmithing to show that Flash Player capability was alive and well, the matter itself seems to have taken on a life of its own. Part of the issue may have been in the way Adobe announced that it was ending additional development on device-specific versions of Flash Player for Mobile, leading to the erroneous assumption that Flash capabilities were no longer available on mobile platforms.
Four years later, in early 2015, the debate continues. Jan Ozer penned a recent commentary titled "Flash is Dead Again (Yawn)" that took on the assumptions on the part of the likes of CNET and Tech Radar that Flash Player was dying, even though all the major sites—including those two —still use Flash Player in their desktop-centric websites.
Even more curious—and what caught my attention regarding the whole “Flash is Dead Again” debate—were a number of comments on a LinkedIn community group saying that Adobe had abandoned mobile platforms like Android years ago.
"Adobe continues to update Flash, that's true, but for Windows and Mac OS only," wrote Jan Sunavec, a streaming technology specialist at B4B Technologies. "In the past they supported Linux and also Android devices. That's why we can say Flash is dying. Especially when mobile devices are crucial for video markets ... Point is there was Flash for Android, and now it's not. Adobe lost quite [a] big market."
I pointed out that Adobe didn’t abandon the Android platform, and has gained additional marketshare on the iOS platform in the past three years. True, Adobe abandoned the Flash Player for Android back in 2011. However, the AIR platform that developers can use to create apps for both iOS and Android is in parity with the current desktop version of Flash Player. Since apps are used to deliver much of the premium content viewed on mobile devices, this means that Flash is still very much alive on these platforms.
To add clarity to my comment on the LinkedIn thread, and to get a sanity check for what I thought was "old news" from several years ago, I spoke to Chris Campbell, senior product manager in the Flash runtime group.
Campbell is a customer advocate and, as a member of the runtime engineering team, he is responsible for both Flash Player on the desktop and AIR on mobile devices.
"AIR and Flash Player are in parity, regardless of whether it’s browser parity or platform parity," says Campbell, noting that, as of earlier this month, the new Flash Player 17 is now out on the desktop, and that the mobile version, in the form of AIR, is in lockstep with the desktop version.
"There are some code restrictions based on the platform, such as Android or iOS," says Campbell, "but AIR and Flash Player are typically released at the same time."
He went on to say that an example of a code restriction in the past might have been a request by the mobile team to offer iOS developers 64-bit support.
As for Flash Player for Mobile, Campbell reiterated the shift in thinking that caused Adobe to move away from specialized versions of Flash Player for every single Android device.
"We are no longer doing development for Flash Player for Mobile," Campbell says. "But we’ve added significant functionality to AIR since that time."
The main thing that AIR adds to the mix, according to Campbell, is OS-specific functionality. These are things that weren’t available in the native browser on a mobile device, but are available in AIR, allowing developers to take advantage of operating system calls through the Flash Builder or Flex programming environments.
Another area that Campbell said has been added is a plug-in structure for AIR.
"The AIR Native Extensions, or ANE, can be written to be plugged in to the run-time," Campbell says, "to allow a platform-specific ANE, or even device-specific ANE, to address particular functions on a device. An example of this might be an extension written to take advantage of an accelerometer or a biometric scanner, as these are not available on every device."
Finally, I asked Campbell about the fear, way back in 2011, about "app bloat" since the Flash engine would now be loaded in to every app, versus residing once on the device. The reason for moving to this approach, which Adobe calls its captive runtime feature, was to avoid an update to Flash Player for Mobile breaking mobile apps on the platform that required functionality from a previous version of Flash Player that may have been deprecated in the upgrade process.
"Captive runtime feature was first launched in AIR for iOS," Campbell says. "It wasn’t available to start with in Android, but is now available on Android and Windows mobile platforms."
The benefit, Campbell says, is the ability to contain everything in the application itself.
"The end user doesn’t need to know that the AIR runtime is within the app," Campbell says. "It’s been successful in the majority of applications, as we’ve continued to optimize the runtime engine to keep it relatively small compared to other assets—such as art assets for a game—that make up the total application’s size."