Explore the integration of web technologies within your app. Discuss building web-based apps, leveraging Safari functionalities, and integrating with web services.

All subtopics
Posts under Safari & Web topic

Post

Replies

Boosts

Views

Activity

Did Instagram just blocked App Store Links?
Is anyone else seeing Instagram fail to open App Store links tonight? Started for me a few hours ago, iOS only. To rule out my own setup I put a bare App Store URL straight in my bio, and I also tapped the App Store links on a few competitors' sites. Same result every time: nothing happens, no error, no page. Same phone, same moment: Safari works, Facebook and YouTube work, TikTok fails. Has Instagram started blocking store links the way TikTok does? If so, it looks like we're back to telling people to tap the ⋯ menu and "Open in external browser" before they can install anything.
Topic: Safari & Web SubTopic: General
4
1
105
2h
Safari iOS 26.5.2: first navigation fails during HTTP/3 0-RTT; reload succeeds (FB23764937)
Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.
4
1
313
17h
Request Guidance on Apple Pay Web Push Provisioning Enablement for Issuer Program Post Content:
We are currently supporting an Apple Pay-enabled card program as an issuer/issuer processor and have successfully completed In-App Push Provisioning integration within our iOS application. The in-app flow is fully operational, including issuer-side cryptographic exchange and Mastercard MDES network tokenization. We are now looking to extend this integration to support Apple Pay Web Push Provisioning, allowing cardholders to add eligible cards to Apple Wallet directly from our web application. We would appreciate guidance on: -The process for enrolling in Apple Business Register (if required) -Enabling Web Push Provisioning for an issuer profile Required entitlements or provisioning certificates Any additional onboarding steps specific to issuer-level Web provisioning We understand that Web Push Provisioning requires issuer-level enablement beyond standard Apple Pay on the Web, and we would like clarification on the correct path to activate this capability. Thank you in advance for your guidance.
3
2
1.8k
3d
Possible increase in false positive “Fraudulent Website Warning” detections in Safari (2026)
Hello Apple engineers and fellow developers, Over the past few weeks I have noticed multiple reports from different developers whose legitimate websites have been classified by Safari as “Fraudulent Website Warning”, despite passing every major public security and reputation check. My websites appear to be affected by the same issue. Domains https://skvoz.net https://skvoz.org Both domains were registered on July 15, 2026. The Fraudulent Website Warning first appeared on July 22, 2026, only one week after registration. Both websites are legitimate services operated by our team. Neither website impersonates another brand, attempts to collect Apple IDs, banking credentials, passwords, or any other sensitive information through deceptive means. Extensive verification performed After the warning appeared, we performed a comprehensive technical and security review. Website security ✅ No malware detected ✅ No phishing content ✅ No unauthorized redirects ✅ No suspicious JavaScript ✅ No mixed-content issues ✅ HTTPS configured correctly ✅ Valid TLS certificates Infrastructure DNS configuration verified SSL certificate chain verified using OpenSSL Server responds correctly over HTTP/2 IPv4 and IPv6 connectivity verified Origin server behaves correctly Cloudflare configuration was thoroughly tested during troubleshooting and ultimately removed from the production setup to eliminate it as a possible cause Reputation checks We verified both domains and the hosting IP address using multiple public reputation services. Results were consistently clean. This included services such as: Google Safe Browsing Google Search Console VirusTotal URLVoid IP reputation databases None of them currently report malware, phishing activity, or any other security issues. Apple-specific actions We have already: submitted a Website Review request; contacted Apple Security via reportphishing @apple.com requesting a manual review. At the time of writing, the warning is still present. One unusual observation One particularly unusual observation is that both of our domains (skvoz.net and skvoz.org) received the warning independently. These are separate domains serving different purposes, yet both appear to have been classified in the same way despite passing the same technical and reputation checks. This made me wonder whether Apple’s reputation system may evaluate related domains or shared infrastructure together. I understand the internal implementation is not public, but I wanted to mention this observation in case it is useful during investigation. Similar reports While investigating this issue, I found several recent reports from other developers describing almost identical behavior. The common pattern is remarkably consistent: Safari displays Fraudulent Website Warning Chrome, Firefox and Edge open the website normally Google Safe Browsing reports the domain as safe VirusTotal reports no malware Google Search Console reports no security issues valid HTTPS certificates relatively new domains no explanation regarding what triggered the warning This suggests the issue may not be isolated to a single website. Questions I would greatly appreciate any guidance from Apple engineers. Does Safari rely solely on Google Safe Browsing, or does Apple maintain an independent reputation database for Fraudulent Website Warning? If Apple maintains its own reputation system, are there any documented technical signals developers should verify? For example: redirects third-party scripts TLS configuration domain age hosting reputation infrastructure characteristics phishing heuristics machine-learning based classification Is there any recommended diagnostic process beyond Website Review? Approximately how long does a manual review usually take? Why I am posting This post is not only about my own websites. Over the past few months I have noticed an increasing number of developers reporting what appear to be false positive Fraudulent Website Warnings affecting legitimate websites. If there have been recent changes to Safari’s reputation or anti-phishing systems, it would be extremely helpful for developers to better understand what technical criteria should be reviewed before requesting reconsideration. Even if the exact detection logic cannot be disclosed, any general guidance on common causes of false positives would help developers resolve issues much more efficiently. Thank you very much for your time.
3
1
638
5d
[iOS Safari] Fullscreen API on a non-video element
webkitEnterFullScreen API is supported on iOS for video element, but not for a div element. Also as a fullscreen demo website shown, Safari on macOS supports div element but not on iOS. Is there any plan to add the support in iOS? If not is there any way to fullscreen a div element or make it run as fullscreen on Safari iOS?
33
14
34k
6d
sign in with apple: transferring website users from one team to another
I operate a website that offers Sign In with Apple as an authentication option for users. When I originally set this up a couple years ago, I'd created an App ID using my personal Developer account, along with the appropriate Services ID and Key. I'm now in the process of creating an iOS app offering users similar functionality. But for this, I have a new, business Developer account, where I've created an App ID and all the same ids allowing Sign In with Apple. It feels like the first appropriate thing to do—before starting my iOS sign-in—is to get my existing website users migrated from my personal developer team to my new business developer team. I found that process very well documented by technote TN3159, which describes this as a six-step process in terms of Team A handing a project to Team B. Team A obtains access token(s) Team A generates transfer identifiers Team A initiates app transfer to Team B Team B obtains access token(s) Team B exchanges transfer identifiers Team B confirms successful user migration ✓ I'm successfully able to complete steps 1 and 2. ✘ Step 3 doesn't seem possible, as it looks like that applies to a team transferring a published app to another team. But I figured maybe that didn't matter in my case, as my website uses a Services ID, not an App ID. ✓ I'm successfully able to complete step 4. ✘ But step 5—the important part, where I get the transfer ID—fails with an invalid_request error. I suspect this is because step 3 really was important. But I can't find a way to transfer an app that isn't really an app, just a website using the Sign In with Apple service. Anyway, any help would be greatly appreciated.
1
0
619
1w
Accessing https://www.cgs.com via Safari returns a restricted website warning.
Hello, I have recently discovered that our company website, https://www.cgs.com, displays the message "Website Not Allowed, cgs.com is a restricted website." when accessed via iOS Safari. After investigation, I found that this occurs when the Limit Adult Websites option is enabled under Settings → Screen Time → Content & Privacy Restrictions → App Store,Media, Web, & Games → Web Content. I believe this restriction has been applied incorrectly to our website, and I would like to formally request that https://www.cgs.com be removed from this restricted list. Please let me know if any supporting materials or documentation are required from our side. Best regards
0
0
478
1w
Did Instagram just blocked App Store Links?
Is anyone else seeing Instagram fail to open App Store links tonight? Started for me a few hours ago, iOS only. To rule out my own setup I put a bare App Store URL straight in my bio, and I also tapped the App Store links on a few competitors' sites. Same result every time: nothing happens, no error, no page. Same phone, same moment: Safari works, Facebook and YouTube work, TikTok fails. Has Instagram started blocking store links the way TikTok does? If so, it looks like we're back to telling people to tap the ⋯ menu and "Open in external browser" before they can install anything.
Topic: Safari & Web SubTopic: General
Replies
4
Boosts
1
Views
105
Activity
2h
Safari iOS 26.5.2: first navigation fails during HTTP/3 0-RTT; reload succeeds (FB23764937)
Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.
Replies
4
Boosts
1
Views
313
Activity
17h
Safari still shows a Deceptive Website Warning
My domain vendezo.com is completely clean on Google Safe Browsing and VirusTotal, but Safari still shows a Deceptive Website Warning. Request through websitereview.apple.com was ignored. Please help
Replies
0
Boosts
0
Views
260
Activity
2d
Request Guidance on Apple Pay Web Push Provisioning Enablement for Issuer Program Post Content:
We are currently supporting an Apple Pay-enabled card program as an issuer/issuer processor and have successfully completed In-App Push Provisioning integration within our iOS application. The in-app flow is fully operational, including issuer-side cryptographic exchange and Mastercard MDES network tokenization. We are now looking to extend this integration to support Apple Pay Web Push Provisioning, allowing cardholders to add eligible cards to Apple Wallet directly from our web application. We would appreciate guidance on: -The process for enrolling in Apple Business Register (if required) -Enabling Web Push Provisioning for an issuer profile Required entitlements or provisioning certificates Any additional onboarding steps specific to issuer-level Web provisioning We understand that Web Push Provisioning requires issuer-level enablement beyond standard Apple Pay on the Web, and we would like clarification on the correct path to activate this capability. Thank you in advance for your guidance.
Replies
3
Boosts
2
Views
1.8k
Activity
3d
Possible increase in false positive “Fraudulent Website Warning” detections in Safari (2026)
Hello Apple engineers and fellow developers, Over the past few weeks I have noticed multiple reports from different developers whose legitimate websites have been classified by Safari as “Fraudulent Website Warning”, despite passing every major public security and reputation check. My websites appear to be affected by the same issue. Domains https://skvoz.net https://skvoz.org Both domains were registered on July 15, 2026. The Fraudulent Website Warning first appeared on July 22, 2026, only one week after registration. Both websites are legitimate services operated by our team. Neither website impersonates another brand, attempts to collect Apple IDs, banking credentials, passwords, or any other sensitive information through deceptive means. Extensive verification performed After the warning appeared, we performed a comprehensive technical and security review. Website security ✅ No malware detected ✅ No phishing content ✅ No unauthorized redirects ✅ No suspicious JavaScript ✅ No mixed-content issues ✅ HTTPS configured correctly ✅ Valid TLS certificates Infrastructure DNS configuration verified SSL certificate chain verified using OpenSSL Server responds correctly over HTTP/2 IPv4 and IPv6 connectivity verified Origin server behaves correctly Cloudflare configuration was thoroughly tested during troubleshooting and ultimately removed from the production setup to eliminate it as a possible cause Reputation checks We verified both domains and the hosting IP address using multiple public reputation services. Results were consistently clean. This included services such as: Google Safe Browsing Google Search Console VirusTotal URLVoid IP reputation databases None of them currently report malware, phishing activity, or any other security issues. Apple-specific actions We have already: submitted a Website Review request; contacted Apple Security via reportphishing @apple.com requesting a manual review. At the time of writing, the warning is still present. One unusual observation One particularly unusual observation is that both of our domains (skvoz.net and skvoz.org) received the warning independently. These are separate domains serving different purposes, yet both appear to have been classified in the same way despite passing the same technical and reputation checks. This made me wonder whether Apple’s reputation system may evaluate related domains or shared infrastructure together. I understand the internal implementation is not public, but I wanted to mention this observation in case it is useful during investigation. Similar reports While investigating this issue, I found several recent reports from other developers describing almost identical behavior. The common pattern is remarkably consistent: Safari displays Fraudulent Website Warning Chrome, Firefox and Edge open the website normally Google Safe Browsing reports the domain as safe VirusTotal reports no malware Google Search Console reports no security issues valid HTTPS certificates relatively new domains no explanation regarding what triggered the warning This suggests the issue may not be isolated to a single website. Questions I would greatly appreciate any guidance from Apple engineers. Does Safari rely solely on Google Safe Browsing, or does Apple maintain an independent reputation database for Fraudulent Website Warning? If Apple maintains its own reputation system, are there any documented technical signals developers should verify? For example: redirects third-party scripts TLS configuration domain age hosting reputation infrastructure characteristics phishing heuristics machine-learning based classification Is there any recommended diagnostic process beyond Website Review? Approximately how long does a manual review usually take? Why I am posting This post is not only about my own websites. Over the past few months I have noticed an increasing number of developers reporting what appear to be false positive Fraudulent Website Warnings affecting legitimate websites. If there have been recent changes to Safari’s reputation or anti-phishing systems, it would be extremely helpful for developers to better understand what technical criteria should be reviewed before requesting reconsideration. Even if the exact detection logic cannot be disclosed, any general guidance on common causes of false positives would help developers resolve issues much more efficiently. Thank you very much for your time.
Replies
3
Boosts
1
Views
638
Activity
5d
[iOS Safari] Fullscreen API on a non-video element
webkitEnterFullScreen API is supported on iOS for video element, but not for a div element. Also as a fullscreen demo website shown, Safari on macOS supports div element but not on iOS. Is there any plan to add the support in iOS? If not is there any way to fullscreen a div element or make it run as fullscreen on Safari iOS?
Replies
33
Boosts
14
Views
34k
Activity
6d
sign in with apple: transferring website users from one team to another
I operate a website that offers Sign In with Apple as an authentication option for users. When I originally set this up a couple years ago, I'd created an App ID using my personal Developer account, along with the appropriate Services ID and Key. I'm now in the process of creating an iOS app offering users similar functionality. But for this, I have a new, business Developer account, where I've created an App ID and all the same ids allowing Sign In with Apple. It feels like the first appropriate thing to do—before starting my iOS sign-in—is to get my existing website users migrated from my personal developer team to my new business developer team. I found that process very well documented by technote TN3159, which describes this as a six-step process in terms of Team A handing a project to Team B. Team A obtains access token(s) Team A generates transfer identifiers Team A initiates app transfer to Team B Team B obtains access token(s) Team B exchanges transfer identifiers Team B confirms successful user migration ✓ I'm successfully able to complete steps 1 and 2. ✘ Step 3 doesn't seem possible, as it looks like that applies to a team transferring a published app to another team. But I figured maybe that didn't matter in my case, as my website uses a Services ID, not an App ID. ✓ I'm successfully able to complete step 4. ✘ But step 5—the important part, where I get the transfer ID—fails with an invalid_request error. I suspect this is because step 3 really was important. But I can't find a way to transfer an app that isn't really an app, just a website using the Sign In with Apple service. Anyway, any help would be greatly appreciated.
Replies
1
Boosts
0
Views
619
Activity
1w
Accessing https://www.cgs.com via Safari returns a restricted website warning.
Hello, I have recently discovered that our company website, https://www.cgs.com, displays the message "Website Not Allowed, cgs.com is a restricted website." when accessed via iOS Safari. After investigation, I found that this occurs when the Limit Adult Websites option is enabled under Settings → Screen Time → Content & Privacy Restrictions → App Store,Media, Web, & Games → Web Content. I believe this restriction has been applied incorrectly to our website, and I would like to formally request that https://www.cgs.com be removed from this restricted list. Please let me know if any supporting materials or documentation are required from our side. Best regards
Replies
0
Boosts
0
Views
478
Activity
1w