Important Development Workflow Change in AIR 2

If you’re an AIR application developer, and you tend to run an installed version of an application at the same time that you’re developing it, this post contains important information on how your development workflow will need to change for AIR 2.

In AIR 1.5.3, we made some changes to the way that AIR files are signed. Previously, publisher IDs were computed using developers’ certificates, and were associated with applications at install time. When running the same application from ADL (which is what you’re doing when running or debugging from Flash Professional and Flash Builder), unless the -pubid flag is passed in, the application runs without any publisher ID. The result was that you could run an application from ADL while running the installed version of the same application simultaneously.

Starting with AIR 1.5.3, publisher IDs are specified rather than computed. If no publisher ID is specified (which is the default), the application is installed without a publisher ID. Since ADL typically runs applications without a publisher ID, and since only one instance of an AIR application can run at a time, the result is that if an installed version of an application is running, you cannot use ADL to launch the same application. In other words, you cannot run and develop the same application at the same time. (For more information on the changes we made in 1.5.3 and the reasoning behind them, see Oliver Goldman’s post, Upcoming Certificate Renewal Changes in Adobe AIR.)

This new behavior isn’t technically a bug since the previous behavior was not so much intended as it was a convenient byproduct of the signing and installation process. That said, we realize this is an important workflow for many developers (including myself), and we plan to re-enable it in the future. In fact, not only should you be able to run and debug the same application at the same time, but we intend to actually support the workflow this time.

Explicitly implementing and supporting this workflow has two advantages over the previous behavior:

  1. We can make sure we never "break" it in the future. (When things just kind of work accidentally, you never know when they might stop working.)
  2. We can make it even more comprehensive and useful than the previous behavior. (We have some good ideas we’re currently considering, but feel free to post suggestions here.)

In the meantime, if you find that you really need to be able to run and debug the same application at the same time, I’ve found that the best work-around is to change your application ID in your application descriptor file. For example, I’m currently working on an application called MailBrew which I also usually have running in the background. The installed application ID is com.christiancantrell.mailbrew, but while developing it, I change the ID to test.com.christiancantrell.mailbrew. Not only does this give me the workflow that I’m used to, but it also allows my test application to use a different application storage directory, encrypted local store, etc. Just make sure that you change your application ID back before building a release version since if you don’t, updates to your existing version will not be allowed. (Note that you can also use third-party tools like Apache Ant to manage this switch for you.)

We apologize if this change negatively affects your development workflow, and we intend to not only re-enable the old workflow, but to also make it better than it was before.

3 Responses to Important Development Workflow Change in AIR 2

  1. Apphacker says:

    This is a huge inconvenience. Please support this right away. I developed an Adobe AIR IRC client app and I want to actually use my installed client while I work on the dev version. The effect of this change is that since I’m always working on my client that I can never actually use it and I made it for me. I’ll try your work around but if this is too big of an inconvenience I think I’ll just port the thing to some other platform.

  2. Chris Rivers says:

    Have you considered allowing the -pubid command line arg in order to support this case? I don’t mind editing my -app.xml file to change the appID/publisherID in order to run two instances of the app, but it results in the (very dangerous) possibility of checking in that appID/pubID change.

    Obviously, it’s unlikely any decent release process wouldn’t catch such an error, it’s just annoying to have to keep in mind all the time.

    If we were still able to specify a pubid at build/package time, we could just do that in Flash Builder (since our real builds are done on the command line).

  3. Tahir Alvi says:

    very nice for our future growth.

    Thanks