I have "http://localhost:8080" showing the index page I've created but php is not handled though an extension is running. Haven't even tried mySQL yet but since there is no reference to it in https.conf the same problem will exist. Homebrew extension running also. https.conf: #PHP was deprecated in macOS 11 and removed from macOS 12 #LoadModule php7_module libexec/apache2/libphp7.so There are no php.so files on my machine and again no mention of mysql What should I enter in http.conf to activate these functionalities? Thanks. PS could you reference a tutorial on using Safari and Web inspector

Environment • Device: iOS 26 Developer Beta 5 (23A5308g) • Xcode: 16.3 Short description The app crashes the moment the user tries to long-press to select text inside a WKWebView, double-tap an image with Text (magnifier appears) The exception is CALayer position contains NaN. frame = (nan,0;0,48) chorPoint=(inf, 0) and it is thrown in the UI process. Build & run any project that hosts a WKWebView. Inject the following CSS via script (this is what we do to suppress the native callout menu): WKWebView *webView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:[WKWebViewConfiguration new]]; NSString *js = @"document.documentElement.style.webkitUserSelect='none';" "document.documentElement.style.webkitTouchCallout='none';"; [webView evaluateJavaScript:js completionHandler:nil]; [self.view addSubview:webView]; Incident Identifier: EE6FB046-5087-4F15-A72D-A74965347A30 CrashReporter Key: 29e8e58e02a07557adb4ce3f463d764f3ce8bbd5 Hardware Model: iPhone16,1 Process: wallet [642] Path: /private/var/containers/Bundle/Application/4B4E609A-C8BF-4C56-AB2A-1638249B98A5/wallet.app/wallet Identifier: xxxx Version: xxxx AppStoreTools: 16F7 AppVariant: 1:iPhone16,1:18 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: xxxxx Date/Time: 2025-08-06 12:05:24.0732 +0800 Launch Time: 2025-08-06 11:49:40.3802 +0800 OS Version: iPhone OS 26.0 (23A5308g) Release Type: Beta Baseband Version: 3.02.02 Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: wallet [642] Triggered by Thread: 0 Application Specific Information: abort() called Last Exception Backtrace: 0 CoreFoundation 0x185e058c8 __exceptionPreprocess + 164 1 libobjc.A.dylib 0x182d797c4 objc_exception_throw + 88 2 CoreFoundation 0x185e908d4 -[NSException initWithCoder:] + 0 3 QuartzCore 0x18678a874 CA::Layer::set_position(CA::Vec2<double> const&, bool) + 160 4 QuartzCore 0x1869a7270 -[CALayer setPosition:] + 52 5 UIKitCore 0x18c4ac564 -[UIView _backing_setPosition:] + 176 6 UIKitCore 0x18cefdf0c -[UIView setCenter:] + 220 7 UIKitCore 0x18cd9f794 -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] + 936 8 UIKitCore 0x18cd9f3c0 __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke + 104 9 UIKitCore 0x18ced1060 -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] + 384 10 UIKitCore 0x18cd9f2e4 -[_UIEditMenuContentPresentation _displayMenu:reason:] + 304 11 UIKitCore 0x18cd9f0d8 -[_UIEditMenuContentPresentation displayMenu:configuration:] + 64 12 UIKitCore 0x18ced0344 __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke + 260 13 UIKitCore 0x18ced1f8c __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke + 80 14 UIKitCore 0x18cc8403c __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke + 180 15 UIKitCore 0x18cc84584 __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke + 148 16 WebKit 0x1a05ae5d4 WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) + 64 17 WebKit 0x1a05bb468 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(IPC::Connection*, IPC::Decoder*) + 196 18 WebKit 0x19fcf5db8 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(IPC::Connection*, IPC::Decoder*) + 64 19 WebKit 0x19fce54f0 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 340 20 WebKit 0x19fcf5aa0 IPC::Connection::dispatchIncomingMessages() + 536 21 JavaScriptCore 0x19a8f85d4 WTF::RunLoop::performWork() + 552 22 JavaScriptCore 0x19a8f838c WTF::RunLoop::performWork(void*) + 36 23 CoreFoundation 0x185da6230 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 24 CoreFoundation 0x185da61a4 __CFRunLoopDoSource0 + 172 25 CoreFoundation 0x185d83c6c __CFRunLoopDoSources0 + 232 26 CoreFoundation 0x185d598b0 __CFRunLoopRun + 820 27 CoreFoundation 0x185d58c44 _CFRunLoopRunSpecificWithOptions + 532 28 GraphicsServices 0x224ce0498 GSEventRunModal + 120 29 UIKitCore 0x18b6c84b8 -[UIApplication _run] + 792 30 UIKitCore 0x18b66cbc0 UIApplicationMain + 336 31 wallet 0x1046f8558 0x1046f4000 + 17752 32 dyld 0x182dcdb18 start + 6332

We’re currently working on an OTT-based application where we integrate Google Ad Manager to serve video ads. As part of the ad experience, users often see a “Learn More” CTA (Call to Action) on these ads. As per our current requirement, when a user taps “Learn More” on an ad: • The link should open in Safari (i.e., an external browser) on iOS devices • The Safari browser should ideally open in portrait orientation, as the ad content and layout are optimised for portrait mode However, based on our understanding and technical constraints on iOS, it appears that: • Orientation control is restricted to the app’s own context. • Once Safari is launched via UIApplication.shared.open, we no longer have control over how it behaves in terms of orientation. • iOS system behaviour determines Safari’s orientation based on the device’s physical orientation and Safari’s own internal configuration. Could you please confirm if there’s any supported way (via SDK, deep link config, or otherwise) to enforce portrait orientation in Safari when opening such external URLs from within an iOS app? If this is not technically feasible, we would appreciate any best practices or alternatives you can suggest for ensuring a consistent user experience.

Currently, im on MacOS Tahoe 26 Public Beta 2, build number 25A5327h. I just recently updated to this, and now, whenever I open some sites like Amazon, or ChatGPT, it freezes my entire browser and I have to force quit it. I tried deleting the SpeakSelection.plist file which everyone swore worked, but not for me. Is this because the new update messed with resource allocation or did my user data corrupt mid-update and i have to transfer all my stuff to a new user?

Hi Apple Developer Community and Support, We are implementing Apple Pay on the Web and are encountering a persistent issue with merchant validation when the ApplePaySession is initiated from a JavaScript application running within a cross-origin iframe. Our Setup: Top-Level Domain: https://application.my.com/ (where the Apple Pay button is displayed, and the iframe is embedded) iFrame Content Origin: https://cashier.my.com/ (Our custom JavaScript application that handles the Apple Pay integration and directly calls our Payment Service Provider's (PSP) API for merchant validation). iFrame allow attribute: The iframe correctly includes allow="payment *". The Problem: When a user clicks the Apple Pay button, the ApplePaySession is successfully created and the Apple Pay sheet opens in Safari iOS. This suggests the browser recognizes the allow="payment *" attribute and allows the API calls. However, during the session.onvalidatemerchant callback, our JavaScript code makes a direct API call to our PSP (Nuvei)'s endpoint. This call consistently fails with an "Invalid domain name!" error, and the Apple Pay sheet then shows "Payment Not Completed." PSP's Diagnosis: Our PSP (Nuvei) has investigated and stated that for this specific endpoint (getAppleValidationApiFlow.do), "there is no explicit way to pass domain to the endpoint and domain for which session is issued is based on 'Referer' header." Our Question for Apple: Given that Safari 17+ now supports allow="payment" for cross-origin iframes to enable Apple Pay APIs, we have the following questions: What is Apple's official guidance or expectation regarding the Referer header for ApplePaySession.onvalidatemerchant calls when the ApplePaySession is instantiated from a cross-origin iframe? Is it expected that the Referer header for calls originating from the iFrame will always be the iFrame's origin? Does Apple's merchant validation process (when the PSP calls apple-pay-gateway.apple.com/paymentservices/startSession) itself rely on or interpret the Referer from the initial client-to-PSP call? Are there recommended best practices or standard approaches for PSP integrations in this cross-origin iFrame scenario to ensure the Referer validation (or equivalent domain validation) is correctly satisfied? We're trying to understand if our PSP's specific reliance on the Referer for this validation is a standard requirement implicitly set by Apple for this flow, or if there are other architectural approaches that should allow this scenario to work seamlessly. Thank you for any insights or guidance you can provide.

When practicing a post request today I forgot to use the setvalue method. Why is this method important and needed for a post request? Don't we just encode the data to JSON and put that as the httpbody and make the request

When CHIPS was introduced in 18.4 it worked well, however on 18.5 it does not appear to work. There do not appear to be release notes about this in 18.5, so can someone provide definitive if this is a defect that will be fixed, or have they already been deprecated?

I have a Net8 Maui WebView app and whenever I use magnifier, it crashes. The magnifier works on iOS18 and lower but crashes on iOS26+ Exception **Type:** CALayerInvalidGeometry **Value:** CALayer position contains NaN: [nan 65]. Layer: <CALayer:0x123e88e40; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x116f2f200; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x123e88e40>>; sublayers = (<CALayer: 0x125232df0>, <CALayer: 0x123e88e70>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0> Stacktrace __exceptionPreprocess in unknown file [Line null, column null] (Not in app) objc_exception_throw in unknown file [Line null, column null] (Not in app) +[NSException raise:format:] in unknown file [Line null, column null] (Not in app) CA::Layer::set_position in unknown file [Line null, column null] (Not in app) -[CALayer setPosition:] in unknown file [Line null, column null] (Not in app) -[UIView _backing_setPosition:] in unknown file [Line null, column null] (Not in app) -[UIView setCenter:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] in unknown file [Line null, column null] (Not in app) __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke in unknown file [Line null, column null] (Not in app) -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation _displayMenu:reason:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation displayMenu:configuration:] in unknown file [Line null, column null] (Not in app) __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke in unknown file [Line null, column null] (Not in app) __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app) __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app) __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)

How to allocate the width of each column when customizing the rendering of HTML tables on iOS with limited screen width

Can anyone of Apple give a status update whats planed with CC module scripts? Issue: https://bugs.webkit.org/show_bug.cgi?id=227967

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

Hey, very strange problem I have on iOS when shared web as an app (pwa) to home screen. Whenever I use it via safari browser on iPhone, it works 100% fine every time. However, when I put it as an app on home screen, first time I open it it works fine, when i close it and reopen again, it just doesnt start recording. I have to restart my phone for it to work. So it works one time, I guess somehow it doesnt end stream or something, but in code I've tried all the possible ways to close and clean the track. tried GPT, Claude, Gemini solutions. nothing worked, it just works 1 time as PWA. my last hope is someone else encountered this issue and may try to help me ? https://pastebin.com/85i2L2vH

Crash Stack: thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x19ba3bb04) frame #0: 0x000000019ba3bb04 CoreFoundation`forwarding.cold.2 + 92 frame #1: 0x000000019b8ab718 CoreFoundation`forwarding + 1288 frame #2: 0x000000019b8ab150 CoreFoundation`_CF_forwarding_prep_0 + 96 frame #3: 0x000000019df230b0 CoreText`TCFRef<CTRun*>::Retain(void const*) + 40 frame #4: 0x000000019e052050 CoreText`CreateFontWithFontURL(__CFURL const*, __CFString const*, __CFString const*) + 476 frame #5: 0x000000019e052874 CoreText`TCGFontCache::CopyFont(__CFURL const*, __CFString const*, __CFString const*) + 144 frame #6: 0x000000019df27dcc CoreText`TBaseFont::CopyNativeFont() const + 232 frame #7: 0x000000019df8ee64 CoreText`TBaseFont::GetInitializedGraphicsFont() const + 152 frame #8: 0x000000019df26d70 CoreText`TBaseFont::CopyVariationAxes() const + 296 frame #9: 0x000000019df2d148 CoreText`TDescriptor::InitBaseFont(unsigned long, double) + 768 frame #10: 0x000000019df21358 CoreText`TDescriptor::CreateMatchingDescriptor(__CFSet const*, double, unsigned long) const + 604 frame #11: 0x000000019df251f8 CoreText`CTFontCreateWithFontDescriptor + 68 frame #12: 0x00000001bff8dfb8 WebCore`WebCore::createCTFont(__CFDictionary const*, float, unsigned int, __CFString const*, __CFString const*) + 124 frame #13: 0x00000001bff8e8bc WebCore`WebCore::FontPlatformData::fromIPCData(float, WebCore::FontOrientation&&, WebCore::FontWidthVariant&&, WebCore::TextRenderingMode&&, bool, bool, std::__1::variant<WebCore::FontPlatformSerializedData, WebCore::FontPlatformSerializedCreationData>&&) + 228 frame #14: 0x00000001c128eef4 WebKit`IPC::ArgumentCoder<WebCore::Font, void>::decode(IPC::Decoder&) + 1352 frame #15: 0x00000001c1333ca4 WebKit`std::__1::optional<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>> IPC::ArgumentCoder<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>, void>::decodeIPC::Decoder(IPC::Decoder&) + 480 frame #16: 0x00000001c1333a5c WebKit`std::__1::optional<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>> IPC::Decoder::decode<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>() + 28 frame #17: 0x00000001c1333804 WebKit`std::__1::optional<std::__1::pair<WebCore::AttributedString::Range, WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>> IPC::Decoder::decode<std::__1::pair<WebCore::AttributedString::Range, WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>>() + 156 frame #18: 0x00000001c121f368 WebKit`IPC::ArgumentCoder<WebCore::AttributedString, void>::decode(IPC::Decoder&) + 172 frame #19: 0x00000001c121f124 WebKit`std::__1::optionalWebCore::AttributedString IPC::Decoder::decodeWebCore::AttributedString() + 28 frame #20: 0x00000001c12594ec WebKit`IPC::ArgumentCoder<WebCore::DictionaryPopupInfo, void>::decode(IPC::Decoder&) + 76 frame #21: 0x00000001c12d0660 WebKit`std::__1::optionalWebCore::DictionaryPopupInfo IPC::Decoder::decodeWebCore::DictionaryPopupInfo() + 28 frame #22: 0x00000001c12ceef0 WebKit`IPC::ArgumentCoder<WebKit::WebHitTestResultData, void>::decode(IPC::Decoder&) + 1292 frame #23: 0x00000001c1338950 WebKit`std::__1::optionalWebKit::WebHitTestResultData IPC::Decoder::decodeWebKit::WebHitTestResultData() + 28 frame #24: 0x00000001c1ec7edc WebKit`WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 31392 frame #25: 0x00000001c1fb8f28 WebKit`IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272 frame #26: 0x00000001c19ab2c0 WebKit`WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44 frame #27: 0x00000001c1fb3254 WebKit`IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) + 252 frame #28: 0x00000001c1fb3768 WebKit`IPC::Connection::dispatchIncomingMessages() + 576 frame #29: 0x00000001b9ab90c4 JavaScriptCore`WTF::RunLoop::performWork() + 204 frame #30: 0x00000001b9ab9fec JavaScriptCore`WTF::RunLoop::performWork(void*) + 36 frame #31: 0x000000019b8cc8a4 CoreFoundation`CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 frame #32: 0x000000019b8cc838 CoreFoundation`__CFRunLoopDoSource0 + 176 frame #33: 0x000000019b8cc59c CoreFoundation`__CFRunLoopDoSources0 + 244 frame #34: 0x000000019b8cb138 CoreFoundation`__CFRunLoopRun + 840 frame #35: 0x000000019b8ca734 CoreFoundation`CFRunLoopRunSpecific + 588 frame #36: 0x00000001a6e39530 HIToolbox`RunCurrentEventLoopInMode + 292 frame #37: 0x00000001a6e3f348 HIToolbox`ReceiveNextEventCommon + 676 frame #38: 0x00000001a6e3f508 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #39: 0x000000019f442848 AppKit`_DPSNextEvent + 660 frame #40: 0x000000019fda8c24 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 frame #41: 0x000000019f435874 AppKit`-[NSApplication run] + 480 frame #42: 0x000000019f40c068 AppKit`NSApplicationMain + 888 frame #43: 0x00000001ca56a70c SwiftUI`merged generic specialization <SwiftUI.TestingAppDelegate> of function signature specialization <Arg[0] = Existential To Protocol Constrained Generic> of SwiftUI.runApp(__C.NSResponder & __C.NSApplicationDelegate) -> Swift.Never + 160 frame #44: 0x00000001ca9e09a0 SwiftUI`SwiftUI.runApp<τ_0_0 where τ_0_0: SwiftUI.App>(τ_0_0) -> Swift.Never + 140 frame #45: 0x00000001cad5ce68 SwiftUI`static SwiftUI.App.main() -> () + 224 frame #46: 0x0000000105943104 MyApp Dev.debug.dylib`static MyMacApp.$main() at :0 frame #47: 0x0000000105943c9c MyApp Dev.debug.dylib`main at MyMacApp.swift:24:8 frame #48: 0x000000019b464274 dyld`start + 2840

Hello, We are setting up Apple Sign In in one of our non production websites but we keep getting a "oauth code says expired or revoked" error. We have created a brand new service ID and key for this but are still getting this error.

Hi everyone, I’m encountering a critical reliability issue with message passing in my Safari Web Extension on iOS 18.4.1 and iOS 18.5. In my extension, I’m using the standard messaging API. The background script sends a message to the content script using browser.tabs.sendMessage(...), and the content script registers a listener via: browser.runtime.onMessage.addListener(handler); This setup has been working reliably in all prior versions of iOS. However, after updating to iOS 18.4.1 and 18.5, I’ve noticed the following behavior: ✅ The content script is successfully injected, and onMessage.addListener is registered (I see logging confirming this). ✅ The background script sends the message using the correct tabId (also confirmed via logs). ❌ The content script’s onMessage listener is not consistently triggered. ⚠️ This issue is intermittent, sometimes the message is received, sometimes it is silently dropped. ❌ No exceptions or errors are thrown in either script, the message appears to be sent, but not picked up from the content script message listener.

We are encountering an issue where the Safari extension we are developing stops working while in use on relatively new iOS versions (confirmed on 17.5.1, 17.6.1, and 18). Upon checking the Safari console, the content script is displayed in the extension script, so the background script or Service Worker must be stopping. The time until it stops is about 1 minute on 17.5.1 and about one day on 17.6.1 or 18. When it stops, we would like to find a way to restart the Service Worker from the extension side, but we have not found a method to do so yet. To restart the extension, the user needs to turn off the corresponding extension in the iPhone settings and then turn it back on. As mentioned in the following thread, it is written that the above bug was fixed in 17.6, but we recognize that it has not been fixed. https://forums.developer.apple.com/forums/thread/758346 On 17.5.1, adding the following process to the background script prevents it from stopping for about the same time as on 17.6 and above. // Will be passed into runtime.onConnect for processes that are listening for the connection event const INTERNAL_STAYALIVE_PORT = "port.connect"; // Try wake up every 9S const INTERVAL_WAKE_UP = 9000; // Alive port var alivePort = null; // Call the function at SW(service worker) start StayAlive(); async function StayAlive() { var wakeup = setInterval(() => { if (alivePort == null) { alivePort = browser.runtime.connect({ name: INTERNAL_STAYALIVE_PORT }); alivePort.onDisconnect.addListener((p) => { alivePort = null; }); } if (alivePort) { alivePort.postMessage({ content: "ping" }); } }, INTERVAL_WAKE_UP); } Additionally, we considered methods to revive the Service Worker when it stops, which are listed below. None of the methods listed below resolved the issue. ① Implemented a process to create a connection again if the return value of sendMessage is null. The determination of whether the Service Worker has stopped is made by sending a message from the content script to the background script and checking whether the message return value is null as follows. sendMessageToBackground.js let infoFromBackground = await browser.runtime.sendMessage(sendParam); if (!infoFromBackground) { // If infoFromBackground is null, Service Worker should have stopped. browser.runtime.connect({name: 'reconnect'}); // ← reconnection process // Sending message again infoFromBackground = await browser.runtime.sendMessage(sendParam); } return infoFromBackground.message; Background script browser.runtime.onConnect.addListener((port) => { if (port.name !== 'reconnect') return; port.onMessage.addListener(async (request, sender, sendResponse) => { sendResponse({ response: "response form background", message: "reconnect.", }); }); ② Verified whether the service worker could be restarted by regenerating Background.js and content.js. sendMessageToBackground.js export async function sendMessageToBackground(sendParam) { let infoFromBackground = await browser.runtime.sendMessage(sendParam); if (!infoFromBackground) { executeContentScript(); // ← executeScript infoFromBackground = await browser.runtime.sendMessage(sendParam); } return infoFromBackground.message; } async function executeContentScript() { browser.webNavigation.onDOMContentLoaded.addListener((details) => { browser.scripting.executeScript({ target: { tabId: details.tabId }, files: ["./content.js"] }); }); } However, browser.webNavigation.onDOMContentLoaded.addListener was not executed due to the following error. @webkit-masked-url://hidden/:2:58295 @webkit-masked-url://hidden/:2:58539 @webkit-masked-url://hidden/:2:58539 ③ Verify that ServiceWorker restarts by updating ContentScripts async function updateContentScripts() { try { const scripts = await browser.scripting.getRegisteredContentScripts(); const scriptIds = scripts.map(script => script.id); await browser.scripting.updateContentScripts(scriptIds);//update content } catch (e) { await errorLogger(e.stack); } } However, scripting.getRegisteredContentScripts was not executed due to the same error as in 2. @webkit-masked-url://hidden/:2:58359 @webkit-masked-url://hidden/:2:58456 @webkit-masked-url://hidden/:2:58456 @webkit-masked-url://hidden/:2:58549 @webkit-masked-url://hidden/:2:58549 These are the methods we have considered. If anyone knows a solution, please let us know.

(Error) When using Safari to access an internal website during development (using a self-signed certificate), may encounter issues where backend data fails to be retrieved.

Hello, In iOS 26 beta, we are seeing an unexpected behavior when using SwiftUI WebView (or a custom WKWebView via UIViewRepresentable). When an alert is presented above the WebView, the WebView immediately reloads to its initial page. The alert itself also disappears instantly, making it impossible for the user to interact with it. This issue occurs both with the new SwiftUI WebView / WebPage API and with a wrapped WKWebView. The problem was not present in previous iOS versions (iOS 17/18). Steps to reproduce: Create a SwiftUI view with a WebView (pointing to any URL). Add a toolbar button that toggles a SwiftUI alert. Run the app on iOS 26 beta. Tap the button to trigger the alert. Expected behavior: The WebView should remain as-is, and the alert should stay visible until the user dismisses it. Actual behavior: As soon as the alert appears, the WebView reloads and resets to the initial page. The alert disappears immediately. Minimal Example: struct ContentView: View { @State private var showAlert = false var body: some View { NavigationStack { WebView(URL(string: "https://apple.com")!) .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Close") { showAlert = true } } } .alert("Confirm close?", isPresented: $showAlert) { Button("Cancel", role: .cancel) {} Button("Close", role: .destructive) {} } } } } I'm using Xcode Version 26.0 beta 7 Thanks for your help.

Hi, My app is using JavascriptCore to run the business logic in a javascript environment. We are randomly seeing crashes when users move the app back to the foreground. These crashes are reported by Firebase (I am attaching an example). I also tried to find them in Organizer, but the stacktraces don't match and I am not sure if they are pointing to the same error (I attach one just in case). I was trying to investigate a little bit about this, but I could find any explanation about what pas_reallocation_did_fail would mean. Here is our implementation: -(void) enqueueCallback:(JSValue *)callback withArguments:(NSArray *)args exclusive:(BOOL)exclusive { [self enqueueBlock:^{ @autoreleasepool { [callback callWithArguments:args]; } } exclusive:exclusive]; } Basically, every JS block is enqueued and then run by a dedicated thread specific to our JSContext. Can I get some help? Thanks in advance! Crashlytics.txt 2024-08-30_10-00-01.2572_-0400-f757f8306eda9679ec1b2ff90fbc66c4eb1fbee7.crash

Video in Landscape takes 2 taps on X to close.This issue can be replicated on iphone 14 ios 18.5.There is no issue on iPhone 15 ios 18.5.