Safari 16.4 is an admission
infrequently.org
infrequently.org
It's interesting how perceptions work. You could say, "Allowing Chromium to ship whatever they want with no regard for standards bodies or their consensus", and it'd be just as accurate.
Chrome is shipping a browser with a well-established goal of narrowing the gap between native apps and web apps, and so it pushes all these features for web apps. Safari seems to prioritise building a solid, fast browser for -websites-, so obviously, web app features will take a back seat. Almost everything in that list of missing features shipped in 16.4 is related to web apps.
And stuff like the Reporting API, which isn't web-app-specific, hasn't been released in Firefox yet either, so it's not like Safari's behind, even if you tag it with "2018"; it sounds like there's more to that story than just "they're five years behind".
Are you really that naive about Apple’s motivations here? From the article:
> They argued that if developers don't like its generous offer to take only 30% of their revenue, there's always Cupertino's highly capable browser to fall back on.
> The only problem, of course, is that lawyers and regulators ask follow-up questions like "is it?" and "what do developers think?"
> Which they did.
It is my professional mission to build a web that works for everyone.
I was on the Safari/WebKit team from 2012-2015, and I can say with absolute certainty that the author has no clue what he's talking about with respect to how bug tracking, feature/bug prioritization, or headcount works at Apple.
I could elaborate on all of that for an hour or more, but what I will say is this:
The _number one_ problem with the speed of Safari/WebKit releases has always been that they have traditionally been tied to the release of major OS versions. A few of us on the team referred to this as the “fundamental tension,” i.e. the tug-of-war between yearly OS releases and the much-faster pace of innovation of the web platform.
Everyone on the team was aware of this. Many of us lobbied to change this. The holdup was _absolutely not_ due to any kind of willingness to keep Safari behind in order to push people toward native apps, it was due to the seemingly-immovable internal culture of everything being tied to a yearly OS release.
The culture finally started to change with the advent of the Safari Technology Preview builds, which were explicitly meant to offer insight into the progress of new WebKit features. It seems like my former colleagues have done a great job in pushing for greater transparency and more frequent release cycles since then, and I applaud them for doing so.
This is not the Safari/Webkit's teams fault, just far too small a team for such a complex project and Apple, without any competition on iOS and an adverse incentive to make the web a compelling platform was not going to fund it. This is in addition to the fact that Google was paying Apple not only for Safari search engine traffic but Chrome traffic as well.
Outside of the stability issues, the gaps in functionality especially for Web Apps became vast and it was not practical to build a viable Web App on iOS. No Install Prompts, no push, no orientation lock in addition to severe issues with scrolll (which haven't yet been fixed) meant the only way to build a working app was to go native.
The only thing that has changed, is that Apple realizes that competition is coming and they need to build a competitive browser. This is why they are investing now. Headcount and the development of Push Notifications was almost certainly related to this regulatory pressure.
This is a great outcome, and just with what's happened in the last year I'm really hopeful for the future.
That said, still quite a number of critical missing features and fixed are needed before Safari can truly be used as an application platform.
I think that all of the recent changes and increased transparency are great, but I disagree that the motivation behind those changes was any form of perceived or actual increased competition. From my perspective, this is the result of years--years!--of internal lobbying to improve transparency and increase release cadence.
Apple, on the whole, has never been interested in competing with other companies that operate in shared spaces on a feature-by-feature basis, even if it came at the expense of market share. The one and only guiding star has always been the user experience, and if there was no obvious user experience-based justification for prioritizing a feature or a bug fix, then it did not get prioritized, period.
This is, in part, why Apple engineers have always been adamant about third-party developers and users filing bugs--a higher quantity of reports makes it easier to justify addressing a particular issue to management during a given development cycle.
How would explain the enormous numbers of serious bugs, or the fact the Safari had slipped well behind Firefox, a non-profit with a fraction of the resources?
I lost count of the number of times local storage or indexedDB was broken by updates. Not to mention countless, very obvious regressions. Web Apps that would randomly crash 60 times a day (with one time requiring us to wait 1-2 months for the patch to role out.
Also even in the code base, you'd have (exceptionally talented) engineers juggling complete disparate and unrelated areas of code.
One major issue with no competition, is Apple never responded to developer needs. There were literally many thousands of requests for Push API for years and since no other vendor could implement them (no other vendor could even install Web Apps), there was no competitive pressure.
I don't buy the "user experience" argument. A browser full of bugs does not lead to a good user experience and the expense it imposes on developers is enormous.
As a personal example, we had such serious issues with scroll, tap to focus and bounce that the only solution was to recode all scroll-logic including scroll-bars, momentum bounce in javascript while the same app could be built with only minor issues in both Firefox and Chrome despite the fact that iOS Safari was our primary target.
As for the bugs, they just didn't get fixed. So many for, years and years.
That all said, this is past history, and I'm very hopeful for the future. The fact Apple has hired a ton more staff (including significant numbers of QA/Testers staff), a ton of really excellent web OG's and are pumping through both the features and the bugs really bodes well for the future of browser competition.
I do agree that developer experience is important, and that Apple should take developer experience more seriously than it does, and that applies across every org in the company. Case in point: the infuriatingly-opaque and mercurial nature of the App Store review process.
The problem is that, percentage-wise, developers are a minuscule portion of Apple's overall userbase. That makes the justification for fixing concerns that are (perceived as) unique to developers difficult when the culture has traditionally leaned toward prioritizing issues with a more obvious impact on the majority of users. I'm not saying this is correct or desirable, just the way things have worked historically.
Given all of that, I think “a browser full of bugs” is relative. I witnessed many instances of bugs being experienced by large numbers of users being fixed extremely quickly. It's always been a function of (obvious, measurable) impact. If a significant percentage of web apps were crashing 60 times a day, those bugs would have been fixed extraordinarily quickly.
The 60 times a day crash (more specifically the app just froze), took 1 to 2 months to fix and it affected every web app. Users would have to force kill the app and restart.
I'd recommend reading through all the comments to get a really good idea on how severe all of the bugs were: https://open-web-advocacy.org/walled-gardens-report/#ios-saf...
https://open-web-advocacy.org/walled-gardens-report/#safari-...
In 2021, after 10 years of these issues, no progress on important web app features (like push/install prompts), no response from Apple or the Safari/Webkit team, we decided the only method by which Apple would fund Safari properly was to goto governments and regulators to reverse their ban on third party browsers.
Not long after we petitioned regulators Apple started working on push notifications, 12 years after they came out for native.
Eg: Not allowing to set the size of an iframe unless using some hack.
https://github.com/PierBover/ios-iframe-fix
This was not a bug. It was a deliberate decision.
Of course it hasn't slipped
> A browser full of bugs does not lead to a good user experience and the expense it imposes on developers is enormous.
I'm one such user. I've been using Safari as my daily broswer on desktop since at least 2011, and I'm an iPhone user.
I've yet to encounter these bugs that lead to bad user experience. And no "only works in Chrome" is not a bug.
As a user, you are not the one that has to invest 100's of hours fixing platform bugs. If a website does break, you'd blame the website even if Safari was at fault.
It's also hard for any end-user to see the absence of functionality, or a useful application that never got built because it was too difficult or didn't have the underlying functionality required. It's hard to see an application that was only ever built for iOS because the costs of producing two native apps was too high, or the app that never got built at all. It's hard to see the increase in prices because of no competitive pressure on the native ecosystems, or a new mobile ecosystem that never got built because it didn't have access to apps users's wanted.
At the end of the day this all ends up harming the user.
Of course it hasn't. Because in your mind "functionality" is "whatever Chrome ships".
And if you pretend that Edge is a separate browser, then Chrome on iOS is a separate browser.
> If a website does break, you'd blame the website even if Safari was at fault.
There are about zero websites that a user visits daily that break in Safari.
Of those that do break yet another near zero are those that break more than some visual glitch.
And of those that have significant functionality broken ... about 99% of those on a yet another Chrome-only non-standard.
> It's also hard for any end-user to see the absence of functionality, or a useful application that never got built because it was too difficult or didn't have the underlying functionality required.
This bullshit argument has a very good counter-argument that trumps everything you pretend is true: https://news.ycombinator.com/item?id=34907860
> At the end of the day this all ends up harming the user.
At the end of the day what you think harms the user has about zero relevance. Because people bemoaning Safari's perceived deficiencies rarely know what actual real breathing users want: https://news.ycombinator.com/item?id=34517503 (and of course browser vendors have no intention of giving us that)
https://developer.apple.com/documentation/safari-release-not...
They shipped a lot of features in Safari over the years, including many that that landed before Chrome and Firefox's implementations, and in general, Safari has remained the fastest, most power-efficient browser on macOS. But PWA-specific features weren't high on the list. Users didn't want them; developers wanted them, and Apple has rarely prioritized what Developers want over what their Users want – with both being second to what Apple wants.
My honest impression is that the entire "PWAs are good" are basically the crowd that make cheap apps discovering a way to sell to Mac users without having to actually make quality software. Any time I encounter a PWA or a chrome wrapper "native" app it's just another chance to experience an app that can't do basic things like "find" correctly.
The entire argument for PWAs is "it's cheaper". I have not once seen a "it results in a better UX or app".
Not necessarily cheaper to make but your revenue isn’t cut by 30%.
Also your app can run almost instantly by visiting a link. App Clips and Instant Apps don’t really cut the mustard unless your app is tiny
Installing to the home screen is not the reason they never took off.
It's because the user experience on them is terrible compared to native. Really is as simple as that.
… because there’s perverse incentives to keep it that way
It was not designed for highly dynamic, fluid, responsive experiences.
> specific performance tradeoffs
But you don’t specify.
Android is built upon the JVM which is affected by GC pauses much the same as JavaScript, but the performance issues are solvable in the browser as much as they have been in the ‘native’ Android domain
I'm also not sure why I'd have to list the tradeoffs on a forum of developers.
They're self-evident.
HTML and the DOM are always going to be a less efficient representation of an interface than a component tree. CSS is always going to be a less efficient manor of appearance specification than direct properties on a component object. JavaScript is always going to be less efficient than something compiled down to machine language.
Each adds several layers of abstraction, processing and adaptions that add overhead. That's their whole point.
It's not exactly something you can "debate".
> HTML and the DOM are always going to be a less efficient representation of an interface than a component tree
Is the DOM – from which is derived from HTML – not also a component tree? Is it a graph or some other topology I'm not aware of? When you specify a design in Interface Builder, Android xml, or even the DOM-differ-like SwiftUI + Jetpack Compose how is the topology different? Check a DOM object, it's a node with children.
> CSS is always going to be a less efficient manor of appearance specification than direct properties on a component object.
Property inheritance is definitely a thing on both Android and iOS. I'm sure you could confect especially non-performant CSS, but at large it isn't taking up great deal of compute. I've definitely seen weird constraint issues on Interface Builder cause glitches and pauses (and even crashes) on iOS.
> JavaScript is always going to be less efficient than something compiled down to machine language
Javascript can be compiled down to machine language, using the JIT. Similarly Android is compiled down to Dalvik/Java-like byte code and run on a JIT. Is Android not native? Or is it some No True Scotsman kind of thing?
> I've been a mobile developer for 10 years, a web developer for 2-3 years, and I've done perf with C++/Asm for years of my career, so know that I'm not coming from a place of naivete on either performance or mobile/web development.
with this:
> Is the DOM – from which is derived from HTML – not also a component tree? Is it a graph or some other topology I'm not aware of? When you specify a design in Interface Builder, Android xml, or even the DOM-differ-like SwiftUI + Jetpack Compose how is the topology different? Check a DOM object, it's a node with children.
Would you like to point out where I'm mistaken? Or are you just feigning superiority?
DOM objects can have exactly one parent, many children, and cannot have cycles (i.e, no parent can be itself or a child). It's very specifically a tree[0] of components. I'll take the L here if I can learn something from you. So tell me, with accuracy, how HTML/DOM is not a component tree? And then extra points as to why this different data structure is inherently less performant.
I'd recommend reading through WebCore, from the WebKit project, as its some of the most readable CPP you'll find, and should give a sense of why that implication is naive:
> converting that markup into a tree
The web is indeed dynamic. It means any cache-misses for webpages will require re-parsing. Could be substantial compute depending on the size of the page, but not necessarily – the vast majority of the delay of a webpage is network. But we're talking a web app here. If it is something visited often (as one would use an app), it's a cache-hit, if it's occasional usage, it's analogous to downloading an app again, but much faster and without having to jump to the app store to do it.
> which in turn may/would have a component tree attached
Read my earlier comment. Component trees are not a point of difference here.
> maintaining state between the DOM's tree
Once again, not a point of difference. DOM manipulation is component tree manipulation, much the same as what's happening under the hood in SwiftUI and Jetpack Compose.
> to an interpreted runtime
Once again, if you're not using an app often, there's a cache-miss and the code will need to be re-parsed, but that's the trivial 'download cost' of the app. Once parsed it's JITable byte code much like Dalvik on Android.
> I'd recommend reading through WebCore
That's cute. Given this whole thread I'd wager you've never read it before, let alone grokked it any of it. You're probably capable of doing so, and you're welcome to, but I'll make no pretense of having read it or intending to.
Caching and execution of dynamic JS was a difficult problem, but one that has received a lot of attention. Similarly caching of dynamic HTML and CSS. These performance problems are fortunately the purview of specialized developers building one of the 3 browser engines in popular use and complexity well abstracted from the developer.
There is one main drawback, which you haven't mentioned yet, that is memory and storage. But once again, because it's cached, it's very easy to 'eject' a web app from storage (e.g. using an LRU policy).
But of course the elephant in the room is that many popular 'native' apps are just Ionic/Electron ports[0], because people gave up waiting for PWAs to be supported fully by mobile OS and browser engine teams. I've used 1Password, Spotify, Slack, Signal, etc. built on HTML/CSS/JS and I don't experience jank, because the performance problems have been solved. You might retort, "But they aren't dynamically loaded", to which I'd point you to back to the concept of caching.
[0] https://en.wikipedia.org/wiki/List_of_software_using_Electro...
And with that, I'm done here.
> Can you make an argument as to why a browser can't provide a native-like experience?
And behold, I explained why.
Every abstraction you layer onto a stack has a performance tradeoff.
You essentially rebutted by saying "we can make things faster" and ... no one said we couldn't.
Your second rebuttal is essentially, "Well, things are fast enough for me!" Which ... OK.
I said they are fast now for the reasons specified.
> "Well, things are fast enough for me!" Which ... OK.
They're 60+ fps. Fast enough for everybody.
This reflects trends in software development. Cheap and easy for developer. Poor user experience.
You see, the goalposts on what "PWA-specific features" are are moved all the time. Because everyone selects their own set of features to wave about as "the one true support for PWAs".
Meanwhile Android has 70% of marketshare in the world, and none of the imagined PWA restrictions. And we've yet to see a single amazing PWA there that Apple is purportedly stopping from happening on iOS.
PWAs are a business solution to a business problem. They don't solve any problems for users.
TIL that I’m a web developer living under a rock.
For a while, I've figured that Apple tends to feel like it's got a self-imposed software-engineer shortage, judging from the long lists of bugs that they have. I've heard some people say that it's mostly a talent-allocation issue by management that seems to have other priorities or misplaced priorities or something. However, since Radar/Feedback Assistant acts like /dev/null most of the time, I figure they just need more engineers to actually work through the list of not-absolutely-critical bugs and spend more engineer-hours getting their software right.
Sorry, but some of us have actual lives outside of our jobs. :p
Oh hang on, this article is only talking about the release of some Apple beta. It's not even a release.
Some people have too much time on their hands I guess...
> Fullscreen API fixes
> AVIF and AV1 support
I thought iPhones also support AVIF now?
Safari support is another matter, and runs on its own schedule. I think Safari, in some configurations, supported WebP before macOS did.
Uh… I think I and every other developer has been saying this for many years. The number of developers who hadn’t “seen behind the veil” must be vanishingly small. Follow the Money was so obviously the reason. Don’t update Safari, reap that sweet sweet app money.
Nope. Most developers haven't been saying this. Also, it's bullshit.
I keep saying this: Android is 70% of world's market share. It has none of the "holding back the web" fully enjoying the Chrome monopoly with all its Chrome-only non-standards.
And yet there are literally zero "amazing paradigm shifting world shattering on par with native" PWAs that we hear that Apple is holding back.
Of course there aren’t. Nobody wants to build the same thing twice. Since PWAs are a no go on Safari, which, despite iOS being a minority compared to Android is still used by many of the wealthier coveted audiences, we would have to build it as a PWA for Android and native for iOS. We’ve consistently chosen not to do that. But, with these recent Safari changes, it might be enough for us to finally consider building PWAs.
Indeed
> we would have to build it as a PWA for Android and native for iOS. We’ve consistently chosen not to do that.
Translation: PWAs and their purported advantages are a myth
> But, with these recent Safari changes, it might be enough for us to finally consider building PWAs.
And they will invariably suck.
Edit: It looks like the only "argument" for PWAs is "but on iOS the people have more money". (They also use much more powerful devices than most Androids out there). So the "argument" for PWAs is "we can't even pretend to care about 70% of the addressable market, and even with the purported advantages we can't even begin to think of building these amazing PWAs that would open the doors to people on non-expensive devices etc. because those people have no money and those people dont have powerful phones"
This works with any kind of pre-formatted text (like a "pre" element with the generic monospace font-family) in every browser, as it has, since there have been browsers, but not with Chrome. For Chrome, we have to put epsilon in a span element, make it display as inline-block, assign a width (0.6em), align the character inside this box, just to write a very basic formula! (I call this "training wheels for text".)
Repro:
x = y × ε + c
y = x × 1 + c
⎛ 1 −1 ⎞
⎜ ⎟
⎝ ε 1 ⎠
<span style="display: inline-block; width: 0.6em; text-align: center; overflow: visible; margin: 0; padding: 0; box-sizing: border-box;">ε</span>Exciting times. I hope the pressure on Apple is kept up
He demonstrated an unwillingness to accept that any opinion other than his own had merit in pretty much every part of the web ecosystem I ever had to interact with him in, and took the opinion that any problem anyone had with a proposal he wanted was made up or fundamentally invalid.
No. They just put their users ahead of developers.
And the huge success of the App Store model proves they were correct.
Users can go fuck themselves the day Apple decides to stop supporting hardware they bought but still prevent other vendors to provide alternative, up-to-date browsers on it.
I know, I inherited an iPad 2 that was lying around in a drawer. This machine is way less useful than what it could be because of its ancient Safari version.
This is the second time I read this sentence in this thread, it sounds like a cult.
True, but for many Android devices, you can install a custom ROM when the vendor decided to stop supporting their product. Still not good enough though, those custom ROMs are usually built using outdated drivers anyway, usually eventually blocked on a given Android version because the kernel can't be upgraded, and it is not trivial to install them.
What's more, Apple is a bit better than Android for this, but that's because Android is incredibly bad at it to begin with. Both are pretty bad. The mobile scene is clearly in a bad shape in this respect. We are happy when a mobile device is supported for a few years, but I'm used to being able to run an up-to-date OS on a desktop computer or a laptop for decades, until it dies.
That iPad 2 probably pre-dates Windows 8, and Google went and dropped support for Windows 8 just last month. Plus the OS wouldn't have gotten security updates. Here's a serious question: what good is a web-browsing device that you wouldn't trust to log in to anything on?
> This is the second time I read this sentence in this thread, it sounds like a cult.
It's a fairly popular meme in Apple-developer circles that Apple prioritizes itself first, users second, and developers third. This priority list tends to crop up often when complaining about Apple's developer tools and/or (lack of) documentation. It's something one tends to hear alongside complaints like "I like Swift the language, but the compiler crashes all the frigging time" on the Apple-developer podcasts I listen to.
I use Firefox. Windows 7 was out 2 years before the iPad 2 and the latest Firefox supports it.
> Here's a serious question: what good is a web-browsing device that you wouldn't trust to log in to anything on?
There are still plenty of useful things you can do without logging in. But my counter question would rather be: why don't Apple let people write alternative OSes for its hardware then? You can install an up-to-date Linux distribution on computers from the 90s. The iPad is a popular product, I'm sure there would be enough people interested in building a Linux-based OS for it.
The problem is that perfectly good hardware is just getting disposed of instead. An heresy, from an environmental standpoint.
>> This is the second time I read this sentence in this thread, it sounds like a cult.
> It's a fairly popular meme in Apple-developer circles that Apple prioritizes itself first, users second, and developers third
Okay, thanks for the context, I didn't know that.
Microsoft doesn't even support Windows 7 anymore. I wouldn't recommend anyone use an OS that isn't getting security updates.
> But my counter question would rather be: why don't Apple let people write alternative OSes for its hardware then? You can install an up-to-date Linux distribution on computers from the 90s. The iPad is a popular product, I'm sure there would be enough people interested in building a Linux-based OS for it.
I'm not sure if Apple is lifting a finger to help, but https://asahilinux.org is a thing.
I'm less than convinced Linux people want to bother, in large numbers, to install Linux on devices that were insanely RAM-constrained until only very recently, when Apple started putting M1 and M2 chips in its iPads. For all I know, there are additional patent minefields around implementing Linux drivers for iPads' hardware.
The only other thing that I can think of that would incentivize them to actively block alternate-OS development is security. If someone else can install a backdoor host OS and then stick iOS on top of it before selling the phone to you, that's a way to compromise a Real Computer that usually isn't possible with an iOS device.
> The problem is that perfectly good hardware is just getting disposed of instead. An heresy, from an environmental standpoint.
Apple will _happily_ buy old iPads for a pittance (or $0.00) and reuse the gold and aluminum and whatnot in it. Because of that, I'm not quite as moved by the anti-e-waste arguments that pop up in discussions of rapidly-advancing hardware. That said, an iPad 2, which pre-dates Retina support on iPads, is going to be slow and RAM-constrained, and anyone who decides to support hardware that old ten years later is going to be in for a world of hurt.
As an aside, one of the ways in which Apple actually helps its developers is by dropping iOS/iPadOS/watchOS support for old, slower hardware, basically giving developers license to require newer versions of the operating system and/or newer hardware models for newer versions of their apps. I listen to <https://www.relay.fm/radar>, and the sighs of relief that David Smith, the watch-app guy, breathes when the old slow watch model gets phased out are palpable even at 1.3x speed.
> Microsoft doesn't even support Windows 7 anymore. I wouldn't recommend anyone use an OS that isn't getting security updates.
I mentioned Windows because you mentioned it, but I would not neither. You can install an up-to-date Linux distro on any computer that ran Windows 7 or 8 though.
> I'm not sure if Apple is lifting a finger to help, but https://asahilinux.org is a thing.
I was only speaking about iOS devices. Apple Desktop/Laptops have a better story on this.
> Apple will _happily_ buy old iPads for a pittance (or $0.00) and reuse the gold and aluminum and whatnot in it
Apple's handling of e-waste is not exactly great [1]. Anyway, recycling is way more costly than just being able to use hardware that exists.
[1] https://www.vice.com/en/article/yp73jw/apple-recycling-iphon...
> Apple released its Environmental Responsibility Report Wednesday, an annual grandstanding effort that the company uses to position itself as a progressive, environmentally friendly company. Behind the scenes, though, the company undermines attempts to prolong the lifespan of its products.
[...]
> Apple rejects current industry best practices by forcing the recyclers it works with to shred iPhones and MacBooks so they cannot be repaired or reused—instead, they are turned into tiny shards of metal and glass.
> As an aside, one of the ways in which Apple actually helps its developers is by dropping iOS/iPadOS/watchOS support for old, slower hardware, basically giving developers license to require newer versions of the operating system and/or newer hardware models
But that's not a good thing! Saying this as a dev, we ought to spend effort not to turn working hardware into waste because it's more convenient.
Please show me a single device from 2011 that "other vendors" aka Google or even Mozilla support [1].
Not saying it's a good thing, but spite and hatred shouldn't replace facts.
[1] Probably apart from desktop. And even there: windows 8 was released in 2012. Chrome droped support for it in 2022, Mozilla will drop support for it this year.
The iPad 2 is blocked on Safari 9, which was released in 2015, only 4 years later.
The Samsung Galaxy S II was released in 2011 too [0]. It was running Android 2.3.3, but could be upgraded to Android 4.1.2. The latest Firefox version to support this version of Android, Firefox 68.11.0, was released July 27, 2020, 9 years later. The web is way more usable today on a 2020 browser than on a 2015 browser. And in 2020, the browser was current on this device!
But the story does not end there. Today, you can install Lineage 18.1 / Android 11 on this device [1]. To be fair, many things don't work on this port, but there's an official Lineage 14.1 / Android 7 Lineage ROM [2] for this device, last built on 2018, 7 years later, on which current versions of Firefox mobile work, because Firefox supports Android 5 and later [3]. And since it is an official Lineage release, you'd expect the device to work correctly on it.
You can have a current browser on this 12 years old device. This is possible because most Android devices are not completely locked out from custom OS development.
> Probably apart from desktop
But that's my point actually. To be fair, the Galaxy sII is an incredibly lucky device compared to most Android devices (however, iPhones and iPads are also usually compared to the Samsung Galaxy ones). And don't be mistaken, I also strongly dislike Android. A computer bought from 2012 can be upgraded to an up-to-date Linux distribution without any issue. There's nothing fundamental to mobile devices that should prevent this.
[0] https://fr.wikipedia.org/wiki/Samsung_Galaxy_S_II
[1] https://www.xda-developers.com/samsung-galaxy-s-ii-unofficia...
[2] https://lineageosroms.com/i9100/
[3] https://en.wikipedia.org/wiki/Firefox_for_Android#Platforms
> The latest Firefox version to support this version of Android, Firefox 68.11.0, was released July 27, 2020, 9 years later.
Android 4.1.2 was released in 2012, a year later.
The latest version of iOS for iPad 2 was 9.3.6 released in 2019, 8 years later.
Apple's support for its mobile and portable hardware far exceeds any other manufacturer.
And though I agree that it's a sad state if affairs, but very very very few people will have the knowledge and the skills to install unofficial unsupported versions of whatever on their phones and tablets.
It does not mean there were no security patches after this though. But let's say you have a point here, security support on Android is usually a complete joke.
> The latest version of iOS for iPad 2 was 9.3.6 released in 2019, 8 years later.
Okay, but that's not the complete story. The previous version, 9.3.5, was released in 2016. It seems 9.3.6 only contains a GPS related fix. It's good they provided this fix (I guess it makes the iPad 2 way more useful, as a GPS device) but it's nothing substantial. Still stuck on a late 2015 browser with some fixes in 2016 when the Galaxy S II could run a up to date browser in 2020
So...
> Apple's support for its mobile and portable hardware far exceeds any other manufacturer.
Yes and no. I agree that they provide support for far longer than any other manufacturer. But after this, you are dead stuck. I'd rather have an Android device supported by the manufacturer for 3 years (Android One) and be able to install and use up to date apps and browsers on it for years after this, and be able to install a Lineage OS on it. The support won't come from the manufacturer and this is a shame, but at least you have reasonable support for years on many device thanks to Lineage.
> very very very few people will have the knowledge and the skills to install unofficial unsupported versions of whatever on their phones and tablets.
Indeed. Though they can still find help from a knowledgeable friend. I suspend most people don't though.
That said, I'm done with Android too, because of this "sad state of affairs" you mention. I am lucky to never have got people used to me having the usual messaging suspects that require an Android or an iOS device so I can get away with avoiding them altogether.
And Apple ahead of both, of course.
I can't.
He has an intense irrational hatred towards Apple. But during all the years of him working at Google he never ever accepted any criticism towards Chrome and Google. The moment he went to work for Edge, he wrote a piece that leveled some criticism at Chrome but then kept on bashing Apple, and only Apple.
Imagine writing "Apple gutted Mozilla's chances" (https://infrequently.org/2022/06/apple-is-not-defending-brow... when it's well known that Google was first and foremost who gutted them (https://threadreaderapp.com/thread/1116871231792455686.html)
And so on and so forth.
He's vitriolic and spiteful, but sadly well-known and moderately influential.
Developers want a better browser on iOS, I agree. But do they also want to support multiple different browsers on iOS, each one with its own shortcomings and quirks?