It’s been good to see feedback on the various forums and messaging boards, we’re perhaps not able to respond to all of those as much as we’d like. It’s still our intention to set something up under our own area, but this is taking a back seat to the focus on getting the updated SDK ready. The input we’ve received online is all useful, but I would encourage anyone with ideas around improvements that could be made to Adobe AIR to email us with “[Feature Request]” at the start of their subject line. Our own use of Adobe AIR over the years has tended to be for OEM customers who have particular needs in order to use AIR for a device user interface framework, so some of our own thoughts may not be so relevant to your mobile/desktop applications and games. One area I’m particularly interested to hear viewpoints on is around the use of audio/video within AIR: Adobe have been making some changes here as many of you will have noticed, but the general capabilities haven’t moved forward much so please let us know if there are any issues here.
As I’d written below (on 31 May), we are hoping to soon publish our beta of the AIR v33 SDK to support Android 64-bit ARM platforms. We were targeting the end of the coming week – 14th June – but this may be at risk now as there were some additional requirements imposed upon us yesterday, which may be tricky to complete by the end of the week. We’re thinking that it would be good to get you “something” that you can use ASAP just to start testing your own applications, so we are planning to push out a beta version (or perhaps we should call it alpha..) as soon as this is ready, prior to us completing our QA activities. This means it may have significant bugs still, particularly around multimedia which is where a lot of late changes are being applied. Due to that, we are going to say that you can use the beta to do your own development/testing but it’s not then suitable for distribution to end users. We are then looking at releasing the proper version after another 3 weeks, and if necessary we will do a patch release just at the end of July in case there are significant issues found for the Android platforms.
In terms of platforms supported, we are just starting off with Android, but are internally now ramping up on iOS as well so we will include that in the SDK later in the year; desktop platforms are slightly less of a priority as Adobe are continuing to support these but they are on the plan for the end of the year. We’ll look into whether there are any changes needed for iPadOS, and – while we can’t yet promise anything – we can also see if it’s viable to bring back a Linux version of AIR. If you would be interested in this, please let me know (if you haven’t already!). We are looking at incorporating some minor updates into the AIR runtime and SDK, based on some of the feedback that we’ve received, but we also need to see how the new versions are working: this is a completely new build set-up and environment from how Adobe do things, which was very tied up with their internal tooling and infrastructure, so there may be some teething issues that we’d have to focus on.
Pricing is something that has gone through a lot of discussions internally here. We’ve had to take on board the feedback that we’ve been receiving, and revisit our plans on how this should work. The expectation now is that we would offer Adobe AIR under a subscription model where there is a commercial license to use the build tools; so rather than having a model based on the numbers of copies of the AIR runtime binary (which is how this is licensed for bespoke/embedded devices), it will be based on your use of the ADT packaging software. We are still finalising the plans on this – we will have an initial/free offering which allows people to get started, and will then have tiers in a similar way to how Unity is priced. Actual pricing details will be published later though – we’re aiming for the end of next week along with the beta, but our management want to get this right and to ensure we’re getting the price as low as possible whilst still getting enough revenue to support our plans for the development team, and they’re asking for a lot more details on likely usage information (i.e. how many subscribers we could expect at what level..). If anyone is comfortable with sharing details with us, it would actually be very helpful: we’d be interested to know (a) how many people in your company use the AIR Development Tool, and (b) how many apps do you publish or update each year.
One quick note as a few people have asked: we are separate from Adobe and the Creative Cloud system, so I’m afraid even if you have a subscription for Adobe Animate, you would still need to license the AIR SDK separately.
In terms of tools, we aren’t taking over Flash Builder as a number of people have asked! We want to ensure that the ‘new’ AIR SDK works with all of your existing tools/IDEs, and have gone through a few of these internally so far to make sure this does work. We will still publish a version that is compatible with the Flex SDK – our aim would be to consolidate these into one, if that’s technically possible – and we’ll provide details on how to get the various IDEs to build for the different Android CPU architectures where there isn’t an option directly available within the tool. We’ve been in touch with the Animate team now, and had a great conversation with the Moonshine developers, so we’re confident that from a workflow perspective you shouldn’t face any challenges.
For ANE developers, again nothing much will change, but I know that you’re keen to get your ANEs updated for the 64-bit Android platform. We may be able to provide the relevant parts of the SDK ahead of time for this, so if you want to receive this, please email us back with “[ANE]” at the start of your subject line – we could then provide the tools that allow you to compile/link your ANE binaries, and even to create the ANE package itself (but not the runtime with which to test these on-device I’m afraid, until the beta release is available).
Finally just to clarify a few things around the offerings listed on our website:
This is all about Adobe AIR, which is the first thing mentioned on our website. While we’ve been adapting/distributing AIR for embedded devices for many years, this is a new initiative to support the ‘open’ community who are using the AIR SDK. We are keen to encourage people to keep using AIR and even for new developers to adopt this – I’ve had some very encouraging meetings with our senior management this week who are keen that we try to build this business up; they don’t see this as an “end of life” handover which I have seen some people comment on online.
We continue to offer custom versions of AIR (and even Flash Player) for those who need it, for closed or embedded devices. Adobe have a different model for this, which we’ve been working under since 2006, and I’m suspecting that this isn’t relevant for the vast majority of people who have registered their interest around AIR SDK.
We are also involved in the migration of content away from Flash: this isn’t meant to be about migrating content away from AIR! This is more for people who have created applications using Flash/Flex who won’t then be able to have their applications working in the browser post 2020, we are working on a few large projects to migrate Flex content over to JavaScript or TypeScript based frameworks, and we have other options available in case your application could be deployed as a standalone installable rather than via a browser. One of the options of course is AIR! So please don’t feel that we’re encouraging people to move away from this technology: instead we’re recognising that, after 2020, the browser vendors will be locking out browser plug-ins such as the Flash Player.
As always, we welcome your input and feedback!