So I have web Augmented Reality apps hosted on AWS S3. It worked fine for a month, but as soon as the IOS 18.4 update was installed they stopped working. It works on every other device and IOS versions. The URLs for the mentioned AR experiences: digitechonline.in/solsprefimaginewt8/ digitechonline.in/solsprefimaginewt8p2/ digitechonline.in/orocarear/ These AR experiences get stuck on the loading screen and either reload or give an error. Ideally the camera is supposed to open. I have tested it on Safari, Microsoft Edge and Google Chrome browsers. They were created through Unity webgl and hosted on AWS S3 bucket. Please provide a quick solution to this.

I'm not loving the huge Favorites icons in Safari on MacOS 26, is there a way to reduce the size of them so that we can see more favorites on the list without scrolling down?

Issue Description I'm developing a hybrid iOS app and encountering WebView bridge communication issues after updating to Xcode 16 with iOS 18 SDK. App Architecture AViewController: Initial view controller displayed at app launch Handles WebView setup and web-to-native bridge communication Pushes BViewController when receiving "B" bridge message from web BViewController: View controller stacked on top of AViewController Managed by navigation controller AViewController's WebView continues bridge communication even when BViewController is active Problem Behavior Xcode 15 (iOS 18): WebView bridge communication in AViewController works normally while BViewController is active Xcode 16 (iOS 18 SDK): Server communication breaks or hangs without response while BViewController is active Communication resumes only after popping back to AViewController from BViewController Questions Is the current architecture (configuring WebView in AViewController and maintaining bridge communication through AViewController's WebView while BViewController is presented) not a recommended pattern? Is Xcode 16's iOS 18 SDK the cause of this issue? If so, could you help me understand which specific changes are affecting this behavior? This is urgent as we need to deploy soon. I would greatly appreciate a prompt response.

Actually this is a duplicate for https://developer.apple.com/forums/thread/106537 but in web-specific forums section. Is there any video/audio codec best practices, guides, recommendations for app/web developers for best performance (take advantage from HW acceleration), power consumption saving? What are officially supported media containers? What are video encoding profiles, video dimensions, frame rates? The only official source I have found is https://developer.apple.com/documentation/webkit/delivering-video-content-for-safari?language=objc. But h264 is pretty old. I experimentally found that the VP9 video format is also supported on iOS newer versions. But is this a requirement? Сan i be sure that the video will play on all devices? My goal is to provide web media content (which will be rendered in my application using WKWebView API) that will be supported by most devices (both iOS and MacOS), takes advantage of such features as hardware decode acceleration and be efficient. Any hints/info is highly appreciated. Best regards.

Dear Apple Developer Support, We are currently developing a system that requires the ability to edit Japanese vertical text within the Safari browser on iPhone. During our investigation, we encountered an issue that matches the following WebKit bug: 283620 – Caret Positioning Issues in Vertical Writing Mode We understand that this issue is being addressed in the following pull request: https://github.com/WebKit/WebKit/pull/39939 However, it appears that a complete fix has not yet been implemented. Given this situation, we would like to confirm the following: Is there any known workaround for this issue in iOS 17.5 or iOS 18.5 (the latest versions as of now)? If a workaround exists, could you please provide details? If not, could you share the expected timeline for a full resolution of this issue? Although this appears to be an open-source WebKit issue, we are reaching out to Apple because WebKit is tightly integrated with iOS and Safari, and ultimately delivered as part of the iPhone experience. Thank you very much for your support. Best regards, Takao Kurabayashi

How can I make a background image take the entire screen in ios26? I've tried position fixed, sticky, env() css variables but nothing worked. It does it when in PWA mode, but I would like to do so in the browser too.

Is there any supported mechanism in Safari Web Extensions (MV3) for capturing or logging network request data (like fetch, XHR, or webRequest) triggered by the web page?

Hello We've encountered an issue with WKWebView in the latest iOS 26 beta. When loading a PDF URL, the background of the PDF viewer now displays as a dark gray instead of the expected white. Device: iOS 26 Simulator/Device Component: WKWebView Issue: The background color of the loaded PDF is gray. Expected Behavior: The background should be white, as it has been in all previous iOS versions. Link for Testing: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf We confirmed that the same PDF and code render with a white background on iOS 26 and earlier. Questions: Is this an intentional change in iOS 26's WKWebView? If so, is there a new property or configuration setting available to control the background color of the PDF viewer within WKWebView? We would like to have the ability to set it back to white. Any insights, workarounds, or information on this matter would be greatly appreciated. Thank you.

I’ve been working on a personal iOS project for fun — essentially a YouTube music player, learning how background media playback works in native iOS apps. After seeing that Musi (a famous music streaming app) can play YouTube audio in the background with the screen off — I got really curious. I’ve been trying to replicate that basic background audio functionality for YouTube embeds using WKWebView. I've spent a crazy amount of time (probably 20 hours) trying to figure this out but have achieved no success. Here’s what I’ve tried so far: -Embedding a YouTube video in a WKWebView -Activating AVAudioSession with .playback and setting .setActive(true) -Adding the UIBackgroundModes key with audio in Info.plist -Adding the NSAppTransportSecurity key to allow arbitrary loads --Testing on a real device (iPhone 14, iOS 18.1 target)-- What happens: Audio plays fine in the foreground. If I exit the app and go to the lock screen quickly enough (less than 3 seconds) after pressing play, I can resume playback briefly from the lock screen — but it doesn’t automatically continue like in Musi and other apps like it. Most of the time, the audio stops when the app is backgrounded. I get this error consistently in the logs: Error acquiring assertion: <Error Domain=RBSServiceErrorDomain Code=1 "(originator doesn't have entitlement com.apple.runningboard.assertions.webkit AND originator doesn't have entitlement com.apple.multitasking.systemappassertions)" It seems like the app lacks some specific entitlements related to WebKit media playback. I don’t have AppDelegate/SceneDelegate (using SwiftUI), but can add if needed. I’m super curious how music streaming apps using youtube as a source get around this — are they doing something different under the hood? A custom player? A SafariViewController trick? Is there a specific way to configure WKWebView to keep playing in the background, or is this a known limitation? Would really appreciate any insight from folks who’ve explored this before or know how apps like Musi pulled it off. Thanks in advance!

Hi folks!! Anyone here experienced issues with video not showing up in webview? I have a simple index.html with a video tag but its doesn't load why?

I want to confirm the specifications and behavior of Safari. We have a system built on Microsoft Azure that uses Azure AD B2C for authentication. When we logging in, there is a phone authentication feature where a call is made to the registered phone number. However, this phone authentication does not work properly only on iPhone's Safari. The specific situation is listed below: When performing phone authentication on iPhone's Safari, a call is made from Azure AD B2C, and pressing the # button on the Safari screen can be done. But then, it transitions to an error screen. We tried multiple iPhone devices and multiple iOS versions, but the result was the same. But when accessing the system on a PC, and performing phone authentication, it works without any errors. Also when we use browsers other than Safari (for example, Google Chrome and Firefox) on the iPhone, the phone authentication works without any errors, too. Even with Safari, if the device displaying the login screen and the device making the call are different, phone authentication works without any errors, too.(it fails if they are the same device). We reached out Microsoft about this issue, and they responded that: The Azure resource called FrontDoor at the front end of Azure AD B2C supports the HTTP/2 protocol, and HTTP/2 protocol is used in communication with Safari. In Safari's HTTP/2 communication, when a call is received while the screen is displayed, a reset packet is sent to the web server (in this case, the web server is FrontDoor). This interrupts the session, causing a session termination error on the Azure AD B2C side, and phone authentication fails. Therefore, we would like to ask you the following two points: In HTTP/2 communication, does the Safari browser send a reset packet to the web server when it receives a phone call? If so, what is the cause of this behavior? And are there any measures to prevent the reset packet from being sent?

We are encountering a download issue in Safari 18.2 on macOS Sequoia 15.2 where file downloads initiated by our AngularJS application (such as Excel exports) are silently blocked. There are no errors in the browser console, and the download does not occur. Interestingly, after testing on Safari 18.3 with Sequoia 15.3, the downloads worked as expected. However, the problem reappeared on Safari 18.4 with Sequoia 15.4. We suspect that recent changes in Safari’s security or download handling may be preventing downloads triggered via asynchronous JavaScript (e.g., AJAX calls) that are not initiated directly by user interaction. We would appreciate any insights, suggestions, or possible workarounds from the community. Looking forward to your guidance on this matter.

iOS 26 (from beta 1 to beta 2) We have a VPN app that installs a per-app VPN profile with SafariDomains to filter Safari network traffic. This setup works as expected on iOS versions lower than 26.0. See here more details on SafariDomains: https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf On iOS 26, all SafariDomains configured to go through the per-app VPN result in the following error: "Safari can’t open the page. The error was: Unknown Error" Additional Details: Only SafariDomains encounter this error. Other managed apps traffic through the per-app VPN works correctly. Steps to Reproduce: Install the VPN app with a per-app VPN profile. Configure SafariDomains with any URL (e.g., example.com). Open Safari and navigate to the configured URL. Example Configuration: We tested with a simple example by adding only one URL to SafariDomains (example.com). Logs from the console were captured at the moment Safari opened and encountered the error. safari_google2.txt Has anyone else encountered this issue on iOS 26? Any insights or solutions would be greatly appreciated. Thank you!

Dear Apple Developer Support Team, I am writing regarding critical issues we are facing with Safari web push notifications in our application iLiveMyLife.io, which is severely impacting our ability to maintain reliable communication with our users. Issue Description: We are experiencing persistent problems with Safari push notification tokens expiring or becoming invalid without any notification to our server. This creates several critical issues: Users stop receiving notifications without any indication of failure Our notification delivery system has no way to detect token expiration The expiration appears to happen frequently (seemingly almost daily in some cases) There is no reliable mechanism to re-establish push communication without users manually revisiting the app Technical Impact: Our messaging functionality becomes completely unreliable We must resort to email or SMS as fallback mechanisms, which is not feasible for a real-time communication platform This makes building any reliable messaging application on Safari practically impossible The Broader Context: What makes this situation particularly challenging is that all potential alternative browser APIs that could help address this issue appear to be deliberately disabled or restricted in Safari: Background Service Workers don't function in the background on iOS Safari Background Sync API is not supported WebSockets cannot operate when the app is closed There's no way to programmatically check the validity of push tokens The combination of these limitations creates a situation where developers have no viable technical path to build reliable notification systems for PWAs on Safari. This appears to be a systematic restriction rather than individual API limitations. Requested Information: Is there a recommended approach to detect Safari push token expiration? Are there alternative notification mechanisms for PWA applications on Safari that offer more reliability? Is there documentation on the lifecycle of Safari push tokens that could help us implement proper handling? Are there plans to improve the Web Push API implementation in Safari to address these reliability issues? Could you clarify if these limitations are intentional design decisions or technical constraints that might be addressed in future updates? Business Impact: This issue fundamentally undermines our platform's core functionality. For a collaborative tool, reliable notifications are essential - users cannot collaborate effectively if they miss updates because their push tokens silently expired. The current state creates confusion among our users, who don't understand why they suddenly stop receiving notifications. Any guidance or assistance you could provide would be greatly appreciated. We're committed to providing an excellent experience on Safari, but the current push notification limitations make this extremely challenging. Thank you for your time and consideration. Best regards, Ilya

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?

Hi everyone, I'm exploring the new app icon appearance options (Clear, Dark, Tinted) for Progressive Web Apps (PWAs) on iOS26, iPadOS26, and macOS26. Currently, PWA icons don't seem to render well with these new appearances, particularly in Clear and Tinted modes, resulting in very very poor visual quality. You can hardly see anything. Has support for these icon appearances been fully implemented for PWAs? If so, could someone point me to the relevant Apple Developer documentation or provide guidance on how to configure PWA icons to support Clear, Dark, and Tinted appearances? I've searched the Apple Developer Forums, Stack Overflow, and Reddit but haven't found clear information on this topic.A possible solution is a png file with transparent areas, but if the pattern is dark, nothing will be visible in dark mode. Any insights or resources would be greatly appreciated. Thanks! (plz don't give up on PWA😭) Reference: https://developer.apple.com/forums/thread/761615 https://stackoverflow.com/questions/78780916/is-there-a-way-to-provide-light-dark-and-tinted-variants-of-apple-touch-icon https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html

iOS 18.4 introduces the new WKWebExtension API to support extensions in WKWebView. However, for extensions that have migrated to Manifest V3 and use an extension service worker as the background script, it's currently not possible to inspect them through Safari. This is only thing I can see, I don't know how to inspect the details of the "background.js" I'm wondering—has this changed? Is it now possible to inspect extension service workers?

Based on the "Build immersive web experiences with WebXR"-Video for visionOS there is no way to disable the consent prompts for entering an immersive experience or consent hand-tracking. For the microphone it's possible to "greenlight" specific websites for mic input, which works great. I'd welcome it, if it were possible to add specific websites in the settings, in which those consent dialogs aren't shown each time. In my opinion, the user interaction through a button that launches the experience would be sufficient to not disorient.

I'm facing an unexpected cancel event, when i get a merchantSession from my sever, and call completeMerchantValidation, then applepay client give a oncancel event, with error: unknown info:{} the session is : { "epochTimestamp": 1762116084960, "expiresAt": 1762119684960, "merchantSessionIdentifier": "SSH60E2321574454A9FB4015EFF24C8769E_CCE257A9D27B42513B2C3CA67DB49F602F3450D996C0811ED462EDCA0D7477FD", "nonce": "43fb3a9a", "merchantIdentifier": "ABD51C33E9F2E612C0D594921DEC478118D23C77525223127FC716DA8589FDDC", "domainName": "checkout.peppr.com", "displayName": "Heji Guilin Rice Noodle", "signature": "308006092a864886f70d010702a0803080020101310d300b0609608648016503040201308006092a864886f70d0107010000a080308203e330820388a003020102020816634c8b0e305717300a06082a8648ce3d040302307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3234303432393137343732375a170d3239303432383137343732365a305f3125302306035504030c1c6563632d736d702d62726f6b65722d7369676e5f5543342d50524f4431143012060355040b0c0b694f532053797374656d7331133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d03010703420004c21577edebd6c7b2218f68dd7090a1218dc7b0bd6f2c283d846095d94af4a5411b83420ed811f3407e83331f1c54c3f7eb3220d6bad5d4eff49289893e7c0f13a38202113082020d300c0603551d130101ff04023000301f0603551d2304183016801423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b304506082b0601050507010104393037303506082b060105050730018629687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65616963613330323082011d0603551d2004820114308201103082010c06092a864886f7636405013081fe3081c306082b060105050702023081b60c81b352656c69616e6365206f6e207468697320636572746966696361746520627920616e7920706172747920617373756d657320616363657074616e6365206f6620746865207468656e206170706c696361626c65207374616e64617264207465726d7320616e6420636f6e646974696f6e73206f66207573652c20636572746966696361746520706f6c69637920616e642063657274696669636174696f6e2070726163746963652073746174656d656e74732e303606082b06010505070201162a687474703a2f2f7777772e6170706c652e636f6d2f6365727469666963617465617574686f726974792f30340603551d1f042d302b3029a027a0258623687474703a2f2f63726c2e6170706c652e636f6d2f6170706c6561696361332e63726c301d0603551d0e041604149457db6fd57481868989762f7e578507e79b5824300e0603551d0f0101ff040403020780300f06092a864886f76364061d04020500300a06082a8648ce3d0403020349003046022100c6f023cb2614bb303888a162983e1a93f1056f50fa78cdb9ba4ca241cc14e25e022100be3cd0dfd16247f6494475380e9d44c228a10890a3a1dc724b8b4cb8889818bc308202ee30820275a0030201020208496d2fbf3a98da97300a06082a8648ce3d0403023067311b301906035504030c124170706c6520526f6f74204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3134303530363233343633305a170d3239303530363233343633305a307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d03010703420004f017118419d76485d51a5e25810776e880a2efde7bae4de08dfc4b93e13356d5665b35ae22d097760d224e7bba08fd7617ce88cb76bb6670bec8e82984ff5445a381f73081f4304606082b06010505070101043a3038303606082b06010505073001862a687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65726f6f7463616733301d0603551d0e0416041423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b300f0603551d130101ff040530030101ff301f0603551d23041830168014bbb0dea15833889aa48a99debebdebafdacb24ab30370603551d1f0430302e302ca02aa0288626687474703a2f2f63726c2e6170706c652e636f6d2f6170706c65726f6f74636167332e63726c300e0603551d0f0101ff0404030201063010060a2a864886f7636406020e04020500300a06082a8648ce3d040302036700306402303acf7283511699b186fb35c356ca62bff417edd90f754da28ebef19c815e42b789f898f79b599f98d5410d8f9de9c2fe0230322dd54421b0a305776c5df3383b9067fd177c2c216d964fc6726982126f54f87a7d1b99cb9b0989216106990f09921d00003182018730820183020101308186307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553020816634c8b0e305717300b0609608648016503040201a08193301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3235313130323230343132345a302806092a864886f70d010934311b3019300b0609608648016503040201a10a06082a8648ce3d040302302f06092a864886f70d010904312204200dd015b60ad5539b1a06704eaacab7d5f2b509aeeaee4de3db0e68771b6c1549300a06082a8648ce3d040302044630440220267b23d8330b8fd6fd78ee68a2b6315b5db65c60e5453c54ccc70a6fe1e800c502204a909d3e6741b8dc82c55edd5c9e569951ee1e45593aa4e3b249b0bfff0314cf000000000000", "operationalAnalyticsIdentifier": "Heji Guilin Rice Noodle:ABD51C33E9F2E612C0D594921DEC478118D23C77525223127FC716DA8589FDDC", "retries": 0, "pspId": "6C8FB940FD816AC15282D94009E72179FC9E5FFBC5712B366EB4364CAFB25153" }

Safari Extension Error: “Non-persistent background content cannot listen to webRequest events.” after macOS 15.4 / Safari 18.4 Update We’re seeing the following error in the Safari Extensions tab after updating to macOS 15.4 and Safari 18.4: “Non-persistent background content cannot listen to webRequest events.” This error did not appear prior to the update, and we haven’t found any official documentation stating that webRequest API is no longer supported in Safari. In our extension (Manifest V3), we are using the webRequest.onHeadersReceived callback to intercept response headers and read updated cookies. While the functionality itself still works as expected. we’re able to access the response headers and this error is now shown in the Extension settings page. We are not seeing this issue in other browsers (Chrome, Firefox) using the same Manifest V3 setup. Is there any plan to deprecate webRequest support in Manifest V3 for Safari? We’d appreciate any clarification or guidance on how to handle this going forward.