Apple simultaneously doesn't want to become a thin client to the browser, yet they also see 3D/GPU/AI as the future and want to be at the forefront. They don't want to cede local compute to cloud and edge services.
I agree. They know their time is coming with being forced to allow other browser engines, and are actually putting in an effort now that there’s competition on the horizon.
It's mostly free from the OS release cycle now: They have been shipping major web platform features in Safari versions that ship with their minor OS updates. (e.g. macOS 14.2, iOS 17.1) so every ~3 months, which is a nice cadence.
The major OS release cadence only seems to affect major UI revamps which aren't that frequent anyway, so it's not that much of a limitation.
You can now also update Safari independently of macOS, which is nice for IT environments that restrict major macOS updates until they have been approved.
Hopefully in the future they will also allow that for iOS, so that older devices that can't update have some more longevity for web apps (and so that we as web developers don't need to support as many older versions)
Apple has released os updates that have specifically targeted Safari issues. Usually point z releases as needed like big bugs and security fixes. Still not as ideal but it’s better than before.
Mind you the version string in Safari might not change as well. Gotta look at the build number.
They’ve been hiring celebrity developer advocates too like Jen Simmons and recently Nichole Sullivan. But it has improved so much in the past few years too.
This is sort of my sense. It feels to me more like it’s just more people knowing about/noticing it.
As a Safari user since release day I never felt like they slowed development or that they have accelerated it lately.
But people are certainly more aware. Maybe it’s more of an “it’s all coming together” for a number of longer term things just hitting around the same time?
WebKit is already better than Blink for many cutting edge features, it is just that Apple and Google have different priorities in terms of what cutting-edge means.
They probably see the writing on the wall for their current restrictions on third-party browser engines, and are as interested in avoiding a Blink monoculture as the rest of us.
I was thinking the same when I saw the release notes of the latest Safari stable version but wasn't sure if it was just me paying more attention than usual... :)
I'm curious why Apple is now putting effort behind the web when it competes with their app store distribution. Don't get me wrong, I'm excited they are. I can imagine a bright future for consumers where games with native-level graphics are distributed via the web.
Safari has been improving at rapid pace for a while now. They were the first to get ES6 support (and the only to implement tail calls), they’re usually the first with CSS features
It’s rare to see that but almost every time I have looked it’s been because the developer did something which used a Chrome API instead of a web standard. I’ve found it best to develop in Firefox and Safari, because Chrome almost always works the first time you test it and you don’t accidentally introduce a dependency on something which is still being standardized.
Honestly, this hasn’t always been my experience: multiple times I’ve targeted Firefox for doing something mildly out of the normal but absolutely within spec and supported across the board for years, and then tried it in Chromium and found debilitating bugs, to the point where once in a case of CSS blending I just had to give up on the entire concept, or else the page would just stop rendering after 8192px.
I’ve never actually developed against Chromium, and my position as a staunch Firefox user (and a Nightly user at that, for at least eleven of the last thirteen years) may be negatively affecting my judgement in this, but although what you say may be true from a features perspective, I don’t find that at all difficult to manage, and from a bugs perspective my impression is that Chromium has historically tended to be much buggier: that Firefox shipped better quality, later, while Chromium shipped lower quality, earlier. Though I do get the sense that this is less true than it used to be, and that Chromium is generally of higher quality for features of a certain age now than five years ago. And I reiterate, this is about the vibes I’ve got, as a Firefox user. I’ve tended to have to file more interesting or problematic bugs against Chromium than against Firefox.
I’m not definitely not saying any browser is perfect - I’ve filed many bugs against all of the major browsers - but I think Chrome took over from IE in the category of browsers which a certain type of developer uses as the only browser and decides that if it works for them it’s ready to ship. I’m not sure I’ve ever had someone rant in the inverse case saying that if code works in, say, Safari but not Chrome it must mean that Chrome is a terrible browser and shouldn’t be used. That default mentality is toxic for the web but not uncommon.
"Reload Without Content Blockers" and "Reload Reducing Other Privacy Protections" might be what you need. It might be Safari's anti-tracking/cookie features that might be at fault or it might be that you have a content blocker that's causing an issue. If you're using iCloud Private Relay, it's possible that sites are filtering those IP addresses or there's a DNS issue and you can use "Reload and Show IP Address" to check that. For example, iCloud Private Relay often uses Cloudflare's DNS. archive.is doesn't work with Cloudflare's DNS (because Cloudflare won't leak your location to their DNS servers and so archive.is returns bad results to them).
I've had various different issues with Safari as a developer for the last few years (also frequently paired with SVGs for some reason). In the absence of IE, Safari has the perfect combination of decent market share and bugs that for my company we get a lot more Safari specific reported issues than any other browser.
It's usually smaller things like SVGs not working with CSS animations, or SVG filters causing weird edge case issues, but I'd really expect any major browser to fully support something like SVG and it's a little disappointing to find that the browser is the issue.
Not to defend Safari in this case, just to give perspective: SVGs are the forgotten unloved child that very few people building browsers care about. And that's unfortunate.
I have reports that this sandbox is failing intermittently only in Safari. I don't have a Safari machine to test with. Reports say that the content pane on the right is empty. By default, there should be a clickable button in it, which is the sandbox output.
Reports say there is some iframe load failure showing in the network monitor. Every file being loaded is a normal static file served from a CDN. Also, sometimes, when it fails there's a rare chance that a reload will make it work?
Because web developers aren’t adequately testing other browsers? Each browser has its own additional APIs and implementation specifics. Chrome in specific has tons of non standard additions.
I wouldn't say they're the first to get most CSS features. Usually just things that are more visual, like color spaces and theming. They still drag their feet on a lot of features, but they are getting better.
I expect webstores to be less relevant in 5 years from now. PWA are getting more on pair with their native sisters. Banking apps, social media etc . There is no real reason to have a native app. Only graphic demanding apps will have a slightly longer life.
But the end is near for Kotlin and Swift apps. I cannot be more happy.
Native apps are restricted for backend tasks as well. Only on very rare exception native apps are allowed to run processes in the background. Now you have service workers in PWA land. They can wake up apps for i.e push notications. So all in all there is not a difference. Location changes are available in web for a long time. Just like camera and other sensor data.
So if that’s true, why are app developers still releasing Android apps instead of just letting them use the web version?
And I haven’t heard anyone say “you know I have a really great experience with web apps. I wish all of my apps were web apps on mobile and Electron on my computer”
I'm wondering about the same. Vast majority of "apps" would work just as well, or better, as a website. In fact a lot of them do, e.g. this very site.
I think a part of it is an "app craze", i.e. organizations want "apps" just because "an app" is something fancier and totally different than "just a website". I have done an "app" like this (implemented as an optionally installable website).
Also many people, including many developers, also vastly underestimate what can be done with contemporary browsers, so they assume that "a native app" is needed if you e.g. want to take a picture or read a file.
Because PWAs on mobile remain kind of underwhelming still. Native APIs are missing, navigation stacks are not there and performance is still quite bad even on higher end phones, although the last one is probably implementation specific. There are also only two platforms so the insensitive for businesses aren’t as strong.
I’m not sure if I’ll be happy about a future where everything is a PWA.
My main concern is monetization.
With a PWA the traditional monetization method of selling apps doesn’t work. So, your options will be a subscription or ads.
But, a subscription is too much hustle for small utilities and casual games. And I love apps like Procreate that are paid, without subscription and ad-free.
With an app store, you're dependent on the app store still supporting the app. They can withdraw the app from the store whenever they feel like it, and then what?
How do you implement that unlock feature without backend support?
I can imagine some encrypted payload the user unlocks or a backend service that keeps track of valid license keys.
Everything is doable, and I recognize that my comment of “doesn’t work” was exaggerated.
But I don’t think small apps will do all that work when it is easier to monetize with ads. A more likely scenario for ad-free utilities will be having umbrella subscriptions a la Netflix (like Apple Arcade).
I’m a web dev, too, and I read many enthusiastic articles about PWAs as the future. (Mostly from Google evangelism, for a good business reason). But, the “old school” guy in me that grown-up loading games in diskettes feels that something is lost and more invasive in that future. (I’m not comparing it with the current App Store experience but with the experience of macOS/Windows/Linux, where you can still manually install app binaries).
We're basically there already unfortunately, even for store-distributed software. Apps like Procreate and Pixelmator are a rarity these days.
It definitely doesn't help that the App Store makes charging for new major versions awkward, and that upgrade discounts are basically impossible, but I suspect the main reason is that most developers just make more money from subs than purchases.
As a consumer though, it sucks. Subscriptions are fine if your product has an ongoing cost to you as the developer, for example server or API fees. And I really don't mind JetBrains-style subs, where you can cancel any time and you retain access to the last version you paid for, for as long as it still works on your machine. But, while I appreciate the need for ongoing revenue to continue paying salaries, I am not interested in renting software in perpetuity—that's not a fair deal. Especially when it robs me of the ability to stick with an older version if I prefer it.
The reason why banking apps are native, not web, is to collect rich fingerprinting for fraud detection and prevention... not for any specific "rich UI" experience, etc.
Both can be true. People hate fingerprinting when it tracks you across sites without your consent. If a service is doing it for your benefit with your express consent, then what’s the problem?
> PWA are getting more on pair with their native sisters.
Not really, no
> There is no real reason to have a native app.
Except, you know, for all the reasons where anything web-based sucks: resources needed to run, fast reaction times, performant animations, rich complex controls etc.
The web, unfortunately, made everyone accept the most limited and under-developed version of what things could be.
I would argue that the css render engine is more performant than its native counterparts. Css animations are very rich. Much more so than android or ios sdks provide
But you have to apply them to DOM. Where every single little thing results in a re-layout and repaint. There are reasons why you still can't animate height: auto.
The built-in controls also don't help. Can't find it now, but details set display:none or visibility:none on closed contents, and that can't be animated.
I wouldn't say never. I mean, you might be right, but between GPU support and WebAssembly, there is a lot of potential for web-based apps to become more popular than native apps in the future. It's all going to come down to the developer and user experiences of each.
Possibly because it's looking likely that they'll be forced to allow other browsers on iOS at some point and they don't want everyone to switch to Chrome?
Apple tends to put effort behind web APIs long after others do. WebGL, progressive web apps, etc etc… they put the effort in when it’s starting to become a competitive disadvantage not to.
WebGPU feels like an outlier in that respect but then it is intended as a “better” WebGL so it makes sense that if you already have WebGL you might as well have WebGPU. It’s a lot closer to Apple’s Metal API than WebGL is so they have an interest in people switching.
The EU's DMA law is going to force them to finally start competing with other browser engines on iOS, at least in Europe. When that became clear they started investing more in WebKit. It's been a few years now.
I switched from Chrome to Safari on my Mac about 7 years ago. At the time Apple was promoting performance and power efficiency. I’ve been very happy. Sometimes I do run into css stuff that is missing, and PWA is still not great. Latest PWA screw up is that the app won’t switch to dark mode except if you force quit the app, and then it gets stuck on dark mode. This worked perfectly prior to iOS 17.
My point is that Apple is competing with other browser implementations on MacOS, yet I’ve very rarely used anything other than Safari. Most exceptions have actually been because I need a plugin to debug the JS framework I’m using.
They're competing a lot less than they could be by nature of being the default browser, and also by not allowing non-webkit based browsers on the iOS apple store. I think without those very few people would be opting in to Safari.
I read that both Google and Mozilla are developing non webkit iOS browsers in anticipation of some regulatory changes, and also that Apple has been staffing up the webkit/Safari team in response.
Lack of real Firefox is the actual blocker for me using an iPhone. But at the same time, I'm glad ios only allow safari and I hope the EU don't change this. I think the consequences would be bad if chrome works on every platform and suddenly there's no cross browser support for a lot of apps.
You are not a representative sample. According to [1] Safari has 28% market share on MacOS. [Edit: This site was wrong, the real number is 37%, see below for a link]
If WebKit's market share on iOS were to drop this low, web developers would likely test for WebKit a lot less, and tolerate WebKit's missing features a lot less, and Apple would soon face much worse web compatibility problems on both platforms. To prevent that they saw that they needed to seriously step up their investment in WebKit, and from what I've observed it seems like they did. Though perhaps not yet to the level they really need. Old habits die hard.
Of course they could just do what Microsoft did and give up. I'm glad they haven't.
[1] [Edit: this site was wrong, see below for better numbers]
Cloudflare puts Safari at a bit under 40% for MacOS, so it looks like I’m very much n=1 and not particularly representative. Marketshare for Safari on MacOS is close to 85%, so I can definitely see that changing if users could install real alternate browsers.
One could say the same for Google's browser investments as well. At this point, if Chrome and Safari don't implement something, it basically doesn't exist as a web technology. The only other engine is Firefox sitting at 3% of usage.
In Apple's case, I think there's some utility behind their drive for WebGPU: it's basically Apple's Metal graphics API. If WebGPU takes off, it'll mean a lot of developers getting familiar with something very similar to Apple's Metal API. Apple seems to be pursuing a long-term strategy of bringing more games to their platform. From the Game Porting Toolkit to ray tracing in their processors to Apple Vision to simply giving gaming a lot more attention in their keynotes.
And Apple might be well positioned to capitalize on gaming. A $130 Apple TV has a lot more CPU and graphics power than a Nintendo Switch. The same applies to the iPhones people are carrying around. It might not compete with giant consoles from Microsoft and Sony, but Apple has been showing that it can offer impressive gaming performance.
Fast forward to 2026: does a next-gen Apple TV have hardware ray tracing? Apple put a 2021 A15 processor in the 2022 Apple TV. It seems reasonable that they could put something better than a 2023 A17 Pro in a 2026 Apple TV (a 3 year old processor at that point). Sure, Microsoft and Sony will have next-gen consoles, but at what point are graphics facing diminishing returns? Nintendo has the most popular console even though it's older and was low-powered to begin with. For PC games, one must assume that some people are running graphics cards that are older.
I'm not saying this will happen. Companies can be fickle. However, Apple has show a reasonably consistent (if slow) move toward games over the past year or two. They're making the investments now and WebGPU's Metal-like API could be part of that strategy.
Heck, maybe WebGPU is even a strategy to avoid lawsuits from companies like Epic and anti-trust action from regulators. If you don't like the App Store rules, just use WebGPU. If games with native-level graphics can be distributed via the web, then there isn't nearly as much for regulators to go after the App Store.
This take doesn’t survive scrutiny. The real money from the App Store comes from play to win games. The reason those make so much money is because of the direct link to in app purchases and “whales” spending money on meaningless coins and loot boxes.
This came out in the Epic Trial. Those people are much less likely to put a credit card on any random site.
Candy Crush games could already be done on the web on mobile - it wouldn’t be nearly as monetizable
I would imagine Apple Pay is used significantly less than iTunes/App Store billing.
Apple Pay is only in certain counties, with supported banks/cards. iTunes/App Store supports a plethora of payment options across the world, as well as Apple Pay.
Indeed, you could totally make the argument based on the store revenues that both the play store and the appstore are just in reality some type of casino/gambling industry middleman.
Both companies are working very hard to remove this image though for obvious political reasons.
It could also be strategic. A more capable web browser along with better PWA support, could be an offering to the EU to settle app store monopoly issues. Apple could say they have made it so easy to install quality apps from the web there is no need to mandate alternative stores.
On this same point, if they don't keep up with PWA support, they risk getting left behind by application developers. So, they have multiple incentives to invest in Safari.
> they risk getting left behind by application developers
There is literally, for now, zero risk of that. companies will have devs meet the customers where they are at. Of the largest mobile market share platform in the USA doesn’t support PWA or only supports it without features the company requires, said company will build an iOS app. As has been the case.
> if they don't keep up with PWA support, they risk getting left behind by application developers.
Application developers will not go anywhere, for many reasons:
- iOS is where the money's at
- PWAs are not "apps". They are web apps with all the limitations it implies. You want complex functionality, rich controls, fluid animations and a billion other things? You go for native apps.
Safari's always been pretty secretly good - they just got a bad rep for not supporting PWA-related technologies for a while. Because Apple uses Webkit to render a bunch of their "native" UIs, they're often first to adopt native-like interactions or css features (or proposed them themselves), like backdrop-filter or CSS Scroll Snap. Because the web can have a pretty big impact on battery life on phones and laptops, they've also always had a pretty fast and energy efficient js engine.
I'm really doubtful Apple sees Safari as competition for their app store distribution. I don't think that matches reality of how most consumers use mobile devices and spend money.
I don’t think they see Safari as competing with the App Store. Even with the recent PWA additions it doesn’t seem to matter.
At this point I’d say Safari is 100% a hedge against being fully dependent on Google/Chrome. It started to not be dependent on MS/IE and improve what MS didn’t care a ton about.
Apple HATES being fully dependent on others for very important stuff. They’ve been burned too many times.
Safari is great. I love it. But there’s no way it is ever going away even if they are forced to preload 18 different app stores and 4 browsers on every phone by the different governments of the world.
The web is getting more powerful and eventually will negate the need for native apps as the performance will be comparable or greater. I'd view moves like this to be preemptive efforts to remain competitive in the future.
On the webGL/GPU side, my cynical speculation is that the Apple has slowly been amassing a nest of graphics talent for the last 5 years (Metal, Vision Pro, ARKit, list goes on), and at this point they can't resist the pressure from employees to not support some of this stuff which should be table stakes and is obviously good for the user experience.
On the PWA side, best guess is anti-competition scrutiny.
WebGPU doesn't have much in common with Apple's original proposal (which was more or less a Javascript API around Metal). I suspect the new implementation is a complete rewrite from the original proposal, since earlier versions of Safari contained an implementation of the Apple proposal, which was then removed for a very long time while work happened on WebGPU.
While that is true, it also true that Apple had a major influence on the current design and is e.g. the reason why we got WGSL [0] as a source language instead of a bytecode (a GPU WASM equivalent if you will).
People keep spreading this incredibly misleading statement - god knows I do not like Apple's closed-source behavior, but at this point people are basically just spreading lies about the situation
By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them, due to ongoing legal issues between Apple and Khronos.
Apple actually proposed WebHLSL in collaboration with Microsoft, to have HLSL be the standard.
Mozilla employee's stance[0] was that SPIRV was too low level, did not fit with the goals of WebGPU portability and security, and expressed concern that Khronos may add functionality to SPIRV they cannot support in WebGPU like raytracing instructions .. 'So we'd always be on the verge of forking SPIR-V in some way.'
It was also noted by many people that even if a bytecode format was used, it would still have to be translated to the target (HLSL/DXIL, MSL, etc.) in almost the same way a text format would.
Nobody proposed a 'GPU WASM equivalent' or an alternative bytecode format, only SPIRV was ever considered AFAIK.
The hard truth is that shader compilation is a fucking nightmare, people do not realize how bad it is across the different native APIs. SPIR-V is good, but it doesn't solve that - and presents other challenges if you are a web browser API. Vulkan and SPIRV are not the golden goose many make them out to be.
I might have expressed myself in an ambiguous and extravagated way, just to be clear, I was not complaining about WGSL. I actually do like it a little better than GLSL and HLSL, though it still leads to more standards / fragmentation.
And exactly, Apple did not want SPIR-V (a bytecode) and proposed WebHLSL (a textual source language) instead. So, I think my statement that Apple preferred a textual format over a bytecode is correct. They could have proposed another bytecode format, but as you noted, nobody did.
It does not really matter anyway, because the GPU hardware and software paradigms are still undergoing rapid change. And there are a whole lot of under-specified things like memory models, scheduling order, control flow uniformity etc. which I expect will take another iteration of standards to be established.
What you linked was a "devil's advocate" position from kvark, not his balanced personal opinion. At this point the decision against SPIR-V was already made and he was not trying to get anyone to change their minds back.
> By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them
This is false. Apple's other stance, very strongly stated, was that no binary IR of any kind was acceptable, full stop. Lichtso's original comment is right. Apple explicitly rejected "GPU WASM equivalent or an alternative bytecode format", not just SPIR-V. They would only accept a textual programming language.
Now Apple didn't mandate WGSL, but clearly they wouldn't have accepted GLSL either for their unfortunate legal reasons so that pretty much leaves WHLSL or "new language" as the only options. I don't know why WHLSL ultimately lost. I remember hearing arguments that HLSL as a language was essentially implementation defined rather than rigorously standardized, making it hard to realize any benefit of code portability or reuse from existing codebases.
What he wrote was not just a devils advocate position. I encourage everyone to read it in full. Also his 'Horrors of SPIR-V' article a year later[0] which has this conclusion:
> I had a chance to work with SPIR-V rather intimately, and I’m becoming convinced that most of the defenders of this format (who like to criticize WGSL in turn) have little experience actually doing anything with it [...] I was one of them. SPIR-V is probably a good format for what it was made for: driver compilers. It’s not as good for the intermediate portable representations of your shaders.
Clearly neither of those two things directly contradict my claim that Apple refused binary formats. It's weird that you would even say that. My source is I was in the meetings where Apple refused binary IR. Man, you're going to make me look up the meeting notes, aren't you?
OK, I found what I believe are the most relevant meeting notes [1]. Unfortunately the meeting notes are not a straight transcript and not everything that was said is in there verbatim. There were also side discussions not captured at all. The meeting notes say "Apple would strongly prefer a text-based language to a binary one". This is really an understatement of their position on the matter, and the notes don't capture the most contentious arguments well. But you can at least see in the notes that Apple was arguing strenuously against binary formats generically, even more so than SPIR-V itself in this meeting, going as far as arguing that a hypothetical SPIR-V assembly in text format would be better than SPIR-V in binary form.
Epiphany is nice. Especially because it features a native toolkit with Gtk4. What few developers do is incredible :)
Main issues:
* Since introduction of sandboxing the memory-usage is far too high. It was pretty low before.
* WebRTC. They had it nearly implemented years ago. Then removed it because they were unhappy with it. But their new approach isn’t available until now.
* Many more developers needed. This means me?
* Epiphany releases are linked to GNOME releases. Only applications which are integrated parts of GNOME should do that. The rigid six months release cycle is problematic.
Regarding memory usage. Sandboxing depends on multi-process. The multi-process shouldn’t be an issue. The sandboxing was added in late 2019 and - if I remember correctly - Epiphany started to eat memory. Like probably most people I keep my tabs when closing/opening the Web-browser. The developers are nice and explained, that for all previous existing tabs a separate sandbox process and a render-process is already started with a blank page. And due to need separation no process is allowed to share memory with others. What is needed is only showing a label on the tab until the tab is actually used.
And. Midori?
There was previously also Midori using WebKitGtk. I liked it and it was pretty nice. But something awkward happened and an unrelated people took over the name and started to ship Electron (i.e. Google Chrome) as “Midori”. It looks untrustworthy to me, I recommend to not install it.
If you use Midori on Archlinux you should be save - they ship and old and original version of Midori. But it is old.
Apple, WebKit and WebKitGtk work together for many years. Good work.
It'll be very nice if Apple also releases a standalone WebGPU.framework (or just expose the APIs in WebKit.framework) so we can finally have a true cross-platform OpenGL successor for native development.
Can't you have that today by using Dawn (used by Chrome) or wgpu (used by Firefox) as a dependency? That said, a third implementation would be nice, too!
A third implementation and also having a WebGPU.framework built-in and shipped with the OS (like all other first party frameworks) would simplify the build and debug process.
Dawn & wgpu projects are great but having native WGSL support with-in Xcode would be pretty nice. They already have the whole spec implemented anyways, why not as a standalone framework?
If it was a system vended framework you wouldn’t be beholden to whether it’s installed or not. It would just be available from a given OS version onwards.
That means easier builds for the developer, smaller apps, receiving implicit upgrades in lockstep with the OS. Take the example of new metal versions enabling new optimization avenues. Bundling your own dependency would mean that you need to keep on top of the changes to take advantage of it , but with a system framework you’d get it whenever Apple’s engineers enable it.
Give it at least few major iOS updates before it is usable.
It is almost a rule with webkit new features.
Those new APIs almost work, but you need to use user-agent detection to make sure it really works and it does not fail randomly/silently when it is in home screen or some other iOS browser.
User agent detection is never a good idea, perhaps just checking if the api is available and if a device can be obtained (see samples on the WebKit website) is enough (and reliable).
As with all STP releases, this is the time to report issues before the feature makes it into the next version of Safari.
To enable WebGPU, turn on the “WebGPU”, “GPU Process: DOM Rendering” and “GPU Process: Canvas Rendering” feature flags in the Feature Flags tab in Safari Preferences. If you don’t see the Feature Flags tab, you need to first check “Show features for web developers” in the Advanced tab.
I am torn about WebGPU - on the one hand it is a necessary improvement, but it does radically increase the attack surface area in ways that just a few years ago would have been complained about by the browser security teams. (The spectre countermeasures around high resolution timing can still bite you).
This makes me suspicious that something has changed to push the balance here, and it must be something to do with trying to offload the execution of LLMs and related neural networks on to clients to reduce the cost of doing it server side.
I currently have mistral 7b running on my phone through the MLCChat app. The performance isn’t too bad for something running on phone hardware. I’d consider that decent, if not world beating.
I think browsers should require sites to request access to WebGPU like they do location and camera.
If a random webpage is asking to use my GPU (especially if it's a sketchy-looking site I just got redirected to), that would raise flags and I'd deny access. If a game or visualization requests access, especially if it's something I've heard others praise, I'd take the risk.
Sure, someone could embed a vulnerability in some decent app which uses the GPU for actual rendering, but it's a lot harder.
> it does radically increase the attack surface area
I've seen this argument being made quite often. However, I have yet to any evidence given. Can you provide concrete examples of how WebGPU is less secure than WebGL or other web APIs?
I did, actually, before posting here. It couldn't tell me anything except a vague "it's a broader and more low-level API so it has a wider attack surface". Except in about 2000 words.
By the way, it was tiresome when people told me to go Google answers. It's just as tiresome when people tell me to go ask an AI. I'm here to talk with real people, not computers.
Besides, HN is a place where there's often an expert who will know far more than what's widely available on the web about even the most obscure of technical knowledge.
> but it does radically increase the attack surface area in ways that just a few years ago would have been complained about by the browser security teams.
Source? "GPUs feel low-level like C and C is unsafe" is a vibes argument.
> (The spectre countermeasures around high resolution timing can still bite you).
The fact this is a problem at the highest of levels provides further damning evidence that this isn't a large change to the status quo.
I think the story was that Apple refused to ship/implement Vulkan drivers for their computers, and everyone was scared of this happening again with WebGPU, so Apple got their way with the design of WebGPU.
I think everyone is in agreement that the Metal API is pretty nice and there was little objection to making the WebGPU API similar (unless portability concerns dictated otherwise). The main disagreement was over shaders.
Yes, really. There were other reservations about shader compilation in particular from other participants, Apple wasn't alone in that department (e.g. asset sizes and needing to fork the format to maintain compatibility guarantees). They did demand a non-binary format, which sealed the deal on no SPIR-V. But it was not as simple as "SPIR-V/Vulkan was perfect and what everyone except Apple wanted." The shading language by far had the most discussion and iterations; none of the participants in contrast had nearly as many reservations about the structure of the API.
It would be weird if everyone wanted the same thing, Vulkan or otherwise, but it seems quite clear that where Apple wanted something and some others did not, Apple got its way more often than not.
I remember Safari had a flag for WebGPU a year or two ago. I even tried some samples and it seemed to work. Does anyone know why they removed it in the middle?
IIRC Safari had the flag too that time, not just the Technical Preview.
That was not the current WebGPU. It was essentially a different API proposed by Apple at the start of the standardization process. The final standard has little in common.
It seems most comments are mostly interested in some sort of LLM or Gaming on the web. I am more interested in how it will shape Desktop applications that is currently on electrons. And in many ways ( the web ) we are reinventing what Java was doing 15 years earlier.
hows the experience of writing webgpu code? Last I checked some tutorials out, you still had to write the code inside a string without syntax highlighting. Has this changed?
If you're talking about the shading language WGSL, yes if you inline it in your code you won't have syntax highlighting (unless your editor happens to support that usage). Depending on your code infrastructure you can have it in separate files though with syntax highlighting. It's just a string you pass to an API, after all.
It's not really anything to do with WebGPU in particular.
170 comments
[ 3.4 ms ] story [ 205 ms ] threadIt’s slowly becoming closer to chromium in cutting edge feature support.
This is shaping up to be a fun battle ahead.
The major OS release cadence only seems to affect major UI revamps which aren't that frequent anyway, so it's not that much of a limitation.
You can now also update Safari independently of macOS, which is nice for IT environments that restrict major macOS updates until they have been approved.
Hopefully in the future they will also allow that for iOS, so that older devices that can't update have some more longevity for web apps (and so that we as web developers don't need to support as many older versions)
Mind you the version string in Safari might not change as well. Gotta look at the build number.
As a Safari user since release day I never felt like they slowed development or that they have accelerated it lately.
But people are certainly more aware. Maybe it’s more of an “it’s all coming together” for a number of longer term things just hitting around the same time?
I’ve never actually developed against Chromium, and my position as a staunch Firefox user (and a Nightly user at that, for at least eleven of the last thirteen years) may be negatively affecting my judgement in this, but although what you say may be true from a features perspective, I don’t find that at all difficult to manage, and from a bugs perspective my impression is that Chromium has historically tended to be much buggier: that Firefox shipped better quality, later, while Chromium shipped lower quality, earlier. Though I do get the sense that this is less true than it used to be, and that Chromium is generally of higher quality for features of a certain age now than five years ago. And I reiterate, this is about the vibes I’ve got, as a Firefox user. I’ve tended to have to file more interesting or problematic bugs against Chromium than against Firefox.
https://i.imgur.com/lMHkiH8.jpg
"Reload Without Content Blockers" and "Reload Reducing Other Privacy Protections" might be what you need. It might be Safari's anti-tracking/cookie features that might be at fault or it might be that you have a content blocker that's causing an issue. If you're using iCloud Private Relay, it's possible that sites are filtering those IP addresses or there's a DNS issue and you can use "Reload and Show IP Address" to check that. For example, iCloud Private Relay often uses Cloudflare's DNS. archive.is doesn't work with Cloudflare's DNS (because Cloudflare won't leak your location to their DNS servers and so archive.is returns bad results to them).
It's usually smaller things like SVGs not working with CSS animations, or SVG filters causing weird edge case issues, but I'd really expect any major browser to fully support something like SVG and it's a little disappointing to find that the browser is the issue.
See this post for historical context: https://codepen.io/AmeliaBR/post/me-and-svg
https://mutraction.dev/sandbox/?view=normal
Reports say there is some iframe load failure showing in the network monitor. Every file being loaded is a normal static file served from a CDN. Also, sometimes, when it fails there's a rare chance that a reload will make it work?
Like can PWAs run in background or respond to location changes, etc
And I haven’t heard anyone say “you know I have a really great experience with web apps. I wish all of my apps were web apps on mobile and Electron on my computer”
I think a part of it is an "app craze", i.e. organizations want "apps" just because "an app" is something fancier and totally different than "just a website". I have done an "app" like this (implemented as an optionally installable website).
Also many people, including many developers, also vastly underestimate what can be done with contemporary browsers, so they assume that "a native app" is needed if you e.g. want to take a picture or read a file.
My main concern is monetization.
With a PWA the traditional monetization method of selling apps doesn’t work. So, your options will be a subscription or ads.
But, a subscription is too much hustle for small utilities and casual games. And I love apps like Procreate that are paid, without subscription and ad-free.
How so? Offer to install the pwa and unlock functionality only after the user has paid. How is that different from a paid "app"?
Everything is doable, and I recognize that my comment of “doesn’t work” was exaggerated.
But I don’t think small apps will do all that work when it is easier to monetize with ads. A more likely scenario for ad-free utilities will be having umbrella subscriptions a la Netflix (like Apple Arcade).
I’m a web dev, too, and I read many enthusiastic articles about PWAs as the future. (Mostly from Google evangelism, for a good business reason). But, the “old school” guy in me that grown-up loading games in diskettes feels that something is lost and more invasive in that future. (I’m not comparing it with the current App Store experience but with the experience of macOS/Windows/Linux, where you can still manually install app binaries).
We're basically there already unfortunately, even for store-distributed software. Apps like Procreate and Pixelmator are a rarity these days.
It definitely doesn't help that the App Store makes charging for new major versions awkward, and that upgrade discounts are basically impossible, but I suspect the main reason is that most developers just make more money from subs than purchases.
As a consumer though, it sucks. Subscriptions are fine if your product has an ongoing cost to you as the developer, for example server or API fees. And I really don't mind JetBrains-style subs, where you can cancel any time and you retain access to the last version you paid for, for as long as it still works on your machine. But, while I appreciate the need for ongoing revenue to continue paying salaries, I am not interested in renting software in perpetuity—that's not a fair deal. Especially when it robs me of the ability to stick with an older version if I prefer it.
Not really, no
> There is no real reason to have a native app.
Except, you know, for all the reasons where anything web-based sucks: resources needed to run, fast reaction times, performant animations, rich complex controls etc.
The web, unfortunately, made everyone accept the most limited and under-developed version of what things could be.
But you have to apply them to DOM. Where every single little thing results in a re-layout and repaint. There are reasons why you still can't animate height: auto.
The built-in controls also don't help. Can't find it now, but details set display:none or visibility:none on closed contents, and that can't be animated.
And there are a million such things.
The development experience for a PWA could be a dream and it won’t matter if users don’t like them.
User acceptance is all that matters.
WebGPU feels like an outlier in that respect but then it is intended as a “better” WebGL so it makes sense that if you already have WebGL you might as well have WebGPU. It’s a lot closer to Apple’s Metal API than WebGL is so they have an interest in people switching.
My point is that Apple is competing with other browser implementations on MacOS, yet I’ve very rarely used anything other than Safari. Most exceptions have actually been because I need a plugin to debug the JS framework I’m using.
I read that both Google and Mozilla are developing non webkit iOS browsers in anticipation of some regulatory changes, and also that Apple has been staffing up the webkit/Safari team in response.
If WebKit's market share on iOS were to drop this low, web developers would likely test for WebKit a lot less, and tolerate WebKit's missing features a lot less, and Apple would soon face much worse web compatibility problems on both platforms. To prevent that they saw that they needed to seriously step up their investment in WebKit, and from what I've observed it seems like they did. Though perhaps not yet to the level they really need. Old habits die hard.
Of course they could just do what Microsoft did and give up. I'm glad they haven't.
[1] [Edit: this site was wrong, see below for better numbers]
https://radar.cloudflare.com/reports/browser-market-share-20...
Cloudflare puts Safari at a bit under 40% for MacOS, so it looks like I’m very much n=1 and not particularly representative. Marketshare for Safari on MacOS is close to 85%, so I can definitely see that changing if users could install real alternate browsers.
In Apple's case, I think there's some utility behind their drive for WebGPU: it's basically Apple's Metal graphics API. If WebGPU takes off, it'll mean a lot of developers getting familiar with something very similar to Apple's Metal API. Apple seems to be pursuing a long-term strategy of bringing more games to their platform. From the Game Porting Toolkit to ray tracing in their processors to Apple Vision to simply giving gaming a lot more attention in their keynotes.
And Apple might be well positioned to capitalize on gaming. A $130 Apple TV has a lot more CPU and graphics power than a Nintendo Switch. The same applies to the iPhones people are carrying around. It might not compete with giant consoles from Microsoft and Sony, but Apple has been showing that it can offer impressive gaming performance.
Fast forward to 2026: does a next-gen Apple TV have hardware ray tracing? Apple put a 2021 A15 processor in the 2022 Apple TV. It seems reasonable that they could put something better than a 2023 A17 Pro in a 2026 Apple TV (a 3 year old processor at that point). Sure, Microsoft and Sony will have next-gen consoles, but at what point are graphics facing diminishing returns? Nintendo has the most popular console even though it's older and was low-powered to begin with. For PC games, one must assume that some people are running graphics cards that are older.
I'm not saying this will happen. Companies can be fickle. However, Apple has show a reasonably consistent (if slow) move toward games over the past year or two. They're making the investments now and WebGPU's Metal-like API could be part of that strategy.
Heck, maybe WebGPU is even a strategy to avoid lawsuits from companies like Epic and anti-trust action from regulators. If you don't like the App Store rules, just use WebGPU. If games with native-level graphics can be distributed via the web, then there isn't nearly as much for regulators to go after the App Store.
This came out in the Epic Trial. Those people are much less likely to put a credit card on any random site.
Candy Crush games could already be done on the web on mobile - it wouldn’t be nearly as monetizable
Apple Pay is only in certain counties, with supported banks/cards. iTunes/App Store supports a plethora of payment options across the world, as well as Apple Pay.
Both companies are working very hard to remove this image though for obvious political reasons.
There is literally, for now, zero risk of that. companies will have devs meet the customers where they are at. Of the largest mobile market share platform in the USA doesn’t support PWA or only supports it without features the company requires, said company will build an iOS app. As has been the case.
Application developers will not go anywhere, for many reasons:
- iOS is where the money's at
- PWAs are not "apps". They are web apps with all the limitations it implies. You want complex functionality, rich controls, fluid animations and a billion other things? You go for native apps.
iOS 16.4 added new wake lock api but it does not work in PWA. Still not fixed in iOS 17.2
iOS 17 removed dark/light mode switching in PWA. Still broken in iOS 17.2
I'm really doubtful Apple sees Safari as competition for their app store distribution. I don't think that matches reality of how most consumers use mobile devices and spend money.
I don’t think they see Safari as competing with the App Store. Even with the recent PWA additions it doesn’t seem to matter.
At this point I’d say Safari is 100% a hedge against being fully dependent on Google/Chrome. It started to not be dependent on MS/IE and improve what MS didn’t care a ton about.
Apple HATES being fully dependent on others for very important stuff. They’ve been burned too many times.
Safari is great. I love it. But there’s no way it is ever going away even if they are forced to preload 18 different app stores and 4 browsers on every phone by the different governments of the world.
It’s Apple keeping control of Apple’s destiny.
How could the performance of a web app ever be faster than a native app? That’s impossible.
On the PWA side, best guess is anti-competition scrutiny.
[0]: https://www.w3.org/TR/WGSL/
By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them, due to ongoing legal issues between Apple and Khronos.
Apple actually proposed WebHLSL in collaboration with Microsoft, to have HLSL be the standard.
Mozilla employee's stance[0] was that SPIRV was too low level, did not fit with the goals of WebGPU portability and security, and expressed concern that Khronos may add functionality to SPIRV they cannot support in WebGPU like raytracing instructions .. 'So we'd always be on the verge of forking SPIR-V in some way.'
It was also noted by many people that even if a bytecode format was used, it would still have to be translated to the target (HLSL/DXIL, MSL, etc.) in almost the same way a text format would.
Nobody proposed a 'GPU WASM equivalent' or an alternative bytecode format, only SPIRV was ever considered AFAIK.
The hard truth is that shader compilation is a fucking nightmare, people do not realize how bad it is across the different native APIs. SPIR-V is good, but it doesn't solve that - and presents other challenges if you are a web browser API. Vulkan and SPIRV are not the golden goose many make them out to be.
[0] https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...
And exactly, Apple did not want SPIR-V (a bytecode) and proposed WebHLSL (a textual source language) instead. So, I think my statement that Apple preferred a textual format over a bytecode is correct. They could have proposed another bytecode format, but as you noted, nobody did.
It does not really matter anyway, because the GPU hardware and software paradigms are still undergoing rapid change. And there are a whole lot of under-specified things like memory models, scheduling order, control flow uniformity etc. which I expect will take another iteration of standards to be established.
> By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them
This is false. Apple's other stance, very strongly stated, was that no binary IR of any kind was acceptable, full stop. Lichtso's original comment is right. Apple explicitly rejected "GPU WASM equivalent or an alternative bytecode format", not just SPIR-V. They would only accept a textual programming language.
Now Apple didn't mandate WGSL, but clearly they wouldn't have accepted GLSL either for their unfortunate legal reasons so that pretty much leaves WHLSL or "new language" as the only options. I don't know why WHLSL ultimately lost. I remember hearing arguments that HLSL as a language was essentially implementation defined rather than rigorously standardized, making it hard to realize any benefit of code portability or reuse from existing codebases.
> I had a chance to work with SPIR-V rather intimately, and I’m becoming convinced that most of the defenders of this format (who like to criticize WGSL in turn) have little experience actually doing anything with it [...] I was one of them. SPIR-V is probably a good format for what it was made for: driver compilers. It’s not as good for the intermediate portable representations of your shaders.
[0] http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
> Apple's other stance, very strongly stated, was that no binary IR of any kind was acceptable, full stop.
Very strongly stated /where/?
I linked my source, in which kvark clearly stated two things (not as part of his 'devils advocate' position) that directly contradict your claim:
> There is much more to it than just "Apple cannot do X" that often shows up.
> the group agreed to [...] take the semantics of SPIR-V where it makes sense
If there really is a source for it, I'd love to see it (genuinely).
OK, I found what I believe are the most relevant meeting notes [1]. Unfortunately the meeting notes are not a straight transcript and not everything that was said is in there verbatim. There were also side discussions not captured at all. The meeting notes say "Apple would strongly prefer a text-based language to a binary one". This is really an understatement of their position on the matter, and the notes don't capture the most contentious arguments well. But you can at least see in the notes that Apple was arguing strenuously against binary formats generically, even more so than SPIR-V itself in this meeting, going as far as arguing that a hypothetical SPIR-V assembly in text format would be better than SPIR-V in binary form.
[1] https://docs.google.com/document/d/1CmKo59tjZwmePVrFpHpIG0W5...
https://github.com/WebKit/WebKit/tree/main/Source/WebGPU
Main issues:
Regarding memory usage. Sandboxing depends on multi-process. The multi-process shouldn’t be an issue. The sandboxing was added in late 2019 and - if I remember correctly - Epiphany started to eat memory. Like probably most people I keep my tabs when closing/opening the Web-browser. The developers are nice and explained, that for all previous existing tabs a separate sandbox process and a render-process is already started with a blank page. And due to need separation no process is allowed to share memory with others. What is needed is only showing a label on the tab until the tab is actually used.And. Midori? There was previously also Midori using WebKitGtk. I liked it and it was pretty nice. But something awkward happened and an unrelated people took over the name and started to ship Electron (i.e. Google Chrome) as “Midori”. It looks untrustworthy to me, I recommend to not install it.
If you use Midori on Archlinux you should be save - they ship and old and original version of Midori. But it is old.
Apple, WebKit and WebKitGtk work together for many years. Good work.
Apple is using WebXR for the Vision Pro, but it isn't clear if it will ever be available on iPhones.
That means easier builds for the developer, smaller apps, receiving implicit upgrades in lockstep with the OS. Take the example of new metal versions enabling new optimization avenues. Bundling your own dependency would mean that you need to keep on top of the changes to take advantage of it , but with a system framework you’d get it whenever Apple’s engineers enable it.
It is almost a rule with webkit new features.
Those new APIs almost work, but you need to use user-agent detection to make sure it really works and it does not fail randomly/silently when it is in home screen or some other iOS browser.
As with all STP releases, this is the time to report issues before the feature makes it into the next version of Safari.
It just silently fails. UA detection is needed for detecting bug version.
For example Wake lock API has been broken from iOS 16.4 that is like over 9 months.
Or zindex rendering was flickering between iOS 15.7 to 16.4
Some renderings work in Desktop safari but it is different in mobile safari with same version.
It sucks but it is reality of iOS developer experience.
From the preview page:
To enable WebGPU, turn on the “WebGPU”, “GPU Process: DOM Rendering” and “GPU Process: Canvas Rendering” feature flags in the Feature Flags tab in Safari Preferences. If you don’t see the Feature Flags tab, you need to first check “Show features for web developers” in the Advanced tab.
https://webgpu.github.io/webgpu-samples/
Same here.
Took a beat to realize I was looking at the OP and WebGPU demos in Safari.app instead of Safari Technology Preview.app.
This makes me suspicious that something has changed to push the balance here, and it must be something to do with trying to offload the execution of LLMs and related neural networks on to clients to reduce the cost of doing it server side.
If a random webpage is asking to use my GPU (especially if it's a sketchy-looking site I just got redirected to), that would raise flags and I'd deny access. If a game or visualization requests access, especially if it's something I've heard others praise, I'd take the risk.
Sure, someone could embed a vulnerability in some decent app which uses the GPU for actual rendering, but it's a lot harder.
I like the permission idea.
I've seen this argument being made quite often. However, I have yet to any evidence given. Can you provide concrete examples of how WebGPU is less secure than WebGL or other web APIs?
By the way, it was tiresome when people told me to go Google answers. It's just as tiresome when people tell me to go ask an AI. I'm here to talk with real people, not computers.
Besides, HN is a place where there's often an expert who will know far more than what's widely available on the web about even the most obscure of technical knowledge.
Source? "GPUs feel low-level like C and C is unsafe" is a vibes argument.
> (The spectre countermeasures around high resolution timing can still bite you).
The fact this is a problem at the highest of levels provides further damning evidence that this isn't a large change to the status quo.
Or was it that metal came from a team in Apple that helped work on WebGPU?
Apple plays that game well.
Then the standard changed a bit, but it was still based on modern GPU APIs
IIRC Safari had the flag too that time, not just the Technical Preview.
It's not really anything to do with WebGPU in particular.
https://github.com/pjmlp/webgpu