Why You Should not Give a Fuck if Flash die in the Browser


#1

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!!”

ORLY ?
Take a good look at what operating system can support a browser running Flash
see the Adobe Flash Player / Tech Specs

  • Windows

    Microsoft® Windows® XP SP3 (32-bit),
    Windows Vista® (32-bit),
    Windows 7,
    Windows 8.1
    and Windows 10

  • Mac OS X

    Mac OS X v10.6, or later

  • Linux

    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

And let’s mention Linux too with that

  • snapcraft.io
    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 :slight_smile:.


Flash & The Future of Interactive Content
#2

Very good read… thanks zwetan! Can’t agree more :wink:


#3

Hello,

I’m following your blog almost at the very beginning.
I’m using AIR instead of FP for Windows/Mac/Android/iOS on the last 3 years, predicting this end and the reasons why, you already mention.
Also my apps, are productive apps that’s fit on a installation product however the users get used to stores.
The user don’t know and don’t want to know if is AIR/Xamarim/.NET/WhatEver. It’s a desktop app period.
The business logic and utils is 100% shared between and environments.
The UI is shared between Android and iOS and between Windows and Mac.

For web FP is doomed at least 3 years ago.
Keeping the head inside the sand does not help.

On my point of view, AIR para Windows and Mac is perfectly safe even if on the worst case scenario, Adobe no longer exists to mantain the runtime.
AIR for Android and iOS need a minimum update every year because Google requires update de SSL and Apple always change something on the new major releases that will break AIR, so we need that Adobe at least keep this minimum updated.

About Windows Store, it’s my very top whist item on my whislist and I don’t thing what you said it’s now viable (by now):
Listin you desktop app in the Store it’s just a link for a website and I already tryed that but ended given up because requires very, very expensive certificates and the process is 1000 complicated than Apple (very stupid and not necessary and probably why you don’t see many popular desktop there).
You can see that Desktop App Converter is still very, very Alpha and a GUI or Wizard is required: https://msdn.microsoft.com/pt-pt/windows/uwp/porting/desktop-to-uwp-run-desktop-app-converter
One issue about MS is that they took too long for doing things (that’s why they lost the mobile boot) and they already give up on Android port project. They thing on the development process like 80’s.
On my last check, I read that even if you go thru the complex process of Desktop App Converter, you can’t publish on the Store (this can be changed after the Universary updated).

If MS don’t give up on Centennial project, finish the project and create a simpler process, than we have a way, but by now it’s not a reality.


#4

Hi :slight_smile:

cool thanks, but this is not “my blog”
really any dev feeling he/she is part of the “as3lang” community can post
well … I’ll post something that make that a bit clearer

Yep I can agree with all that.

Now you don’t exactly share 100% of the code, you can share a big part,
but even on desktop apps like Windows vs Mac OS X, there are always little differences (even on pure business logic), still a well organised code base can deal with that.

For the part where you say the user does not care about the tech used to develop the app you are totally right.

That’s also why I see ActionScript 3.0 as a “secret weapon”, it help solo dev, indie dev, small teams to produce “big apps” that can compete with other “big apps” that may use completely different technology.

Not fully agreeing here.

Flash on the web and the Flash Player is still a huge thing.
I mean when you have around billions of install/update per month, it is huge.

But the strong points of Flash are also its weakness: it does depend on the browser.

If the main browser vendors decide to kill Flash, they can (and they probably will do that at one time).

So yeah saying “ignore the haters just keep producing SWF as nothing happened” that would be crazy if we did not have a backup plan which here can be Adobe AIR to some extend.

My logic is pretty simple within the idea of “keep building apps in AS3”

  • if I can still produce a SWF to be hosted online I will do it
    it may be harder for SWF/plugin detection, require more efforts
    but as long as still possible I plan to do it
  • in parallel, I organise every single of my apps to be published
    as SWF (for the web), but also as Adobe AIR apps for mobile and/or desktop
    with a fallback on publishing them as local SWF hosted in a local desktop browser
    like Atom Electron.
  • also I see those apps as only clients and so I spend a big deal of time
    “covering” the server-side, and that’s Redtamarin, in short it can deal with
    HTML clients “presentation” and all the server logic for API, REST, etc.
  • at the very worst of the very worst
    Flash is dead or impossible to use it inside the browser or even as local SWF
    AIR is dead, the runtime not anymore updated to work on mobile and/or desktop
    Redtamarin is my ultimate fallback plan, with either the whole business logic
    on the server the client is just a “dumb” HTML client
  • and other plans like integrating Redtamarin with WebKit and/or CEF etc.

People may think it is nuts but I know exactly why I’m doing that :wink:.

The part where Adobe could not update or maintain anymore the AIR runtime can be problematic.

On desktop it should be OK’ish as desktop apps in general can “survive” over many operating system updates, for example: a desktop exe made for Windows XP could probably still run under Windows 7, Windows 8 etc.

On mobile, not so much. Some things could still works and allow to publish AIR mobile apps,
but the lifespan would be much much shorter. So imagine a dev who has a couple of apps on the mobile app stores and maybe get some revenue from that, an abrupt break of the Adobe AIR runtime could mean for this dev not being able to publish his/her apps anymore and then a total loss of revenue.

I’m not about the money, but knowing how much time 1 dev can spend on building, programming , publishing an app etc. that could be a very scary scenario.

But we are not at all in this situation, Adobe update the AIR runtime on a regular basis and focus in particularly on the mobile platform, and there is no indication whatsoever it gonna change soon.

Yep, it is possible but it is also very expensive due to the license cost.

In fact, if you already survived the Apple bullshit to publish apps on the app store,
the level of bullshit from Microsoft to “link” a desktop app on the Windows 8 app store is
beyond anything I could have seen, almost like them saying “yes it is possible but we gonna make very hard for you, to the point where we hope you gonna give up”.

That said, Windows 8 app store is a total flop, WinRT/Metro is a big failure with a low market share, and I mean by that lower than Linux market share.

And this is exactly why Microsoft is changing stuff around and try to make it much easier on the Windows 10 app store.

On the other end, without being part of the Windows 8 app store you can easily publish an Adobe AIR app for the desktop, so yeah users will have to go the “classic” way: download your app, authorise your app (unless you buy an also expensive SSL cert to sign it), etc.

I don’t agree there.

The success of UWP and/or the Windows 10 app store is a matter of “life and death” for Microsoft,
they have realised that their WinRT/Metro approach was not working and they are quite invested
in not having this same kind of failure for Windows 10.

For the “Desktop App Converter” you don’t really need a GUI, it would be nice,
but honestly as a dev, you do want to be able to run all that on the command-line
in order to automate the packing/publishing of your app.

And yeah it is beta quality, all that will be officially supported with the Windows 10 anniversary release (that happened in August).

But there is no rush for us dev, it’s not like Windows 10 have reached 90% of Windows user install.

The main goal is to support Windows 7 first (50% of Windows users), then maybe try to support Windows 8 (~10%) and/or Windows XP (~9%), and prepare/plan to support Windows 10 (~20%).

You are unlikely to be able to support 100% of everything, wether on desktop or mobile,
you will always have to trade between the time/effort to support a particular version vs ignoring it.

Would you spend weeks or months to support Windows Vista to reach only 1% of the Windows users? I know I won’t.

With time Windows 10 will reach more user and the “Desktop App Converter” will be ready to use in a non-beta stage, it’s not there yet imho.

Sure it is less easy to install a desktop outside of the Windows app store, but it is still possible and work perfectly fine with Adobe AIR and a bit of efforts with a MSI/EXE installer setup.


#6

More or less.
Utils and other stuff is in a AS3 Library that is shared between all apps (100% reused).
I can publish (without any line change) between Mac and Windows (also Mac Store as long I don’t use WebAPI - a new ANE in on the way by Adobe).

Mobile prepared to all screensizes (and updated). Even for 120 DPI (Android) I support (this is why Flex support this kind of DPI’s - I was the tester), so without any single line changed, I can produce an IPA and APK.
However, yes, there is few differences and is about ANE’s: I do my very best to use ANE’s that have the same AS3 interface between Android and iOS and support both OS, however thirt party ANE’s don’t have this vision and I’m forced to put code to see if is Android or iOS to call different methods/parameters to do the same thing.
Also ANE’s very specific for Android (integration with hardware that iOS API don’t support) force me to code exclusively for Android and hide the feature for iOS.

I agree on that. For a Indie developer I can produce code that people think that was produced by a team and I do for 2 OS at the same time (Windows/Mac or Android/iOS) !
When same one ask for a app (not web app), they think they 2 developers are required or a team during many months to produce the Android and iOS.
However, tell that was developed with AIR (a superset of Flash outside of the browser and able to extend), is a mental block (isn’t Flash dead ?; no, it’s impossible to do that on iOS, Jobs formated my mind, impossible !).
But, in thousands of users, just a single one cares about the SDK (was also a developer :D).

That’s why I think that is doomed. Browser vendors want that for all stupid reasons that we know. Seems that they are competing each other to not be the last one.

Thousands of business desktop applications from Windows XP era still work on 10 (only Windows Metro UI was a killer app and we saw what happen to MS and angry users).
Applications developed with Visual Basic 6, etc …, so it’s very likely that AIR for desktop is very safe for many years to come (if not ours lifes, but that is assumptions field), so I’m not worry.

Yes, it’s what it seems.

That’s why I don’t really worry about that.
Even (if/when) desktop app converter is ready, we still need one version outside of the store, because a lot of users still use Windows XP !


#7

I thin we are on most stuff :slight_smile:

For the 100% shared code, I can still see edge cases.

here a little scenario for example:

sometimes I will publish an app using purely the display list for the UI
if the app “grab some interest”, I can the share the logic but start a new project
with a different type of UI: like starling, HTML, etc.

my point is even if you target only Adobe AIR for Android (1 platform)
you can share code (about 80%) for 2 Android app
while the 20% is the difference in UI implementation

or another kind of example when you need to change the logic between
the Google Play Store and the Amazon App store for the very same Android app.


#8

Hello and thanks for this post.

I have a small question:

After 2020, can i still using the HTML tag within an Adobe Air app to serve a html page wich include an swf file ?

I mean does, the flash player stiil exist and still be able to be installed on windows to be used with an Adobe air version > v21 ?

Thanks in advance


#9

Hi,

yes

that’s the goal of Let’s Build a Web Browser

you can somewhat easily build your own web browser with the Safari Webkit embedded in Adobe AIR

now for the support of the Flash Player plugin, in AIR 21 or earlier the plugin is already embedded (eg. you don’t need to install it on the system), and from AIR 22 and later it reuses the system installed plugin (eg. the plugin HAVE TO be installed).

By 2020 and after, Adobe will have released “the latest Flash player plugin” and depending on which version you need to support you will be able to distribute a small web browser built with Adobe AIR with either a plugin already embedded or with the need to install the latest plugin released.

So yes the flash player will still exists, even if not updated anymore; but the key thing to understand is you will need a browser actually capable of supporting that plugin, and from what have been announced by the major browsers (chrome, firefox,etc.) they will stop supporting any plugin.


#10

Thanks a lot Zwetan,

So to be sure that I understand:

  • With AIR 21 I dont need a flashplayer to render a html page wich Include an swf file
  • Beginng with AIR 22 I need a flashpalyer installed on my PC even if it didnt exist on the browser (after 2020)

My last question:

  • Even without a flash player on my PC neither embeded with my default browser, can I run an swf (flex application not a game) and without using the html tag (saying with a swfloader or a loader) as a destop app ?

Thank you again
Sabri


#11

yes

the Flash player as well as Adobe AIR are both runtimes that support playing SWF files

what is described above is using Adobe AIR as a web browser so you can load HTML that embed a SWF file to have that SWF file run by the Flash player

this is, in general, for cases where you already published online SWF, don’t necessarily want to reproduce the whole thing, and want to quickly wrap it into a desktop app.

Now, if you decide to load a SWF file directly into Adobe AIR, without any HTML involved, yes you can do that too, but it may require other changes if you relied on HTML interaction etc.

See an earlier post, where all the 6 or so different way to “do it” are explained
AIR, HTML and SWF


#12

Thanks a lot. You are the One

But what do you mean by “you relied on HTML interaction etc.”

Actually I have just an index.html with nothing but an embded swf file (my app wich calls a set of soap web services) and I planed us you say to package my swf as an adobe air application.

I think there will be no trouble , no ?


#13

Should be no trouble, but again don’t expect everything to work.

My point is: If you produced a project as SWF embedded in HTML,
when you move the project to an Adobe AIR app, be ready to edit the sources.

Now, setup an AIR project and test for yourself to be completely sure, is the easiest/fastest way.


#14

Thank Zwetan. I appreciate your help :wink: