I have a UI application built with the Vue framework, using Vuetify for the UI components. There's a div with the class v-application--wrap, which is provided by Vuetify. This class internally includes the following style rule. .v-application--wrap { backface-visibility: hidden; display: flex; flex: 1 1 auto; flex-direction: column; max-width: 100%; min-height: 100vh; position: relative; } The pages were rendering correctly up to version 18.3, but after upgrading to version 18.4, we encountered layout issues related to height. Upon investigation, we discovered that the min-height property was no longer being interpreted or applied correctly. Replacing min-height with height resolved the issue, and the pages began loading as expected. Any insights into why this behavior is occurring would be greatly appreciated.

version:26.0-23A5308g Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan 103.667]. Layer: <CALayer:0x15793f720; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x10f962f80; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x15793f720>>; sublayers = (<CALayer: 0x155964e70>, <CALayer: 0x15793eaf0>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0>'

Apple must comply with the requirements of the Level Index, the global digital credit gateway, and suspend gift cards and similar services until formal arrangements are made with service providers.

Our app encountered a new crash since beta5(23A5308g) released last week,and it seems the crash is not solved yet in beta6(23A5318c).The crash stack below `-[UIView _backing_setPosition:] -[UIView setCenter:] -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] ___54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] -[_UIEditMenuContentPresentation _displayMenu:reason:] -[_UIEditMenuContentPresentation displayMenu:configuration:] ___58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke ___80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke ___109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke ___107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) WTF::Detail::CallableWrapper<IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)> >(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::{lambda(IPC::Connection*, IPC::Decoder*)#1}, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRefIPC::Encoder&&, WTF::OptionSetIPC::SendOption, std::__1::optionalIPC::ConnectionAsyncReplyHandler, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) IPC::Connection::dispatchIncomingMessages() WTF::RunLoop::performWork() WTF::RunLoop::performWork(void*) _CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION ___CFRunLoopDoSource0 ___CFRunLoopDoSources0 ___CFRunLoopRun __CFRunLoopRunSpecificWithOptions _GSEventRunModal -[UIApplication _run] _UIApplicationMain main main.m start

What happens if Safari is uninstalled or disabled on iOS? Will SFafariviewcontroller still work? Kind regards

Hello - we have a Mac application that uses a browser extension and the web extension JS APIs to communicate with Safari. During user testing we found that the tab title and tab URL properties are empty when obtaining the set of open windows via windows.get() after a Safari restart. We are testing with Safari 18.4 (20621.1.15.11.10). We have made a TestFlight version of our app and extension available to help with testing: https://testflight.apple.com/join/Va8Zdv9d. Screenshot and screen recording are attached to the Feedback ID supplied below. STEPS TO REPRODUCE Install Tabby via the TestFlight link Enable the Tabby for Safari extension in the Safari extensions dialog Grant permissions for Tabby for Safari to all windows all the time Within Safari, open two windows each with at least two tabs Within the Tabby app, ensure you see the windows and tabs listed correctly (tab title displayed for each) Quit and restart Safari Expected behavior Safari re-opens existing windows and Tabby displays title for each tab Observed Safari re-opens existing windows but within Tabby all tabs except the current tab are displayed with a title of “Start Page”. Under the hood the tab title and tab URL properties are empty when returned via a windows.get() call after Safari restarts. NAME AND APPLE ID OF APP Tabby - Browser Tab Manager 1586203406 FEEDBACK ASSISTANT ID FB16389506

0x158c2ce18 - [pageProxyID=33, webPageID=34, PID=883] WebPageProxy::didFailProvisionalLoadForFrame: frameID=4294967298, isMainFrame=1, domain=NSURLErrorDomain, code=-999, isMainFrame=1, willInternallyHandleFailure=0 Error Domain=NSURLErrorDomain Code=-999 "已取消" UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <9A09D8F8-351D-4BE3-A1F7-0E2E325DC7BA>.<4>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <9A09D8F8-351D-4BE3-A1F7-0E2E325DC7BA>.<4>" ), NSLocalizedDescription=已取消, _WKRecoveryAttempterErrorKey=<WKReloadFrameErrorRecoveryAttempter: 0x159acf6c0>, networkTaskDescription=LocalDataTask <9A09D8F8-351D-4BE3-A1F7-0E2E325DC7BA>.<4>, NSErrorFailingURLStringKey=https://oamobile.zmmc.com.cn:28385/pages/Reports/ZBReport.aspx?ShowInLegend=true&appid=69b487001fcc11bc30c7344e50768c3c&userid=9784299b-cced-4702-91b0-0476511ba8d2, NSErrorFailingURLKey=https://oamobile.zmmc.com.cn:28385/pages/Reports/ZBReport.aspx?ShowInLegend=true&appid=69b487001fcc11bc30c7344e50768c3c&userid=9784299b-cced-4702-91b0-0476511ba8d2, networkTaskMetricsPrivacyStance=Unknown} Failed to terminate process: Error Domain=com.apple.extensionKit.errorDomain Code=18 "(null)" UserInfo={NSUnderlyingError=0x159bd1830 {Error Domain=RBSRequestErrorDomain Code=3 "No such process found" UserInfo={NSLocalizedFailureReason=No such process found}}} After upgrade to ios 26， if WKWebView load url which did not contain "#" will always ok. but load url contain “#” will cancel when start load, then result in white screen

On iOS 26 Beta, WKWebView consistently crashes when interacting with pages that use -webkit-user-select: none. This issue does not reproduce in Safari, but only when the same content is loaded inside a WKWebView. Steps to Reproduce: Install iOS 26 Beta. Open a WKWebView that loads a webpage with the following style applied globally: -webkit-user-select: none; Perform the following gesture sequence inside the WKWebView: Double tap anywhere in the web content. On the second tap, keep your finger pressed (do not lift). While still holding the second tap, drag your finger across the screen (pan). This sequence reliably produces the crash. Expected Result: No crash. The gesture should either be ignored or handled gracefully. Actual Result: The app crashes 100% of the time with the following exception: #0 0x000000013f1a0874 in __pthread_kill () #1 0x00000001357522ec in pthread_kill () #2 0x00000001801ad950 in abort () #3 0x00000001802fa26c in __abort_message () #4 0x00000001802ea1a4 in demangling_terminate_handler () #5 0x0000000180077218 in _objc_terminate () #6 0x00000001802f9758 in std::__terminate () #7 0x00000001802fc7c0 in __cxxabiv1::failed_throw () #8 0x00000001802fc7a0 in __cxa_throw () #9 0x000000018009c1bc in objc_exception_throw () #10 0x00000001804f38f8 in +[NSException raise:format:] () #11 0x000000018c5fb570 in -[CALayer setPosition:] () #12 0x0000000185d02414 in -[UIView _backing_setPosition:] () #13 0x00000001867ec978 in -[UIView setCenter:] () #14 0x0000000186666468 in -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] () #15 0x0000000186666088 in __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke () #16 0x00000001867b3ed4 in -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] () #17 0x0000000186665fb0 in -[_UIEditMenuContentPresentation _displayMenu:reason:] () #18 0x0000000186665de4 in -[_UIEditMenuContentPresentation displayMenu:configuration:] () #19 0x00000001867b3260 in __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke () #20 0x00000001867b4c98 in __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke () #21 0x000000018653ff80 in __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke () #22 0x0000000186540448 in __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke () #23 0x000000018dba84f8 in WTF::Detail::CallableWrapper<WTF::CompletionHandler<void (IPC::Connection*, IPC::Decoder*)> IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>>(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*>::call () #24 0x000000018dca14cc in WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef<IPC::Encoder>&&, WTF::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call () #25 0x000000018e2d5c54 in IPC::Connection::dispatchMessage () #26 0x000000018e2d6118 in IPC::Connection::dispatchIncomingMessages () #27 0x00000001997f9c58 in WTF::RunLoop::performWork () #28 0x00000001997fa930 in WTF::RunLoop::performWork () #29 0x000000018044d4dc in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () #30 0x000000018044d424 in __CFRunLoopDoSource0 () #31 0x000000018044cc0c in __CFRunLoopDoSources0 () #32 0x000000018044bd84 in __CFRunLoopRun () #33 0x0000000180446e24 in _CFRunLoopRunSpecificWithOptions () #34 0x00000001924c19bc in GSEventRunModal () #35 0x00000001862217a8 in -[UIApplication _run] () #36 0x00000001862259d0 in UIApplicationMain () Same issues below. https://developer.apple.com/forums/thread/796799 https://developer.apple.com/forums/thread/796501 https://developer.apple.com/forums/thread/796874 https://developer.apple.com/forums/thread/796686

Our team has implemented a video player using the HTML5 tag, but we have identified an issue with loading media files. While Safari on iOS 18.0 downloads each TS file listed in the m3u8 playlist correctly, on iOS 18.4 and 18.5, a single TS file is downloaded repeatedly. Our statistics indicate that approximately six requests are made per second for the same TS file. Is this intended behavior? If not, are there any known workaround or solutions? If this issue is due to the OS or browser, are there any plans to address it in iOS 18.6 or a future release? Could you advise on the proper channel to submit a bug report for this issue? Similar issues have been reported in the past with WKWebView. The previous thread is here: https://developer.apple.com/forums/thread/784134

I recently noticed that putting the app on background for some time, then switching back to it again causes the WKWebView to reload the current page, same with just hitting f5 on it. How do we disable this behavior?

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!

If we use webView.loadFileURL(indexURL, allowingReadAccessTo: readAccessURL) on an iPad it loads the data and navigation works. But if we place two hands on top of the screen and move a bit, all click events are not working anymore. It works again if we call loadFileURL again. We filled a bug report: FB19812304

On iPhone 16 running iOS 18.0(Xcode 16.2), cookies configured with SameSite=None; Secure fail to apply correctly—iOS forcibly converts the attribute to SameSite=Lax. As a result, cross-site requests from H5 pages within our app cannot carry the required cookies, causing failures. Can anyone help me on this? Thanks in advance.

As you see in the image, when I fullscreen in WKWebView, it shows black instead of the webpage in full screen. It works fine in Sequoia. It has happened to me since beta 1, but I post it now, because we’re in beta 8 and it’s not fixed. What’s going on? Can somebody tell me if they have the same issue?

I use WKWebView to display a webpage that requires authentication through an authentication provider. This works as expected, but when I close and reopen the app, I have to reauthenticate. However, if I open the same page in Safari, I only have to authenticate once. If I close Safari and reopen it, the page displays without prompting me to authenticate again. I see some cookies stored in httpCookieStore, so I assume that storing cookies works. Does anyone have an idea why authentication is not persistent between app launches? Thanks in advance. Best regards, Marc

Hi,
 We’re implementing Apple Pay on the Web for a multi-tenant platform via a PSP. The PSP operates multiple HSM/clusters and gave us multiple CSRs, asking us to register all.
Our understanding: a Merchant ID can hold several PPCs over time, but only one is active at once. Questions Is there any supported way to keep more than one PPC active simultaneously for the same Merchant ID? If not, what does Apple recommend for web-only, multi-tenant setups: a single MID with PSP-side decryption & sub-merchant separation, or separate MIDs per brand/region? Any official guidance on PPC rotation and handling many domains for Apple Pay on the Web? links to official docs or prior Apple responses would be appreciated.

Even default Safari Web Extension project is not displayed on iOS 18.4 simulator ("No extensions installed"), so it's not possible to test extensions in simulator, only on real device.

Hello all, As you may know, the company ProofPoint is an Apple partner, and is engaged (I think) to reduce misuse of icloud emails. We have two servers solely set up for our web-app, which is a specialised forum for apartment owners. The new servers were established about the same time, with the same provider, with clean new IP addresses - and as mentioned above, are only used for this web-app. During a testing phase a YEAR ago, we became aware that our in-house icloud emails weren't receiving notifications via the app, and further investigations revealed that the cause was that ProofPoint had placed a block on that server's IP. We immediately, via their website form initiated a Support Ticket, which, the site indicated was lodged, BUT we have never received any response to that Ticket, nor have we received any response to four subsequent Tickets we initiated - nothing. In over a year!! Yesterday, we contacted Apple support, but the devices area of support is the main section and they said it wasn't an issue they could assist with. Some relevant matters: SPF: DKIM: DMARC: are, I believe all configured correctly (and Gmail gives a PASS to all of them). The IP is not blacklisted by any list we are aware of. Our other server's IP isn't blocked by ProofPoint. So, literally at wits end, I'm reaching out to the developer subscribers here to see if they have any suggestions for us. We currently are unable to accept any new subscriber that is using an icloud email address, and that's an absurd situation to be in. Surely we don't have to go to the trouble and inconvenience of obtaining a new IP because of this!!! But when we can't get ANY response to the Support Tickets, it's really hard. Thanks

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.

window.location.href = "tel:02-xxxx-xxxx" Can the development team modify the screen text? Or can the country code be erased? What are the reasons for continuing to be "on the phone" if the country code is automatically attached to the phone like this?