Hello Apple Developer Community, I'm reaching out to ask whether anyone else is currently experiencing unusually long review times in App Store Connect. Our app, NumbuX, has been stuck in the "Waiting for Review" status for approximately three weeks, without any updates or requests for additional information. We understand that review times can vary, but this delay seems significantly longer than usual. I would appreciate any clarification regarding the following: Are there any known technical issues or backlogs affecting the App Store review process? Are other developers experiencing similar delays? Is there a recommended way to escalate or request an update when an app remains in "Waiting for Review" for several weeks? Could there be an issue with our submission that is preventing it from progressing, even though no action is requested in App Store Connect? We want to ensure that there is nothing missing on our side and that our submission is being processed correctly. We have also opened few tickets in different areas and we have not had any replied yet. Is anyone in the same situation? Thank you in advance for any information or guidance.

Hi everyone, I'm hoping someone can help with an issue I'm having with Apple's Web Content Restrictions. I manage a legitimate fitness and wellness website, but some iPhone/iPad users are unable to access it when they have: Settings → Screen Time → Content & Privacy Restrictions → App Store, Media, Web & Games → Web Content → Limit Adult Websites enabled. They receive: Website Not Allowed The website is a restricted website. I've been able to reproduce the exact same issue myself by enabling this setting on an iPhone. The important point is that the website is not adult content whatsoever. It is a normal fitness/wellness website providing workouts, fitness programmes, nutrition guidance and related content. There is no pornography, sexually explicit content or adult services. I've also tested blank pages and different URLs associated with the site, and the restriction still occurs. Everything works normally when the Web Content setting is changed to Unrestricted Access. I've contacted Apple Support and Apple Developer Support but haven't been able to get the issue in front of someone who can review the website's classification. Does anyone know how to request a review or reclassification of a website that appears to have been incorrectly flagged by Apple's Web Content Filter? I'm not trying to bypass Apple's parental controls. I simply want to understand how a legitimate fitness website can be reviewed and removed from whatever classification is causing it to be blocked under Limit Adult Websites. Any advice from anyone who has dealt with this before would be hugely appreciated.

I’m the owner of actifinder mobile app. Apple’s Screen Time ‘Limit Adult Websites’ setting is incorrectly blocking our website, including the homepage. ActiFinder is an outdoor activities platform for hiking, cycling, kayaking, skiing, events and similar activities and does not contain adult content. I believe our domain has been incorrectly classified as adult content. I’d like to have actifinder.com reviewed and removed from the adult-content block/classification. Could you please escalate this to the team responsible for Screen Time web-content filtering/domain classification?

Hello. I'm using Sololearn and ChatGPT to learn how to code. I've made a calculator before, but I want to make one similar to the one on iPhone. Is ok to have a link to apple.com or do I say I was inspired by Apple Here is the code I currently have: HTML <!DOCTYPE html><html> <head> <title>Page Title</title> <meta name="viewport" content="width=device-width, initial-scale=1"> </head> <body> <div class="calculator"> <input class="display" type="text"> <div class = "scientific"> <button>(</button> <button>)</button> <button>mc</button> <button>m+</button> <button>m-</button> <button>mr</button> </div> <div class ="standard"> <button class="utility" id="backspace">&#9003;</button> <button class="utility" id="clear">AC</button> <button class="utility" id="percent">%</button> <button class="operator">/</button> <button class="number digit">7</button> <button class="number digit">8</button> <button class="number digit">9</button> <button class="operator">*</button> <button class="number digit">4</button> <button class="number digit">5</button> <button class="number digit">6</button> <button class="operator">-</button> <button class="number digit">1</button> <button class="number digit">2</button> <button class="number digit">3</button> <button class="operator">+</button> <button class="number" id="plusmn">⁺&frasl;_-</button> <button class="number digit">0</button> <button class="number" id="decimal">.</button> <button class="utility equals" id="equals">=</button> </div> </div> </body></html> ``` ``` CSSbody{ background-color: black; } html, body { margin: 0; width: 100%; height: 100%; background-color: black; } input { font-size: 48px; box-sizing: border-box; width: 100%;} .utility { background-color: #666; color: white; } .operator { background-color: orange; color: white; } .equals{ background-color: orange; color: white; } .number{ background-color: #333; color: white; } .calculator { display: grid; /*grid-template-columns: repeat(4, 1fr);*/ grid-template-columns: 1fr; gap: 4px; width: 100%; box-sizing: border-box; padding: 12px; position: fixed; bottom: 0; left: 0;} .calculator button { width: 100%; aspect-ratio: 1; border: none; border-radius: 50%; font-size: 32px; } .scientific{ display: grid; grid-template-columns: repeat(6, 1fr); gap: 4px;} .standard{ display: grid; grid-template-columns: repeat(4, 1fr); gap: 4px;} .display { color: white; background-color: black; border: none; height: 100px; font-size: 48px; text-align: right; box-sizing: border-box; width: 100%; } /* .display { grid-column: 1 / -1; color: white; background-color: black; border: none; height: 100px; font-size: 48px; text-align: right; box-sizing: border-box; width: 100%; } */ /* .zero { grid-column: span 2; border-radius: 40px; aspect-ratio: auto;} .calculator button.zero { aspect-ratio: auto; border-radius: 40px;} */ JS const display = document.querySelector(".display"); let fontSize = 48; function adjustFontSize() { fontSize = 48 - display.value.length * .99; if (fontSize < 20) { fontSize = 20; } display.style.fontSize = fontSize + "px"; } const buttonsJS = document.querySelectorAll(".digit"); buttonsJS.forEach(function(buttonJS) { buttonJS.addEventListener("click", function() { display.value += buttonJS.textContent; adjustFontSize(); }); }); const clear = document.querySelector("#clear"); clear.addEventListener("click", function() { display.value = ""; adjustFontSize(); }); const backspace = document.querySelector("#backspace"); backspace.addEventListener("click", function() { display.value = display.value.slice (0, -1); adjustFontSize(); }); const percent = document.querySelector("#percent"); percent.addEventListener("click", function(){ display.value /= 100; adjustFontSize(); }); const plusmn = document.querySelector("#plusmn"); plusmn.addEventListener("click", function(){ display.value /= -1; adjustFontSize(); }); const decimal = document.querySelector("#decimal"); decimal.addEventListener("click", function(){ if (!display.value.includes(".")) { display.value += "."; // Add the decimal point here } adjustFontSize();}); const operators = document.querySelectorAll(".operator"); operators.forEach(function(operator) { operator.addEventListener("click", function() { display.value += operator.textContent; adjustFontSize(); }); }); const equals = document.querySelector("#equals"); equals.addEventListener("click", function() { display.value = eval(display.value); adjustFontSize(); }); /* const display = document.querySelector(".display"); const buttonJS = document.querySelector(".digit"); buttonJS.addEventListener("click", function() { console.log("You clicked the button!"); }); const buttonsJS = document.querySelectorAll(".digit"); buttonsJS.forEach(function(buttonJS) { buttonJS.addEventListener("click", function() { display.value += buttonJS.textContent; }); }); */

Safari displays a red “Fraudulent Website Warning” for my website q-saver.com. The warning has been present for more than 5 months. I have already submitted two requests through https://websitereview.apple.com/, but neither resulted in the warning being removed or any response. The website is a video downloading service. It does not impersonate Apple or financial services and does not ask for Apple IDs, banking credentials or other sensitive information. The only password it asks for is the optional password of a q-saver.com account; sign-in with Google or Telegram goes through their official OAuth pages, and payments are processed on the payment providers' own pages. The site used to show pop-under ads from third-party ad networks. They have been turned off (the last one on September 26, 2026), and the ad network code has been removed from the pages. On 27 September I submitted a new Website Review request. Google Safe Browsing reports no unsafe content for the site: https://transparencyreport.google.com/safe-browsing/search?url=q-saver.com The website works normally in Chrome, Firefox and Edge. In iOS in-app browsers (for example, Telegram) it does not open at all because of the warning. Is there an official escalation path for Safari's Fraudulent Website Warning classification when Website Review requests remain unresolved for several months? I can provide screenshots and technical information privately if required.

Environment macOS 26.5.1 (Build 25F80) Safari 26.5 Apple Pay JS API version 8 Using https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js Reproduces on the staging website (Does not reproduce on the production website with non sandbox account) Signed into a Sandbox Tester Apple ID, with a test credit card registered exactly per Apple Pay Sandbox Testing — this is the only card in Wallet on the laptop Merchant validation is performed by our staging backend against our real (non-sandbox) merchant identity/certificate — i.e. a sandbox tester card being evaluated against a staging merchant session, which per the sandbox testing documentation is the expected/supported setup for testing on a live site without a separate merchant sandbox environment Summary After completeMerchantValidation() succeeds and the merchant session is accepted, the payment sheet still terminates with PKPaymentAuthorizationStateFatalError a few hundred milliseconds later, right after the native side logs a second "Evaluating merchant session using PROD trust policy." for the same session. The user sees "Payment failed" and the sheet closes. This happens on the very first attempt, with no user interaction beyond tapping the Apple Pay button — no shipping address is even selected before the failure. Since the sandbox tester card + production merchant session combination is the setup the sandbox testing guide describes, we'd expect the sheet to proceed to onpaymentauthorized (Apple's sandbox docs describe payments as being processed as $0 test transactions in this mode) rather than fail natively before that stage is ever reached. Steps to reproduce Visit an item page with an Apple Pay button. Tap the Apple Pay button to open the payment sheet. The sheet presents normally; no interaction with shipping address or payment method is required for the failure to occur. Within ~1 second, the sheet dismisses and displays a "Payment failed" error state. Minimal reproduction of the JS side const session = new ApplePaySession(8, { countryCode: 'US', currencyCode: 'USD', supportedNetworks: ['visa', 'masterCard', 'amex', 'discover'], merchantCapabilities: ['supports3DS'], total: { label: 'Merchant', amount: '10.00' }, }); session.onvalidatemerchant = async () => { const merchantSession = await validateMerchantOnServer(); // succeeds session.completeMerchantValidation(merchantSession); // accepted — see log below }; session.onpaymentmethodselected = () => { session.completePaymentMethodSelection({ newTotal: { label: 'Merchant', amount: '10.00' }, }); }; session.oncancel = event => console.log('cancelled', event); session.begin(); We reproduced this with both our full checkout implementation and this stripped-down request object (no shipping contact required, no line items) — same failure either way, which rules out anything about our order/line-item data. What we expected The sheet to proceed to the biometric authorization step and dispatch onpaymentauthorized once the user confirms. What actually happens The sheet fails immediately with a PKPaymentAuthorizationStateFatalError transition, even though every JS-side completion call (completeMerchantValidation, the payment-method selection) succeeded and returned PKPaymentAuthorizationStatusSuccess. System log (captured via log stream --info --debug --predicate 'process == "Safari" OR process == "passd" OR process == "com.apple.PassKit.PaymentAuthorizationUIExtension"') 21:50:41.544 PaymentCoordinator::beginPaymentSession() -> 1 21:50:41.570 Received prepareWithPaymentRequest: <private> 21:50:42.297 PaymentCoordinator::validateMerchant() 21:50:42.563 PaymentCoordinator::completeMerchantValidation() 21:50:42.564 Received merchant session update with status:PKPaymentAuthorizationStatusSuccess session:<private> 21:50:42.564 Evaluating merchant session using PROD trust policy. <- 1st occurrence, passes 21:50:42.572 PaymentCoordinator::didSelectPaymentMethod() 21:50:42.572 PaymentCoordinator::completePaymentMethodSelection() 21:50:42.653 Evaluating merchant session using PROD trust policy. <- 2nd occurrence 21:50:42.656 State machine change state from ClientCallback to PrepareTransactionDetails with param: <private> 21:50:43.391 Task Completed: <private> 21:50:43.393 State machine change state from PrepareTransactionDetails to PKPaymentAuthorizationStateFatalError with param: <private> 21:50:43.393 Error Payment failed with fatal error <private> 21:50:45.130 PaymentCoordinator::didCancelPaymentSession() The first "Evaluating merchant session using PROD trust policy." line passes (the flow continues to didSelectPaymentMethod). The second occurrence is immediately followed by Task Completed and then the FatalError transition, which suggests PassKit re-validates the merchant session's trust a second time right before PrepareTransactionDetails, and that second check is what's rejecting the session — even though the identical session object was accepted moments earlier at completeMerchantValidation(). What we've tried / ruled out Confirmed every JS completion method (completeMerchantValidation, completePaymentMethodSelection) is called and returns success — no 30-second timeout, no missing completion call, no thrown exception on our side. Reproduced with a minimal, hardcoded ApplePayPaymentRequest (fixed $10.00 total, no shipping fields) — rules out anything about our real order/line-item/sales-tax data. Reproduced on the main branch and independently on our staging deployment running unmodified code — rules out anything specific to our recent frontend changes. The <private> redaction in the system log prevents us from seeing what specifically fails during the second trust evaluation. Confirmed the sandbox tester card and its registration follow the sandbox testing guide exactly — it's the only card on the device, and no other Wallet cards are involved. Question What does PassKit's second "Evaluating merchant session using PROD trust policy" check (immediately before PrepareTransactionDetails) actually validate, beyond what's already checked at completeMerchantValidation() time? Is a sandbox tester card being evaluated against a production merchant session expected to pass this second check, or does sandbox testing per the linked guide require something additional on the merchant/session side (e.g. a specific field on the merchant session, or a specific environment value) that our backend isn't setting? Is there a way to get an unredacted reason for the rejection — e.g. via a private-data-enabled log profile or another diagnostic — since the redacted system log alone doesn't surface one?

White flash when opening a new tab overridden by a Safari Web Extension on iOS Safari intermittently displays a white flash when opening a new tab overridden by a web extension. I reproduced this on an iPhone 13 mini running iOS 26.5 using a minimal test extension. Minimal reproduction The extension replaces the new tab page through chrome_url_overrides.newtab. The page has a static magenta background, set directly on the root element and through inline CSS. The test page contains no JavaScript, images, fonts, external stylesheets or network requests. Steps to reproduce Install and enable a Safari Web Extension that overrides the new tab page with a static magenta HTML page. Select the extension for new tabs in Safari settings. Open Safari in normal browsing mode. Open a new tab and wait for the magenta page to appear. Open another new tab. Repeat several times. Expected: The page area remains magenta throughout the transition. Actual: The page area intermittently transitions from magenta → white → magenta. The issue reproduces without JavaScript or external resources, so the flash does not require delayed script execution or image loading. Is this a known issue with Safari’s handling of new tab overrides? Is there a supported way for an extension to control the background displayed during this transition?

Environment: MacBook Air M4 macOS 27 Beta Safari Safari Technology Preview Issue: I am experiencing an issue where mouse/trackpad clicks are intermittently ignored near the bottom portion of a webpage. The trackpad hardware appears to be functioning normally, as physical clicks are registered and the issue does not occur consistently across all browsers. Steps to Reproduce: Open Safari or Safari Technology Preview. Navigate to a webpage with interactive elements near the bottom of the visible page. Attempt to click links, buttons, or text fields located in approximately the bottom quarter of the browser window. Observe that clicks are sometimes not registered. Resize the Safari window so that the affected area is no longer located in the bottom portion of the screen. Attempt the same clicks again. Expected Result: Clicks should be consistently registered regardless of their position within the webpage. Actual Result: Clicks in the lower portion of the webpage are sometimes ignored. Resizing the window may temporarily resolve the issue. Additional Information: The trackpad itself appears to function normally. Physical clicks are detected. I have observed the issue in both Safari and Safari Technology Preview. I tested the same website in Perplexity Comet, where the issue does not appear to occur. This suggests the issue may be related to Safari’s rendering, hit-testing, event handling, or window management rather than the website itself. Has anyone else been able to reproduce this on macOS 27 Beta?

Hi, I’m testing file uploads to a web app that sits behind an AWS Application Load Balancer, and I need a way to make Safari use HTTP/1.1 instead of HTTP/2 while I test. What I’m seeing: Uploads up to about 4 MB work. Anything bigger slows down more and more and then fails with a network error. A 49 MB file never finishes. The same upload over HTTP/1.1 works every time. I tested this with curl (--http1.1 against --http2), and with Chrome started with --disable-http2. In that Chrome, the 49 MB file uploaded fine. In Safari, which uses HTTP/2 with this server, the same file fails every time. My questions: Is there any way to make Safari use HTTP/1.1 for a site, or turn HTTP/2 off, for testing? For example a hidden setting, a defaults write key, something under Develop → Feature Flags, or a Web Inspector option. I couldn’t find one. If not, is there a recommended way to test how Safari behaves with HTTP/1.1 only? Safari supports HTTP/3. Our load balancer doesn’t offer HTTP/3 at the moment, but if it did, would Safari switch to it automatically for uploads? And are large uploads over HTTP/3 known to behave better than over HTTP/2? I have also asked AWS about the load balancer side. The long-term plan is to switch HTTP/2 off there, but I’d like to be able to confirm the behaviour in Safari directly in the meantime. Thank you

Hello, I'm trying to package a Safari Web Extension using Apple's web-based Safari Web Extension Packager in App Store Connect. However, both export processes consistently fail, and I have been unable to determine the root cause. Environment Apple Developer Program membership: Active App Store Connect app configured for both iOS and macOS Development environment: Windows PC and iPad; no access to a Mac Packaging method: Safari Web Extension Packager in App Store Connect Issue Every packaging attempt results in these two errors: Development Distribution: Exporting for Development Distribution failed. Please download the logs artifact for more information. App Store Distribution: Exporting for App Store Distribution failed. Please download the logs artifact for more information. The interface does not appear to provide any button or link to download the referenced logs artifact. As a result, I cannot access the diagnostic information needed to investigate the failure. Troubleshooting performed To determine whether the problem was caused by my extension's code, I created and uploaded a separate, minimal test extension. The same export failures occur with the minimal test extension, not just my original extension. Questions How can I download the logs artifact referenced in the error message? Could this be a server-side packaging, signing, or provisioning issue in App Store Connect? I have already reviewed Apple's documentation, but it does not provide enough information to diagnose these specific failures. Any guidance from someone who has successfully used the current web-based packaging workflow, or from an Apple engineer familiar with this service, would be appreciated. Thank you.

Summary On iPadOS 27.0 (build 24A435), MobileSafari crashes with SIGABRT the first time the software keyboard is brought up by focusing a form field inside a web page. It happens on any website that has a text input: we reproduced it on our own web app, amazon.co.jp, Yahoo! Mail, Gmail, Rakuten, X, and two Japanese public-sector sites. No login is required to reproduce. Environment Devices: iPad mini (A17 Pro / iPad16,2) x2, plus a third iPad (reproduced on 3 devices) OS: iPadOS 27.0 build 24A435 — both the public beta and the RC build (releaseType "User"). Also reproduces after a full erase + clean install, so it is not device-state related. NOT reproducible on: iPhone (iOS 27, same build 24A435), Chrome on the same iPads, or the Xcode 27 Simulator. Steps to reproduce (no login required) Launch Safari and open any page with a login form (e.g. the amazon.co.jp sign-in page). Without logging in, kill Safari from the app switcher (or background it and go to the Home Screen). Launch Safari again; the same page is shown. Tap any text field (ID / email / password) to focus it. Safari crashes immediately. The essential condition appears to be: the FIRST keyboard activation in a freshly launched MobileSafari process is driven by focusing a form field inside WKWebView. If the keyboard has already been built once in that process (see Workaround below), the crash never happens. Crash details We collected five .ips crash reports from three devices and two unrelated websites (our web app and amazon.co.jp). lastExceptionBacktrace is identical across all five, down to the instruction offsets, so page content is not a factor. Key frames: The exception is thrown by NSISEngine (CoreAutoLayout) while -[TUIKeyplaneView prepareForSplitTransition] removes layout constraints in an inconsistent state (this split-keyplane path is iPad-only, which explains why iPhone is unaffected). The re-entrancy: Safari's AutoFill metadata round trip (WBSAutoFillJavaScriptInjectionController -> _SFFormAutoFillController beforeStartInputSession: -> TabDocument _beginAutomaticPasswordInteraction:) calls -[UIResponder reloadInputViews] from -[WKContentView _continueElementDidFocus:requiresStrongPasswordAssistance:] while -[UIKeyboard activate] is still on the stack. In all five reports, a com.apple.root.utility-qos thread is blocked in DISPATCH_WAIT_FOR_QUEUE doing dispatch_sync onto the main queue from -[UITextChecker initGlobalsWithAsynchronousLoading:] (a once-per-process initialization). Four of the five crashes occurred 1–6 seconds after process launch. After the crash, Safari itself sometimes fails to launch until you do Settings > Safari > Clear History and Website Data. Already ruled out (all verified on device) Settings > Passwords > AutoFill turned OFF: still crashes Split keyboard setting turned OFF: still crashes Full device reset + clean install of the RC build: still crashes Site-side causes: reproduces on completely unrelated sites; the crash fires before any login/auth JavaScript runs, and no page code appears in the stack Workaround (reliable, verified) Focus Safari's own address bar FIRST, so the keyboard is constructed through a native text field without the asynchronous AutoFill round trip. After that, focusing web form fields works normally for the lifetime of the process. This workaround is unavailable in SFSafariViewController / in-app browsers, where the crash also reproduces. Questions Can anyone else reproduce this on iPadOS 27.0 (24A435)? Confirmations/boosts appreciated — we want to know how widespread this is before the public rollout. Is there any site-side mitigation (markup, autocomplete attributes, JS) that prevents Safari's AutoFill round trip from re-entering keyboard construction? Standard autocomplete attributes did not help in our tests. Is this a known regression being tracked for an iPadOS 27.x update? Is there any mitigation for SFSafariViewController-based in-app browsers, where the address-bar workaround cannot be used? Filed via Feedback Assistant: FBxxxxxxxx (five .ips crash reports attached there).