The basic strength you can attribute to AIR is that:
be able to publish to cross-platforms from the same code base and assets
The default cross-platform targets are:
and to that many different people (maybe dev?) will come back with a “but …” or even many but
here few examples
- but … it does not publish to the web
- but … it does make an installer for me
- but … I can not publish on that platform from Windows
First thing first, cross-platform (also XP ) is hard.
Every single platform will have their own particular quirks, and so if you thought AIR was something as easy “hey let me build something in Animate CC and just click the publish button and I’m done”, you are so out of your depth.
Sure, AIR made some complicated things simpler, but as any other solutions AIR is not perfect, as always you have pros and cons.
Native Installer vs Captive Runtime
Since AIR 2.0 you can make AIR Package a desktop native installer
- publish a
- publish a
- publish a
And yeah that’s very easy, but since then things evolved, and publishing just a
.air app bound to such native installer is doomed to fail in the long run.
This kind of installer will rely on the AIR runtime being installed on the system, and even if this can be detected, if that runtime is not there it is then fetched from Adobe and installed from there.
Problem with that is the Adobe Flash Player EOL General Information Page
4. Will Adobe make previous versions of Adobe Flash Player available for download after 2020?
No. Adobe will be removing Flash Player download pages from its site and Flash-based content will be blocked from running in Adobe Flash Player after the EOL Date.
Adobe always recommends using the latest, supported and up-to-date software. Customers should not use Flash Player after the EOL Date since it will not be supported by Adobe.
OK it is Flash, not AIR, but make you wonder how long this page
https://get.adobe.com/air will be around ?
Well they did not say for sure but from The Future of Adobe AIR
Adobe will provide basic security support – limited to security fixes only for desktop platforms (Windows 7 and above, and Mac OS X) – for Adobe AIR v32 until the end of 2020. After that time, Adobe support for AIR will be discontinued and ongoing support will be managed by HARMAN and communicated by them directly.
So it is more likely that users will not be able to download the Adobe AIR runtime from Adobe web site after end of 2020, which make native installers a gonner.
Also, from what happened on Android, we do know that the advised thing to do is to publish a captive runtime instead of a native installer.
here in the Adobe AIR 30 release notes
Android AIR Runtime Play Store Availability
Adobe will be unpublishing the shared AIR Runtime from the Google Play Store for all devices running Android 4.0 or below on March 13th, 2018. AIR applications that require the shared runtime will not be able to be able to access the required download from the Play Store from these older systems. We recommend impacted developers convert and republish their applications to use the captive runtime before March 13th.
Android AIR Shared Runtime
Starting with AIR 26, packaging of shared runtime applications for Android has been disabled. With this change, published applications will always have a captive copy of the runtime included in their installation package irrespective of the target the developer has selected (that is, apk or apk-captive-runtime ). This change allows us to focus our testing and engineering on captive installations, by far the most popular option for Android.
Yep, distribution of a runtime is key, either Flash or Adobe AIR, if the runtime is not available anymore it is a huge problem.
So the captive runtime should become your default, like right now (not later)
Packaging a captive runtime bundle for desktop computers
and the pros and cons are listed clearly
- Produces a self-contained application
- No Internet access required for installation
- Application is isolated from runtime updates
- Enterprises can certify the specific application and runtime combination
- Supports the traditional software deployment model
- No separate runtime redistribution required
- Can use the NativeProcess API
- Can use native extensions
- Can use the File.openWithDefaultApplication() function without restriction
- Can run from a USB or optical disk without installation
- Critical security fixes are not automatically available to users when Adobe publishes a security patch
- Cannot use the .air file format
- You must create your own installer, if needed
- AIR update API and framework are not supported
- The AIR in-browser API for installing and launching an AIR application from a web page is not supported
- On Windows, file registration must be handled by your installer
- Larger application disk footprint
let me add a bit more
- You have to build your own installer for desktop
- You have to manage your application updates
- Because your app is now bigger than a small
you need a distribution web site
if we were to stope there it would sucks,
learning to build an installer take some time,
hosting your own installers on your own site cost money,
but there are also good parts
- More control on the installation experience
- you can add analytics/metrics for the “install”, “uninstall”
- and you can also add analytics on the “download” numbers
- you can install daemon and background service that work with your app
like an “upgrade the app service”
- Oh you are forced to have a web site to host the installers, that’s good
- do more than just host the installers, use the web to increase the visibility of your app
- point of contact for customer supports, documentations, forum, etc.
- use the server for online service needed by your app: user logins, save/restore data, etc.
- advertising/promotions etc. “hey look we have also a mobile app”
- You can still update parts of your app dynamically loading remote SWF
- It forces you to me more “professional” and that’s a very good thing
- copy what other big software are doing: online release note, blog post on how your app is used, etc.
- look at what other are doing and you will see how much you did not do and what you should do
What does not change, you needed a mac to publish that native installer
.dmg and you needed a windows to publish that
.exe, that would be the very same for installers.
Sure, for a moment, those things could be ignored, but now you’re really forced to think of your users on their platform of choice and that should result in a better product.
Things like “Can use the NativeProcess API” can be often overlooked, but now that you have access to it, you can do a bit more without having to go all the way to ANE.
It does not target the Web
Yep, you got that right, AIR does not target the web at all, some people think it sucks but it is good really.
The web, and so the HTML/CSS/JS target is not replacing the desktop app,
you can whine about it or embrace it, your choice.
I’m talking about “oh Flash is dead, AIR does not support the web target, so I’ll move everything to XYZ”, XYZ being Unity, Flutter, React Native, Swift, etc.
Here few examples:
- Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions
- React Native for Windows and Mac
- Desktop support for Flutter
First thing that I see is, if all those tech push for desktop support, hey desktop is still considered an important target, otherwise they will simply ignore it pure and simple.
Second thing is the developer part
- React Native and React JS, not exactly the same thing
if you think you can publish a mobile app and a web app easily, think again
- same for Flutter,
if you think you can publish a mobile app and a web app easily, think again
- Swift, well… the web target is not really there yet, even if there are ways to compile to WebAssembly, but haha that not easy at all
So yeah they can add the desktop targets too, not gonna magically become easier.
Let’s take Flutter as example
- in May 2019, Flutter for Desktop: Create and Run a Desktop Application
- in April 2020, Responsive Web And Desktop Development With Flutter
I would rather take my chances with Apache Royale
- keep AS3 for the logic parts of the app
- do a Web UI with what Apache Royale propose
- do a Desktop and Mobile UI with what AIR can do
At the very worst, I would have to provide API compat for the web.
And I know some people could argue “but … if I publish to the web I can wrap it up on the desktop with Electron” to which I will answer back “no way that the very same code base work the same you will still have to have different parts for web, desktop and mobile”.
I also know Flash and AIR and the web, with those you go by default with a custom UI,
please do not bring the “native UI argument”, it is a custom UI you’re building.
So yeah the hard part is to have that same custom UI works the same on desktop, mobile and the web, but with Flash/AIR I also know I can build very very quickly a custom UI, so if I wanted the app to look the same, I would just “clone” whatever I setup for the web ui, into AIR.
Now to rub a bit more the web target, here some interesting reading
Second-Guessing the Modern Web
and interesting reaction
This hits the nail on the head. And is 100% matching our long term
thinking. Client-side-only is not sustainable. We need to move more stuff
to the server, but without sacrificing seamless composition of interactive pieces.
It is almost shocking how nobody produced the equivalent of
getbootstrap.com as some kind of ActionScript UI components.
Personally, I would advise going with Spectrum (Whaaaat? you don’t know Spectrum???).
XP means cross-UI, cross-Functionality, cross-Logic
That’s why XP (Cross-Platform) is hard, you have to cross a lot of
Ts and dot a lot if
If you cross-compare the native UI guidelines, from the icons to so many other things, everything is different.
If you accept that the “right” way is to go with a custom UI, things will be less painful.
Sure you have to respect some native customs, like how installers should work or the size of icons, but within your app I really do think the custom UI is the way to go.
I’m not saying you should completely re-invent the basic concept of how a button should work but your app UI should not necessary look like the system native UI, why ?
- all web apps use a custom UI by default
so if you also target desktop and/or mobile, and want to keep a consistent look
there too you should go custom
- branding is important, and your brand is not just the logo
- it is already done heavily with desktop games for years
- Native UI changes over time
nothing is sadder that a not-updated mobile app with the native UI of 5 years ago
- Desktop apps from the OS vendor use custom UI
look at Office 365 or the macOS calc
Problem is building a custom UI that encompass everything is not just building a custom UI, it is building a design system and that is extremely lengthy and hard to build.
And not too long ago, Adobe released their own design system: Spectrum.
The same way I don’t have time to build from scratch the CSS of web sites or web apps and so I use a CSS kit among the gazillion existing, see
- Curated list of Awesome CSS
- List of awesome CSS frameworks
- A curated list of awesome CSS frameworks, libraries and software.
I do not have time, nor the resources, to build from scratch a full design system, and you probably don’t too.
Here come Spectrum, Adobe provide a full set of guidelines and docs about why things are done like that, they cover platform scale to internationalisation to many many many different and important parts of a design system, and they provide all that for free :).
WTF am I talking about?
OK, let take it from the ground and build it up
- your goal is to build a cross-platform app, if possible with AIR and so AS3
- if possible it would be nice to publish this app for the web too right?
- let’s say the app need a button
- I can follow the Spectrum Button guideline
and build a Button component in AS3 in what? 1h top
- I can follow the Spectrum Button guideline
- I can reuse the Spectrum CSS to get the same button works for the web
- I can even push it to reuse Apache Royale to publish a web app
with the benefit that the app will use AS3 and I can use a Spectrum-Royale component
- A Button component in AS3 will just works on desktop and mobile
- Do that long enough and then you have enough components to build an app based on a solid design system
Compared to other CSS kits, the Spectrum CSS is coming our of a general design system, it can apply to more than just CSS, imho it is easier to “port” Spectrum to Flash/AIR (basic display list or starling), than to port something like Bootstrap.
Also that design system, being generalist, leave enough room to do custom UI to brand your app but is at the same time thought for all platforms.
Look at Headers
from the anatomy, the behaviour, the responsiveness, the platform considerations to usage guidelines, everything is very well thought out
If you follow all those and do some bit custom stuff the app will look nice and very pro, imho that’s exactly what any app dev want, anyway that should cover the cross-UI part.
Cross-Functionality is more or less what your programming language and API can do, and how you can extend it.
No matter what is the technology, language and framework, you will never have everything done for you, and so there are always things missing (also why we need developers to build apps, some code still need to be written).
And this is exactly what everyone underestimate when they start their own port of Flash,
it is not only the language or the SWF format or the rendering, it is the API.
Unless your main interest is game and you are obsessed by that famous 60fps, UI rendering does not really need much oomph, displaying buttons, text fields, etc. those kind of basic stuff are not gonna kill your speed.
But something that certainly gonna kill your time is if you’re missing API for basic stuff like display an image, load something from an URL, play a sound, etc.
Most of what is defined in the
flash.* package is what is underestimated, and most importantly done in a cross-platform way.
That for example would be my main critic of Apache Royale, and I say that liking it,
see cross-compiling the AS3 builtins to JS that’s the basic default needed,
if you target only app UI without doing lot of animations, alphas, etc. the
flash.display part can be done with Canvas2D, but then things like ByteArray, Socket, Sound, etc. are what you will miss.
The day when you’ll have a good 80% of
flash.* API available in Apache Royale is when you can target the web from writing AS3 with not too much worries (I know I ask a lot but I don’t really ask that).
My point is that Flash/AIR API is where everyone choke, not really their fault, it is hard indeed, also the platform like the web make some things particularly difficult to implement 1to1.
So cross-functionality, is how much you can reuse cross-platform and AIR is pretty good at that.
Which lead to cross-logic, basically the user code or the code you as a dev you write for your app.
Even if you do a very simple app, how much you can do cross-UI and cross-Functionality will limit your cross-Logic.
If I publish only to desktop, I can reuse the whole strength of the AIR API minus the parts only for mobile, or maybe I limit myself to subset of those functionalities because Im stupid enough to also publish an AIR desktop app for Linux, but still within those limits I can still do a lot.
If I publish both to desktop and mobile, I need to limit myself to use only the common API to both platforms within the AIR API, and if I want more niceties I can have common abstractions with different implementations for desktop and mobile, one of those in particular will be UI elements.
Now if I want to publish to desktop and mobile and the web (via Apache Royale),
same I will have abstractions for UI and different implementations for each platform targets,
but with something like Spectrum I can still achieve the same UI everywhere.
But then the functionalities will be limited by the common denominator of the AIR API and what is available in Apache Royale, if I want more I need to port some of those AIR API to work for the web target.
And then in this user code, there are some things I can limit: as for the web platform simply not implement it and make the app not support that particular feature there, but there are other things which I can simply not do: as it is not me deciding to limit what I implement, but me facing a wall being not able to implement it due to limitations of the platform.
So, with AIR, not only I got this great API that works more or less the same on desktop and mobile, but the web target haha, no there you got the Web API and so plenty of limitations, supposed you would go into a big implementation efforts like writing all those AIR API for Apache Royale, there are things you can simply not implement like TCP/UDP sockets.
My point here, especially for the people that say “oh AIR does not target the web, so it sucks”,
is that the limitation is coming from the platform itself: the Web, you do not have access to everything, and it is worst than that you can not extend (you could with plugins, but plugins are dead).
In AIR, if I’m missing something really important for my app and even wit what I have in AS3 and API I can not implement it, I can still go the ANE way and still implement it, no limits.
It is not easy, but the option is there, it is possible.
For the Web platform, in many case the option is not there at all and probably will never be there.
Where does all that leave us?
We are just dev who try to build apps, and ideally when we build an app we would like this app to be used by as much users as possible.
But users can use different operating systems, in general, you would want users to be able to use your app on Windows, on macOS, on Android, on iOS, on Linux, etc.
But you do not want to write as many apps as there are platforms, ideally you would want to have one code base and be able to reuse a maximum of its code on all those platform.
From the get go, 100% code reuse does not exists, literally impossible, so the next best thing is having 90% code reuse, 80% code reuse, maybe 70% code reuse, etc.
Hell, even 50% code reuse is good to have.
Some will tell you to use HTML/CSS/JS and with that every platform can use your app, but this is a lie, or at least uninformed people that do not dare to go into the details.
Web apps are not bad but there are limited, no matter what.
Yep, they have evolved over the time, you could spend the effort to build a mini-photoshop in web tech, but still the limitations are still there.
It is not about the speed or the performance, or not even about the UI, it is about the context;
NO MATTER WHAT, a web app will always be limited by its container: the browser.
Because the browser can load any HTML/CSS/JS and so there are many security measures in place, you do not want to just visit a URL and execute nasty code that will exploit your machine.
And to those people with a little grin on their face thinking of Flash being killed because of security, well… that very same reasons are limiting your web apps.
When you install desktop apps or mobile apps, you do not have the same limitations,
you still have security measures like signing the app with a certificate, or not being able to access some API on some platform (I’m looking at you Apple), but you can go much much further with such apps.
It is kind of XP vs XP, and people think there is only one choice among
- either build only desktop/mobile apps
- or build only web apps
But it is not that kind of duality.
Remember this advice use the best tool for the job ?
It is more like that, even if you go only AIR apps and publish only on desktop, you will still need a web page for your app because you want your app to be discoverable with a google search.
Even if you go only web app , that will be at first, for many kind of apps you will want to go on the desktop too (hey look the rise of all those Electron apps, that must mean something right?).
Think you only need a GUI app ? in some case you will also need a CLI app.
because it is what the users want.
Look at Github, technically it is a web app and so extremely popular and successful
it is all GUI and all on the web right? no need of a CLI app right?
wrong, big need of a CLI app, proof here: https://cli.github.com/
There are some category of apps that will force you in a certain direction even if you don’t want to go there.
And that’s here I talk about AIR again, if you spend those efforts to build the installer, to build for different platforms, to abstracts different UI for those platforms, etc.
You HAVE TO know why you’re picking up AIR instead of something else.
Let see some examples (yeah I love example I’m an old schmuck )
This is perfect as a web app, lot of text content, light formatting, heavy use of a server to create/update/share the data.
You would not pick up AIR to build wikipedia, it is the wrong tool for the job.
But … you could perfectly pick up AIR to build an offline wikipedia.
In fact, there are tons of app mobile and desktop
List of Wikipedia mobile applications
Wikimedia CH, the Swiss chapter of the Wikimedia movement, has developed a number of offline apps based on Wikipedia content.
These apps were mainly developed to display articles and are often used on platforms for which an official Wikipedia app was not formerly available, such as Windows Phone. Typical features include searching for articles, bookmarks, sharing, or enlarging images.
That would be some of the reasons to build a non-web app
- offline access
- personal notes
- zoom/enlarge images
And you could push the concept even further, remember Microsoft Encarta ?
You could go in that kind of direction, take wikipedia content, focus on interactive content added to it ala Encarta, and make a pretty nice product.
And funny enough, after Encarta moved to the web, it died as an app because of wikipedia
Move to the web and demise
In 2000, the full Encarta content became available on the World Wide Web to subscribers, with a subset available for free to anyone. In 2006, Websters Multimedia, a Bellevue, Washington subsidiary of London-based Websters International Publishers, took over maintenance of Encarta from Microsoft. The last version was Encarta Premium 2009, released in August 2008.
Microsoft announced in April 2009 that it would cease to sell Microsoft Student and all editions of Encarta Premium software products worldwide by June 2009, citing changes in the way people seek information, and in the traditional encyclopedia and reference material market, as the key reasons behind the termination. Updates for Encarta were offered until October 2009. Additionally, MSN Encarta web sites were discontinued around October 31, 2009, with the exception of Encarta Japan which was discontinued on December 31, 2009. Existing MSN Encarta Premium (part of MSN Premium) subscribers were refunded.
The demise of Encarta was widely attributed to competition from the free and user-generated Wikipedia, which grew to be larger than Encarta from its early beginnings in 2001, thanks to popularization by web search services like Google. At the time of its closure in 2009, Encarta had about 62,000 articles, most behind a paywall, while the English-language Wikipedia had over 2.8 million articles in open access.
But things change all the time, personally I bet that many people will be very happy to have an Encarta like app on things like iPad.
For some time, that was one of my main argument against web app, something like Photoshop would be too complicated and resources intensive for the web.
OK, not anymore, but I would say for a mini-photoshop not a full blown photoshop.
So there, does AIR would be better instead ?
I think yes, if you look at all the photoshop clone out there, most are on desktop,
my guess is the interaction with files and the file system, even a very simple mini-photoshop, if you need to browse 100s of images it is just more convenient to do on the desktop, something like that.
That kind of app would be the case where you could start as a web app but you will most surely end up as a desktop app (probably because it is what the users want).
Or in another scenario, the users demand in features could simply force you to go the desktop way, eg. “I want to be able to browse the 1000s of png on my hard drive”.
Let’s look at photoshop alternatives the lazy way and compare platforms
26 Best Photoshop Alternatives from Around the Web
- Affinity Photo
Platform: Mac, Windows, iPad
Platform: Online, mobile app available
Platform: Online, mobile apps
Platform: Mac OS X
Platform: Web, iOS, Android
note: old versions use Flash
Platform: Windows, macOS, Linux
- Corel Photo-Paint
- Photo Pos
Platform: Mac, Windows
Note: online editor photo pos snap defined as “lite multi platform version”
Photo Pos Pro is a Windows desktop application intended
to run on Windows OS (Also can be run on MAC OS with emulator)
Note: was done in Flash before see here
now done in React, so I guess the download versions are react native but not sure
as it seems they had some plan to do it in AIR here?
Platform: Online, Mac OS, Windows, app
Platform: Online, Mac OS, Windows, iOS, Android
- Photoshop Express
Platform: iOS, Android, Windows
Platform: Mac, Windows, Linux
Platform: Windows, Mac
Platform: Mac OS, iPhone, iPad and Android
Platform: Windows, Mac OS, iPhone, iPad and Android
Note: Online editor use Flash eg. “To edit in your browser you need to enable Flash”
The mac desktop use AIR, the Android version does not use AIR
There is no Linux desktop, it is the online Flash version
Platform: Online editor that works on any system
Platform: iPhone, Android, Mac OS, Windows, Linux
Platform: iOS, Android, Online
Platform: Mac & PC
Platform: Mac, Windows
- PaintShop Pro
Platform: Windows 10
Platform: Windows 10
Note: This was open source before that happened
see for ex rivy/OpenPDN Paint.NET source (v3.36.7; prior to non-MIT license change)
Platform: Online Editor
Platform: Mac, Windows, iPad
Platform: Mac, Windows.
- Design Wizard
which gives us that table
|-------------------|---------|---------|---------|---------|---------|---------| | name | Online | Windows | macOS | Linux | Android | iOS | |-------------------|---------|---------|---------|---------|---------|---------| | Affinity Photo | | y | y | | | y | | PicMonkey | y | | | | y | y | | Canva | y | | | | y | y | | Acorn | | | y | | | | | Pixlr | y | | | | y | y | | Pixelmator | | | y | | | | | Sketch | | | y | | | | | GIMP | | y | y | y | | | | Corel Photo-Paint | | y | | | | | | Photo Pos | | y | | | | | | SumoPaint | y | | | | | | | Fotor | y | y | y | | y | y | | Photoshop Express | | y | | | y | y | | Krita | | y | y | y | | | | PhotoLine | | y | y | | | | | Ribbet | y | y | y | | y | y | | BeFunky | y | | | | | | | Pizap | y | | | | y | y | | Luminar | | y | y | | | | | Photolemur | | y | y | | | | | PaintShop Pro | | y | | | | | | Paint.net | | y | | | | | | Venngage | y | | | | | | | Placeit.net | y | | | | | | | Visme | y | | | | | | | Design Wizard | y | | | | | | |-------------------|---------|---------|---------|---------|---------|---------| | total = | 12 | 13 | 11 | 2 | 7 | 8 | |-------------------|---------|---------|---------|---------|---------|---------|
so OK this list from that site sucks monkey balls, it is clearly advertising disguised as “let make a list of the top N stuff”, more than half of the reported platform were wrong as if they did not even bother to test or verify looking at the web site, etc.
but still… we can extract infos
- there is almost the same amount of Online and Desktop apps
but they are mutually exclusive
- 1/2 of the Online apps also go Mobile
- 2/3 of the Desktop apps do both Windows and macOS
- only 2 of Desktop apps also do Linux
- the same amount of Desktop apps or Online apps target only 1 platform
eg. only Web or only Windows, or only macOS
- and the same amount of Desktop or Online apps target multiple platforms
- only 2 apps target Online and Desktop and Mobile
- when the app target Mobile, they do both iOS and Android
- not a single app do only Mobile
- every single app has a web site
So the pattern I see is that
- one camp do cross-platform with Online (for desktop users) and Mobile
- other camp do cross-platform with Desktop only, ignoring Mobile
- either Online or Desktop very few care about Linux
My conclusion, if you can publish to all the AIR targets (Windows, macOS, Android, iOS) then you can cover the major platforms while “ignoring” Online (Web app).
Yep it would be worth it to pick up AIR for such “photoshop clone” app.
The examples above illustrate (ok maybe badly) why you would pick up AIR for cross-platform.
- with less limitations and being able to extend without limits
you can do stuff on Desktop/Mobile the Online/Web can’t do
- all the current active AIR targets: Windows, macOS, Android, iOS
cover 90% of the users preferred OS
- Desktop/Mobile apps are as much discoverable as Online/Web apps
as long as they have a web site
Your XP app build with AIR can still work kinda like Online
We all know the pros of cons of Online app vs Desktop app.
One great pro of the Online app is that it is fast and easy to deploy,
you don’t need to download and click install.
For a Desktop app you could do a portable app as “no need to install it”,
just run the exe, even from a USB key.
You can do a portable app with AIR, but you can also update it dynamically,
at application start (or other trigger) you could check online and download an updated SWF
that you load from within the AIR desktop app.
It need to be carefully planed but yeah that works, thanks the inheritance from Flash.
With others solution like Unity, Flutter, Swift, etc. it would be harder to do that.
Another one is that usually Online app are considered “thin”
while Desktop app are considered “fat”.
I would argue that some Web apps need to load MB of JS to work as SPA,
and so each time you visit the web site hosting this app.
For example, many would advise a SPA first load to be around 2MB,
but to achieve that it is pretty hard, you see often dev using React JS
struggling with first load around 10MB.
So sure your AIR app + installer could be 5x that, yeah a big fat 50MB,
but you install that only once and it does not cost bandwidth on your server.
And compared to other solutions (like Electron) your AIR desktop app can be much lighter to distribute, 100MB vs 50MB.
The web works the same for everybody, even Desktop apps.
One of the great feature we had (but not anymore) with AIR was to be able to embed in a web page an install badge that could install an AIR app or launch it directly from a browser if already installed.
No more Flash so no more AIR install badge.
Instead the official way would be to register a URL handler eg.
myapp://some-arg to open a Desktop app from the browser, but that is a huge PITA.
Have you heard of Zoom and people being able to invite themselves into chat they were not invited in the first place ? Or in the same vein Stealing secrets from developers using WebSockets.
That little trick is very simple, instead of calling a URL handler, you make a direct call to localhost and a daemon or background service listening there then run/open your Desktop app.
That’s the “more control” part with building your own installer, you can not only install your app but also install such background service that can be used for
- checking your app updates on a remote server
- listening on localhost to open your app from a browser
- and more
It does not work on the Web
Sure, but you have alternatives
- Apache Royale that can cross-compile your AS3 to JS
- the Spectrum design system that can work as a CSS and be replicated in AIR
- if you absolutely need a Web app you can build a lite version Online
- also detect the user platform, propose the installer for that platform
and/or detect (with localhost) the app is already installed and launch it from the browser
- at the very least you can build a sexy web site that promote your desktop apps
for example, from the list of photoshop clone above: Luminar
And, in a not too far future, you can even keep the logic of the AS3 server-side with something like Redtamarin, and your Web app is basically just a UI.
If you publish to both Windows and macOS, you are covering most users.
AIR even gives you that advantage of targeting older OS by downgrading your AIR version, for some apps people want that.
Your problem is not really not having a Web app, it is using the Web to promote your app and make it discoverable.
It does not work on Linux
Sure, but you have alternatives
- you can downgrade AIR to 2.6 and publish a
it will be only 32-bit
- you can publish a projector binary for Linux
it can be 64-bit and use latest FP 32.0
- and use Redtamarin daemon to do some of the AIR API from Flash
- and use
wmctrlto control the size and positioning of the window
- you can publish a AIR Windows and run it through wine
- you can publish a docker version with everything pre-installed neatly
see this Running decade-old games in containers
- you can publish an Electron app as an HTML container for a SWF
and you will need to bundle the
so no need to ask the user to install Flash
- you can publish an Electron app embedding the Online lite version of your app (as described above)
- you can build a C/C++ wrapper around the NPAPI flash player
- you can provide a CLI version of your app, some Linux users would love that
OK Linux a special case for many many reasons … let’s keep it short.
it is still hard
Off course it is hard, cross-platform is hard, AIR has good things going but it not gonna make the whole app for you, it still requires work.
Just building 1 app on 1 platform is hard.
I’m not talking about just publishing an AIR exe, I’m talking about producing the whole app from start to finish.
Let’s see a basic checklist
- functional spec
- design spec
- technical spec
- brand and design
- assets production
- automated build
- setup / maintenance
- web site
- REST API / app service
- support / forum
- advertising / SEO
- promotion assets
- blog / use case
- social media
test on WIN 7, WIN 8.1, WIN 10
both 32-bit and 64-bit
what minimum? 10.9? 10.11?
For some they’ll think that’s crazy, for others they’ll think I have not even scratched the surface, but “just writing the code” is not the same as “building a product”, the code part is not 99% of the job.
If you publish a small app as an hobbyist, sure you don’t care.
But if you plan to sell it? that app gonna need to look professional
firstname.lastname@example.org as customer support not gonna cut it
Acquiring credibility from many people (the users) is something extremely hard to do
the more you do it “professional” and put the hard work the more chance you give your app
but still one stupid mistake can make you lose most if not all that credibility
aka “those guys does not look serious I don’t feel comfortable at all running their app”
So AIR only gonna ease the sharing code parts among different platform, the cross-platform, but all the other stuff, even if it just an installer or the correct icons for the app, this is on the platform.
It’s not AIR that make it hard, it is the platform itself.
If you can not load SWF containing code on iOS, it is on Apple, not AIR.
If it is hard to sign a macOS app, it is on Apple, not AIR.
If you have to update your Android mobile app to 64-bit, it is on Google, not AIR.
If you have to jump through loops on Windows 10 to publish an app on their app store, it is on Microsoft, not AIR.
Off course you can use any tech stack you want, but the tantrum of throwing AIR out of the window and blaming it for all the hard things imposed by the platforms is just not justified.
There are a lot of things that AIR is doing right in the cross-platform area but the other things (checklist above) is the real battle.
It is a long post so I will not go into too much details, but your app discovery depends on google search, and I can guarantee you the first results you get when searching apps, even if they look like “genuine” blog post or “top N this” etc. those are all advertising, do the test yourself on an app you know is real good and exist for a long time, search its category / type of app, and you will barely find it if they don’t advertise like crazy.