Today in 2018, after Flash EOL been announced, when we can say the community of ActionScript developers have shrunk quite a lot, and tons of hammering from flash haters who love to repeat that Flash is dead and so ActionScript must be dead too ...
If you look around you may be under the impression that something like Adobe AIR is doomed and anybody using it, or more exactly still using it, would be flat out of their mind, right ?
Not so fast.
OK, so here I could start to make a very long list of all the great features of Adobe AIR, but I'm not gonna do that.
First, if you're here reading that you probably already know those features or at least some of it.
Second, even if you don't know Adobe AIR at all it is quite easy to pick it up and build a prototype of your app with it.
Just by following the documentation and reference from Adobe, looking into what is available in the API you can get started and progress a lot.
So why should use Adobe AIR if it's not for a long list of features ?
Well ... let's look around and see what kind of problems those other dev using other tech stack still have, and let's compare to what we have with Adobe AIR.
And one among the first to have tried that ?!?
ActionScript 3 off course
in the specification you can read
2 Design perspective
It is sometimes difficult to understand design decisions without understanding the perspective of the designers. Here are the major viewpoints that have grounded the design changes introduced in ActionScript 3.0 and ECMA-262 edition 4.
2.1 Compatibility with existing programs
ECMAScript was originally designed for and used by consumers of host object models. Because ECMAScript is one of the most widely used programming languages, it is important that existing ECMAScript-compliant programs continue to work in systems that are updated to support the new definition of the language.
Therefore, programs written for ECMA-262 edition 3, compact profile, or ECMAScript for XML (ECMA-357 edition 2, also known as E4X) must continue to behave the same way in both ActionScript 3.0 and ECMA-262 edition 4.
21 Compatibility with ECMAScript edition 3
While we have made this edition as compatible as possible with the ECMAScript (ECMA-262) edition 3 language specification, there are certain behaviors for which there is no clear use case and keeping them as-is would have been placed an unneeded heavy burden on the new features of the language. In such cases, we have made small and calculated changes to allow the new definition to be simpler and easier to use.
In the same logic as TypeScript and others, ActionScript 3.0 specification improved on ECMAScript 3rd edition, introducing the concept of types, classes, interfaces, namespaces, etc.
The difference is that something like TypeScript will import and export to ES3, while the ActionScript compilers only import and do not export to ES3.
But, as everything else, compilers evolve over time, and Apache Royale is something that can export your AS3 to ES3.
As ActionScript 3 developers you have access to this superset of ECMAScript 3 since 2006, and in the following decade all those others supersets like TypeScript, Dart, etc. have popped up all over the place.
To me it looks like that TypeScript etc. are catching up to ActionScript, not the opposite.
In fact, what happened to AtScript is interesting
AtScript was originally intended to run on top of TypeScript, while including some features from Dart.
In October 2014, Google announced that Angular 2.0 would be written in AtScript.
In March 2015, Microsoft announced that many of AtScript's features would be implemented in the TypeScript 1.5 release, and that Angular 2.0 would be built on pure TypeScript.
You could say that TypeScript killed AtScript, and to a certain extend TypeScript casted it shadow over Dart.
Dart is not dead and recently Google tried to revive it by releasing Dart 2,
On another thread (Microsoft Acquires GitHub) I commented
Look at Dart for example
in a recent video Ryan Dahl mention in 10 Things I Regret About Node.js at 20:20
euh ... Dart!!
do you guys know Dart?
like ... jesus
I mean ... very good intentions and very cool
but obviously a failure at this point
and TypeScript took a totally different approach to the problem
and solved it in a way that is satisfying many people
so if you have not been using TypeScript, please check it out
I want this thing to do TypeScript because I like it
that's why Google is trying to reboot the language
Announcing Dart 2: Optimized for Client-Side Development see comments
and double down on Flutter (which use Dart)
Ready for Production Apps: Flutter Beta 3 see comments
So yeah you could say that ActionScript 3 is old, that it had not been updated and will probably never be updated (Adobe announced they will not work on ActionScript 4), but does it make it dead?
At worst ActionScript 3 was a precursor and you can only target ActionScript runtimes (based on AVM2),
at best you can reuse all your AS3-fu and build a lot of stuff based just on Adobe AIR, probably a bit more based on things like Redtamarin and/or Apache Royale.
The Next Big Thing at Apple
It had been announced at the WWDC 2018 and posted in many places
On the Verge article you can see this tweet
yeah always à la mode to summon the death of Flash, I'll comment later ...
But let go with this article which imho is more developers oriented
Marzipan: What you need to know about Apple's universal framework API
Apple is reportedly working on a new, cross-platform iOS and macOS development framework... but we won't see it until 2019.
here the intro
Apple has a problem. The teams working on its apps increasingly have to develop and maintain features across iOS and macOS. Sometimes that causes work to go more slowly than anybody would like. Sometimes it causes a lack of feature parity that nobody likes.
That problem is echoed throughout the third-party developer community as well. It results in fewer Mac apps with fewer features updated less often. Or not at all.
So, what to do? The answer, it seems, is a universal framework that allows developers to port iOS to macOS.
Later in the article you will see this
Other companies were using web apps, Electron (Chrome packaged web apps), or progressive web apps to deploy cross-platform. But, like the Java and AIR apps before them, the ease they offered developers was paid for by users who had to put up with a worse experience.
Something I will also comment later ...
Read the article and then watch the associated video
where you can listen to some Apple fanboys discussing about
Marzipan: Apple's Next Big Software Thing!
The article conclude with
When will Apple release this universal framework?
For developers, as soon as WWDC 2019 next June. It will come to iOS 12 and macOS Mojave for us in the fall of 2019 in the form of four Apple built apps that are being ported from iOS to Mac.
- Voice Memos
These apps are going to be identical to their mobile counterparts, but available on Mac! Once Apple feels confident that this testing phase is successful, we'll probably see a developer update.
Euh ... wait a minute, where did I already seen something similar to this?
I mean, a framework where you can share a lot of code, and have identical apps on desktop and mobile?
Oh yeah Adobe AIR is doing just that since 2011 (AIR v3.0).
Humm what do we learn here?
Marzipan replacing Electron marks the second time UIKit has killed flash.
So the first time UIKit killed Flash is when Steve Jobs wrote that famous Thoughts on Flash (which by the way has its own wikipedia page).
And so the second time it's UIKit by killing Electron (that can run Flash in HTML on the desktop)
which would kill Flash again ?
Nope. That still the same error that most Flash haters and other misinformed developers are making, Flash is just a browser plugin, you can only kill it in the browser.
But when it come to desktop and mobile territories, there we have the very same Flash technology
and that is called Adobe AIR, and that one you can not kill it, because its sole purpose is to exists
outside the browser.
There you can not kill it.
and what about this
But, like the Java and AIR apps before them, the ease they offered developers was paid for by users who had to put up with a worse experience.
ORLY? You got a worse experience with Adobe AIR?
Like any other technology it is possible to produce shitty apps with Adobe AIR, but it is also possible to produce great, tight, lean and mean wonderful apps, unless you completely don't know Adobe AIR and so don't know what is capable of.
From the article and the video, here what those Apple devs are discussing
- the building blocks could be the same, you could reuse a lot of code
- the UI does not have to be exactly the same, but some UI elements could be shared
- every company have limited amount of resources
- why such framework as Electron are popular is because developers are lazy,
because they don't have the resources to dedicate teams to maintaining this things (native apps)
- it would be nice to share more the "view" side of things
- if you could have a "common view" on Mac and iOS it could save a lot of time,
like fixing a bug in the model is like fixing a bug in two apps
- by not having the layer to share more code kind of guarantee that it will be drifting away in term of consistency
- it's this all little death by a thousand cuts, there is no reason to not share the core logic, the basic stuff
- what is the current situation for desktop apps in general? I feel like the heyday of a lot of native apps on desktop is over sadly
- all of the big apps, the apps that I would consider world-changing on smaller or bigger scales recently, they've been mobile first, they've been things like or at least web first and mobile first yeah, like Instagram, things like Uber and Lyft
- I mean there's no reason I wouldn't want to be on the Mac other than that I haven't have the resources and the effrot required is it's been prohibitive
- I would love to see the good Gregg peers to ve able to do drafts for Mac, because I would kill for that
- on the inverse side, in a perfect world, I also like to be able to say maybe you have some really good mac apps that have never come to mobile that might be able to come to iOS in better ways
and from the video here the best quote
I guess bottom line for me, my dream is that Craig Federighi would show up on stage at WWDC
2018 or 2019 and he would say we've had 20 years of AppKit we've had 10 years of UIKit
and today Apple takes the next step forward, today we announced a framework that let's you
share your resources between iPhone and iPad and Mac much more easily, much more effectively,
and we call it Xkit or we call it AppleKit
So what do we learn ?
That we have all that since the beginning with Adobe AIR!!
Color me not impressed by Apple next big thing, because I can do the same but not only on iPhone, iPad and Mac, but also on Android and Windows and Android TV and Apple TV too, and to a certain extend with Linux desktop too.
It's been close to 10 years that I'm thinking all my apps as multiple-screen and cross-platform thanks to Adobe AIR, and thanks to Flash legacy too.
Running Android Apps on the Desktop
If you search a little you can find many solutions to run Android apps and especially games on the desktop, see for example: 14 best Android emulators for PC and Mac of 2018.
Based on that here a little list
So yeah that is a thing, look at all those freaking 14 solutions
but why you may ask ?
Here for example the bluestacks 3 video promo
Do you see?
There are some people that make that a platform, that make you think.
So it's there and from the software developer it is far from ideal, someone else is making your app/game run on their simulator as a platform thingy, eg. the dev have no control over that.
In fact, for devs the only way to fight this kind of thing would be to publish their game themselves on the desktop, as such providing a better experience and cutting the grass under the feet of those Android emulators.
And guess what would be ideal, no!!, perfect to do that?
Adobe AIR yet again
Sure, it is a bit much more efforts, but if your game is already running on Android, porting it to desktop Windows and/or Mac would be quite easy because those are real desktop, not mobile, so you have access to much more resources for CPU and RAM and HDD etc.
Tango is Down
This is military slang for the "target is down", and what is the target?
It is the web.
OK, so let's not exaggerate too much, sure the web is as big as before and growing bigger, and sure you can decide to go web-first for your app, if the model fit it will probably work.
But I would say it is not because the web is growing that the other things are gone and dead, and mobile is proving that for almost a decade, as now you can also go mobile-first.
The desktop is still here and still used
- why do you think people port their web app to Electron?
- why do you think Apple think to help devs to publish their iOS apps to Mac?
- why do you think people want to consume their Android games on the desktop?
The desktop is still a big platform, you can not completely replace it with web or mobile apps, you still want (if you can) publish a desktop app.
I push this argument for a long time now with ActionScript, sure still being able to publish on the web as a SWF would be nice because less efforts, but technically you can simply and purely ignore the web for your apps publishing need.
I would almost say publish cross-platform first and Adobe AIR is just perfect for that.
It is a no brainer really, just structure and organise your app to be able to test and publish for the 4 main platforms supported by AIR: iOS, Android, Windows and macOS.
That is why you would chose Adobe AIR, because it allow you to do exactly that, and that cross-platform publishing is pretty damn competitive compared to just publishing for the web.
If you had a Flash game that was published on the web as a SWF you should be already porting it to AIR for mobile and desktop.
If you already have published a mobile app with AIR you should seriously consider publishing it also on the desktop.
And the inverse works too, if you had a somewhat "old" AIR app that was published for the desktop you should port and publish it on mobile already.
People will go mobile-first because it is hard to also build the app for the desktop, even worse they will go iOS-first or Android-first because it is also hard to publish the same mobile app on two different platforms, but with Adobe AIR? it is not hard.
Being able to target cross-platform, to support as well touch than mouse and keyboard, to customise the UI exactly as you want and better display the same UI on all those platforms, to be able to support multiple screens wether the size of an iPhone or iPad or multiple screens on desktop, to share a good 90% of your code base among all those platforms, and many more cross-platform thingy is a real strength.
This cross-platform strength is at the core of Adobe AIR.
When people decide to go web-first and then produce the app on the desktop with Electron, it is like an after-thought, they make it work but they did not really planed to do it cross-platform, they assumed that their web tech stack is cross-platform by default, not completely.
One argument that can be used against Adobe AIR is that it does not support native UI like a native app would and tons of criticism follow, but when it is a web app that is ported to the desktop and also does not use the native UI, there, it seems to not cause any problems ... go figure.
Personally I'm 200% for pushing the UI boundaries outside of the default native UI widgets, your UI should be custom because your app is like a brand, the same way a logo shape and color is unique and make a brand instantly recognisable it should be the same for the UI, exactly like video games.
I'm talking about UI like this
Where the app has a strong visual identity, not the same template reused by 1000s of other apps (cough cough Bootstrap anyone?).
Being able to do that on one platform is already quite good, but being able to do that on multiple platform is priceless, it almost automatically put your app into another (and hopefully higher) category, users do notice.
That is Why you would Adobe AIR.