Overview

My DSA trader verification in App Store Connect has been In Review since October 6, 2026. I’ve sent more than 10 follow-up inquiries without a response so far, and the delay is blocking the planned EU release of my apps. The original DSA submission may have been made under my former legal name. Apple has since verified my identity under my current legal name. I don’t know whether the pending submission still contains my former name or whether that is causing the delay. Has anyone resolved a pending DSA verification after a legal name change? Is there a way to correct the existing submission, or is there a specific support channel that can escalate it to the DSA verification team? Any guidance would be appreciated. I can provide my account and case details privately through an official Apple support channel.

I’m investigating delayed HealthKit background delivery in an iPhone calorie-tracking app installed through TestFlight. The app reads activeEnergyBurned and submits a local notification with a custom sound for every newly accumulated 20 kcal. The intended behavior is passive: the user walks normally without explicitly starting a workout. Current behavior: Rewards appear after opening the app. Unlocking the phone to the iPhone Home Screen does not trigger the accumulated rewards. The app is backgrounded, not force-quit. A separate local notification scheduled 10 seconds ahead successfully displays and plays its custom sound while the phone is locked. Implementation: An HKObserverQuery for activeEnergyBurned, with predicate nil, is registered during application(_:didFinishLaunchingWithOptions:). Background delivery is requested with frequency .immediate. The installed TestFlight app has the HealthKit and HealthKit background-delivery entitlements. With valid locally stored access, Health processing does not wait for a StoreKit subscription query. In the captured trace, observer callbacks complete promptly and healthd reports no outstanding launches afterward. Recorded test on November 7, 2026 (device-log times, UTC−07:00): Around 07:03, I manually added 40 kcal in Apple Health. At 07:03:42, Health received an added sample. healthd scheduled the next Active Energy background launch for 08:03:14, approximately one hour after our previous observer completion. At 07:05:42, I unlocked to the Home Screen. Protected Health data became available, but no corresponding observer callback reached our app. At 07:08:40, I opened our app. Its observer callback arrived immediately, and two reward notification requests were accepted without error. Earlier development installations appeared to deliver accumulated rewards upon unlocking to the Home Screen, even after the debugger had disconnected. Subscription integration occurred between those versions, but we have not established the cause of the difference. My questions: Is an approximately one-hour interval expected for activeEnergyBurned on iPhone despite requesting .immediate? Can foreground observer completions advance the next permitted background delivery time? Is there a supported way to receive pending Active Energy updates after unlocking, without opening the app or starting an HKWorkoutSession? I can provide targeted implementation details and additional relevant log excerpts if needed. Thank you.

I purchased the $99 membership 2 weeks ago and it’s still pending; is there any solution to this?

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

Dear Apple Review Team, I hope this post finds you well. My app CapDex: Language Learning (App ID: 6805323578) was rejected on October 30, 2026. I have since addressed the issues and resubmitted version 1.0.1, which has been in “Waiting for Review” for over 7 days. Could you please help me with the following: Provide more detailed feedback on the specific reasons for the previous rejection (if possible). Advise if there is anything else I should check or improve before the next review. If appropriate, kindly consider prioritizing the current submission so we can move forward. I am fully committed to complying with the App Store Review Guidelines and will make any necessary changes immediately based on your guidance.Thank you very much for your time and support. Submission ID: f9633cec-c596-4e78-90b8-aec89b0e2691 Best regards, Hiến Hồ

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).

Hello, I'm having an issue with SwiftUI Preview in Xcode. When I switch between different iPhone models, including iPhone 18 Pro, iPhone 18 Pro Max, iPhone Air, and iPhone Duo, the selected device name changes, but the actual device appearance and preview dimensions remain exactly the same. This happens in all SwiftUI projects, including newly created ones. I've tried reinstalling Xcode, clearing DerivedData and caches, and even performing a clean macOS installation, but the issue still persists. - macOS 27.0.1 - Xcode 27.2 Has anyone experienced this issue or found a solution? Thank you!

I was hoping with an OLED display that the new MBP might support true Adaptive Sync aka VRR. Alas, it only gets ProMotion, with the same huge gap between supported refresh rates at the top end (60hz and 120hz). Hooking up an HDMI VRR display such as any LG TV results in a display that works much better with variable framerates than the built-in display, since you can deliver frames at any interval between the min and max. VRR greatly improves games and already works great in macOS with an external display, so I humbly request that Apple consider another option next to ProMotion, for Adaptive Sync/VRR.

Hello, I’m a paid Apple Developer Program member and I want to share my frustration with Apple Developer Support. I have emailed Developer Support 5 times about my App Store Connect issue and have received no reply at all. My case ID is 30000005720177, but nobody has updated me on it in any way. For a company of Apple’s size, this level of unresponsiveness is unacceptable. I pay for my membership, so I expect at least basic communication. What I think needs to change: Clear status updates: Even if a fix takes time, developers should be told so properly, with an estimated timeline. A real contact person: A case ID alone is not enough. There should be a named person or team we can follow up with. 24/7 live support: Apple has developers in almost every country and time zone. Round-the-clock live support should be standard for a company this big. I’m very disappointed with this experience. If anyone from Apple sees this, I’d really appreciate a response on my case 30000005720177. If other developers have run into the same problem, I’d like to hear how you got a response. Thank you.

Hello App Review team and fellow developers, Our app (Apple ID 6822788527) is a free AI chat client with no account, In-App Purchase, subscription, paywall or locked feature. A user pastes a key they already hold with their own AI provider (Anthropic, OpenAI, Moonshot or DeepSeek), much like a mail password in a mail client. On iOS the key is kept in the device Keychain; on macOS it is stored on the Mac, encrypted with a key held in the macOS Keychain. It is sent only to the provider it belongs to, which bills the user directly. We do not issue, sell or mark up keys, and we run no server or proxy for AI requests. Since Oct 31 the app has been rejected three times. Below is every point App Review raised on iOS and macOS, and what happened to each one. Screenshots of the three notes are attached, with our app name, our names and the submission IDs blacked out. What App Review wrote A. macOS, build 355, Oct 31 (screenshots 1-2) Guideline 3.1.1: "Specifically, the app uses DeepSeek license keys to unlock digital content." Guideline 4: "when the user closes the main application window there is no menu item to re-open it." B. iOS, build 5, reviewed on iPad, Nov 2 (screenshots 3-4) Guideline 3.1.1: "the app uses API keys to unlock or enable paid functionality, but some of these API keys are not available for purchase via In-App Purchase in this or the associated apps by the API provider on the App Store." C. macOS, build 357, Nov 6: "The issues we previously identified still need your attention." (screenshots 5-7) Guideline 3.1.1: "the app still uses API keys(DeepSeek) to unlock or enable paid functionality, but some of these API keys are not available for purchase via In-App Purchase..." Guideline 4: the Oct 31 description and next steps, repeated word for word. All three notes add: "Please note API keys can only be used to unlock content if those API keys can be purchased with In-App Purchase in this or the associated app by the API provider on the App Store." 1. Fixed or answered, but not checked 1a. Guideline 4 (macOS). We agreed with this one and fixed it. Build 357 adds a Window menu item that reopens the main window after it is closed and restores it when minimized, as the note itself suggested ("implement a Window menu that lists the main window so it can be reopened"). On Oct 31 we told App Review about the fix and gave two steps to check it. The Nov 6 note for build 357 repeats the Oct 31 text word for word and does not mention the new menu item (compare screenshots 2 and 6). We tested build 357 again on Nov 7: after the main window is closed the item is still listed in the Window menu, choosing it re-opens the window, and minimize and restore also work. We can send screen captures. 1b. "License keys" (macOS). On Oct 31 we explained that the DeepSeek value is the user's own API key, not a license key of our app. We put a working test key in the App Review notes and listed three steps to try it. The Nov 6 note changed "license keys" to "API keys" but kept the same conclusion, and the screenshot attached to it shows the API keys settings with all four providers "Not set": the test key had not been entered, so nothing could have been unlocked. Our review notes give the steps for entering a test key, and for any provider the reviewer prefers we will supply a key in the notes. 1c. "Unlock" (iOS). Both screenshots attached to the iOS note show the app before any key was entered: each provider still offers "Add", and the key field still reads "Paste your Key" with "Verify and add" dimmed. Nothing could have been unlocked in either screenshot. 2. Double standards and inconsistencies 2a. One provider singled out. The macOS notes name DeepSeek only. On Nov 6 we checked the four providers' own App Store apps (screenshots 8-12). DeepSeek's lists no In-App Purchases. ChatGPT, Claude and Kimi list subscriptions, and ChatGPT and Claude also list credits. If the distinction is that OpenAI, Anthropic and Moonshot sell subscriptions or usage credits in their own apps while DeepSeek sells nothing there, none of those purchases is an API key: a ChatGPT Plus subscription, ChatGPT credits or Claude usage credits cannot be entered as a key in our app or in any other app. Under the note's own words ("those API keys can be purchased"), no provider qualifies, so DeepSeek cannot be singled out, yet it is treated differently from OpenAI, Anthropic and Moonshot for no stated reason. 2b. Other apps on the App Store. On Nov 6 the listings of Open Minis, Solair AI, SageChat and Chatlo, and five more apps, named DeepSeek together with the user's own API key. OpenCat (854 ratings), Superwhisper (858), Speech Central (1,565) and Petey (351) let users bring their own API keys, and Pal Chat (440) lists DeepSeek and tells users to get an API key (screenshots 13-16, in the reply below). These apps are live today. Applied as written, the note would reach all of them. We assume that is not the intent, and we ask for no action against any of them. We ask that the same standard apply to ours, or that App Review name the rule that separates DeepSeek from the other providers. 2c. Three notes, three readings. The same app with the same key screen got three different 3.1.1 descriptions: "license keys to unlock digital content" (macOS, Oct 31), "API keys... paid functionality... some of these API keys" with no provider named (iOS, Nov 2), and "API keys(DeepSeek)... paid functionality" (macOS, Nov 6). There is no paid functionality in the app, and we cannot tell which of the three we are meant to fix. (Continued in the reply below: the rule we cannot find, our unanswered appeals, and what we ask.)

Hello App Review team, Our first app, FormaCoach AI (Apple ID 6826677522), was rejected on Oct 30 under Guideline 2.1(a) (date of birth could not be entered). We fixed the cause (a time-zone issue in date parsing) and resubmitted build 23 on Oct 31. An expedited review was granted the same day, but the submission has stayed in "Waiting for Review" since then. Submission ID: 16c87033-937e-4bcb-8ab3-95c25dca87be Could you please confirm the expedite is attached to this submission and let us know if anything is needed from our side? Thank you.

I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.

Two notarization submissions for a Developer ID–signed macOS app have been "In Progress" for over an hour. Earlier submissions from this same team, credentials and workflow were all Accepted within minutes. Submissions Created (UTC)IDFileStatus2026-11-05 15:54:4802956de4-0ec7-4009-8f8e-1635f93a10d1ProxyPal.zipIn Progress2026-11-05 16:37:25e38d47a1-6709-4008-9682-18f9b96af217ProxyPal.zipIn ProgressThe second one is a resubmission of the identical zip, sent after the first had been stuck for about 40 minutes. What I've checked xcrun notarytool info <id> returns In Progress. xcrun notarytool log <id> returns "Submission log is not yet available". Authentication and upload work, and notarytool history lists both submissions. codesign --verify --deep --strict passes on the app. Every executable in the bundle has the hardened runtime and a secure timestamp. The zip is made with ditto -c -k --keepParent, the same command as the earlier accepted releases. The bundle contents are essentially unchanged since the last accepted release. The differences are a small generated static HTML help folder and version-number changes. Environment Submitted with xcrun notarytool submit ... --keychain-profile ... --wait from a script. macOS 26 (Darwin 25.6), Xcode toolchain notarytool. Zip is 89 MB, 193 files, and includes two nested .apk files that were also in earlier accepted releases. Questions Are these two submissions held for additional analysis, or stuck in the queue? Is there anything on my side I should change?

Hello, Our first iOS app has remained in “Waiting for Review” for an unusually long time. Timeline: Initial submission: October 13 We received a reviewer-access issue on October 27. We corrected the access issue immediately and resubmitted on October 29. The demo accounts are active, require no OTP or additional verification, and are ready for review. The current submission is still showing “Waiting for Review,” with no additional request for information or visible action required in App Store Connect. We have also contacted Developer Support but have not received a further update. We understand that review timing can vary and are not asking for an exception to the App Review Guidelines. Could an Apple representative please advise whether there is an account, queue, or submission issue requiring action from our side, or whether an internal status check is possible? Thank you.

On Apple silicon macOS, is there a supported public mechanism that can enforce a hard combined mapped virtual address-space ceiling of 512 MiB for a parent process and its new child from the first charged creation step through loading the child's executable image, before the child runs any application code? The current investigation targets macOS build 26B123 on arm64. We need to know how the supported limit accounts for inherited maps, shared-region reservations and image mappings during process creation. If the supported route is to partition the ceiling between per-process limits, please specify whether the child limit applies before its first charged map and how a limit failure is reported. Please identify the public API or documentation, supported OS versions and required setup. A control that only applies to resident memory or starts after application code begins would not cover this question.

Hi, I'm an enrolled Apple Developer Program member. My membership is approved and I've already submitted my app for App Review, but I can no longer sign in to my Apple Account because two-factor verification codes can't be delivered. What happens: Sign-in with SMS fails with error -28248: "Verification codes can't be sent to this phone number at this time. Please try again later." Account Recovery (adding a phone number to receive instructions) returns the same -28248 error, even with a second number on a different carrier. The account flags show it isn't locked (securityCodeLocked: false, tooManyCodesSent: false), so this looks like an SMS delivery problem to +880 numbers rather than an account lock. I don't have a trusted Apple device signed in to this Apple Account, so I can't use "Get Verification Code". I opened a Developer Support case on November 6, 2026: Case ID: 30000007200849 (Membership and Account → Account Access) Because of this I can't respond to App Review or manage my app in App Store Connect. If anyone from Apple can look at this case, I'd really appreciate it. Thank you.

Our app vCard — Digital Business Card (Apple ID 6820835727, version 1.0) was first submitted on October 11, 2026. We removed it and resubmitted it on October 23, and it has remained in Waiting for Review since then, with no messages in App Store Connect. Its in-app purchase and subscription are also waiting for review. Our agreements, tax and banking information are all active, and other apps on the same account have been reviewed and released normally. Support case 103010061741 was opened on October 27 and followed up on October 29, and we have not received a resolution. We also submitted an expedited review request on November 6. Could you please check whether something is blocking this submission, and tell us if any action is needed from our side?

Hello, I'm having an issue with my Apple Developer account being inactive, and I'm unable to access the developer services I need. I paid my yearly developer payment a month early which didnt make the warning dissapear that i needed to pay. When time came ran up the system acts as if i never paid. I even submited my receipt invoice number in my support ticket. I submitted a support request to Apple over a week ago, but I have not received any response other than the initial confirmation. Apple Developer Support Case ID: 103013969563 I've been developing and publishing games on Apple's platform for approximately 10 years, and this situation is preventing me from continuing my work. Has anyone experienced something similar? Is there a way to escalate an existing support case or contact someone at Apple who can help resolve account activation issues? I would appreciate any guidance, especially from an Apple representative. Thank you.

I have been waiting for over 2 weeks now for getting my account activated, and now the account is still pending? Is there any solution please? Best regards Kais

Hello everyone! 😊 I recently submitted my first app to the App Store, and it has been stuck in the "Waiting for Review" status for over 7 days now. I completely understand that Apple's review team may be handling a large number of submissions, and I truly appreciate their hard work. I was just wondering if other developers have experienced similar delays recently. Is this a normal waiting time for a first-time app submission? I'm really excited to launch my first app, so any insights or experiences you could share would mean a lot to me! Thank you so much for your time and help. Wishing everyone a wonderful day! 😊