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.

I am implementing push notifications for a web application running as a PWA on iPad using Web Push. When sending a push notification to the web application, I received a 410 response from the server. I would like to understand the cause and reason for receiving this 410 response. The library used for sending push notifications is a commonly used JavaScript Web Push library. Could you please explain under what circumstances Apple Web Push endpoints return a 410 response, and whether this indicates that the existing push subscription is no longer valid and should be re‑registered.

My Iphone 17 Pro Max is in ioss 27 and it is having troubles with wifi issues, It works on celluar data but however when conected to wifi it only work son certain programs such as safari, it does not work on imsg, social media and app store. However everything works fine on data, I know its not a wifi problem as my Iphone 16 pro max is having zero issues with the wifi connected to it so I am not sure what the issue is

Although I have reduced my Mac's MTU to solve the MTU blackhole problem, Safari is quite slow if I enabled iCloud private relay (scenario 1). At the same time, Chrome functions normally. When I turns off iCloud private relay, the Safari's performance improves immediately. Packets captured by tcpdump at a LAN gateway (FreeBSD) shows iCloud private relay uses UDP protocol and doesn't fallback to TCP protocol. If the MTU blackhole is a problem, the connection will switch to TCP protocol, given prior tcpdump captures. I am waiting for macOS 27 Beta 5 but still no update released yet.

When using passkeys stored in iCloud Keychain (Passwords app) via Passkey Autofill in browsers other than Safari, the userVerification parameter is ignored and user verification (UV) is not performed. As a result, relying party servers that require userVerification = required fail validation because the UV flag is not set, causing passkey authentication to fail. This issue occurs when the following setting is disabled: Settings → Face ID & Passcode → Use Face ID For → Password AutoFill The issue is reproducible only with the following combination: Non-Safari browsers (e.g. Chrome) Passkeys stored in iCloud Keychain (Passwords app) Passkey Autofill The issue does not occur in the following cases: Safari with passkeys stored in any credential manager Non-Safari browsers using credential managers other than iCloud Keychain Steps to Reproduce: Go to Settings → General → Autofill & Passwords, and enable the Passwords app under “Autofill From”. Go to Settings → Face ID & Passcode → Use Face ID For, and disable “Password AutoFill”. Open Chrome and navigate to https://webauthn.io Enter a username and tap “Register” to create a passkey using the Passwords app (iCloud Keychain). On webauthn.io, go to Advanced Settings → Authentication Settings, and set “User Verification” to “Required”. Reload the page, tap the input field, and perform Passkey Autofill. User Verification is not triggered, and “Authentication failed” is displayed on webauthn.io. === This issue has already been reported via Feedback Assistant as FB21756948. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.

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.