Update on Adobe AIR 33 SDK


#1

Here some great news :slight_smile:
if you subscribed you must haver received this already, otherwise I just copy it here for the people who would want to know but did not subscribed to anything

Hi

Thanks to everyone who’s registered their interest with us, I thought it worth sending out an update (a few of the more recent registrants may not have seen our earlier email, copied below). As a quick admin note, if you want to be removed from this mailing list then please just email us at adobe.support@harman.com to request this. For any details around this, please see our privacy policy at https://www.harman.com/privacy-policy.

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:

  1. 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.

  2. 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.

  3. 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!

best wishes
Andrew

and from a previous email

Hi all

Thanks for your emails registering your interest in this, apologies we can’t reply to everyone individually.

To add a little more information:

  • We’ve had a relationship with Adobe for a dozen years to provide the Flash Player and AIR technologies to customers who don’t fall into the “normal” category of desktop/mobile application development, so we know the AIR runtime code very well; some of the wider SDK is new to us so for example we’ve only recently got access to the source of the AIR Developer Tool, but we are being well supported by Adobe and have already built on their initial work by adding support for an Android-ARM64 platform for ANE creation.

  • We’ve got AIR building and running in 64-bit mode on Android, but not yet extensively tested, so that’s our focus currently. We want it to be in reasonable shape before we release the beta! We also need to integrate some updates from Adobe that they’re making in AIR 32 around the multimedia area, taking advantage of the underlying platform/OS for some of the a/v playback.

  • We’ve been focussing on the engineering side of it and not necessarily the infrastructure quite so much, but we do plan to have a web portal and will upload the SDKs to that; in the short term we may use an alternative mechanism for distribution though, the focus is still more on the runtime and SDK than on a web portal…

  • Pricing is still going through final approvals here, we have some initial thoughts from which our initial business model was created which would involve a free tier and then a kind of ‘pay-as-you-go’ mechanism which is based on a low royalty fee depending on distribution levels. We’re looking at an alternative subscription method but this may need to follow later. Feedback is welcome; obviously we’ve been looking at Unity and other such products/frameworks to ensure that we’re being competitive and not putting too big a burden on anyone. Ultimately though, the fees that we can raise through distribution of AIR will be paying for the development team, so we’re really going to strive to make it a success.

  • The goal is to make this work just the same with all the existing IDEs. We can look at ways to help where an IDE may use a graphical dialog to allow you to select ARM vs x86, prior to them hopefully updating the UI; I’m also wondering whether we can make the packaging a little simpler (if anyone else uses the command line directly… it’s a bit convoluted!)

  • Timescales: we are aiming to release an initial beta version in around two weeks’ time; this would only be for internal development/testing, i.e. no using this for uploading to the Play Store and distributing to millions of end users, as we are still going through the QA processes! The goal for the formal release of AIR v33 is then at the start of July, hopefully giving sufficient time for application packaging/testing/deployment prior to the 1st August deadline. Apologies for the delay (and for the information drought recently) – this deal has been a long time being prepared and ensuring that all the lawyers are happy!

I hope this is useful: thank you for your interest in this, we’re hoping it will be a fairly seamless transition and are looking forward to what we can then do with the runtime to help support you and your applications!

thanks
Andrew

thanks to Andrew Frost @ajwfrost at HARMAN

it is all very clear and packed with concrete informations
and I hope it will make everyone happy


#2

Timely and reassuring. :slight_smile:
Thank you @ajwfrost! Thank you @zwetan!