Overview

Hi everyone, I'm hoping someone can shed some light on an App Review issue we're currently experiencing. We have submitted our Caffè Sabrina iOS app (version 1.0, build 5) for review. The app was previously reviewed by Apple and we were told that the demo account credentials we had provided were no longer valid. We immediately fixed this by creating a completely new demo account, testing it successfully, and updating the App Review information in App Store Connect. We then resubmitted the app. The submission has been sitting at “Waiting for Review” since Wednesday at 7:57 AM. The unusual part is that we have now requested expedited review twice, and Apple confirmed that the review would be expedited. However, the submission still hasn't moved to “In Review.” We've checked everything we can think of: Current build is correctly submitted. New App Review credentials have been tested successfully. App Review information has been updated. The latest build has been tested through TestFlight. The latest build has had installs and multiple sessions. There are no known crashes on the latest build. The current submission has not been cancelled or resubmitted again. We're now several days beyond the expedited request and are concerned that something may be preventing the submission from entering the review queue. Has anyone else experienced an expedited review being granted but the app remaining stuck on “Waiting for Review” for several days? If so, did Apple eventually move it into review automatically, or did you have to contact App Review again? Any advice would be greatly appreciated. Thanks, Michael Darling Tech Ltd

Hello App Review Team, I’m following up regarding our app Neat Everyday, which has been in Waiting for Review for approximately one week. We submitted an Expedited Review request yesterday because the app is part of our planned India launch, but we have not received any update and the submission remains in Waiting for Review. Could you please check whether the submission is correctly queued for review or if any action is required from our side? The app has been reviewed and approved by Apple previously, and there are no outstanding issues or requests for information in App Store Connect. We would greatly appreciate it if you could check the status of this submission. Thank you.

For some reason, Carplay 18.x works fine, however in under certain situations in our app, Carplay 26.x breaks. The expected grid layout should be : However, this is what we see in some cases when we update our templates. I have not been able to isolate the cause of this issue. Has anyone ever seen this happen on their CarPlay apps and discovered the cause? The data sets fed into the templates are identical, the difference is in some of the timing and update order...

For macOS 26.7.1 (25G241), Xcode 27.0 (27A266a), and macOS SDK 27.0, we request the supported, exact Info.plist schema for NSDataAccessSecurityPolicy: its value type, literal key names and nesting, item types, and identity-selector grammar. Can the policy allow only the owning process signed with a specific Team ID and signing identifier, without allowing all applications signed by that Team? Are cdhash or designated-requirement selectors supported, and how do process and installer/package identities differ? Please clarify the relationship to user consent and Full Disk Access exceptions, and confirm whether this configuration is supported for the macOS build listed above. Please provide primary documentation or an authoritative schema, rather than a schema inferred from NSUpdateSecurityPolicy.

App Review, App stuck in "Waiting for Review" since Sep 30 after expedite approval Hello, Our app HospiSavvy (Apple ID: 6766224866), iOS version 2.5, has been in "Waiting for Review" since September 30. Timeline: Sep 25: Resubmitted after addressing metadata feedback Sep 30: Expedited review approved. A reviewer asked about VPN functionality the same day. We replied (the app has no VPN functionality) and resubmitted at 11:06 AM. Since then, the status has not changed, and we can't reply further in the App Review thread. Oct 5: Opened a support case (Case ID: 102986178435), no response yet. Could someone from App Review please check whether this submission is stuck? Any help would be appreciated. Thank you.

Hello Apple Developer Community, Our iOS App Version 1.0 has been in the App Review process since September 2, 2026, with multiple review and rejection cycles. Our latest submission was made on September 25, 2026, and has remained Waiting for Review since then. We have submitted 2 Expedited Review requests and contacted Apple through Contact Us / Support by email once, but we have received no response or update. As of October 6, the overall review process has been ongoing for 34 days. Has anyone experienced a similar situation or can advise how we can follow up or escalate this with Apple? Thank you.

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

SwiftUI Button hit area extends ~16pt beyond its visual frame — expected OS behavior? Hi everyone, I’m working on a custom SwiftUI segmented control and noticed some unexpected hit-testing behavior with Button. I have a button structured roughly like this: Button { selectItem(at: index) } label: { ZStack { if selectedIndex == index { selectedBackground } SegmentCellView( tab: tab, isSelected: selectedIndex == index ) } .frame(maxWidth: .infinity) .contentShape(Rectangle()) } .accessibilityLabel(Text(tab.labelText)) The visual frame of the button has a certain height, but when testing on a real device, I can tap approximately 16pt outside the button's visible frame and the button still receives the tap. This seems to happen even though I explicitly use: .contentShape(Rectangle()) to define the tappable shape. My questions are: Is this ~16pt expansion of the interactive area expected SwiftUI/OS behavior? Is this related to Apple's minimum hit-target/accessibility guidelines being automatically applied to controls such as Button? If so, is there an official API/documentation describing this behavior? Is there a recommended way to make the Button's hit-testing area exactly match the bounds defined by .contentShape(Rectangle()), if that is actually possible? I'm particularly interested in understanding whether this is intentional system behavior or something caused by the ButtonStyle / layout hierarchy. Thanks!

I’m using MFMailComposeViewController to send emails from my app. Since updating to iPadOS 26.4, there is no way to cancel the mail composer because the “X” button in the top-left corner has disappeared. On iPhone with iOS 26.4, everything still seems to work as expected. Is this a known issue, or am I missing something? Has anyone else experienced this, or found a workaround?

When i use the MFMailComposeViewController in visionOS, there is no cancel button for the controller. The button at the bottom closes the app. Is anyone else experiencing this? if([MFMailComposeViewController canSendMail]) { MFMailComposeViewController* controller = [[MFMailComposeViewController alloc] init]; controller.mailComposeDelegate = (id <MFMailComposeViewControllerDelegate>)view; [controller setToRecipients:toAddresses]; [controller setSubject:subject]; [controller setMessageBody:body isHTML:isHtml]; [view presentViewController:controller animated:YES completion:nil]; }

I’m developing a SwiftUI iPad app that runs on an Apple silicon Mac as an iPad app—not as a Mac Catalyst app. The app supports multiple windows, with each Live Screen window associated with a different virtual machine. In the macOS Window menu, all child windows appear as “VirtualProg” rather than showing their content or VM name. The Live Screen window is created from a data-driven  WindowGroup , roughly like this: WindowGroup(id: "vm-screen", for: String.self) { $vmName in VMScreenWindow(vmName: vmName) .navigationTitle(vmName.map { "Live ($0)" } ?? "Live Screen") } I’ve tried setting the title with  .navigationTitle  both on the  WindowGroup  content and inside the window’s  NavigationStack . I also tried setting  windowScene.title  on the specific scene obtained from  view.window?.windowScene  after the view controller appeared. Neither changed the Window-menu entries. Is there a supported way to set a per-window title for the macOS Window menu when running an iPad app on Mac? Does  UIScene.title  affect that menu, or only the window title bar and app switcher? Is this a limitation of the iPad-app-on-Mac runtime, or is there a recommended SwiftUI/UIKit lifecycle hook for this? I’m looking for a public API solution rather than private AppKit/window introspection.

MapKit offers showsTraffic: Bool, which is great for displaying live traffic data on the map. However, MapPolyline sits above it, which makes it quite useless. Is this the expected behaviour?

I am seeing a reproducible Developer ID code-signing issue on an Apple Silicon Mac running macOS 26.6.2. A Universal macOS app and its Quick Look extension (arm64 + x86_64) are signed with a newly issued Developer ID Application certificate using Hardened Runtime and a secure timestamp. Immediately after signing, all verification succeeds, including: codesign --verify --strict --verbose=4 and architecture-specific verification for both arm64 and x86_64. At this point, codesign reports: valid on disk satisfies its Designated Requirement The expected Developer ID authority chain and TeamIdentifier are present. However, after some time, without modifying the bundle or executable, the exact same Quick Look extension starts failing verification for both architectures: invalid signature (code or signature have been modified) codesign -d then reports: Authority=(unavailable) Info.plist=not bound The executable SHA-256, size, and mtime remain unchanged. I also copied the now-invalid extension to a different directory, creating completely new inodes. The copy remains invalid. I verified that: all regular files in the original and copy are byte-for-byte identical executable SHA-256 is identical _CodeSignature/CodeResources is identical there are no hard links (link count is 1) there are no extended attributes anywhere in the extension com.apple.provenance, com.apple.quarantine, and com.apple.FinderInfo are absent copying the bundle to a new inode does not restore signature validity The affected extension executable currently has: SHA-256: 3b36d1aca258a371311a9c94e93d10606edc184ea120dd252cf230a251c67243 CDHash arm64: 178ff5b7b2cedbed00ec6bc07536d168e22d9ba5 CDHash x86_64: ada914101f5b107704b78958520c904c4f022894 Signing environment Developer ID Team ID: XY2B8MLPV8 The Developer ID Application certificate is newly issued with a new RSA 2048-bit private key. I have also observed the following message in the Security log during signing: CSSMERR_CSP_INVALID_KEYATTR_MASK No new occurrence of that error is logged when subsequently verifying the already-invalid extension. Troubleshooting already performed I have: issued a completely new Developer ID Application certificate with a new RSA 2048-bit private key verified the certificate chain and code-signing policy successfully reproduced related Keychain/identity problems in a fresh macOS user account tested with a newly created independent Keychain tested in Safe Mode reinstalled macOS without erasing user data Before reinstalling macOS, even security find-identity -v -p codesigning eventually failed to recognize otherwise valid Developer ID identities. After reinstalling macOS, security find-identity -v -p codesigning correctly reports all identities again. I then performed a durability test using the new Developer ID identity on a minimal Universal Mach-O binary. Verification succeeded: immediately after signing after approximately 2 minutes after approximately 5 minutes after copying the binary to a different directory The minimal binary remained valid throughout. However, the problem subsequently reproduced with the actual Quick Look extension. Notarization The application was packaged in a Developer ID Installer-signed PKG and submitted to Apple Notary Service. The submission was Accepted, stapling and validation succeeded, and Gatekeeper accepted the notarized PKG. Notarization submission ID: 54dc0de7-5089-4b8c-9c10-b5a74df8df97 I initially suspected the packaging process, but I subsequently found that the original pre-PKG Quick Look extension itself had become invalid. Therefore, this does not appear to be caused by PKG creation or extraction. Questions What could cause a Developer ID signature that initially verifies successfully to become invalid later when the signed files themselves have not changed? Is there a Security.framework / codesign diagnostic that can show exactly which part of the CMS signature or CodeDirectory validation is failing? Are there any known macOS 26.x issues involving code-signing validation or CSSMERR_CSP_INVALID_KEYATTR_MASK that could explain this behavior? I would be happy to collect additional Security logs, codesign diagnostics, or a sysdiagnose if that would help identify the cause.

My Individual Developer account (Team ID: SU8NVE3Z6C) has been suspended due to an automated compliance check regarding digital assets, citing Sections 14.8(a) and 2.8 of the DPLA. I have a clean 13-year track record on the App Store. On September 23, immediately after receiving the automated notice, I submitted all requested documentary evidence directly to provider_review. I provided my official residence documents and description of my apps. They do not involve custody, exchange, trading, or transmission of digital assets, nor do they violate any applicable laws. It has now been over a week since I submitted the full documentation. My entire portfolio of apps remains removed from the App Store. This prolonged downtime is causing severe ongoing financial loss and severely disrupting the experience for my active subscribers. Could an Apple Community Specialist or a senior support engineer please help escalate this review? I have provided everything asked of me and urgently need my account access restored. Thank you in advance for your assistance.

I'm submitting a new version of my app, and after click "submit for Review", it show that: A few more items are needed in order to submit for review The items listed below are required for submission:There are still screenshot uploads in progress. I didn't met this problem before. Is that mean I haven't upload all the screenshot required or it's still uploading the screenshots to App Store Connect's server? Cause before there is a "save" button after you drag images to the screenshots area, now you don't. And I think I have uploaded all the screenshots needed and I waited a day to try submit again, still the same. What should I do?

We are seeing a production crash that only affects devices reporting iOS 27.0.0. Devices on 27.0.1 and later, and on iOS 26, are unaffected. The app is built with Xcode 27.0 (the same binary shape appears with the Xcode 27.1 RC toolchain), deployment target iOS 26.0. The crashing code is a plain availability-gated call: extension View { @ViewBuilder func disableNavigationBarMinimization() -> some View { if #available(iOS 27.0, *) { toolbarMinimizationBehavior(.never, for: .navigationBar) } else { self } } } Crash report excerpt (addresses and app symbols removed): crash_info_entry_0: Failed to look up symbolic reference at <addr> - offset <n> - symbol <nearest stripped symbol> in <app binary> - pointer at <addr> is likely a reference to a missing weak symbol Crashed: com.apple.main-thread 0 libsystem_kernel.dylib __pthread_kill 2 libsystem_c.dylib abort 3 libswiftCore.dylib <redacted> 9 libswiftCore.dylib swift_getTypeByMangledName + 908 10 libswiftCore.dylib swift_getTypeByMangledNameInContext2 + 248 11 <app> __swift_instantiateConcreteTypeFromMangledNameV2 12 <app> specialized closure #1 in View.disableNavigationBarMinimization() 13 <app> closure #1 in SomeView.body.getter What we established: Because the deployment target is 26.0 and the API is @available(iOS 27.0, *), the app weak-imports both the function and its opaque result type descriptor. dyld_info -imports on the binary shows: _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtF [weak-import] (from SwiftUI) _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtFQOMQ [weak-import] (from SwiftUI) The call site has to instantiate the opaque return type's metadata before calling the function. That is the frame that aborts. So when dyld binds the descriptor to null, #available(iOS 27.0, *) passes and the process still dies. The symbol is present and exported on the iOS 27.0 build we can inspect locally (24A437, via Xcode's DeviceSupport symbols), and the same code runs fine on the iOS 27.0 simulator runtime (24A434). We cannot reproduce the crash on any device we own. The SwiftUI binary in 24A437 exports both toolbarMinimizeBehavior(_:for:) / ToolbarMinimizeBehavior and toolbarMinimizationBehavior(_:for:) / ToolbarMinimizationBehavior. The iOS 27.1 SDK only declares the latter, still annotated @available(iOS 27.0, *). This looks like a rename late in the 27.0 cycle. Our working theory is that some iOS 27.0.0 builds in the field (earlier 27.0 builds, possibly the ones preinstalled on new devices) predate the rename and only contain toolbarMinimizeBehavior, so the renamed symbol is absent and the weak import resolves to null. Questions: Is the @available(iOS 27.0, *) annotation on toolbarMinimizationBehavior(_:for:) accurate for every shipped 27.0.0 build? Should it be 27.0.1 or 27.1? Is there a supported way to guard against a missing opaque type descriptor at runtime, short of raising the availability check? Feedback filed as FB25095054.

I've never had anything but trouble with xcappdata, but I got what I wanted working in the previous xcode version, I could specify the xcappdata in my testplan and it would work on the simulators. Now, on XCode 27, the xcappdata doesn't load. I look in the xcode 27 release notes and see there is indeed an issue with xcappdata, and a workaround. Workaround: To make a .xcappdata bundle for use in Xcode’s Run scheme action do the following. Add .xcappdata to the folder created by Device Hub when downloading app data containers. Inside that folder make a new folder named AppData. Move the other content in that folder into AppData. For example, com.example.MyApp/{Documents,Library,tmp} becomes: com.example.MyApp.xcappdata/AppData/{Documents,Library,tmp} This is completely unhelpful. When am I downloading app data containers? What folder is created by Device Hub? Where is it? How does this apply to my testplan? What if I have multiple xcappdata bundles for different test plans? It looks to me like this workaround would be part of a script where at some magic moment I inject my app data into a simulator. Which might not be too bad So if I wanted to build this script it I imagine it looks like create a simulator install the app on the simulator find the folder related to the simulator copy in my xcappdata? Then I can run my tests?

I downloaded the CarPlay Simulator from Additional Tools for Xcode 27, but I can't find a way to test the navigation banners on the left or right side Several users have complained, and one of them finally sent me a photo. It looks fine in my simulator but not on their CarPlay screen How do we test those edge cases scenarios? This is my Simulator, looks fine And this is user's photo clearly showing the navigation banners in a different position

Hi there, My app uses UIScreen.screens.count (deprecated) to predict whether mirroring is happening on older iOS devices I noticed that the number of screens is different between iOS 26 SDK apps, and iOS 27 SDK apps. Can I expect that iOS 26 SDK apps will continue to return 1 screen like below for the iPhone Duo release?. I assume it's like this is to maximise compatibility. App built with SDK 26 on Xcode 27.1b1 iPhone Duo sim: UIScreen.screens.count == 1 App built with SDK 27 on Xcode 27.1b1 iPhone Duo sim: UIScreen.screens.count == 2 Thanks for the help! Sam

I am diagnosing a trust failure for an archived iOS arm64 app, without changing trust settings or rebuilding speculatively. Environment: macOS 26.6.2 (25G83), Xcode 27.0 (27A266a), as reported by installed public metadata. The diagnostic is a non-interactive Python helper calling the installed Security/CoreFoundation APIs through a bounded child-process runner in a desktop coding-agent session. This is not an Xcode GUI operation; an effect of the session, keychain/cache, or service access has not been established. Observed results: The app's embedded code CMS supplies three certificates. One explicitly identified signer matches the stored signer receipt in memory. The helper places the signer first, followed by the other supplied certificates. It uses SecPolicyCreateWithProperties(kSecPolicyAppleCodeSigning), SecTrustCreateWithCertificates, and SecTrustSetNetworkFetchAllowed(false). The status-returning setup calls succeed. Disabling intermediate fetching does not prove that all OS revocation/cache/network activity is absent. One SecTrustEvaluateWithError call returns false. The top-level CFError and its single kCFErrorUnderlyingErrorKey child both report NSOSStatusErrorDomain / -26276. The child has no further underlying-error key. This designated key chain was collected completely; other userInfo and localized descriptions were not collected. A prior recorded evaluation returned a chain containing only the signer. The latest diagnostic did not request another evaluated chain. Supplied certificates and the evaluated/trusted chain are distinct observations. Separate metadata collection found three distinct supplied certificates within their validity intervals at the observation time. Issuer/subject names matched signer → supplied issuer → third certificate, and the third had equal issuer/subject names. This does not verify issuer signatures, CA purpose, or root trust. Existing independent codesign --verify --deep --strict verification exits 1 with CSSMERR_TP_NOT_TRUSTED for arm64; it does not identify the failing certificate. The extraction/trust helper does not validate the CMS/CodeDirectory signature. The public SecTrust header allows false both for denied trust and for an evaluation that cannot complete. The inspected installed SecBase header defines errSecInternalComponent as -2070 and errSecDecode as -26275; it provided no name for -26276. I am not treating -26276 as either code or as proof of certificate/profile damage, sandbox denial, or trust-service failure. Questions: What supported interpretation or specific conditions explain -26276 on this public Code Signing API path, including the underlying error repeating the same domain/code? What smallest independent public field or observation distinguishes policy rejection from evaluation failure while keeping the policy, intermediate-fetch=false, and trust settings unchanged? The underlying key chain supplies no more specific code. How should this be interpreted alongside CSSMERR_TP_NOT_TRUSTED from strict verification of an archived iOS app? What specific evidence separates an embedded-signature/signing-input defect from a local trust or evaluation-context failure and justifies a targeted correction? No certificate names, fingerprints, DER, profile identifiers, account details, private paths, raw payloads, or attachments are included.