Web Apps on macOS Sonoma 14 Beta | Hacker News Reader

Web Apps on macOS Sonoma 14 Beta

blog.tomayac.com

187 pointsgoranmoomin134 comments

> 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.

https://developer.apple.com/documentation/webkit/promoting_a...

> 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.

Share became Export so slowly I never even realized it.

Seriously, I'm already sick of "let me send you desktop notifications!" popups.

To turn off notification popups, in Safari...

1. Go to Settings

2. Open Websites tab

3. Select General -> Notifications

4. Untick "Allow websites to ask for permission to send notifications"

No more notification popups!

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.

Yeah, I hate that. It's usually easy to spot, so I click "allow" on the JS notification and then block the real one when it pops up.

Today I learned, thanks!

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...

Firefox solved this years ago. The only indication is a little icon in the address bar.

https://blog.mozilla.org/futurereleases/2019/11/04/restricti...

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.

And behold.

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.

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.

See: https://www.nytimes.com/2022/07/08/business/korea-internet-e... as an example of something that should never have been implemented but is forced on a populace and becomes an anchor to an entire society.

You're free to do what you want but I don't want to be stuck with the consequences.

The problem is that the choice of shipping a webapp has consistently and persistently eroded the platform’s value proposition for users.

We’ve gone from having highly polished native Mac applications to a suite of crappy electron apps.

The slow death of Electron & Co?

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.

Why don't apps that require additional access write a "runtime" daemon their website can connect to?

Actually that might be a security nightmare

This sounds like what Figma does to support custom fonts in their webapp!

https://help.figma.com/hc/en-us/articles/360039956894-Access...

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.

One can only hope.

We keep having this idea since MSHTML and XUL,and thankfully it eventually goes out of fashion.

I already have a browser, an OS Web widgets, no need to package a browser with the application other than laziness.

Everyone shipping Electron is yet another ChromeOS advocate.

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.)

[0] https://twitter.com/TauriApps/status/1505618001126731781

In a couple of years one can scrape Web Developer designation on job advertising, replacing it by ChromeOS Developer instead.

And they used to complain about IE hegemony, what goes around comes around.

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.

But your "a browser" is different for other people, which one do you expect devs to target?

I expect they to do the same I have been doing since 1996 for Web projects, Web standards, and do the needful to make it work across browsers.

Alternatively, do what I have been doing since 1990, middleware for business logic with native UI integration.

The four preceding years don't count, as I was using only Timex 2068 as my single computer.

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.

Can't say the same for the Electron generation.

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.

At least we weren't shipping browsers alongside the content.

No, we were just mailing CDs and floppy disks with ISP software. At least the shipped browser isn't clogging the landfills =)

I mean Discord, and Slack still need to run on non-Apple devices.

Chrome supports "installing" apps for a long time. Apple is the blocker for true web apps with the year long lack of notifications for example.

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.

A floppy disk icon somewhere that will download the PWA.

floppy disk? what's that? why would I ever click that?

> 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.

screenshot – https://i.imgur.com/NALZpz8.png

> on a phone (or in browser dev tools emulating a phone)

or on any browser supporting Web Apps (like recent versions of Chrome/Chromium)

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…

I think web pages can detect whether they’re running as a Web App using the display-mode media query (https://web.dev/learn/pwa/detection/)

If so, they can use that to help/annoy their users/casual visitors by showing an “install me as a web app” banner.

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...

Websites do this already. On my iPad I have used sites that suggest doing this.

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.

Please no. Just have a button appear on the toolbar to install the site as a web app if it has a web app manifest, like Chromium browsers do.

I would prefer for PWAs to be in the Mac App Store. PWAs are already in the Windows Store, so there's a precedent.

Does using Slack as a Safari Web App reduce resource consumption vs the Electron app? This seems like a huge deal if so

> 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.

https://blog.chromium.org/2023/06/how-chrome-achieved-high-s...

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.

Yes, but...

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.

Seamlessly? How is Electron not seamless?

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.

> Seamlessly? How is Electron not seamless?

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?

Sure but that has nothing to do with the idea of being seamless.

Seamlessness is a UX concept, not a memory/resources concept.

Responsiveness, start up time and resource usage absolutely affect the user experience.

It becomes a UX concept when your laggy application sticks out like a sore thumb.

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.

Having tabs would just make it a browser. Your description leads me to believe you want a browser anyways, not a single app experience whatsoever.

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.

Another useful example of this is the Notion desktop app in which they manually created their own tab interface: https://twitter.com/NotionHQ/status/1601291261469548545

I agree that it would be much nicer to have this at the system level.

Sure. Even the most basic text editor is a lot nicer if it has tabs, or some tab-equivalent.

Um am I not understanding what "Web App" means?

"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."

https://en.wikipedia.org/wiki/Web_application

Progressive Web App

https://en.m.wikipedia.org/wiki/Progressive_web_app

Am I missing something there? Appears a browser is still required. i.e. at the moment these don't work with Firefox.

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.

Not really. Plenty of Electron apps for web apps like Notion, Figma, Linear all support tabs.

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.

You should be aware of the tabbed application model proposal, which would allow PWAs to have tabs: https://web.dev/tabbed-application-mode

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

Chicken and egg

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.

Extensions not running is disappointing. I would prefer my adblocker run in the app as well.

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]

[1] https://browser.kagi.com

[2] https://blog.kagi.com/orion-new-features

I am an active user of Orion! I'd like Safari-based apps to be better, if only so I can also use them as such on iPad and iPhone.

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.

Are SSBs popular again? I remember them being all the rage with Mozilla Prism or Fluid.

Yeah, seems like it; this time they have first party support by the os vendor, which is nice.

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.

>very slow to adapt new web technologies

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?

Push notifications where a chromium thing?

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?)

A review comparing the bleeding edge versions of Chrome, Edge, Safari, and Firefox on caniuse.com shows that Safari is doing quite well: https://caniuse.com/?compare=chrome+117,edge+114,safari+TP,f...

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)

> very slow

Cautious.

Chrome often adds features that are used to track you or have a negative impact on performance and battery life.

They recently added a bunch of long-awaited PWA features to mobile safari, and now this. I think Apple's stance is changing

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).

This is already available in Orion [1] which installs any site (PWA or otherwise) as .app

[1]: https://browser.kagi.com/

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.

Flotato got sherlocked

https://flotato.com

Any reason you can think of that local storage gets ignored while cookies are maintained?

LocalStorage may include application state that is irrelevant/incompatible with the PWA version of the page(?).

For session authentication a http secure cookie has long been the best practice for anyway, which is now marginally underlined even more so.

Cookies have a very small size limit. Other storage like cache, IndexedDB, etc can be 100MB+

Also Safari’s IndexedDB implementation has always been a little shaky I wouldn’t want to deal with it if I was implementing this feature!

Credit to Microsoft for having a similar feature in 1999: https://en.wikipedia.org/wiki/HTML_Application

This is amazing!

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 can’t help think Apple’s sudden interest in making web apps more useful has to do with visionOS.

Of course it does.

But that has nothing to do with the cynical conspiratorial manipulation you then go on to describe.

Sure, if past behavior is no kind of prior.

Confirmation bias is never a prior.

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.

For web apps using wasm for development could be a game changer

I how wonder how well these will render Flutter desktop apps.

Edit: Wait - I realize flutter desktop apps on macOS won't have to use Flutter web at all.

I don't get why it is forced to be on the Dock. I like having a super slim dock that only has open apps in it.

>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.

Really it would make more sense to be added to Launchpad but they seem to have all but forgotten about that feature

Just like all PWAs I get the appeal as a developer, but I have no clue as a user why I would ever want this.

If there’s a .app package, does that also mean there’s a signable + distributable app ready to go?

If so, good bye electron.

There is a .app (saved to ~/Applications) but there’s no binary inside. The full file structure:

  .
  └── Contents
      ├── Info.plist
      ├── Resources
      │   └── ApplicationIcon.icns
      └── _CodeSignature
          ├── CodeDirectory
          ├── CodeRequirements
          ├── CodeResources
          └── CodeSignature

Looks like all the necessary information is saved inside the Info.plist.

Does anyone know if the new Safari web app stuff means you can connect a web app to a widget?

What’s different from opening the websites from safari?

This is described in the article.

Hello internet explorer, active desktop etc... We are going full circle there.

Except it’s not pinned to your desktop.

Reply on news.ycombinator.com