> Let web apps programmatically trigger the Add to Dock flow, since the Share icon and the File menu install ways are hard to discover.
Please, for the sake of all decency, no!
We do NOT need new ways for web sites to badger users.
(Sorry to focus on this one thing. This was a great and informative article, with 99% good ideas. I just had a visceral reaction to the idea of yet more ways for sites to harass me as a user.)
This one isn't particularly abused. It's already available in Chrome and the number of sites that leverage it at all is vanishingly small. No real abuse from it - so far at least.
It does offer a much better user experience than "go search out these obscure menu methods".
Safari might do well offering a "don't badger me" option that just shuts all page based prompts and requests.
It wouldn't be a "new" way to badger users, because developers can currently badger users to install a native app. A Smart App Banner for installable web apps would be no worse than what Apple currently offers, a Smart App Banner exclusively for native apps, and I think those banners are just fine.
> Smart App Banners vastly improve users’ browsing experience compared to other promotional methods. In iOS, Smart App Banners provide a consistent look and feel that users come to recognize. They trust that tapping the banner will take them to the App Store and not a third-party advertisement. They appreciate unobtrusive banners at the top of a webpage, instead of a full screen that interrupts their experience with the web content. And with a large and prominent Close button, a banner is easy to dismiss. When the user returns to the webpage, the banner doesn’t reappear.
Note that "Add to Dock" installable web apps already do have a Smart App Banner on the new macOS 14 Sonoma, but only when you already have the web app installed. (It's exactly like the Smart App Banner for native apps, but, for web apps, it only works with the "Open" button, not with the "Install" button.)
It's just not good UX to programmatically trigger the dock flow either.
But it does signal an important aspect about the current iteration: the share icon hides way too many choices that don't make any real sense for being under the share icon. This is something Apple should absolutely work on ASAP because it's becoming a bloated list. Seriously, why is find under the share icon? How absurd this has gone on for THIS long.
Unfortunately many websites send a JS-based notification which can't be blocked before prompting you for the system one. I think the idea is that that can spam the JS one as much as they want, but once you say no to the system one, that's it, they can't prompt with it again.
I kind of wish there was a "Block and notify" option though, like there is with pop-up windows. One reason is that sometimes you might actually want to enable them, but it seems like there's no indication of the attempt at all.
But even for crappy websites, it would also be nice to know that they tried because it's one of the things that help to weed them out more easily.
I'm sort of resistant to that, because despite never having actually wanted to do so I keep thinking that there might someday be a site I'll want to allow notifications on...
The nasty thing that some sites will prompt you via a notification within the page. They want people who decline to do it there because it means they can try to bother you about it later (the request to the browser to show notifications was never made in this case).
The strategy with those is to accept the prompt in the page and then deny it at the browser level, but that's not something many people would know.
All browsers should have a setting that just tells all sites that notifications are enabled but never actually shows them until the user opts in so sites can't present those stupid prompts.
And why attempt to start sending notifications if it is the first time I have visited a site? I don't know the site, I haven't had time to read any of the content. Why would I possibly want to get notifications from a site I know nothing about? Maybe if I visit it several more times in the next week or two, then ask me if I want notifications if you feel you must. Anything else is just annoying and sort of mindless.
Sites likely do this to prey on "yes-click syndrome" where people just blindly mow through prompts to get to whatever it was they came for more quickly.
+1. I've never needed that crap and can assume the vast huge majority of users won't either.
The Notifications Api only exists for websites as marketing channels and spamming. Think of email spam but one that's right in your face.
There are so many developers that seem to have a hard time with the notion that, just because they wouldn't abuse a feature, doesn't mean someone else wouldn't.
I was actually against web push notifications as a feature precisely because I knew it'd just create a thousand push notification pop-ups on the web.
I am unreasonably excited about Safari PWAs on macOS. This is a very good start.
Some of my favorite details from the article:
> Different from iOS/iPadOS, credentials in cookies are copied over, so if you were logged in when running in the tab, you're logged in when you launch the app. No other storage means apart from cookies are copied.
> Same-origin (or in-scope if a manifest exists) links are handled in-app, cross-origin (or out-of-scope if a manifest exists) links open in the default browser. A notable exception are OAuth flow links, which are handled in-app based on a heuristic.
> Web apps run in the context of a separate process called `Web App.app`. Separating Safari and Web App allows both to run independently. You can open a Web app without opening Safari, you can close Safari without all web apps closing.
Buuutt... FileSystem API is not supported yet. Nor is drag-and-drop or LaunchHandler (open a specific file type with the web app). If we had those features, we could get back to storing and editing files on disk, using web apps, which would be a huge improvement for local-first apps.
> Web apps run in the context of a separate process called `Web App.app`. Separating Safari and Web App allows both to run independently. You can open a Web app without opening Safari, you can close Safari without all web apps closing.
This is a big thing that's dampened my desktop usage of PWAs with Chrome and other Cloniums - it's highly irritating for Chrome itself to fire up when I launch an installed PWA. Not a problem if Chrome is your main browser I suppose, but that's not an assumption that should be made. Glad Apple took this route on this.
> FileSystem API is not supported yet. Nor is drag-and-drop or LaunchHandler
Drag-and-drop as in, not handled any better than current web apps?
As for the other two, I hope they never are. My hope is that this feature is for process isolation for things that may be open all of the time anyway and not have native alternatives: project management tools, social sites, media sites.
I don't want developers to build web apps in place of native and point to "Web Apps". I know I'm fighting an uphill battle, but 10 years later, Electron apps still suck. I'm not interested in making it easier for developers to build crappy desktop apps.
It is so weird hearing people hope Safari doesn't implement feature X, Y or Z simply so users and developers don't have a choice. If you don't want to use or support something don't, but you have no idea what is best for me.
As is mentioned elsewhere in the thread certain features are too easily abused. Part of being a platform owner is saying no to things that may seem like a good idea but are short-sighted and have a high likelihood of abuse.
Electron apps like Discord, Slack, etc. don't seem to gain any benefit from being wrapped in Electron anymore. Have one codebase, one app, that works everywhere and can now even be "installed" with Safari.
You're probably right with regard to Slack, Discord. However, some Electron apps require access to the filesystem or other APIs that these installed web pages wont't support (as far as I know). FS access is listed as a wishlist item in the article.
Electron still has a lot going for it if you need access to system APIs or you want it to be cross platform.
The manifest.json spec supports declaring “file_handlers” mapped to a URL action. Only supported in Chrome and Edge at the moment. The action URL could be handled by the service worker, so there’s no need for files to be sent over the network if all the processing can happen offline.
I mean, wouldn't the ChromeOS way be to just... use Chrome itself without also running server-side JS underneath it? Arguably this is the opposite -- Google goes in hard on the idea of expanding the Web's capabilities, after all, where a lot of the Apple camp has historically preferred keeping certain system-level stuff like hardware access away from browsers. Shipping Node underneath seems to skew more toward the latter, even if it's going to vary by team whether it's a philosophical choice or just a pragmatic one.
I agree that I'd rather just have a system WebView for things like this, but putting aside that the landscape for those is effectively just Blink/V8 or WebKit/JavaScriptCore at this point, it's still perfectly valid to just want a single engine that behaves consistently across environments -- particularly given Safari's history of being slow to adopt Web standards even when they don't fall into the whole argument of capability.
Even Tauri, which currently relies on system WebViews, has started collaborating with the Servo team[0], at which point you're cycling right back to shipping a browser stack for writing desktop apps in JavaScript. (And for that part, I'll take the further development of alternative browser engines as a net gain tbh. See also: Wolvic.)
I don't know if you noticed but this is literally a thread about installable web apps on a browser that isn't Chrome (or derived from Chrome) on an OS that isn't developed by Google.
The 90-s have very little to show for, especially in the area of Web projects and standards, the testament of the failure of the latter is precisely the required scale of "the needful"
Thankfully many old timers aren't frozen in the 90's, we rather use our experience to write proper Web applications instead of being ChromeOS advocates.
here here. please excuse me while i adjust my suspenders and twist my beard as i yell get off my lawn.
when i reference things from the 90s, it is far from my being stuck there. it is because i have the living memory of the pain from that time, and can see it being repeated by the people that have no living memory of that time. i lived that pain once, i don't need to relive it because someone else hasn't and is too stubborn to look at the history and not repeat it.
I don't want to be nit-picky and it might seem like a minor nuisance, but developers will need the ability to display a small banner/prompt to educate user's about the possibility of installing the website like a regular app, otherwise it will be lost on casuals. I really hope that Apple implements this fully and doesn't use strategic loopholes to sabotage Web Apps in small but clever ways.
Sorry to be dimissive, I know it's good intentions and all, but please don't do that. We don't need any more unsolicited banners or prompts. See it's one reason native apps are so much preferred over websites. Websites always have banners and whatnot, good apps don't do these things.
Fully agree. I'd say that there should be an agreed-upon way for users to opt out of any kind of obnoxious banner/"dickbar" but it'd probably be obeyed about as often as the "do not track" flag was.
> We don't need any more unsolicited banners or prompts.
If you open https://squoosh.app on a phone (or in browser dev tools emulating a phone), you will see what I think is a great example of use of an install prompt that I personally would be totally ok with.
I actually tried it in Chrome on MacOS before writing my comment, and did not see the Install button, but only the tiny install hint in the url bar. That surprised me, because I clearly remembered the button; which is why I thought that maybe the button only appears on mobile browsers where it's harder to find the install option in browser's own ui. But now when I open it again in desktop Chrome, there it is, the Install button. Strange.
I wouldn't hold my breath. This always was and I think still is the problem with web apps on iOS: there's no good way to prompt the user to add it to their Home Screen. There's tons of sites out there that do it in their own ad-hoc way, but point in the wrong place because they were designed for Safari (n-1).
Meanwhile there's long been special affordances to make it easy to go to an App Store page. The purpose of a system is what it does…
The trouble with that is every website will set the flag so they try and grab some nice traffic generating (they hope) screen real estate. So less savvy users will get a bad user experience with a home screen / dock full of spam sites because they always hit yes and tech savvy users will just turn off the banner as every site spams them with it. Plus, we already have enough spam interactions before you can actually use websites with stuff like notification enabling prompts, newsletter signups, chatbots and cookie stuff. No more please...
I would think this could be done the same way that some websites that are optimized for web apps on iOS will have a prompt (often pointing to the control) saying you can save the website as a web app.
> Does using Slack as a Safari Web App reduce resource consumption vs the Electron app?
Yes. Yes it does.
This is why “native” apps that use the operating system’s default WebView for the corresponding platform run seamlessly compared to apps packaged with Electron.
Safari is has much better performance than any other web browser on macOS, and this change will allow users to access those benefits.
> Safari is has much better performance than any other web browser on macOS
Typical marketing BS. Browsers are probably very close to performance. Chrome said last year they are actually the fastest browser on M1/2. On Speedometer 2.0 (apple developed benchmark) with M2 Air Chrome currently has the highest score of 491.
What does fastest mean? Does it have the most responsive UI? Is it the fastest to open? Is it using less memory than the competition to achieve its speed?
To me, proof is in the pudding: Chrome feels large and bloated when I use it. Safari feels snappy.
I know it is an early developer beta, and I haven't even begun to debug it, but Slack running in this method does not perform well. My sent messages frequently show and then get stuck in the grey "sending" text indefinitely after they appear as sent on other devices, and I often don't receive messages in the web app until I force a refresh.
This is my experience with Slack as a PWA in Chrome, or even in a regular tab in Safari. My guess is that Slack doesn't play nice with attempts to snooze background tabs to save system resources.
Also using Safari is great if your app is Mac-only, but the whole point of Electron is to support Mac and Windows and Linux. And not have to worry about browser quirks and Safari versions and backfills and whatnot.
Because it duplicates the overhead of an entire browser (and Chromium at that) rather than the overhead of a single webpage in an already-open browser?
So overhead for a single app might be comparable, but each subsequent Electron app that I replace with a Safari Web App would use significantly less CPU/RAM
I believe so. I would hope that the overhead for "having more than 0 webviews open" is global across the entire OS; we know that macOS uses a global shared library cache at least.
I think it's safe to assume any Safari PWA will be more resource-efficient than a Chromium counterpart.
In most cases, the decision will finally always revolve around the system hooks – how many does the Electron app have, and whether are you able to live without them.
Can Web Apps use tabs? As in, if I command click a link, will it open in a native tab in the Web App? If they can't, then a bunch of apps I want to use as web apps will have to stay within the main browser unfortunately.
It seems weird to have to point this out, but there are many apps that have tabs that are not web browsers.
Any sort of document-based app benefits tremendously from tabs, and thus it would be unfortunate to have to lose that feature when making it a Web App. I for example often need a couple Google Docs open at once. I would very much like to have Google Docs as a separate item in my Dock though. However, I don't want to be forced to have each individual Google Document in a separate window like it's Mac OS 9 just because it's a "Web App".
Or for example Airtable. I have a few Airtables that I basically always have open. I currently have them "pinned" just because if not they become impossible to find in the sea of other windows and tabs in my browser. I would love to command-tab to Airtable and bring these up, but not have them in an overlapping mess of windows.
Another great example is social media "Web Apps" (like Elk for Mastodon), which basically get "stacks" for free by leveraging tabs. Instead of the Elk team having to develop an "internal tabbing" feature, I can just have a tab for each hashtag I am following. But this does not mean that I want all these tabs mixed in with random other unrelated websites.
Literally any app (vs. "page") that uses multiple windows that you would personally prefer to group into tabs is a good candidate. Tabs are a window organizational tool, they have no inherent "webness" to them aside from that being the first place they originated. macOS's AppKit framework has built-in support for automatically making document-based apps support tabs with zero additional programming. I assure you this feature wasn't added in to allow anyone to write a web browser. In fact, I think the opposite of your assertion is true: the more like an "app" the thing you're turning into a Web App is, the more likely it is to use multiple windows, and thus the more it can benefit from tabs. I agree that if you are for some strange reason turning a blog into a Web App, then tabs don't make any sense, but it also doesn't make sense to turn it into a Web App.
"A web application (or web app) is application software that is accessed using a web browser. Web applications are delivered on the World Wide Web to users with an active network connection."
Yea a browser is required and is provided by whatever browser was used to install the app. So if you “install” the PWA with Chrome, then Chrome is used to open it. On Mac/Safari 17+, it looks like it’s provided by Web App.app, which is probably just a wrapper for Safari. A separate browser install is not required.
It works in Firefox, not sure why Wikipedia has that wrong.
Yeah this is a real UX conundrum, because the whole windows/tabs paradigm right now is kind of confused.
Like when I use Google Docs, I've usually got several open as separate tabs in my browser. If I wanted Docs as a webapp, it wouldn't have the tabs functionality anymore, which would make it immediately useless. In the way that every IDE or Photoshop now use tabs inside the app.
We're at this place now where I actually wish tabs weren't handled by applications but rather by the OS, together with windows. Let me create a window that has three Chrome tabs, a Safari tab, a Terminal tab, and a Preview tab. Another window with a Word (installed) doc tab, an image in Photoshop tab, and several Finder tabs.
The fact that web apps can't be tabbed is almost this weird step backwards.
Tested it on the beta, and tabs are not available. The option isn’t there even if you right-click a link. But you can create new windows of the same app.
Under the Window menu there are options to Show Previous Tab, Show Next Tab, and Move Tab to New Window, but they’re all greyed out.
Yeah I think this has held/will hold up adoption. Of course web apps can implement their own tab UIs like native apps do, but many don't because they figure you already have tabs in your browser
Having the choice is great. I sometimes open a Google Spreadsheet as an app so that any links I click in the spreadsheet will open in my browser and not steal focus from the spreadsheet.
While I understand where you're coming from, I think it makes a lot of sense continuity-wise. A regular user doesn't care nor know how these apps work internally, as far as they're concerned, it's just another app. You wouldn't expect changing the settings of one of your apps to change the way random other apps work (power user tools notwithstanding).
Given I'm a developer who uses PWAs on every device, my opinion probably doesn't mean much compared to the general public.
But this means I'll never use YouTube in Web App.app, and just sounds like it's going to be annoying using my password manager (though to be fair, Safari alone makes it a pain to use my password manager)
You can try Orion browser's [1] web apps which inherit the native adblocker from Orion and have more powerful options than Safari, while still running WebKit underneath. [2]
My main objection to PWAs is that I can't run an content blocker or other extensions inside of them. This renders them unacceptable to me.
For example, one main use would be YouTube. Right now I use a separate Firefox profile on my second monitor so I can run uBlock Origin and Sponsorblock.
It isn't solely about blocking advertisements. I use content blockers extensively to get rid of annoyances, popup banners, intrusive elements of websites like Reddit's incessant prompting to buy "coins" (whatever the heck those are) or join their social media push a la moment. I can't comfortably use the web without this functionality.
I would love to be able to ship apps in this, with a code bundle, so we don't need to ship a full Electron engine for every app. Even better, I wish someone would standardise it so we could still write one, ship to all platforms.
It is standardized and Safari isn’t the first. Edge already supports this on Windows, Chrome does everywhere, and they’re all using the same “manifest.json” declaration whenever display is set to “standalone”.
These all require a service worker, so that’s the destination of your pack and, conveniently, a cache for downloaded assets.
There’s that Tauri project that is pretty close to exactly this. It’s Rust code using a browser UI layer, but unlike Electron, it uses the native Web control for the platform. That way you don’t ship the browser portion, just your business logic and UI experience.
You’ll have some cross browser issues but save on footprint.
I imagine most developers will still elect to ship their apps using Electron for the usual Safari issues: Safari is only on macOS, very slow to adapt new web technologies and Safari updates are largely tied to macOS updates.
I'm not sure this argument holds water given the shockingly old versions of Electron that vendors ship (WhatsApp is using 13.6.9, Slack 24.2.0, Skype 19.0.9, Discord 22.3.2...)
Separately, is Safari actually slow to adopt new web technologies, or do they wait for standardisation and not simply accept the latest half-baked api of the week that Google builds for Chromium, uses across their websites, and then proclaims a New Web Standard?
Remembering that this thread is in the context of using native browser engines for desktop apps vs Electron, and the original poster's suggestion was quite measured (i.e. we don't need electron for every desktop app). I don't think your point about push notifications is particularly relevant in this use case (personally I don't want desktop apps sending me any push notifications when they're closed - am I in a minority?)
Many of the areas of "no" for Safari are also "no" for Firefox, suggesting Chrome/Chromium features without a consensus amongst browser vendors, and many don't make any sense for desktop apps (e.g. Vibration/Gyro/Accelerometer APIs).
The GP made a fairly broad statement about web technology support which is what I was responding to - I know they've lagged behind on Push Notifications but what I'm arguing is that I think the narrative of "Safari is slow to adopt new web tech" is more a perception driven by Chromium constantly pushing new features into their browser (and them being regarded as 'web tech' rather than 'chrome tech' simply by nature of their position in the market) than Safari actually lagging behind standards implementation generally.
P.S. On Web Push, I don't think anybody whose older relatives use Android and get regular advert-laden push notifications (from sites they didn't realise they were accepting push notifications from, and often aren't sure how to stop them) would disagree that Google's attitude on Web Push was foolhardy, and Apple taking a more thought out approach is welcome (although I agree that it should have happened faster)
It would be nice for web apps to have a setting users (not only the developers) can enable that will allow closing the app's window without quitting the app, like a lot of native desktop apps behave (eg, Safari).
I can't seem to figure out if it's possible to run the web apps (PWA) without launching Safari every time. That has been one of my main complaint about Chrome PWAs. Everything I launched Google Chat, Chrome would also start. I get that it's Chrome doing the actual work, but I don't use the browser, so why would I want it on my Dock.
I can confirm that you can run web apps created this way on the developer beta without having Safari running, and if you have both running than quitting Safari will not quit the web app.
> Observation: Separating Safari and Web App allows both to run independently. You can open a Web app without opening Safari, you can close Safari without all web apps closing.
I probably wouldn't use something like this without extensions support. I can't imagine browsing the web these days without an adblocker. Otherwise, this seems pretty neat.
I think I'll stick with my current approach unless they decide to enable extension support.
I just finished working on a tiny ChatGPT wrapper in Electron just to mimic this feature. I'm very excited to be able to do that easily with GSuite and basically every other website I use daily.
"When a user adds a website to their Dock, Safari will copy the website's cookies to the web app. That way, if someone is logged into their account in Safari, they will remain logged in within the web app. This will only work if the authentication state is stored within cookies. Safari does not copy over any other kind of local storage. After a user adds a web app to the Dock, no other website data is shared, which is great for privacy."
What is the additional privacy risk from IndexedDB and localstorage?
I would have thought apps that store everything locally, that don't require any backend at all are great for privacy, but what do I know, I don't have billions to spend on privacy branding.
Usable PWAs on macOS is great news. At the same time, I can’t help think Apple’s sudden interest in making web apps more useful has to do with visionOS.
When iOS was brand new, they were talking up web apps because they needed the content. When the platform got established, Apple could tighten the screws and drive developers towards native apps by not supporting the latest web features.
Now that they have an upstart platform again, they’re once more interested in PWAs, WebXR and so forth — until the day comes that visionOS is established enough.
Of course this was always Microsoft’s playbook too, as we saw most egregiously with Internet Explorer 6 not receiving any updates after MS concluded they had won.
I'd say it's more likely a way for them to argue that there's an alternative way to publish applications to the device so they can keep big government away from their App Store cashflow.
>When right-clicking the Dock icon, you can uncheck Keep in Dock and still launch the app via Launchpad, Spotlight Search, or even just by double-clicking the app icon in ~/Applications/.
It's not - it's just an app in your Applications folder that's automatically put in your dock. You can remove it. They just label it that way to make it easier for beginners to reason with.
Please, for the sake of all decency, no! We do NOT need new ways for web sites to badger users.
(Sorry to focus on this one thing. This was a great and informative article, with 99% good ideas. I just had a visceral reaction to the idea of yet more ways for sites to harass me as a user.)