This demonstrates an issue with SwiftUI's WebView on iPadOS. To repro, testing on iPad Simulator OS 26.2, macOS 26.2, Xcode 26.2. Download and unzip this project: https://drive.google.com/file/d/1z3MobjDf_RvvOtriXtinXvrJ7rGHwZRs/view?usp=share_link Set up Signing and Run the swiftui-webview App target on simulator (I'm using iPad Pro 13-inch (M5 simulator) Tap/click the fullscreen [ ] button in the bottom left corner of the webpage. Tap/click the 'X' button in the top left, to exit fullscreen. Result: The WebView exits fullscreen, but there is no content loaded, just a white background. It's also now not possible to visit other URLs - the WebView appears to be unresponsive and not repaint. This does not appear to affect macOS 26.2, just iPadOS.

aID is an ID service for 150+ newspaper sites in Norway. Since the middle of January the average login time with passkeys on our site https://www.aid.no/ has increased for Safari users, the number of logins using passkey in Safari has decreased dramatically. Previously Safari was the browser that provided the best user experience during login, since it triggered fingerprint reader straight away, but this behavior has vanished. Has something changed that we should be aware of, and is there something we can do to make conditional get great again? Without mediation conditional, the passkeys work as expected. In Chrome and Firefox, we get passkey suggestions in the username field, in Safari it's only password suggestions. To make things even stranger, the same code works as it used to in our test environment. It triggers a small popup by the username field and activates the fingerprint reader. If I cancel this, I can click on the Passwords icon and get passkey suggestion there.

Our app uses ASWebAuthenticationSession for login. This launches an incognito (ephemeral) browser window of the system’s default browser with the authentication URL. Recently, on the latest macOS Tahoe, we observe that: The browser application is launched(we could see in the dock) But the authentication window with the URL does not appear No error is returned to the app (silent failure)

Issue: On Safari, two Smart App Banners appear for the same webpage when the iOS app is installed. Cause: • Banner 1: Native Apple Smart App Banner, automatically triggered by Safari via AASA / Universal Links. • Banner 2: Smart banner injected by a third-party SDK (Branch.io). • Both operate independently, resulting in duplicate banners. Finding: Safari’s native Smart App Banner behavior is system-controlled and cannot be disabled programmatically using web rules or JavaScript while Universal Links are enabled. Question: Is this behavior expected by design? Is there any Apple-supported way to suppress the native Smart App Banner when using a third-party banner, or is the recommended approach to rely on only one banner system?

There appears to be a regression or restriction in iOS 26.2 and 26.2.1 regarding the Web Authentication API in third-party browsers (browsers other than Safari). Specifically, the method PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() returns false when called from within non-Safari browsers (e.g., Chrome, Firefox, Edge) on iOS, even when the device supports biometrics (FaceID/TouchID) and Passkeys are enabled. This prevents third-party browsers from correctly detecting Platform Authenticator availability, leading websites to hide Passkey login options or default to cross-device authentication flows instead of using the local device's biometric authenticator. Environment: OS: iOS 26.2, iOS 26.2.1 Device: iPhone 17 Browsers Tested: Chrome iOS and Firefox iOS Steps to Reproduce: Launch Safari on an iOS device running iOS 26.2+. Navigate to https://www.passkeys-debugger.io/. Observe that "Platform Auth" is highlighted in Green (true), indicating the device is eligible for passkey authentication. Launch a non-Safari browser (e.g., Chrome or Firefox) on the same device. Navigate to https://www.passkeys-debugger.io/. Expected Results: "Platform Auth" should be Green (true), matching the behavior in Safari, as the device possesses a built-in platform authenticator. Actual Results: "Platform Auth" is highlighted in Red (false). Impact: This discrepancy fragments the Passkey user experience on iOS. Users preferring third-party browsers are unable to utilize the seamless on-device biometric authentication that is available in Safari. It forces developers to implement complex fallbacks or results in users believing their device is incompatible with Passkeys.

Hello Apple Developer Community, I currently have a Safari Web Extension on iOS that blocks certain URLs for users. I would like to provide the same functionality for Chrome on iOS. I understand that Chrome on iOS uses WebKit under the hood, and Safari Web Extensions can run in Safari, but I am unsure whether there is any way to implement URL blocking in Chrome for iOS—either via an extension, API, or other supported mechanism. Specifically, I’m looking for guidance on: Whether any browser extension (Safari, Chrome, or otherwise) can intercept or block web requests in Chrome on iOS. If not, what Apple-supported alternatives exist for implementing URL-blocking functionality for users of Chrome on iOS. Any best practices for maintaining a cross-browser URL-blocking solution for iOS users. I want to make sure my approach is aligned with Apple’s policies and platform capabilities. Any guidance or official references would be greatly appreciated. Thank you!

When using iOS 26.2 (23C55) Safari, the following can occur. The current tab (A) opens a new tab (B) via window.open(url, target, windowFeatures). The user clicks the "back" button to close tab B, and returns to tab A. Tab A attempts to open tab B again at a later point, using the same "target" as before, and fails (no window object is returned by window.open). This bug only occurs when the target is the same as the previously closed tab (which was closed via the back button). If a new target is specified, the new tab opens as expected. This bug is also limited to the back button. If the user manually closes tab B, then it can be re-opened by tab A using window.open using the same target as before.

When using iCloud Keychain passkeys with WebAuthn (mediation: "conditional") in non-Safari browsers (e.g. Chrome or WKWebView-based browsers), Face ID / Touch ID is requested twice during Passkey Autofill. This issue occurs only when the focused input field shows a numeric keypad–style keyboard, such as: Japanese Kana Chinese Zhuyin With a standard QWERTY keyboard, authentication completes with a single user verification. Notably: Safari completes authentication with one Face ID / Touch ID prompt even with numeric keypad keyboards. Other browsers require two prompts. The issue does not occur with other credential managers (Google Password Manager, 1Password), suggesting this is specific to iCloud Keychain. This issue has been confirmed on the following OS versions: iOS 17.6.1 iOS 18.7.2 iOS 26.2 iOS 26.3 beta Impact This behavior results in a confusing and unintuitive login experience for users relying on Passkey Autofill. Steps to Reproduce: Go to Settings → Keyboards → Keyboards, and set “Japanese – Kana” as the primary keyboard. Enable Face ID / Touch ID, and make sure “Use Face ID / Touch ID For” → “Password Autofill” is enabled. Open Chrome and navigate to https://webauthn.io. Enter a username and tap “Register” to create a passkey using iCloud Keychain. Tap the username field again so that the “Japanese – Kana” keyboard appears and the passkey suggestion created in step 4 is shown. Tap the passkey suggestion. Face ID / Touch ID is requested twice. === This issue has already been reported via Feedback Assistant as FB21726047. 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.

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.

Starting with iOS 26.2, when Safari tabs are set to Bottom or Compact view, some pages are not rendering properly. The error does not occur in Top view. For some pages, scrolling causes rendering to be very slow, causing the user to experience page breaks and missing parts. If the user waits a few seconds, the missing parts of the page will appear, but the issue will reoccur when scrolling further. We have tested this on all available iOS devices and the issue occurs on all iPhones running iOS 26.2. The issue does not occur on iOS 26.1, and we have not experienced it on devices running iOS 18. The issue can be reproduced on the following pages with an iPhone running iOS 26.2: https://fotosakademia.hu/products/course/fotografia-kozephaladoknak-haladoknak https://oktatas.kurzusguru.hu/products/course/az-online-kurzuskeszites-alapjai

Hi everyone, recently I used codex and GPT-5.2 to build a simple SSL certificate monitoring website, and I'd like to share some of my development experiences. The project link is at the end, but first, let's talk about the technical implementation. The Motivation I've encountered several service outages caused by expired SSL certificates in the past. Each time, I had to react after users reported the issue, which was very passive. While there are some monitoring tools on the market, they are either too heavy or lack the necessary features, so I decided to build my own. Technology Stack Next.js 16 + shadcn/ui + TypeScript I chose Next.js because: The development experience with App Router is excellent, with a clear mapping between routes and file structure. Server Components reduce the need for client-side JavaScript. Built-in features like image optimization and font loading are ready to use out of the box. shadcn/ui is a component library based on Radix UI, and its advantages are: Components are copied directly into your project, giving you full control. It uses Tailwind CSS, making style customization easy. It has excellent accessibility features. Drizzle ORM + PostgreSQL I've used Prisma before, but I tried Drizzle this time and found it to be more lightweight: Faster type generation. More intuitive SQL operations. Better query performance. better-auth Authentication System This is a recent discovery I made, and it's more modern than NextAuth: Better TypeScript support. A cleaner API design. Supports email/password and multiple OAuth providers (GitHub, Google). Some Challenges I Faced 1. The Complexity of Certificate Chain Validation At first, I thought checking an SSL certificate was simple—just get the certificate information. I later discovered that certificate chain validation is quite complex: You need to verify the signature of each certificate in the chain. You must check the integrity of the entire certificate chain. You have to determine if the root certificate is trusted (which browsers have built-in lists for). You need to handle cases where intermediate certificates are missing. The solution was to create a complete certificate chain extraction and validation module that includes: Extracting the full certificate chain from a TLS connection. Verifying the signature and validity period of each certificate. Detecting broken or incomplete chains. Visualizing the chain structure in a tree format. 2. Designing the Security Scoring System To help users quickly understand the security status of their certificates, I created a scoring system from A+ to F. The core logic is: Weighted score across four dimensions - Certificate Validity: 30% - Chain Integrity: 25% - Cryptographic Strength: 25% - Protocol Version: 20% If there are critical issues (e.g., expired certificate), the maximum grade is C The challenges were: How to allocate weights reasonably. How to design the penalty rules. How to provide valuable improvement suggestions. Ultimately, I adopted a layered scoring approach where each dimension is calculated independently and then combined with weights. 3. Hydration Issues with Multi-language Routing When supporting 6 languages, I encountered React Hydration errors: // ❌ Incorrect approach // app/[locale]/layout.tsx contained the <html> tag // This conflicted with the root layout // ✅ Correct approach // The root layout has only one <html> tag // Use a client component to dynamically update the lang attribute 4. Graceful Degradation for Redis Caching To improve authentication performance, I added Redis caching. But I had to consider: What happens when Redis is unavailable? How do you handle cache and database data inconsistency? The solution was: Automatically fall back to the database if the Redis connection fails. Actively invalidate the cache when the database is updated. Provide cache statistics API to monitor the hit rate. 5. PageSpeed Optimization Initially, the Lighthouse score was only in the 60s. The main problems were: Large JavaScript Bundle Used Next.js's dynamic imports to load components on demand. Removed unused dependencies. Enabled Tree Shaking. Image Optimization Used the Next.js Image component for automatic optimization. Added appropriate placeholders. Enabled lazy loading for images. Font Loading Used next/font for automatic font optimization. Reduced the number of font variants. Used font-display: swap to avoid layout shifts. Critical Rendering Path Identified critical CSS and inlined it into the HTML. Deferred loading of non-critical JavaScript. Optimized the loading order of third-party scripts. Third-party Script Optimization Deferred loading for Google Analytics, Crisp Chat, etc. Used the defer/async attributes. Considered using Web Workers for time-consuming tasks. After optimization: Performance: 60 → 95 Accessibility: 85 → 98 Best Practices: 90 → 100 SEO: 100 Some Technical Highlights Certificate Chain Visualization A tree structure is used to display the certificate chain, with expand/collapse functionality and color-coding for different statuses: Green: Valid Yellow: Expiring soon Red: Expired Security Issue Detection Automatically detects insecure cryptographic algorithms: MD5, SHA-1 signature algorithms. Weak ciphers like RC4, DES. Old protocols like TLS 1.0/1.1. Multi-channel Notifications Currently supports five notification channels: Email, Slack, Discord, Telegram, and Feishu. Users can freely combine them. Project Link https://guardssl.info Features: Free SSL certificate checking. Domain monitoring and expiration reminders. Security scoring and improvement suggestions. Multi-language support (Chinese, English, Japanese, French, Spanish). Feel free to try it out and provide feedback. We can discuss any questions you might have.

Hello Friends, This is my first post so would love any suggestions on how to make posts here. So I have a shopify widget which is type of clone for Instagram stories, with videos but I noticed some issues where my videos are kind of unresponsive or just shuts down. Below is the screen shot of the issue: This problem I noticed on iPhone 11 Pro on clients phone, the IOS version is below 26. Some times my iPhone 13 also faces same issue but only when battery is low and multiple heavy apps are opened. Attached a code block also: {validStories.map((story) => { const videoUrl = extractVideoUrl(story.sv?.[0]?.m); const storyThumbnail = story.tu && story.tu.length > 0 ? story.tu : null; const videoThumbnail = story.sv?.[0]?.m?.[0]?.t && story.sv[0].m[0].t.length > 0 ? story.sv[0].m[0].t : null; const thumbnailUrl = storyThumbnail || videoThumbnail; const hasThumbnail = !!thumbnailUrl; const isPlaying = playingVideoIds.has(story.i); const shouldRenderWrapper = hasThumbnail || isPlaying; return ( <div key={story.i} className="ins-story-item" onClick={(e) => { handleActiveStoryChange(story.i, e); handleActiveVideoId(story.i); }} style={{ position: "relative", zIndex: 1 }} > {shouldRenderWrapper && ( <div className="ins-story-circle-wrapper" style={{ position: "relative", overflow: "hidden" }} > {hasThumbnail && !isPlaying && ( <img src={thumbnailUrl} alt={story.t} className="ins-story-image" onError={() => { console.log( `[Story ${story.i}] Thumbnail failed to load: ${thumbnailUrl}` ); }} /> )} <video src={videoUrl} className="ins-story-video" autoPlay={true} muted playsInline loop onLoadedData={() => handleVideoPlaying(story.i)} onPlaying={() => handleVideoPlaying(story.i)} onError={(e) => { console.log(`[Story ${story.i}] Video error`, e); }} /> </div> )} {story.t !== "New Collection" && ( <span className="ins-story-title">{story.t}</span> )} </div> ); })} </div> {activeStoryId && <StoryModal />} </>```

We operate a native iOS app that authenticates users via the system browser using OIDC against a 3rd party SaaS authentication broker, which then performs authentication against the individual customer IdPs using SAML within the browser session, and then completes the OIDC login between the broker and our application. Our application initiates the OIDC login using ASWebAuthenticationSession, using the broker’s library, against the broker, and at that point the authentication workflow is handled by the broker. At the beginning of the login session, the broker sets a session-identifying cookie for their domain, before redirecting the user to their company’s identity provider to authenticate, which then redirects the user back to the broker. Intermittently, Mobile Safari does not include that previously set cookie on the final communication with the broker, when being redirected from the IdP as the final step of the SAML portion of the login workflow. When the cookie is missing, the broker cannot correlate the authentication response to the original request and the login fails, even though the user successfully authenticated at their identity provider. The same user can sometimes find success after retrying on the same device minutes later, without any changes. When we first started diagnosing this issue, we were seeing about a 20% rate of these errors across all Mobile Safari logins, which we can identify fairly conclusively (from provider logs, based on their guidance) as being caused by the session cookie set in one request not being provided on the subsequent request to the same domain. Our authentication broker provider has indicated, based on their server logs, and logs from an affected device, that this behavior is caused by Mobile Safari’s Intelligent Tracking Protection (ITP) causing Mobile Safari to not send the login session cookie to the broker when handling the SAML redirect from the IdP back to them. Our authentication broker provider recommended that we switch the SAML Request binding setting from POST to Redirect in the SAML configurations against our customer IdPs, which reduced the rate of these errors to about 5% for most of our customers. However, we have at least one customer which is still seeing about a 20% rate in these errors for Mobile Safari logins after this change, and even a 5% error rate seems high. Our authentication broker has not been able to suggest any further remediation options, and has suggested we contact Apple for assistance. Our questions are: Is it reasonable to assume that ITP is causing this issue? Is there any way to confirm, conclusively, that ITP has caused a previously-set cookie to not be provided on a subsequent request to the same domain, i.e. via device logs? If so, are there any steps which can be taken to reduce or eliminate this error? Changes to how ASWebAuthenticationSession is invoked? Changes to the Authentication Broker which would reduce the chance of ITP being triggered? Changes to the Customer IdP configuration which would reduce the chance of ITP being triggered?

I'm using a CSS filter to achieve dark mode for my HTML page. I know it's imperfect, but I have no choice for many reasons. However, I found that the CSS filter produces incorrect colors in iOS 26.2 WebView, while it works fine in iOS 18.6.2 WebView. Here is my HTML and CSS filter: <html> <head> <style> .filter_container { /* invert colors for the entire page */ filter: invert(1) hue-rotate(180deg); } .filter { /* restore colors for specific elements, such as img */ filter: hue-rotate(180deg) invert(1); } </style> </head> <body> <div>original & bgcolor+filter & img+filter</div> <table> <tr> <td> <div style="display:flex; gap:1px; align-items:center; justify-content:center;"> <div class="origin_container"><div class="origin" style="background-color:#FFFFFF; height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px;"></div></div> <div class="filter_container"><div class="filter" style="background-color:#FFFFFF; height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px"></div></div> <div class="filter_container"><img class="filter" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADwAAAA8CAYAAAA6/NlyAAAAdklEQVR4nOXOQQEAIACEMKR/57OFPliCnW0jRGIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkxt+B1y6HmAR0uIzOQQAAAABJRU5ErkJggg==" style="height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px"></img></div> </div> <div style="text-align:center;">#FFFFFF</div> </td> ...many other colors </table> </body> </html> It works fine in iOS 18.6.2 WebView: But renders incorrectly in iOS 26.2 WebView:

Is iOS WebRTC communication via WebView stable when the app is in the background? I'm implementing SIP communication using JsSIP within a WebView. On iOS, I'm using WKWebView, but I'm concerned that its resources may be limited by the system when the app is backgrounded. Even with the VoIP background mode declared in the Info.plist file, will the system preserve sufficient resources to keep the SIP communication active?

We are embedding TikTok Live streams inside our iOS app using WKWebView. The Live stream loads and plays normally at first. However, when the app goes to the background (for example, user presses the Home button or switches apps) and then returns to the foreground, the TikTok Live video and audio become paused and do not resume automatically. Expected behavior When the app returns from the background to the foreground, the video/audio should resume playback automatically Actual behavior Video/audio pauses after app resumes from background Any guidance would be greatly appreciated. Thank you.

On iOS Devices with ProMotion (120HZ) if you animate Elements on your Page with animation-timeline you get Ghosting Effects. You can not see the Ghosting with a Simulator or on Screenshots, only on real Devices. To Reproduce I made a Minimal Example: https://codesandbox.io/p/sandbox/120hztest-xrwgtc When you scroll quickly on the Page with an iOS 120HZ Device (https://en.wikipedia.org/wiki/List_of_smartphones_with_a_high_refresh_rate_display) you will see ghosting on the Top of the right Element (animation-timeline) and no ghosting on the other animated Element. (I edited the Screenshot, to Illustrate how the Effect looks like, since it is only visible on the real Display)

Scenario Overview: In our app, we open an in-app browser to complete a third-party consent flow. The sequence is: App → Website A (set cookie and redirect) → Google → Website A (check cookie) → App After upgrading the app, the first consent attempt fails because the cookie cannot be written, causing the check cookie step to fail. However, if we use the native Safari browser, this issue does not occur. Observed Behavior: Scenario Result Upgrade app → Consent ❌ Fail Upgrade app → Consent fail → Consent again immediately ✅ Pass Upgrade app → Consent fail → Upgrade again after 1–2h → Consent ✅ Pass Upgrade app → Consent fail → Upgrade again after 1d → Consent ❌ Fail Install a new app → Consent ✅ Pass Upgrade app → Consent, cancel flow → Consent again ✅ Pass Install new app → Wait for upgrade → Upgrade app → Consent ✅ Pass Install new app → Wait 1–2h → Upgrade app → Consent ✅ Pass Investigation: From Safari documentation, this seems related to Intelligent Tracking Prevention (ITP), which restricts cross-site cookie behavior during first-party interactions. However, I haven’t found a clear mitigation strategy yet. Question: Has anyone encountered similar issues with Safari ITP after app upgrades? Are there recommended approaches to ensure cookies persist across this redirect flow?

After App uses Network.framework PrivacyContext Api, dns has been encrypted, that is good. But when using wkwebview to load web page, wireshark captures normal dns request sent by wkwebview. Does wkwebview use DoH to resolve domain? if can, how to config params? If can not, is there anyway to stop wkwebview sending normal dns, such as local proxy.

It’s the small things that make a difference, and the three dots at the top of the screen in Safari and Chrome are such examples. I’ve already accidentally deleted several tab groups by accident and try to relearn browsing is harder than it should be.