Captive Runtime packaging in Air 3.0

When I talk with people about the Flex framework, many think of it as a Flash library. They often refer to Flex as a web framework that runs in a plug-in. To me, however, Flex is an application framework. To be honest, Flex in the browser doesn’t excite me. I am much more interested in using Flex on the desktop or on mobile devices.

Some History

Until recently, Flex has been criticized for requiring a separate runtime install. The criticism is valid – users were often confused by this and found the need to upgrade something other than the app they wanted to install. The user experience became one where the user was left wondering, “what just happened?”

In one case, my customer required that nothing be allowed installed on the users’ machine (network access was not available either). This meant no Air runtime and no app. We had a workaround which included an app embedded inside of a PDF but that left the user feeling like they were watching Inception (an app within an app…).

Although this was the case in OSX, Windows and Android, it was not the case in iOS (iPhone and iPad). Apple doesn’t allow third-party runtimes on their devices so Adobe created a native compiler and packager that bundles the Air libraries directly into the app.

Captive Runtime

In Air 3.0, however, the requirement for a separate Air runtime has been lifted. With the “Captive Runtime” feature, developers can bundle the native Air libraries with the app. When apps are bundled this way, they can be deployed any way you want. They won’t require an installation of Air OR the application itself (on the desktop; mobile apps still need to be installed but can be without the separate runtime). This doesn’t mean you are restricted from installing your app but it means that it is no longer required. In addition to iOS, Captive Runtime will work in Android, OSX and Windows.

Let’s see how easy it is to use. I will create a “Hello World” app for illustrative purposes but significantly more complicated applications work just as easily.

Flash Builder 4.6 has integration built-in integration for captive runtime.  When you “Export Release Build” from Flash Builder, you simply create a “Signed application with AIR runtime bundled”.

Everything else is the same. You add a signed certificate to the app as you normally would and any other packaging settings.  When you are complete, you will get a native application that is ready to execute but doesn’t require Air to be installed.

This app can be copied to a thumb drive, shared from network storage or embedded into an installer. It is an application just like any other.

Note that this does bloat the size of your application. This may or may not be an issue for you depending on your audience and deployment mechanism. You can always package your app as a traditional Air app if you prefer.

The Windows story for building your app is exactly the same as the OSX side. The only difference is that the app is packaged as an EXE with the Air support alongside it.

The story for Android is similar. You have a different dialog for packaging, but the idea is the same. The APK that is produced will have Air bundled inside.

Of course, you don’t need to use Flash Builder to package your app. You can do it from the SDK and the command line. Instead of repeating what you can already find out in other places, I will just refer you to Andrew Trice’s blog for more info on that.


If you would like to get a sneak peek of Flash Builder 4.6, you can apply for the Flex and Flash Builder pre-release.


Tags: , ,

15 Responses to “Captive Runtime packaging in Air 3.0”

  1. ScottR says:

    Any idea if the normal air application updates work (my app, not the Air player) so I can easily roll out newer versions of myapp.swf to users or will I have to roll out a whole new bundled exe again and again?


  2. admin says:

    That’s a good question. In the OSX and Windows case, the SWF file is in plain sight. (In iOS and Android, you would have to package fully, I’d imagine.)

    For OSX/Windows, it would seem like a simple copy/replace would do it as long as you don’t require a new version of the runtime. I haven’t tried this, though. There might be something preventing you from doing this…

    I’d suspect that users wouldn’t feel comfortable, though, copying SWF files around, so you would probably want to include a script or something… Let me know if you figure anything out. It would be interesting to know.

  3. ScottR says:

    I did a quick test by replacing the main swf file with a slightly updated one. Seems to run just fine. :-) Anyway, Captive Runtime is a fantastic new feature. Looks to me like Flex/Air is really headed in a great direction.

  4. Pete Magsig says:

    Very cool. Do you have numbers on the bloat?

    I have a feeling I’m going to end up buying the IDE for flex before the year is out. This just seems to get better and better.

  5. admin says:

    Well, the bloat is significant for the time being. It packages the entire Air runtime beside your app so a 1 MB app goes to about 40/60 MB in Windows/OSX. I have wanted to experiment with it, though, to see what I can prune. For instance, if you are not embedding WebKit, then you probably don’t need to ship it. Hopefully you can just rip it out. Also, I am hoping that they will be a bit smarter about it as the feature progresses.

  6. obirocks says:

    i got myself the flash builder 4.6 from the prerelease program, but i dont have the option “Signed application with air runtime bundled” in the “export release Build” window nor can i find the dialog box “target platform google android” and the export options in the deployment window “export application with embedded air runtime” as shown in your last image.. what version of the builder did you use there??? or could it be that there is a difference because i installed it with german language?

  7. obirocks says:

    there is no difference in german/ english version with my flash builder 4.6 .. so what version of flash builder did you use?

  8. mr_iks says:

    I have not this option on the first page of the Export release build too. It’s in the next step under Deployment – Export options – Export app with captive runtime

  9. YopSolo says:

    Really cool feature !
    Thx :)

  10. narita says:

    Hello! You say, When apps are bundled this way, they can be deployed any way you want. Can I deploy my apps in this way via website? AIR3 distribution via an externally facing Internet site is prohibited. But if I deploy my apps with captive runtime, it’s not problem.

  11. Andrew says:

    Any idea what determines what version of AIR gets bundled into the captive runtime? We have an up to date version of Flash Builder, but our captive runtimes are running into problems with accessing the web from within Android. If we use a non-captive runtime and a current version of AIR installed on the device, then everything works great.

  12. Robert says:

    I am developing an application that runs on Android and iOS devices. I find that the Android APK without captive runtime is 4.4M. The iOS IPA with captive runtime is 9.6M. The Android device launches my application in about 5 seconds. The iOS device launches my application in about 90 seconds. That’s right! 90 seconds. I looked at a black screen for 12 seconds, and about 78 seconds of splash screen.

    I have 400k of embedded images. I have 44k of embedded icons. The SWF file is 2.92M.

    This is my experience with the captive runtime on iOS.

  13. admin says:


    I agree that the real-world story for using Captive Runtime for mobile is questionable. There are things that don’t work very well. This article is more about Captive Runtime for use with desktop apps. In that case, CaptiveRuntime is a real win IMO.

    Thanks for your experience with the mobile side of it. I think things like that leave it as a good technology for prototyping, but the real-world mobile story can leave some to be desired.

    Good luck,

  14. cx says:


    it only means that while debugging your application you’ll have plenty of time to learn about code optimization.
    i mean i’ve seen it many times when single ad banner took 99% of my top shelf cpu.
    just because code compiles it doesn’t mean you know how to write software.

Leave a Reply