OMG OMG OMG Google Chrome, and Mozilla Firefox and few others they all gonna block by default the Flash player plugin in their respective browser … OMGWTFBBQ that’s it … Flash is Dead?!?
As it is, publishing a SWF file online and be able to read it in the browser on different operating system etc. is sure quite convenient and it has been for years, it helped many creators and other makers to build, program and create rich user experience, from multimedia-like interactivity to animation, to games, to video, audio etc. player.
I’m not here to debate if HTML5 have reached a point where the technology can produce the same kind of content, I’m here to defend this very simple POV (Point of View):
You write code in ActionScript 3.0, you like the tools, the way the publishing works, you maybe like to build your assets in Animate CC (ex-Flash CC), test locally and other stuff to the point where when you publish your apps/games the result is consistent with what you have experienced locally.
In short you like the toolchain, the ecosystem, the platform and you would very much like to keep building stuff with it.
What we had and why it worked
Flash in the mid-nineties was a killer app, it was basically bringing the equivalent interactive content you could find in a CD-ROM and allowed designers and developers to bring it to the web.
The first focus of the Flash player plugin was to stay small (in size) so even if a user did not have the plugin installed it was a very small download, even on a slow as shit connection.
The other focus was to make the content as a binary format, the SWF file, so it could be distributed consistently, stay small (packed) and be able to do more advanced stuff like embedding image, sound, video, font, etc.; The evolution of the SWF specification is all about that: a binary format that can embed stuff.
Flash got popular because of all that, it was like Macromedia and then Adobe reinvented the GIF and ZIP and added a tons of features to it. I know whole company who got build only because 1 SWF spread virally to millions, at one time people where not even bothering pointing to an HTML page and linked the SWF file directly.
And that has been the relationship between Flash and HTML for many years, HTML was just a dump container to display a SWF file, the browser was just a vehicle that allowed to run a plugin that then could run and execute the content of that SWF file.
Different philosophy about apps
For the last 10 years, the web technology and the browsers developed and extended, to the point where many people found it more convenient to publish their app for the browser, versus publishing an app for the desktop.
Developing, testing, publishing cross-platform desktop apps is really hard and error prone, and even if you can support a lot of operating systems you app is still no universal.
But when you have a browser app, the only app your desktop need is a browser, there your app is really universal (as long as you support every goddam browsers out there).
On top of that you have the very nice bonus to be able to update your app instantly to everyone as soon as you update it on your server.
My point here is that there are two main school of app publishing:
- Desktop app
- need to be compiled for a particular OS / CPU
- limited by the hardware
- need to be updated locally
- can work offline
- Browser app
- limited only by the browser features
- can be limited by the hardware
- can be updated instantly
- most can not work offline
Such apps as eBay, Amazon, Facebook, etc. would have literally fail as desktop applications.
To compare apples with apples (pun intended), compare a spreadsheet you can edit with Google Docs online and the equivalent spreadsheet you can edit with Microsoft Excell on your desktop.
All that to say that for some people the only way to publish an app and put it in the hand of their users is to publish a web app intended to be consumed within the browser.
But things have evolved
At one moment you could draw a vey hard line between desktop and web apps and depending on what kind of app you wanted to publish the choice was obvious.
“I wanna publish a photoshop like graphic editor app”
well… go desktop
“I wanna do commerce online”
duh… do a web app
And then, with time, technologies evolving, mobile coming to fruit, etc. everything got mixed up.
Now you have case where publishing a native app is the only way to publish on a particular platform: iOS, Android, etc.
And other case where building a cross-platform desktop app is not as hard as it was before.
Even case where people will argue you could use web technologies like HTML5 and JS to publish desktop and mobile app.
But one of the biggest change are the different app stores that have popped up.
It is not only a technical change but also a change of habits for how users install apps.
So let’s raise a couple of things
- when you want to install another browser than the one that come by default on your mobile, you are installing a native mobile app
- even if you can browse stuff from your mobile, some apps that you would use in a browser on your desktop (example: gmail), you end up installing the equivalent native app on your mobile (again gmail for iOS/Android).
- all those popular big web apps like eBay, Facebook ,etc. that existed only in the browser for the desktop, have all become native app on mobile
- the mobile platform has made people to get used to the app store: a place where you browse app and install them
- we have now desktop app stores: Mac App Store, Windows App Store, etc.
- if you can get away with publishing a web app “as if” it was a native app on mobile, the opposite is also true: you can get away with publishing a desktop app inside a desktop app store “as if” it was a web app (people just see a nice icon to click and install)
- a web site for a mobile app is one web page with links to the app store installation
And all those things matters.
Here an ironic comparaison:
for more than a decade people were so addicted to Flash content that it made then run anything-SWF, they did not think twice to install/update the plugin, in fact in went to the point where the users expect the Flash plugin to be already pre-installed in their browser so they don’t even have to install it.
The app store is about the same thing but in the opposite direction (almost), now if a user see an app in an app store the user does not think twice to install it, because all apps are signed and verified now, it is just one icon to click. The users also know that the install is painless and that if the app doesn’t do what they want they can also easily uninstall it without breaking the whole system.
My point here is the users do not hesitate to install apps the same way they were not hesitating to run SWF file.
Also, if the app is in the app store, then it is de facto trusted, you don’t have those scary warnings requiring you to input your administrator password.
Just saying’ user habits towards native apps have evolved a lot, thanks to mobile, thanks to Apple (that’s why it is ironic, you will see why in a moment).
What can we actually do now
So, what can yo undo if you can not publish a SWF online anymore ?
well… you can publish it but the browser will not run it
Do you rot it to HTML5 ?
you can, but it’s like writing a whole new application from scratch.
But we are in luck, we have other options, the Flash ecosystem evolved too for quite few years and brought us another runtime: Adobe AIR, this runtime is described by Adobe as an “Out of the Browser experience”.
See the chose of words? OUT OF THE FUCKING BROWSER
simply put, your SWF file can run perfectly fine if not better without the browser.
Whatever apps or games you had published as a SWF or you were planing to put online, you can simply publish it as an AIR application.
And there some reflexes should kick in and I already hear you crying:
“but it will not work as universally as in the browser!!”
Take a good look at what operating system can support a browser running Flash
see the Adobe Flash Player / Tech Specs
Microsoft® Windows® XP SP3 (32-bit),
Windows Vista® (32-bit),
and Windows 10
Mac OS X
Mac OS X v10.6, or later
Red Hat® Enterprise Linux® (RHEL) 5.6 or later,
openSUSE® 11.3 or later,
or Ubuntu 10.04 or later
Latest versions of Firefox or Google Chrome
See, the Flash player is not really universal, it will mainly run on popular operating systems.
And that’s about where you can publish with Adobe AIR.
Porting a SWF to a desktop AIR app, if you target mainly Windows and Mac OS X is almost trivial.
For Linux, it is possible with and old AIR 2.6, but there are still another alternative.
You can perfectly publish a SWF app as a SWF embedded in a thin HTML wrapper running inside a custom browser native app, see for example: Atom Electron and in particular the doc about Using Pepper Flash Plugin.
At the very worst, you can distribute your SWF packed inside a custom browser, yes it is more work than just publishing a simple HTML with the Flash plugin, but it is a custom browser so you can control what is running or not.
Simply put: Google Chrome official distribution can block the Flash plugin by default, your desktop app (which is basically a reformatted Google Chrome) doesn’t have to follow this rule.
But wait … you can do even more.
If you put a bit more efforts in organising your project, and many other little details, you can also publish that very same SWF file as a mobile app.
I already said it but I’ll say it again: you can share 80% to 90%+ ActionScript 3.0 source code between Windows, Mac OS X, iOS and Android.
It’s harder, more advanced, etc. but not that hard really.
What do do with the HTML
The same way you use a one page HTML to promote a mobile native app you can do exactly that to promote your AIR app and have 4 or 5 nice littles icons that redirect to the different app stores.
OK I hear you
“hey since when can we publish on Windows App Store ? that’s not possible with AIR app”
Oh no, it is very much possible, here few references
Listing your desktop app in the Store
where the Windows Store for developers blog explain to you how you can list a classic desktop app into the Windows 8 app store.
Bring your desktop app to the Universal Windows Platform
where the Windows Dev Center explain how you can convert a classic desktop app to the Windows 10 app store
And let’s mention Linux too with that
Package any app for every Linux desktop, server, cloud or device, and deliver updates directly.
Last but not least, I’m finishing my “hello world” templates for Redtamarin which basically show a workflow to publish command-line apps to different platforms from programming, building, packing, publishing, etc.
And right after that, I will extend those very same “hello world” templates to show different workflow to publish GUI apps, either Adobe AIR or SWF in HTML running on the desktop, with the same logic of showing the details of how to organise the programming part, how to do the building parts, how to do the packaging parts (custom installers, signing, everything …), and finally how to do the publishing parts and where exactly you can actually publish those GUI apps.
When you put everything together you do realise you can do quite a lot .