Disclaimer, just in case… 🔗

I work for Google on the Chrome Developer Relations team. But for this post, I want to make it super duper clear that I'm speaking not on behalf of my employer and that all views and opinions expressed in this blog post are purely my own: Thomas Steiner's, the guy commonly known for his avatar with a green hat, but today in my pajamas having my second morning coffee. Oh, thanks for asking, the two cats are Lluna (yes, with double 'l', it means moon in Catalan) Norris, looking at the camera, and Skinny Norris, looking out of the window.

How I noticed 🔗

With this out of the way, it's time to dive in and answer the question of what exactly did Apple break in the EU? I'm physically located in the European Union and my iPhone has a German SIM card. On January 30, 2024, I sent the following toot with attached screenshot (cropped here):

Hope this is a bug in the beta, but opening previously installed Home Screen Web apps on iOS 17.4 (21E5184i) results in a prompt:

Open "Example app" in Safari. "Example app" will open in your default browser from now on.

Newly installed apps always open in the browser. There doesn't appear to be a standalone mode anymore.

Reported as FB13567834.

The toot that all the news outlets cited was the one from Mysk from February 1, 2024, that said:

🎬 Finally, iOS treats all browsers equally when it comes to PWAs. Previously, only Safari was able to install and run PWA apps. With iOS 17.4 beta in the EU, no browser can install PWA apps, even Safari. It seems PWAs have been disabled entirely.

Oh yes, when you set a third-party browser as the default browser and then you delete it, iOS sets Safari as the default browser. Watch this:

#iOS #Apple #DMA #EU #maliciouscompliance

youtu.be/AST12aDGf0Q

Then, on February 2, 2024, Tixie opened a WebKit bug titled "Bug 268643 - [iOS 17.4 Beta (21E5184k)] REGRESSION: PWA added to Home Screen are forced to open in Safari."

🆕 Update: The message in the release candidate of iOS 17.4 (21E217) is now: "Open 'Example app' in 'Default browser'? In your region, web apps now open in your default browser".

What does Apple say? 🔗

By now, you have probably heard that users in the EU don't have access to Home Screen web apps anymore. Here is Apple's statement in its full glorious detail:

To comply with the Digital Markets Act, Apple has done an enormous amount of engineering work to add new functionality and capabilities for developers and users in the European Union — including more than 600 new APIs and a wide range of developer tools.

The iOS system has traditionally provided support for Home Screen web apps by building directly on WebKit and its security architecture. That integration means Home Screen web apps are managed to align with the security and privacy model for native apps on iOS, including isolation of storage and enforcement of system prompts to access privacy impacting capabilities on a per-site basis.

Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user's camera, microphone or location without a user's consent. Browsers also could install web apps on the system without a user's awareness and consent. Addressing the complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps. And so, to comply with the DMA's requirements, we had to remove the Home Screen web apps feature in the EU.

EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change — that was made as part of the work to comply with the DMA — may have on developers of Home Screen web apps and our users.

These changes are iOS only! 🔗

The first important thing to note here is that this statement exclusively applies to iOS, but not iPadOS and not macOS. This works because Apple managed to convince the EU Commission that iPadOS and macOS are distinct core platform services. The relevant section of the DMA says:

Moreover, the Commission considers, in line with Apple's view, that iOS, iPadOS, macOS, watchOS, and tvOS constitute distinct CPSs [core platform > services] within the meaning of Article 2, point (2), sub (f), of Regulation (EU) 2022/1925.

This means on iPadOS and macOS, everything will stay the same. You can still add Web apps to the Home Screen on iPadOS or the Dock on macOS, and they will open in standalone mode as they always did.

💡 Note: This article exclusively talks about Home Screen Web Apps, not bookmarks. According to Apple's documentation, "Web developers have the option to create a manifest file (with its display member set to standalone or fullscreen) and serve it along with their website. If they do, that site becomes a Home Screen web app. Then, when you tap on its icon, the web app opens like any other app on iOS or iPadOS instead of opening in a browser. You can see its app preview in the App Switcher, separate from Safari or any other browser."

What happens on iOS? 🔗

Looking now at iOS. If…

1. you have an iPhone that runs (betas of) iOS 17.4 or later, and iff (if and only if)…
2. you are detected as being in the European Union (EU), you can still add apps to the Home Screen, but they will open in a regular new browser tab in your default browser.

How exactly Apple detects if you're in the EU isn't clear yet. It seems not to be based on the SIM operator, as some users claim they are affected even on SIM-less iPhones. Possibly IP geolocation as it doesn't require location access? Or maybe GPS for improved accuracy based on a system-level access grant? What about travelers in the EU from non-EU countries? I hope we will find out eventually. People started noticing an IDENTIFIABLE_REGION string in iOS 17.4 beta 1 (21E5184i) as early as January 25, 2024, but it was removed in the next beta.

💡 Note: Since iOS 16.4, apart from Safari, alternative browsers, too, have the ability to add apps to the Home Screen. Based on Apple's instructions, "if your app has the com.apple.developer.web-browser entitlement, the iOS share sheet can offer Add to Home Screen for an http or https webpage, creating a convenient link to a web app or bookmark. To allow someone to add the current webpage to the Home Screen, include the WKWebView instance in the activityItems array when you call init(activityItems:applicationActivities:) to create the UIActivityViewController."

There are different scenarios listed in the following.

You previously added an app to the Home Screen with Safari 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if Safari was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You previously added an app to the Home Screen with an alternative browser that has the com.apple.developer.web-browser entitlement 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if the alternative browser was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You newly add an app to the Home Screen with Safari 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if Safari was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You newly add an app to the Home Screen with an alternative browser that has the com.apple.developer.web-browser entitlement 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if the alternative browser was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

What breaks? 🔗

As you see, all the cases mentioned above lead to the same result, a new tab in your current default browser. While simple to understand, there are a number of things that now break.

Push API 🔗

The Push API was described in the article Web Push for Web Apps on iOS and iPadOS published on February 16, 2023. It's important to note the caveat: "A web app that has been added to the Home Screen can request permission to receive push notifications as long as that request is in response to direct user interaction — such as tapping on a 'subscribe' button provided by the web app." Since Home Screen web apps are no longer available in the EU, the Push API is effectively broken for EU users.

Badging API 🔗

The Badging API was described in the article Badging for Home Screen Web Apps published on April 25, 2023. The important caveat here is: "The user must grant the app permission to display notifications before the badge will appear." Since the Push API is no longer exposed, the Badging API breaks as collateral damage.

Standalone mode 🔗

Running in standalone mode allows Web apps to look and feel like native apps without any browser UI. This was particularly useful for game streaming services like NVIDIA GeForce Now or XBox Cloud Gaming, but also just any other app that wants to make best use of the limited screen real estate. Even manually entering fullscreen mode isn't possible anymore, as Safari 17.4 "[f]ixed multiple issues by disabling support for the Fullscreen API on iOS."

Stored data 🔗

Home Screen Web apps ran in a different isolated context than regular in-tab Web apps. This means that if you were logged in to a Web app from the Home Screen, you need to log in again in the browser tab, and all previously stored data is gone. This includes any data stored in:

• IndexedDB
• LocalStorage
• Media keys
• SessionStorage
• Service Worker registrations and cache
• Origin private file system

Exclusion from storage eviction 🔗

Home Screen Web apps were exempt from Safari's 7-Day Cap on All Script-Writeable Storage, but now they aren't anymore. Unless you use a Web app regularly enough, its data will be evicted from storage. This also applies to WKWebView-based browsers that have the com.apple.developer.web-browser entitlement:

Additionally in iOS 14.0 and macOS Big Sur, Intelligent Tracking Prevention (ITP), is enabled by default in all WKWebView applications.

[…]

Note that applications taking the new Default Web Browser entitlement always have a user control in Settings to disable ITP[.]

Multiple installs of the same Web app 🔗

iOS has supported multiple installs of the same Web app since the very beginning. Apple highlighted the ability for people to install any Web app more than once on their device, which can indeed be useful:

When adding a web app to the Home Screen, users are given the opportunity to change the app's name. iOS and iPadOS 16.4 combine this name with the Manifest ID to uniquely identify the web app. That way, a user can install multiple copies of the web app on one device and give them different identities. For example, notifications from "Shiny (personal)" can be silenced by Focus while notifications from "Shiny (work)" can be allowed. If the user gives their favorite website the same name on multiple devices, Focus settings on one device will sync and apply to the others as well.

Technically, this still works and people can add apps more than once, but because the apps now open in the same browser context, the multiple installs people used, for example, to sign in to different accounts, are now effectively useless.

What now? 🔗

The DMA opened the door for browser vendors to ship their own engines on iOS. This would mean that push notifications, app icon badges, storage management, storage eviction, and fullscreen/standalone mode could be decoupled from the previous model of creating a browser shell that until now needed to embed a WKWebView and at best could inject JavaScript to expose APIs that WKWebView didn't support natively to Web apps. The process of Using alternative browser engines in the European Union is going to be maximally painful, as Alex Russell points out and as Mozilla has gone on the record to say.

According to the Financial Times and The Verge, the European Commission is on the case. This is what spokesperson Lea Zuber shared with both publications:

We are indeed looking at the compliance packages of all gatekeepers, including Apple.

In that context, we're in particular looking into the issue of progressive web apps, and can confirm sending the requests for information to Apple and to app developers, who can provide useful information for our assessment.

An open letter to Tim Cook 🔗

The good folks from Open Web Advocacy have written an open letter addressed at Tim Cook in which they outline why Sabotaging Web Apps Is Indefensible. As an immediate action, I would very much encourage you to go 🖋️ sign it. I did. And now back to my third morning coffee and my cats.

This post appeared first on https://blog.tomayac.com/2024/02/28/so-what-exactly-did-apple-break-in-the-eu/.

Disclaimer, just in case… 🔗

I work for Google on the Chrome Developer Relations team. But for this post, I want to make it super duper clear that I'm speaking not on behalf of my employer and that all views and opinions expressed in this blog post are purely my own: Thomas Steiner's, the guy commonly known for his avatar with a green hat, but today in my pajamas having my second morning coffee. Oh, thanks for asking, the two cats are Lluna (yes, with double 'l', it means moon in Catalan) Norris, looking at the camera, and Skinny Norris, looking out of the window.

How I noticed 🔗

With this out of the way, it's time to dive in and answer the question of what exactly did Apple break in the EU? I'm physically located in the European Union and my iPhone has a German SIM card. On January 30, 2024, I sent the following toot with attached screenshot (cropped here):

Hope this is a bug in the beta, but opening previously installed Home Screen Web apps on iOS 17.4 (21E5184i) results in a prompt:

Open "Example app" in Safari. "Example app" will open in your default browser from now on.

Newly installed apps always open in the browser. There doesn't appear to be a standalone mode anymore.

Reported as FB13567834.

The toot that all the news outlets cited was the one from Mysk from February 1, 2024, that said:

🎬 Finally, iOS treats all browsers equally when it comes to PWAs. Previously, only Safari was able to install and run PWA apps. With iOS 17.4 beta in the EU, no browser can install PWA apps, even Safari. It seems PWAs have been disabled entirely.

Oh yes, when you set a third-party browser as the default browser and then you delete it, iOS sets Safari as the default browser. Watch this:

#iOS #Apple #DMA #EU #maliciouscompliance

youtu.be/AST12aDGf0Q

Then, on February 2, 2024, Tixie opened a WebKit bug titled "Bug 268643 - [iOS 17.4 Beta (21E5184k)] REGRESSION: PWA added to Home Screen are forced to open in Safari."

🆕 Update: The message in the release candidate of iOS 17.4 (21E217) is now: "Open 'Example app' in 'Default browser'? In your region, web apps now open in your default browser".

What does Apple say? 🔗

By now, you have probably heard that users in the EU don't have access to Home Screen web apps anymore. Here is Apple's statement in its full glorious detail:

To comply with the Digital Markets Act, Apple has done an enormous amount of engineering work to add new functionality and capabilities for developers and users in the European Union — including more than 600 new APIs and a wide range of developer tools.

The iOS system has traditionally provided support for Home Screen web apps by building directly on WebKit and its security architecture. That integration means Home Screen web apps are managed to align with the security and privacy model for native apps on iOS, including isolation of storage and enforcement of system prompts to access privacy impacting capabilities on a per-site basis.

Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user's camera, microphone or location without a user's consent. Browsers also could install web apps on the system without a user's awareness and consent. Addressing the complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps. And so, to comply with the DMA's requirements, we had to remove the Home Screen web apps feature in the EU.

EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change — that was made as part of the work to comply with the DMA — may have on developers of Home Screen web apps and our users.

These changes are iOS only! 🔗

The first important thing to note here is that this statement exclusively applies to iOS, but not iPadOS and not macOS. This works because Apple managed to convince the EU Commission that iPadOS and macOS are distinct core platform services. The relevant section of the DMA says:

Moreover, the Commission considers, in line with Apple's view, that iOS, iPadOS, macOS, watchOS, and tvOS constitute distinct CPSs [core platform > services] within the meaning of Article 2, point (2), sub (f), of Regulation (EU) 2022/1925.

This means on iPadOS and macOS, everything will stay the same. You can still add Web apps to the Home Screen on iPadOS or the Dock on macOS, and they will open in standalone mode as they always did.

💡 Note: This article exclusively talks about Home Screen Web Apps, not bookmarks. According to Apple's documentation, "Web developers have the option to create a manifest file (with its display member set to standalone or fullscreen) and serve it along with their website. If they do, that site becomes a Home Screen web app. Then, when you tap on its icon, the web app opens like any other app on iOS or iPadOS instead of opening in a browser. You can see its app preview in the App Switcher, separate from Safari or any other browser."

What happens on iOS? 🔗

Looking now at iOS. If…

1. you have an iPhone that runs (betas of) iOS 17.4 or later, and iff (if and only if)…
2. you are detected as being in the European Union (EU), you can still add apps to the Home Screen, but they will open in a regular new browser tab in your default browser.

How exactly Apple detects if you're in the EU isn't clear yet. It seems not to be based on the SIM operator, as some users claim they are affected even on SIM-less iPhones. Possibly IP geolocation as it doesn't require location access? Or maybe GPS for improved accuracy based on a system-level access grant? What about travelers in the EU from non-EU countries? I hope we will find out eventually. People started noticing an IDENTIFIABLE_REGION string in iOS 17.4 beta 1 (21E5184i) as early as January 25, 2024, but it was removed in the next beta.

💡 Note: Since iOS 16.4, apart from Safari, alternative browsers, too, have the ability to add apps to the Home Screen. Based on Apple's instructions, "if your app has the com.apple.developer.web-browser entitlement, the iOS share sheet can offer Add to Home Screen for an http or https webpage, creating a convenient link to a web app or bookmark. To allow someone to add the current webpage to the Home Screen, include the WKWebView instance in the activityItems array when you call init(activityItems:applicationActivities:) to create the UIActivityViewController."

There are different scenarios listed in the following.

You previously added an app to the Home Screen with Safari 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if Safari was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You previously added an app to the Home Screen with an alternative browser that has the com.apple.developer.web-browser entitlement 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if the alternative browser was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You newly add an app to the Home Screen with Safari 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if Safari was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You newly add an app to the Home Screen with an alternative browser that has the com.apple.developer.web-browser entitlement 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if the alternative browser was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

What breaks? 🔗

As you see, all the cases mentioned above lead to the same result, a new tab in your current default browser. While simple to understand, there are a number of things that now break.

Push API 🔗

The Push API was described in the article Web Push for Web Apps on iOS and iPadOS published on February 16, 2023. It's important to note the caveat: "A web app that has been added to the Home Screen can request permission to receive push notifications as long as that request is in response to direct user interaction — such as tapping on a 'subscribe' button provided by the web app." Since Home Screen web apps are no longer available in the EU, the Push API is effectively broken for EU users.

Badging API 🔗

The Badging API was described in the article Badging for Home Screen Web Apps published on April 25, 2023. The important caveat here is: "The user must grant the app permission to display notifications before the badge will appear." Since the Push API is no longer exposed, the Badging API breaks as collateral damage.

Standalone mode 🔗

Running in standalone mode allows Web apps to look and feel like native apps without any browser UI. This was particularly useful for game streaming services like NVIDIA GeForce Now or XBox Cloud Gaming, but also just any other app that wants to make best use of the limited screen real estate. Even manually entering fullscreen mode isn't possible anymore, as Safari 17.4 "[f]ixed multiple issues by disabling support for the Fullscreen API on iOS."

Stored data 🔗

Home Screen Web apps ran in a different isolated context than regular in-tab Web apps. This means that if you were logged in to a Web app from the Home Screen, you need to log in again in the browser tab, and all previously stored data is gone. This includes any data stored in:

• IndexedDB
• LocalStorage
• Media keys
• SessionStorage
• Service Worker registrations and cache
• Origin private file system

Exclusion from storage eviction 🔗

Home Screen Web apps were exempt from Safari's 7-Day Cap on All Script-Writeable Storage, but now they aren't anymore. Unless you use a Web app regularly enough, its data will be evicted from storage. This also applies to WKWebView-based browsers that have the com.apple.developer.web-browser entitlement:

Additionally in iOS 14.0 and macOS Big Sur, Intelligent Tracking Prevention (ITP), is enabled by default in all WKWebView applications.

[…]

Note that applications taking the new Default Web Browser entitlement always have a user control in Settings to disable ITP[.]

Multiple installs of the same Web app 🔗

iOS has supported multiple installs of the same Web app since the very beginning. Apple highlighted the ability for people to install any Web app more than once on their device, which can indeed be useful:

When adding a web app to the Home Screen, users are given the opportunity to change the app's name. iOS and iPadOS 16.4 combine this name with the Manifest ID to uniquely identify the web app. That way, a user can install multiple copies of the web app on one device and give them different identities. For example, notifications from "Shiny (personal)" can be silenced by Focus while notifications from "Shiny (work)" can be allowed. If the user gives their favorite website the same name on multiple devices, Focus settings on one device will sync and apply to the others as well.

Technically, this still works and people can add apps more than once, but because the apps now open in the same browser context, the multiple installs people used, for example, to sign in to different accounts, are now effectively useless.

What now? 🔗

The DMA opened the door for browser vendors to ship their own engines on iOS. This would mean that push notifications, app icon badges, storage management, storage eviction, and fullscreen/standalone mode could be decoupled from the previous model of creating a browser shell that until now needed to embed a WKWebView and at best could inject JavaScript to expose APIs that WKWebView didn't support natively to Web apps. The process of Using alternative browser engines in the European Union is going to be maximally painful, as Alex Russell points out and as Mozilla has gone on the record to say.

According to the Financial Times and The Verge, the European Commission is on the case. This is what spokesperson Lea Zuber shared with both publications:

We are indeed looking at the compliance packages of all gatekeepers, including Apple.

In that context, we're in particular looking into the issue of progressive web apps, and can confirm sending the requests for information to Apple and to app developers, who can provide useful information for our assessment.

An open letter to Tim Cook 🔗

The good folks from Open Web Advocacy have written an open letter addressed at Tim Cook in which they outline why Sabotaging Web Apps Is Indefensible. As an immediate action, I would very much encourage you to go 🖋️ sign it. I did. And now back to my third morning coffee and my cats.

This post appeared first on https://blog.tomayac.com/2024/02/28/so-what-exactly-did-apple-break-in-the-eu/.

Disclaimer, just in case… 🔗

I work for Google on the Chrome Developer Relations team. But for this post, I want to make it super duper clear that I'm speaking not on behalf of my employer and that all views and opinions expressed in this blog post are purely my own: Thomas Steiner's, the guy commonly known for his avatar with a green hat, but today in my pajamas having my second morning coffee. Oh, thanks for asking, the two cats are Lluna (yes, with double 'l', it means moon in Catalan) Norris, looking at the camera, and Skinny Norris, looking out of the window.

How I noticed 🔗

With this out of the way, it's time to dive in and answer the question of what exactly did Apple break in the EU? I'm physically located in the European Union and my iPhone has a German SIM card. On January 30, 2024, I sent the following toot with attached screenshot (cropped here):

Hope this is a bug in the beta, but opening previously installed Home Screen Web apps on iOS 17.4 (21E5184i) results in a prompt:

Open "Example app" in Safari. "Example app" will open in your default browser from now on.

Newly installed apps always open in the browser. There doesn't appear to be a standalone mode anymore.

Reported as FB13567834.

The toot that all the news outlets cited was the one from Mysk from February 1, 2024, that said:

🎬 Finally, iOS treats all browsers equally when it comes to PWAs. Previously, only Safari was able to install and run PWA apps. With iOS 17.4 beta in the EU, no browser can install PWA apps, even Safari. It seems PWAs have been disabled entirely.

Oh yes, when you set a third-party browser as the default browser and then you delete it, iOS sets Safari as the default browser. Watch this:

#iOS #Apple #DMA #EU #maliciouscompliance

youtu.be/AST12aDGf0Q

Then, on February 2, 2024, Tixie opened a WebKit bug titled "Bug 268643 - [iOS 17.4 Beta (21E5184k)] REGRESSION: PWA added to Home Screen are forced to open in Safari."

What does Apple say? 🔗

By now, you have probably heard that users in the EU don't have access to Home Screen web apps anymore. Here is Apple's statement in its full glorious detail:

To comply with the Digital Markets Act, Apple has done an enormous amount of engineering work to add new functionality and capabilities for developers and users in the European Union — including more than 600 new APIs and a wide range of developer tools.

The iOS system has traditionally provided support for Home Screen web apps by building directly on WebKit and its security architecture. That integration means Home Screen web apps are managed to align with the security and privacy model for native apps on iOS, including isolation of storage and enforcement of system prompts to access privacy impacting capabilities on a per-site basis.

Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user's camera, microphone or location without a user's consent. Browsers also could install web apps on the system without a user's awareness and consent. Addressing the complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps. And so, to comply with the DMA's requirements, we had to remove the Home Screen web apps feature in the EU.

EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change — that was made as part of the work to comply with the DMA — may have on developers of Home Screen web apps and our users.

These changes are iOS only! 🔗

The first important thing to note here is that this statement exclusively applies to iOS, but not iPadOS and not macOS. This works because Apple managed to convince the EU Commission that iPadOS and macOS are distinct core platform services. The relevant section of the DMA says:

Moreover, the Commission considers, in line with Apple's view, that iOS, iPadOS, macOS, watchOS, and tvOS constitute distinct CPSs [core platform services] within the meaning of Article 2, point (2), sub (f), of Regulation (EU) 2022/1925.

This means on iPadOS and macOS, everything will stay the same. You can still add Web apps to the Home Screen on iPadOS or the Dock on macOS, and they will open in standalone mode as they always did.

💡 Note: This article exclusively talks about Home Screen Web Apps, not bookmarks. According to Apple's documentation "Web developers have the option to create a manifest file (with its display member set to standalone or fullscreen) and serve it along with their website. If they do, that site becomes a Home Screen web app. Then, when you tap on its icon, the web app opens like any other app on iOS or iPadOS instead of opening in a browser. You can see its app preview in the App Switcher, separate from Safari or any other browser."

What happens on iOS? 🔗

Looking now at iOS. If…

1. you have an iPhone that runs (betas of) iOS 17.4 or later, and iff (if and only if)…
2. you are detected as being in the European Union (EU), you can still add apps to the Home Screen, but they will open in a regular new browser tab in your default browser.

How exactly Apple detects if you're in the EU isn't clear yet. It seems not to be based on the SIM operator, as some users claim they are affected even on SIM-less iPhones. Possibly IP geolocation as it doesn't require location access? Or maybe GPS for improved accuracy based on a system-level access grant? What about travelers in the EU from non-EU countries? I hope we will find out eventually. People started noticing an IDENTIFIABLE_REGION string in iOS 17.4 beta 1 (21E5184i) as early as January 25, 2024, but it was removed in the next beta.

💡 Note: Since iOS 16.4, apart from Safari, alternative browsers, too, have the ability to add apps to the Home Screen. Based on Apple's instructions, "if your app has the com.apple.developer.web-browser entitlement, the iOS share sheet can offer Add to Home Screen for an http or https webpage, creating a convenient link to a web app or bookmark. To allow someone to add the current webpage to the Home Screen, include the WKWebView instance in the activityItems array when you call init(activityItems:applicationActivities:) to create the UIActivityViewController."

There are different scenarios listed in the following.

You previously added an app to the Home Screen with Safari 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if Safari was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You previously added an app to the Home Screen with an alternative browser that has the com.apple.developer.web-browser entitlement 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if the alternative browser was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You newly add an app to the Home Screen with Safari 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if Safari was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

You newly add an app to the Home Screen with an alternative browser that has the com.apple.developer.web-browser entitlement 🔗

In this case, the app will open in a regular new browser tab in your current default browser. It doesn't matter if the alternative browser was your default browser when you added the app to the Home Screen, it will still open in your current default browser.

What breaks? 🔗

As you see, all the cases mentioned above lead to the same result, a new tab in your current default browser. While simple to understand, there are a number of things that now break.

Push API 🔗

The Push API was described in the article Web Push for Web Apps on iOS and iPadOS published on February 16, 2023. It's important to note the caveat: "A web app that has been added to the Home Screen can request permission to receive push notifications as long as that request is in response to direct user interaction — such as tapping on a 'subscribe' button provided by the web app." Since Home Screen web apps are no longer available in the EU, the Push API is effectively broken for EU users.

Badging API 🔗

The Badging API was described in the article Badging for Home Screen Web Apps published on April 25, 2023. The important caveat here is: "The user must grant the app permission to display notifications before the badge will appear." Since the Push API is no longer exposed, the Badging API breaks as collateral damage.

Standalone mode 🔗

Running in standalone mode allows Web apps to look and feel like native apps without any browser UI. This was particularly useful for game streaming services like NVIDIA GeForce Now or XBox Cloud Gaming, but also just any other app that wants to make best use of the limited screen real estate. Even manually entering fullscreen mode isn't possible anymore, as Safari 17.4 "[f]ixed multiple issues by disabling support for the Fullscreen API on iOS."

Stored data 🔗

Home Screen Web apps ran in a different isolated context than regular in-tab Web apps. This means that if you were logged in to a Web app from the Home Screen, you need to log in again in the browser tab, and all previously stored data is gone. This includes any data stored in:

• IndexedDB
• LocalStorage
• Media keys
• SessionStorage
• Service Worker registrations and cache
• Origin private file system

Exclusion from storage eviction 🔗

Home Screen Web apps were exempt from Safari's 7-Day Cap on All Script-Writeable Storage, but now they aren't anymore. Unless you use a Web app regularly enough, its data will be evicted from storage. This also applies to WKWebView-based browsers that have the com.apple.developer.web-browser entitlement:

Additionally in iOS 14.0 and macOS Big Sur, Intelligent Tracking Prevention (ITP), is enabled by default in all WKWebView applications.

[…]

Note that applications taking the new Default Web Browser entitlement always have a user control in Settings to disable ITP[.]

Multiple installs of the same Web app 🔗

iOS has supported multiple installs of the same Web app since the very beginning. Apple highlighted the ability for people to install any Web app more than once on their device, which can indeed be useful:

When adding a web app to the Home Screen, users are given the opportunity to change the app's name. iOS and iPadOS 16.4 combine this name with the Manifest ID to uniquely identify the web app. That way, a user can install multiple copies of the web app on one device and give them different identities. For example, notifications from "Shiny (personal)" can be silenced by Focus while notifications from "Shiny (work)" can be allowed. If the user gives their favorite website the same name on multiple devices, Focus settings on one device will sync and apply to the others as well.

Technically, this still works and people can add apps more than once, but because the apps now open in the same browser context, the multiple installs people used, for example, to sign in to different accounts, are now effectively useless.

What now? 🔗

The DMA opened the door for browser vendors to ship their own engines on iOS. This would mean that push notifications, app icon badges, storage management, storage eviction, and fullscreen/standalone mode could be decoupled from the previous model of creating a browser shell that until now needed to embed a WKWebView and at best could inject JavaScript to expose APIs that WKWebView didn't support natively to Web apps. The process of Using alternative browser engines in the European Union is going to be maximally painful, as Alex Russell points out and as Mozilla has gone on the record to say.

According to the Financial Times and The Verge, the European Commission is on the case. This is what spokesperson Lea Zuber shared with both publications:

We are indeed looking at the compliance packages of all gatekeepers, including Apple.

In that context, we're in particular looking into the issue of progressive web apps, and can confirm sending the requests for information to Apple and to app developers, who can provide useful information for our assessment.

An open letter to Tim Cook 🔗

The good folks from Open Web Advocacy have written an open letter addressed at Tim Cook in which they outline why Sabotaging Web Apps Is Indefensible. As an immediate action, I would very much encourage you to go 🖋️ sign it. I did. And now back to my third morning coffee and my cats.

This post appeared first on https://blog.tomayac.com/2024/02/so-what-exactly-did-apple-break-in-the-eu.md/.

The Lenovo ThinkVision P27h-20 screen I get from work is a decent 27 inch screen. Coming from the Retina screen of my laptop that I worked on for a long time, I was initially (and still am) not impressed by the resolution of 2560×1440. It took some time to get used to the low resolution on such a big screen, but it gets the job done…

My biggest gripe with the screen was that it just randomly turned off when connected to my MacBook Pro in clamshell mode. I finally found the culprit after combing through the Console system logs for any trace for the longest time. I found out that the MacBook Pro thought the power was changing from grid to battery and vice versa (all while being constantly on-power), and whenever it did that, the screen would turn off.

The solution was to disable the "Smart Power" option in the screen's settings. According to the manual, the "Smart Power" option does the following:

Smart Power intelligently distributes power to connected USB and USB Type-C devices, maximizing power supply efficiency while also reducing overall consumption.

Turns out, it wasn't so smart after all. I saw it range between 65W and 90W, but after turning the option off, the laptop gets a constant 65W, all my USB-C devices still work, and I'm happy to report that the screen no longer randomly turns off. This is the blog post I wish I had found when I was looking for a solution, so I hope it helps someone else.

This post appeared first on https://blog.tomayac.com/2024/02/lenovo-p27h-20-randomly-turns-off/.

Background 🔗

The WebAssembly meetup in Munich has a history that reaches back to 2018. After a long Covid-related hiatus and a lack of organizers to pick up the ball again, A Wasm New Year! was the first event under the new organizing team. Google always had a strong presence at the events, so to continue the tradition I happily agreed to offer a talk at the first post-Covid meetup.

Talks 🔗

Compiling to and Optimizing Wasm with Binaryen 🔗

Speaker: Thomas Steiner

In the first half of the talk, I showed at the example of a toy programming language that I called ExampleScript how to write a compiler with Binaryen that compiles the toy programming language to WebAssembly. In the second half, I then demonstrated various optimization techniques in Binaryen and ways to use them from JavaScript with Binaryen.js and from the command line with tools like wasm-opt and wasm-merge.

Resources:

• Compiling to and optimizing Wasm with Binaryen

LLM inference with WebAssembly 🔗

Speaker: Sven Pfennig

In this talk, Sven showed three ways of how Wasm helps with interacting with large language models (LLM): in the browser, on the command line, and in the cloud. His running example was the task of creating a bedtime story from the PAW Patrol ecosystem for his daughter. First, the speaker demonstrated WebLLM running variants of Llama 2 and Mistral-7B right in the browser. He mentioned the challenges of keeping large models cached, and also showed how these models have trouble with seemingly simple tasks like creating a list of the PAW Patrol members, where the model would plain hallucinate a member that never existed. Second, Sven showed how to use the run-llm.sh script to get an LLM running on-device with WasmEdge. He noted the usefulness of this approach to mock an OpenAI API response due to the compatibility of the responses. Finally, he showed Fermyon's Spin solution to create serverless WebAssembly apps, run them locally, and finally deploy them to the Fermyon cloud.

Resources:

• WebLLM
• run-llm.sh script
• Fermyon Spin

Observations 🔗

There was huge interest for Wasm on the server. People were particularly curious about WASI, the WebAssembly System Interface. It's an API in the process of standardization that provides access to several operating-system-like features, including files and filesystems, Berkeley sockets, clocks, and random numbers. (There's also a proposal for wasi-nn, a WASI API for performing ML inference modeled closely after WebNN.)

The company that hosted the meetup, Liquid Reply, is pitching WebAssembly as a solution for creating production-grade Wasm apps on Kubernetes and hosting a workshop titled Create Production-Grade Wasm Applications on Kubernetes at the upcoming Wasm I/O conference in March 2024 (where Thomas Nattestad and I are going to present on WebAssembly at Google, alongside with Kevin Moore, who's going to present Flutter, Dart, and WASM: Shipping a new model for Web applications).

I also got a fair amount of questions on WasmGC and what it means for compiling new programming languages to Wasm. The strategy of writing a higher-level article (WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome) and a lower-level article (A new way to bring garbage collected programming languages efficiently to WebAssembly) really paid off and I could point developers at either of the two, dependent on how deep they wanted to go.

This post appeared first on https://blog.tomayac.com/2024/01/17/a-wasm-new-year/.

Background 🔗

The 2023 edition of the World Wide Web Consortium (W3C) Technical Plenary and Advisory Committee (TPAC) meeting took place from September 11 to 15 in the Meliã hotel in Seville, Spain. The hotel is located right next to the Plaza de España, a major Spanish tourist destination. The setup of the meeting was hybrid, and on site, strict Covid precautions were enforced, even though the pandemic was declared to be "over". Despite these methods, several people caught it. This is my personal report as a representative of the Chrome DevRel team at Google.

Monday, Tuesday 🔗

Web Applications Working Group 🔗

I attended the Web Applications Working Group meetings on Monday and Tuesday. After a quick rundown of all the APIs in scope for the working group, the first topic was the Screen Orientation API, which was mostly driven by questions and improvement proposals the WebKit folks had after implementing it.

Next, the group discussed the Badging API, which is only available after installation, and browsers differ on whether they make the API detectable when the app is running in a tab.

An interesting corner case was debated in the context of the joint meeting with the Devices and Sensors Working Group. Apple can't join the group due to its unwillingness to implement some of the APIs and the sheer volume of proposals the team would have to review. The workaround is shared deliverables, where the APIs that there is agreement on get cross-delivered by a working group Apple is part of.

Following this, we talked about whether the Screen Wake Lock API should use transient or sticky activation.

The group made no progress on François Beaufort's suggestion for a Screen Brightness API.

On the topic of DeviceOrientation API vs. Generic Sensor API, the soft-conclusion was that the new API provides not enough advantage over the existing API. There's still disagreement about whether using the API should require a permission, which is mostly used for fraud detection to determine if a real user is holding a device.

For the Geolocation API, most discussion circulated around limiting its precision by encouraging more coarse data. On the opposite side, there's also still the open question of floorLevel data, which Safari exposes, but which isn't standardized. The group briefly discussed a toJSON() method for geolocation results, but it probably would be a breaking change due to instanceof checks. The background geolocation discussion was taken over repeatedly by trolls, which made proper discussion partly impossible. It's a solve-worthy problem, albeit it's a heated space. Geolocation Sensor had promises but we're not sure it's worth bringing this over, since the callback can easily be wrapped.

There was a joint meeting with the Internationalization Working Group to discuss long-standing open questions regarding translations of the Web App Manifest were investigated, which resulted in a potential solution. I foresee challenges when looking at the "shortcuts" member.

Notes and resources 🔗

• WebApps WG TPAC 2023 Meeting (Day 1)
• WebApps WG TPAC 2023 Meeting (Day 2)

Web Platform Incubator Community Group 🔗

On Monday afternoon, I switched over to the Web Platform Incubator Community Group (WICG) meeting. The topics I was interested in were Low Level Device APIs and First Party Sets (now Related Website Sets).

In the first part, Vincent Scheib presented on low level device APIs. Firefox has rolled out Web MIDI access based on an ad-hoc extension, which didn't seem it would convince Apple people. Apple also had doubts whether a permission prompt would be enough for people to understand that devices can be abused to circumvent the same-origin model. Reilly Grant outlined that Chrome stopped tying WebUSB to websites in an attempt to keep devices usable, even if the original website disappears.

For First Party Sets, there are currently only a few entries in the First Party Sets list, following the Submission Guidelines. It's rolling out to Chrome slowly. Other browser vendors do not implement First Party Sets at the moment.

On Tuesday, the big topic was installable web apps where Dan Murphy presented our existing solutions around Launch Handling. Marcos from Apple and Olli from Mozilla questioned the queue model vs. an event model and suggested to replace LaunchParams with DataTransferItem. Apple noted that a launch handling feature is something that they would probably need.

Apple's questioning of Chrome's established solution caused me to raise a meta question: Chromium already asked for input years ago and got no meaningful feedback and then shipped a solution that was proven to be successful. Now other vendors are interested, but want to change the fundamental design (and perhaps together we can all agree on a better design). What is the process here? Are we as Chrome supposed to unship ours?

Sangwhan Moon provided the Technical Architecture Group (TAG) perspective that Chrome makes sure other vendors provide input before Chrome ships. Chrome can't wait until vendors have an active interest. The group agreed to discuss next steps.

Diego from Microsoft then presented the Install API proposal. There was general interest in a solution, but a lot of skepticism when it comes to cross-origin installations, which would be an important use case for app stores or search engines.

The group further discussed the standardization of [iOS' proprietary navigator.standalone](https://github.com/w3c/manifest/issues/1092).

After that, we looked at the update algorithm discussed at the last TPAC and confirmed an update token would be the way to go.

The group briefly touched upon isolation of installed apps from the running browser context and the challenges it introduces with OAuth etc.

Next was protocol handling which Apple mostly opposed, window controls overlay and tabbed application mode which Apple was neutral-ish to, and my app menu proposal which Apple committed to coming up with a proposal for. Mozilla notably was in the room, but had no opinion on almost all topics close to PWA.

Apple then dropped a proposal for declarative push notifications. I filed a number of questions to the proposal.

Notes and resources 🔗

• Web Apps and Handling Data for TPAC (public)
• WICG TPAC 2023 Low Level Device APIs (2022 TPAC Device APIs)
• TPAC 2023 - Web Platform Incubator CG (WICG) - Isolated Web Apps - Notes
• First Party Sets ([Public] TPAC 2023: Related Website Sets (fka First-Party Sets))
• Web Install API TPAC 23 discussion

Wednesday 🔗

Wednesday was the breakout session day. As always, there were some sessions that I wish I could have attended, but due to scheduling conflicts I couldn't. Below is the list of the sessions I attended.

Accelerating the Web performance by compiling Javascript code to WASM 🔗

This session introduced JWST, a JavaScript to WebAssembly static translator (compiler) co-developed by Huawei and a professor from a university in Beijing, after claiming the (somewhat [citation needed]) problem of slowness of JavaScript being a problem for web apps and the lack of DOM access of Wasm as a major challenge. The presented compiler in their example converted a ~1.6MB JavaScript app (which is already big) into a >20MB Wasm app that under certain conditions slightly outperformed the JavaScript solution in their benchmark. I asked for more details about the compiler, but there wasn't any and the Huawei representatives said they weren't entirely sure about open-sourcing it. As it stands, my current evaluation of the solution is that it's technology feasibility demonstration at best.

Notes and resources 🔗

• Minutes
• Slides web for apps
• Slides for JWST

Page Embedded Permission Control (Permission Element) 🔗

In this session, the Chrome team introduced our current thinking of a permission element. The reaction from both Apple and Mozilla was that they both "don't immediately hate it". Many questions remain to be answered, mainly around how this would deal with multiple permissions, whether it should allow blocking permissions, the spoofability of its UI and whether that poses a risk, the customizability of its UI, and how revoking permissions would look like with it.

Notes and resources 🔗

• TPAC Permission Control (public)
• (public) Page Embedded Permission Control (Permission Element) - TPAC 2023 Breakout

The Future of Powerful APIs on the Web Platform 🔗

This TAG-initiated session stated the problem of powerful APIs on the Web, leading to permission fatigue and browsers simply not implementing certain APIs as a consequence, and motivated something like an extended trust mode for the Web. Sangwhan Moon said that without all browser vendors agreeing, the situation would not improve. Mozilla sort of soft-excluded the browser from the effort by stating that they were not thinking of messing with the origin model and to not assume that all capabilities were on the table. They also said as a community, we shouldn't let envy of native capabilities drive this.

Notes and resources 🔗

• The Future of Powerful APIs on the Web Platform
• Powerful APIs TPAC 2023 Breakout minutes

Privacy Principles 🔗

This session introduced the privacy principles jointly developed by TAG and Privacy Interest Group (PING) and solicited feedback from the persons in the room. The document is currently in wide review and seeks to be both aspirational and practical. Each member of the author group outlined their favorite sections of the document, like data minimization, device owners and administrators, or execution context. I asked about a conscious opt-in for objectively hard to understand things like requestStorageAccess() to which the answer was to abstract as much as possible in the permission prompt.

Notes and resources 🔗

• Slides
• Minutes

The cross-browser future of Installable Web Apps 🔗

This was a session I had organized together with Apple, Microsoft, and Intel. We discussed a number of approaches to installability taken by the various browsers, including new surfaces like sidebars and widgets—a currently proprietary approach based on Microsoft's Adaptive Card format. Of special interest was whether criteria should be required before a Web app can be installed. Chrome talked about the no longer required service worker. Apple insisted no requirements at all should be made, not even a title or icon. Apple's requirements for installable experiences are focused on ensuring consistent experiences. Users should know exactly where to go in their device settings to, for example, turn off Web push notifications, which require installation on iOS. We ended talking about extensions and whether they should be exposed in installed apps. Currently, Chrome and Edge expose extensions, Safari doesn't.

Notes and resources 🔗

• The cross-browser future of Installable Web Apps
• The cross-browser future of Installable Web Apps

Installing Web Apps 🔗

This was again a deep-dive in Microsoft's Web Install API proposal. Many points or arguments were already made in the WICG session on Tuesday (same notes document as for the breakout session). A noteworthy new point was the question if something like sidebar apps should be supported in a sense that a PWA would be able to express it would like to be installed to the sidebar. Apple said the baseline assumption of this API should not be that of an app store; the API should be useful in itself. If stores are involved, how would stores know if an app was already installed through another store or mechanism? Could getInstalledRelatedApps() be the solution for this? Another point raised was the trackability of installs, so stores could know if an installation was triggered by them, and apps what store an install came from. Finally, we discussed double prompting, first a bootstrap prompt whether a store may install apps in general, and then a concrete prompt to install a given app.

Notes and resources 🔗

• Minutes

Thursday 🔗

Devices and Sensors 🔗

I spent Thursday in the Devices and Sensors Working Group meeting. The first part of the day was occupied by a charter discussion between Philippe Le Hégaret from the W3C. The core question that was discussed was cross-deliverables between the Web Apps WG and the Devices and Sensors WG, since Apple can't commit to joining the Device and Sensors WG but is interested in some of the things the group is working on.

Next, we looked at the privacy principles and how they are applied by some of the specs. Marian Harbach briefly presented the permission element.

In suite, Intel talked about testability improvements they made around WebDriver.

Regarding Generic Sensors, we made a resolution to ensure Generic Sensor-based specs have mitigations normatively defined for factory calibration device fingerprinting, matching existing normative mitigations in the DeviceOrientation Events spec.

After that, we went through all the APIs in scope of the working group and looked at their status:

• Accelerometer, Gyroscope, and Magnetometer, all with no issues.
• Orientation Sensor and DeviceOrientation Events in the context of spatial audio, referring to WebXR as the better home for the use case.
• Ambient Light Sensor with going through existing use cases.
• Proximity Sensor with no issues.
• Geolocation Sensor where we went through the existing use cases for background geolocation and geofencing again.
• Screen Brightness API with no updates since Apple's negative feedback on an imperative API and after François Beaufort's proposal for an element attribute for increasing the screen brightness.
• Screen Wake Lock API with some address-worthy implementer feedback from Apple.
• System Wake Lock API with a discussion of use cases.
• Contact Picker API with no updates.
• Battery Status API which might be turned into a user preference media feature.

Next, Intel gave a device market overview followed by an implementation overview including compelling use case demonstrations for the Device Posture API. Fine-grained angle information was removed from the spec due to privacy concerns.

In the following, Intel continued on presenting on the Compute Pressure API, with a special focus on cross-site tracking mitigations through randomization that were proven to be effective in experiments, plus showing future extensions for the API like memory stalls and an "it's you" hint when the current process is responsible for CPU usage peaks.

The day ended with a look at the Geolocation API, which is mostly stable but could add improvements around encouraging more coarse location access.

As a meta remark, I feel like as a working group, we didn't achieve much new things compared to last year, mostly due to a lack of cross-implementer support for some of the APIs like the generic sensor APIs, and only a limited appetite to move on with things vendors at least partially agree on like screen brightness or ambient light sensor.

Notes and resources 🔗

• Minutes

Friday 🔗

WHAT Working Group 🔗

On Friday, I saw an interesting proposal for a headinglevelstart attribute that would allow authors to embed content with a heading structure into another context with an already existing heading structure, while overall correctly nesting both heading structures. This was mostly driven by GitHub, who embedREADME.md files into repository homepages and who wish to adjust heading levels accordingly.

Next, a focus navigation start point proposal was brought forward, which would allow to set the start point for the next focus point (which is not the same as the focus). Again this was driven by GitHub, who wanted to make the file tree fully keyboard-navigable.

Noteworthy was also a proposal for an Observable API presented by Dominic Farolino , which would allow for more convenient event handling scenarios and that was greeted with great interest.

Notes and resources 🔗

• Minutes: WHATWG session
• Observable API Presentation TPAC 2023

Web Platform Incubator Community Group 🔗

In the afternoon, I attended Web Incubator Community Group (WICG) sessions focused on the Accessibility Object Model (AOM), the Shape Detection API, and the File System.

Unfortunately the AOM session was a little confusing and it was not entirely clear what the status of the AOM was and which parts of it are cross-browser vs. abandoned. The AOM explainer contains many abandoned sections and the AOM spec is just a barebones skeleton, plus the demo doesn't work (anymore).

For the Shape Detection API, there's some interest from Apple to implement this. They raised questions about batch processing and synchronization challenges with video, which would likewise apply to blurring. I pointed at my demo that solves this with MediaStreamTrack Insertable Media Processing using Streams. Apple was also worried about the Chrome-specificity of the test suite and the future venue of the proposal, hinting it could be the WebML WG. As a final point, I noted that Apple's implementation works, but only on the main thread and not in workers. This is a known issue and "for reasons", according to Apple.

The File System Access session proposed by Austin Sullivan unluckily saw no attendance from Apple or Mozilla, so the meeting was adjourned since it would have been Googlers preaching to Googlers (and Google Developer Expert Christian Liebel).

Notes and resources 🔗

• Minutes
• [TPAC 2023] WICG File System

Web App Security Working Group 🔗

On the end of the day, I crashed the Web App Security WG meeting and saw Mike West's proposal for purposeful permissions. I made the point for aligning with other efforts in this area in an issue, namely the W3C MiniApp Manifest and Isolated Web Apps permissions.

Notes and resources 🔗

• Minutes

Meta observations 🔗

Covid measures 🔗

Covid measures were strictly enforced during the indoor sessions with a masking mandate and encouraged daily testing. All the breaks and lunches were outside or outside-ish (partially in a well-vented tent). After hours at dinners and drinks at the hotel bar, everyone partaking in those activities took their masks off. There were, I think, around 15 documented cases of infections.

In-person event 🔗

It was really, really great to be able to do in-person events again. While the group meetings worked pretty well with remote attendance (both from across the world, or from the conference hotel if you caught Covid), the famous hallway track and spending time with people at dinner or after-hours drinks is just not replaceable by video conferencing technology.

Food 🔗

Food was boxed lunches with the now infamous soggy potato chips and each day a variety of pre-packed industrial sandwiches. It felt wasteful, since there was a lot of food in a lot of packaging. Maybe a buffet-style lunch would have been better. There was typically an early dinner train, which ended up in one of the tourist trap-ish restaurants in old town that open early compared to local Spanish dinner times. My food quality indicator was always to check the bread: if it's plastic-sealed, the food will be fine; if it's fresh, it will be amazing.

Coffee was available in the breaks, and either horrible if you got the milk directly from the machine, or great if you got the milk separately from a waiter.

Google attendance 🔗

There were (again) a lot of people from Google in attendance. This year, we made a concerted effort to highlight more closely what team we represent, for example, Google Chrome, rather than all of Google. More than once, I saw other people mirror this, and introduce themselves as "from the X team at Y".

This post appeared first on https://blog.tomayac.com/2023/09/25/w3c-tpac-2023-trip-report/.

Executive summary 🔗

With macOS Sonoma, Apple goes all-in on the concept of installable web apps. They're highly integrated in the overall macOS experience and don't give away their web roots by not showing any Safari UI at all.

Testing environment 🔗

Tested on macOS Sonoma 14.0 Beta (23A5257q) with Safari version 17.0 (19616.1.14.11.11). It probably doesn't matter, but the testing device was a 13-inch, M1, 2020 MacBook Pro.

Install experience 🔗

On macOS Sonoma, you can add a website—any website, not just apps with a manifest—to your Dock. Go to the Share icon and click Add to Dock, or use the menu item File > Add to Dock.

Adding an app via the Share icon.

Adding an app via the File menu.

You can adjust the name and icon if desired. The URL is the URL you're on for pages without a manifest, or the start_url for pages with a manifest. It can't be changed. For pages without an icon, Safari will create a fallback icon based on the first letter of the page's title.

👀 Observation: Unlike on iOS/iPadOS, you can't add the same app twice, unless you rename it.

App name and icon are adjustable, the URL is not.

The web app icon then appears in your Dock. Maskable icons are supported, and the typical macOS squircle shape is respected. Closing all windows of an app leaves the app running, aligned with macOS UX paradigms.

👀 Observation: Unlike on Chrome, the app doesn't launch immediately and "morph" from in-tab to in-app, but instead you remain on the tab and need to launch the app manually.

Web app added to the Dock.

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

Launch experience 🔗

The out-of-the box launch experience of web apps is fantastic. Nowhere does it give away that this is a web app. For apps with a manifest, there's no Safari UI whatsoever, and the expectation is that such apps are single-page apps that provide their own navigation controls. If an app is well made, lay persons probably wouldn't be able to tell that something is a web app.

Web app running without any Safari UI.

👀 Observation: 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. "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".

👀 Observation: Web Inspector (DevTools) is blocked, even with the Show features for web developers checkbox checked. There's no Develop menu item nor can you right-click and Inspect Element. This looks like a conscious decision.

👀 Observation: Extensions don't run and likewise aren't displayed. Also probably a conscious decision.

👀 Observation: Same-origin (in-scope) links are handled in-app, cross-origin (out-of-scope) links open in the default browser. A notable exception are OAuth flow links, which are handled in-app based on a heuristic.

If a user navigates to an already installed app in Safari, a prompt is displayed that invites the user to Open in web app.

Prompt inviting the user to Open in web app.

macOS integration experience 🔗

Web apps on Mac let you focus on the websites you use all the time, separate from the rest of your browsing. Like all Mac apps, web apps work great with Stage Manager, Mission Control, and keyboard shortcuts like Command + Tab. Web apps can be opened from the Dock, Launchpad, and Spotlight Search.

Multitasking experience.

Spotlight search experience.

Launchpad experience.

Stage Manager experience.

All web apps have an About dialog.

Settings and permissions 🔗

Web apps work with AutoFill credentials from iCloud Keychain and from third-party apps that have adopted the Credential Provider Extension API. Users can grant permission to a web app to use their camera, microphone and location in the same way they grant such permissions to other Mac apps through system prompts and the Privacy & Security section of System Settings.

System settings with Camera permissions.

Web apps on Mac support web push, badging, and all the usual web standards implemented by WebKit, just like web apps on iOS and iPadOS.

👀 Observation: There seems to be a bug where the hosting Web App appears as the app requesting the Notifications permission. Notifications then work as expected, though, including using the correct icon.

Notifications permission prompt with the wrong app name and icon.

Web apps have their own Settings dialog. In General, the app name and icon can be changed and navigation controls can be toggled on or off. The theming behavior of the title bar can be changed, too.

👀 Observation: Navigation controls are toggled off when there's a manifest with "display": "standalone". In all other cases, even if a manifest exists but with a different "display" mode,

Web app Settings dialog on the General tab.

👀 Observation: There's currently a bug where web apps don't correctly report matchMedia('(display-mode: standalone)'). Added to the Dock web apps think they run in a tab.

With navigation controls enabled, there's an Open in Safari icon in the upper right corner. Despite its label, it actually respects the user's default browser.

Open in Safari icon.

Web pages get navigation affordances in the form of a back and forward button. There's no reload button.

Back and forward buttons.

👀 Observation: With navigation controls toggled to off, the title of the web app sourced from the manifest is not shown. With navigation controls toggled to on, the title sourced from the <title> is shown.

👀 Observation: When you right-click, there's a context menu with Reload or Back and Reload. This works independent from whether navigation controls are toggled on or off.

The Privacy tab allows the user to clear website data and links into the Privacy & Security Settings of the System Settings app.

Web app Settings dialog on the Privacy tab.

Technical analysis 🔗

(See comment #7 of Chromium bug 1451667 for the full details.)

All apps are stored in ~/Applications/. The package contents of each apps are:

• a _CodeSignature folder with code signature metadata
• a Resources folder with just the app icons as a single ApplicationIcon.icns file
• an Info.plist file.

The package contents of an app.

The Info.plist file interestingly contains an XML version of key parts of the manifest and metadata about the app.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>CFBundleIconFile</key>
    <string>ApplicationIcon</string>
    <key>CFBundleIdentifier</key>
    <string
      >com.apple.Safari.WebApp.svgco.de.53298B34-AF7F-4074-9CA9-1EE46B7E3E83</string
    >
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>SVGcode</string>
    <key>CFBundlePackageType</key>
    <string>AAPL</string>
    <key>CFBundleShortVersionString</key>
    <string>1.0</string>
    <key>CFBundleSupportedPlatforms</key>
    <array>
      <string>MacOSX</string>
    </array>
    <key>CFBundleURLTypes</key>
    <array>
      <dict>
        <key>CFBundleURLSchemes</key>
        <array>
          <string>x-webkit-app-launch</string>
        </array>
        <key>LSHandlerRank</key>
        <string>None</string>
      </dict>
    </array>
    <key>CFBundleVersion</key>
    <string>1</string>
    <key>LSMinimumSystemVersion</key>
    <string>14.0</string>
    <key>LSTemplateApplication</key>
    <true />
    <key>LSTemplateApplicationParameters</key>
    <dict>
      <key>CFBundleIdentifier</key>
      <string>com.apple.Safari.WebApp</string>
      <key>TemplateAppUUID</key>
      <string>53298B34-AF7F-4074-9CA9-1EE46B7E3E83</string>
      <key>defaultarguments</key>
      <true />
      <key>teamIdentifier</key>
      <string></string>
    </dict>
    <key>Manifest</key>
    <dict>
      <key>description</key>
      <string
        >SVGcode is a Progressive Web App that lets you convert raster images
        like JPG, PNG, GIF, WebP, AVIF, etc. to vector graphics in SVG
        format.</string
      >
      <key>display</key>
      <string>standalone</string>
      <key>icons</key>
      <array>
        <dict>
          <key>purpose</key>
          <string>maskable</string>
          <key>sizes</key>
          <string>1024x1024</string>
          <key>src</key>
          <string>https://svgco.de/favicon.png</string>
          <key>type</key>
          <string>image/png</string>
        </dict>
        <dict>
          <key>purpose</key>
          <string>any</string>
          <key>sizes</key>
          <string>150x150</string>
          <key>src</key>
          <string>https://svgco.de/favicon.svg</string>
          <key>type</key>
          <string>image/svg+xml</string>
        </dict>
        <dict>
          <key>purpose</key>
          <string>monochrome</string>
          <key>sizes</key>
          <string>150x150</string>
          <key>src</key>
          <string>https://svgco.de/favicon-bw.svg</string>
          <key>type</key>
          <string>image/svg+xml</string>
        </dict>
      </array>
      <key>name</key>
      <string>SVGcode</string>
      <key>scope</key>
      <string>https://svgco.de</string>
      <key>short_name</key>
      <string>SVGcode</string>
      <key>start_url</key>
      <string>https://svgco.de/</string>
      <key>theme_color</key>
      <string>#ffffff</string>
    </dict>
    <key>WKPushBundleMetadata</key>
    <dict>
      <key>manifestId</key>
      <string>https://svgco.de/</string>
    </dict>
  </dict>
</plist>

Similar to iOS/iPadOS, web apps run in the context of a separate process called Web App.app, which resides in /System/Volumes/Preboot/Cryptexes/App/System/Library/CoreServices/Web App.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.

The Web App.app app in Finder.

Each web app runs as its own process of kind Web, accompanied by a number of helper processes of kind Apple. They can all be seen in Activity Monitor.

Activity Monitor showing all processes associated with a web app.

Wish list for Apple 🔗

(Also see Most wanted PWA features on iOS/iPadOS/macOS Safari.)

• Add support for the File System Access API, so users can install apps and edit files directly, rather than opening them and then downloading a copy. [🧭 231706]
• Add support for DataTransferItem.getAsFileSystemHandle(), so users can drag and drop files into web apps and edit the file. [🧭 257792]
• Add support for the Web Share Target API, so you can share data to installed web apps. [🧭 194593]
• Let web apps programmatically trigger the Add to Dock flow, since the Share icon and the File menu install ways are hard to discover. [🧭 255716]
• Add support for the Window Controls Overlay API, so the gorgeous current experience can be made even more gorgeous. [🧭 257782]

Spotify native app title bar experience.

Spotify web app title bar experience.

• Add support for the File Handling API, so web apps can open files from Finder by double click if the web app is registered as the default file handler for a given file type, or by right click and then Open with if the web app can handle a file type, but isn't the default file handler. [🧭 257783]
• Add support for the Launch Handler API, so web apps can decide how they want to handle launch events. [🧭 257785]
• Reflect the cookie-copying logic on iOS/iPadOS. It's a very frustrating experience if you have to log in twice, even more so if two-factor authentication is involved. [🧭 257786]
• Allow users to turn off the Open in web app prompt.

Recommendations for Chrome 🔗

• Better respect macOS' design paradigms. Currently web app icon handling looks not integrated and icon shapes are all over the place. The examples below are all web apps installed via Chrome.

Web app icon shapes installed from Chrome don't respect the squircle.

• Move the extension puzzle piece and the Window Controls Overlay chevron into the three dots menu. Web apps can look so much cleaner without both in plain sight.

Window Controls Overlay chevron and extension puzzle piece clutter the UI of Chrome-installed apps.

New Fugu API needs 🔗

With Chrome and Safari now allowing web apps to be installed on macOS, it would be fantastic if installed apps could respect macOS UX guidelines and populate the system-level menu. Ideally Apple and Google engage jointly on the corresponding Project Fugu 🐡 API request tracked in crbug/1295253.

Web app default menu.

Conclusion 🔗

Web apps in macOS Sonoma 14 Beta seamlessly integrate into the macOS experience, with no or very little visible Safari UI and with support for various operating system features. There is an enormous potential for web apps on macOS to succeed, and if Apple only works on a third of the items on my wish list, the potential is even bigger.

Related links 🔗

• News from WWDC23: WebKit Features in Safari 17 beta
• What's new in web apps

This post appeared first on https://blog.tomayac.com/2023/06/07/web-apps-on-macos-sonoma-14-beta/.

There's this old mantra that Cool URIs don't change that Tim Berners Lee has been championing since 1998. And in the subtitle of the linked document it says:

What makes a cool URI?
A cool URI is one which does not change.
What sorts of URI change?
URIs don't change: people change them.

And that's exactly what happened in my case: I changed them. Tim goes on later in the document:

Pretty much the only good reason for a document to disappear from the Web is that the company which owned the domain name went out of business or can no longer afford to keep the server running.

That latter part ("or can no longer afford to keep the server running") was me—a person, not a company—in my late, money-saving student days. At the time, I owned tomayac.de, and after making the switch to tomayac.com, I let go the .de domain after a while because I didn't want to pay for it anymore.

While I did make sure to redirect everything properly (that is, using a permanent 301 redirect), the problem really was that I had referenced the .de domain in my printed Master's thesis that I couldn't change and in which I wrote about a tool I built called REST Describe & Compile. And of course over the years I had accrued the occasional external link that I likewise couldn't control.

I think the .de domain was parked for a while gathering dust, until it was taken over by André Nowak who redirected it to a page on his site called Tomayac.de – REST Describe & Compile Tool. Many years passed…

For some nostalgic reason a couple of days ago, I decided to see if I could get my domain back. So I emailed André out of the blue based on the imprint of linux-abos.de and asked him how much it would cost to transfer tomayac.de back to me, and what happened next is just the nicest story.

André kindly offered to sell it back to me for a back link and the price he originally payed for the domain, that is 12€, plus 1€ for his tax advisor, since, turns out, domains are fixed assets. Before I even had a chance to pay him, he sent me the auth code. I ended up sending him 25€ as a thank you after successfully moving the domain to Google Domains.

Now all that remains is setting up DNS properly, get a certificate, set up an .htaccess, and all these things I'm not really good at and never know if I'm looking at the cached version from the DNS server or the live one, but I'll figure it out eventually and make all those cool URIs work again!

So for the back link, if you ever need to update the operating system on your smart phone, consider the page Linux auf dem Handy » Das Smartphone mit Linux updaten! and for the historical REST Describe and Compile content André created, read Tomayac.de – REST Describe & Compile Tool. Thanks again, André 🙏, for being the kindest person on the Internet last Wednesday.

This post appeared first on https://blog.tomayac.com/2023/04/18/getting-my-domain-tomayac-de-back/.

There's this old mantra that Cool URIs don't change that Tim Berners Lee has been championing since 1998. And in the subtitle of the linked document it says:

What makes a cool URI?
A cool URI is one which does not change.
What sorts of URI change?
URIs don't change: people change them.

And that's exactly what happened in my case: I changed them. Tim goes on later in the document:

Pretty much the only good reason for a document to disappear from the Web is that the company which owned the domain name went out of business or can no longer afford to keep the server running.

That latter part ("or can no longer afford to keep the server running") was me—a person, not a company—in my late, money-saving student days. At the time, I owned tomayac.de, and after making the switch to tomayac.com, I let go the .de domain after a while because I didn't want to pay for it anymore.

While I did make sure to redirect everything properly (that is, using a permanent 301 redirect), the problem really was that I had referenced the .de domain in my printed Master's thesis that I couldn't change and in which I wrote about a tool I built called REST Describe & Compile. And of course over the years I had accrued the occasional external link that I likewise couldn't control.

I think the .de domain was parked for a while gathering dust, until it was taken over by André Nowak who redirected it to a page on his site called Tomayac.de – REST Describe & Compile Tool. Many years passed…

For some nostalgic reason a couple of days ago, I decided to see if I could get my domain back. So I emailed André out of the blue based on the imprint of linux-abos.de and asked him how much it would cost to transfer tomayac.de back to me, and what happened next is just the nicest story.

André kindly offered to sell it back to me for a back link and the price he originally payed for the domain, that is 12€, plus 1€ for his tax advisor, since, turns out, domains are fixed assets. Before I even had a chance to pay him, he sent me the auth code. I ended up sending him 25€ as a thank you after successfully moving the domain to Google Domains.

Now all that remains is setting up DNS properly, get a certificate, set up an .htaccess, and all these things I'm not really good at and never know if I'm looking at the cached version from the DNS server or the live one, but I'll figure it out eventually and make all those cool URIs work again!

So for the back link, if you ever need to update the operating system on your smart phone, consider the page Linux auf dem Handy » Das Smartphone mit Linux updaten! and for the historical REST Describe and Compile content André created, read Tomayac.de – REST Describe & Compile Tool. Thanks again, André 🙏, for being the kindest person on the Internet last Wednesday.

This post appeared first on https://blog.tomayac.com/2023/04/18/getting-my-domain-tomayac-de-back/.

Cross Platform Software Frameworks 🔗

The other day, I came across Elk Native, a native version of the rather excellent, if early-stage, Mastodon Web client Elk. To be honest, I wondered why they would build a native version, if the Web client works so well. I downloaded the 7.8 MB Elk_0.4.0_macos_x86_64.dmg and immediately ran into Issue #74, that is, a blank screen.

To better understand the motivation behind the Elk Native developers, I tried the same for one of my apps, with different frameworks. This repository contains the same PWA, SVGcode, wrapped five times with different cross platform software frameworks.

Running the apps 🔗

SVGcode is included as a git submodule in each framework folder. To run the apps, you first need to build SVGcode, and then start the wrapper app. In each subfolder, run the following commands.

npm run build-svgcode
npm start

Included frameworks 🔗

• Electron.js ("Getting started" guide)
• NW.js ("Getting started" guide)
• Tauri ("Getting started" guide)
• Neutralinojs ("Getting started" guide)
• Gluon ("Getting started" guide)

Screenshots 🔗

• Electron.js
• NW.js
• Tauri
• Neutralinojs
• Gluon

Issues 🔗

⚠️ I'm a Web developer, not a desktop app developer. I simply followed the "Getting started" guides and may well be holding the frameworks wrong.

While I managed to get all apps to run, none of them worked perfectly out of the box, and there was always a strange error I could not explain. SVGcode works fine on Chrome, Safari, and Firefox when run in the standalone browsers. To see what's under the hood of the frameworks, I looked at the user agent data via DevTools.

// If `navigator.userAgentData` is available, use it.
copy(JSON.stringify(await navigator.userAgentData.getHighEntropyValues([
  "architecture",
  "bitness",
  "model",
  "platformVersion",
  "uaFullVersion" ,
  "fullVersionList",
]), null, 2));

// Else use the user agent.
copy(navigator.userAgent);

Electron.js 🔗

Clicking the Copy SVG button causes an Uncaught (in promise) ReferenceError: Cannot access 'P' before initialization. error.

{
  "architecture": "arm",
  "bitness": "64",
  "brands": [
    {
      "brand": "Not A(Brand",
      "version": "24"
    },
    {
      "brand": "Chromium",
      "version": "110"
    }
  ],
  "fullVersionList": [
    {
      "brand": "Not A(Brand",
      "version": "24.0.0.0"
    },
    {
      "brand": "Chromium",
      "version": "110.0.5481.100"
    }
  ],
  "mobile": false,
  "model": "",
  "platform": "macOS",
  "platformVersion": "13.3.0",
  "uaFullVersion": "110.0.5481.100"
}

NW.js 🔗

Clicking the Copy SVG button causes an Uncaught (in promise) ReferenceError: Cannot access 'P' before initialization. error.

{
  "architecture": "arm",
  "bitness": "64",
  "brands": [
    {
      "brand": "Not A(Brand",
      "version": "24"
    },
    {
      "brand": "Chromium",
      "version": "110"
    }
  ],
  "fullVersionList": [
    {
      "brand": "Not A(Brand",
      "version": "24.0.0.0"
    },
    {
      "brand": "Chromium",
      "version": "110.0.5481.97"
    }
  ],
  "mobile": false,
  "model": "",
  "platform": "macOS",
  "platformVersion": "13.3.0",
  "uaFullVersion": "110.0.5481.97"
}

Tauri 🔗

Clicking the Save SVG button does nothing.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)

Neutralinojs 🔗

Clicking the Open Image button does nothing. Clicking the Save SVG button does nothing.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)

Gluon 🔗

Fails with a RangeError Failed to execute 'createImageBitmap' on 'Window': The crop rect width is 0..

{
  "architecture": "arm",
  "bitness": "64",
  "brands": [
    {
      "brand": "Chromium",
      "version": "110"
    },
    {
      "brand": "Not A(Brand",
      "version": "24"
    },
    {
      "brand": "Google Chrome",
      "version": "110"
    }
  ],
  "fullVersionList": [
    {
      "brand": "Chromium",
      "version": "110.0.5481.177"
    },
    {
      "brand": "Not A(Brand",
      "version": "24.0.0.0"
    },
    {
      "brand": "Google Chrome",
      "version": "110.0.5481.177"
    }
  ],
  "mobile": false,
  "model": "",
  "platform": "macOS",
  "platformVersion": "13.3.0",
  "uaFullVersion": "110.0.5481.177"
}

Building the apps (incomplete) 🔗

I started looking into building the apps, but didn't get too far. Electron.js looks like it has the most developed toolchain, but when I ran electron-forge make, I ended up with a 332,1 MB executable called svgcode-electron.app that only showed a white screen, despite the electron-forge start development app working mostly fine.

To build the apps, run the following command in each subfolder. (So far I have only worked on Electron.js.)

npm run build

I didn't even look into the signing part, which is required for proper distribution.

Conclusions 🔗

I'm not sure what to make of this. To be honest, I didn't see anything that would be more compelling than just browsing to svgco.de, clicking Install, and be good. But then I obviously didn't tap into any of the native features that cross platform frameworks allow you to do. I only noticed how features that I get for free in the Web version, like Window Controls Overlay or File Handling were broken. But again, I may just be holding these frameworks wrong. For now, it was a worthwhile exercise, but I think I'll stick to the Web.

This post appeared first on https://blog.tomayac.com/2023/02/23/cross-platform-software-frameworks/.