Apple to completely remove Flash support in next version of Safari

Cal Jeffrey

Posts: 2,505   +570
Staff member

Apple just released the latest Safari Technology preview. It comes with many changes, most notably the removal of support for Adobe Flash.

Apple dropping Flash support in Safari is not too big a surprise. The company has criticized it for its numerous security flaws and has never supported it in iOS. Even Flash on the desktop version of the web browser was limited to a hobbled downloadable extension. Once the update is finalized, not even a plugin will work.

The revision rings a final death knell for Adobe's interactive web technology that has been around since 1996. In the pre-broadband days, it was invaluable for some types of content. The platform-agnostic plugin was used primarily for simple games and animations that could be played within a browser. It also supported media playback. YouTube, Hulu, and others used it for their video players for quite some time.

Aside from its many security vulnerabilities, the platform was also used for phishing. Users, when visiting some questionable sites, would be presented with fake notices that told them they needed to update Flash. These would contain a download link to a page mimicking Adobe's. It would then attempt to gain personal information such as passwords or infect the users' computers with a trojan, virus, or other malware when they tried to download the bogus version of the program.

With the increased adoption of the HTML5 standard, which replaced a lot of Flash's functionality, Adobe decided it was time to put the software to bed. In 2017, it announced it would end support at the end of 2020. Since then, most of the major tech companies, including Facebook, Google, Mozilla, and Microsoft, have abandoned Flash and patched it out of their platforms.

Once the newest version of Safari releases, the few legacy websites still using the as-good-as-dead software will essentially be killed as well. By next year, the only place you will be able to find the Flash Player and other related content will be the graveyard that is the Internet Archive, where you can already view its tombstone.

Masthead credit: PixieMe via Shutterstock; Image credit: Jarretera via Shutterstock

Permalink to story.

 

Puiu

Posts: 4,009   +2,525
How about actually making the browser good? I've use the latest beta versions and Safari is still a nightmare for web developers (while I can drop support for IE, I can't do it for Safari). It breaks so many things and is incredibly slow to add new modern features.
 

jobeard

Posts: 13,934   +1,770
Hmm; must be your implementation as Safari works with the same code as Firefox & Chrome.
 

Puiu

Posts: 4,009   +2,525
Hmm; must be your implementation as Safari works with the same code as Firefox & Chrome.
That's the biggest lie I've ever heard. Safari is years behind those two. Just because it loads simple code fine doesn't mean that it works fine. For example it has major issues with performance when it involves fixed elements and if you add some mildly heavy JS it just craps itself. Another example, It has some different "default" css values which forces you to write extra code just to make things work properly (you have to spend hours searching why things don't render correctly).
 

CharmsD

Posts: 411   +254
How will Safari, or any other software run when Apple throws away their whole operating system?
 

jobeard

Posts: 13,934   +1,770
That's the biggest lie I've ever heard. Safari is years behind those two. Just because it loads simple code fine doesn't mean that it works fine. For example it has major issues with performance when it involves fixed elements and if you add some mildly heavy JS it just craps itself. Another example, It has some different "default" css values which forces you to write extra code just to make things work properly (you have to spend hours searching why things don't render correctly).
Interesting, however the web pages I've written work find in FF, Chrome, Opera, IE9 and ...
Safari (on Mac OS X 10.13)
 

jobeard

Posts: 13,934   +1,770
My experience has shown that coding like
<!--[if IE 8]> ...
is inherently flawed and leads to all kinds of DOM and JS issues, so I've adopted means to avoid browser & version sniffing. The webpages are sensitive to the platform mobility, like "Desktop, Tablet, Phone" and that's sufficient for me.
 

Puiu

Posts: 4,009   +2,525
Interesting, however the web pages I've written work find in FF, Chrome, Opera, IE9 and ...
Safari (on Mac OS X 10.13)
It's 100% impossible that you've never hit a quirk from a browser, especially IE and Safari. Or you just don't do anything complicated (a lot of animations and JS)

It's not about whether I can't make it work or not, it's how I get there.
 
Last edited:

jobeard

Posts: 13,934   +1,770
some different "default" css values which forces you to write extra code just to make things work properly (you have to spend hours searching why things don't render correctly).
Personally, I never rely upon defaults but use CSS class to fill a desktop presentation and then added tablet or phone classes as necessary per the device. FF option for debugging shows the class structures and which are being applied, so it becomes only "why didn't xyz get applied for that device".
 

Puiu

Posts: 4,009   +2,525
Personally, I never rely upon defaults but use CSS class to fill a desktop presentation and then added tablet or phone classes as necessary per the device. FF option for debugging shows the class structures and which are being applied, so it becomes only "why didn't xyz get applied for that device".
It's not that easy when it works on 3-4 other browsers but one just craps out. The time wasted for debugging is very significant. For example there are situations where Safari stretches images when all other browsers maintain the aspect ratio.

Being more "careful" or not leaving "default values" is not an answer. You want to write as little code as possible in as little time as possible. If you can make the CSS and JS 20% smaller then you win a lot in terms of load time performance.
 

jobeard

Posts: 13,934   +1,770
I typically make the width a percentage of a space and let the browser maintain the aspect ratio
If you can make the CSS and JS 20% smaller then you win a lot in terms of load time performance.
Removing all whitespace from JS and CSS works wonders
 

Puiu

Posts: 4,009   +2,525
I typically make the width a percentage of a space and let the browser maintain the aspect ratio

Removing all whitespace from JS and CSS works wonders
I always minify my code for production. I was obviously talking about the code after minify (and even gzip) was applied. And typically nobody uses fixed width images, everything I make follows a responsive design --> Safari has problems with maintaining the aspect ratio in certain situations (regardless of fixed width or percentage).
 

jobeard

Posts: 13,934   +1,770
And typically nobody uses fixed width images, everything I make follows a responsive design
very typically, responsive IS a set of fixed widths

Enough -- we both know what and why we're make our choices -- best wishes.
 

Puiu

Posts: 4,009   +2,525
very typically, responsive IS a set of fixed widths

Enough -- we both know what and why we're make our choices -- best wishes.
responsive is a set of fixed widths? ok dude, I guess I've been making websites and apps wrong then, I should just put px, instead of em, rem, vw, %, etc, and just hope that all screens have the same size and that my clients always have the browser fullscreen.
or maybe I should be using 100 media queries?
 

jobeard

Posts: 13,934   +1,770
NOT AT ALL!! You're in the 10% of developers Not being lead like lemmings :)

Your percentages allow a fluid flow regardless of screen or object sizings, unlike fixed objects.