Overview

At first, the MacBook Air M2 gives an "failed to personalize" error when updating, the detailed error message shown by softwareupdate shows that something related a recovery partition is wrong. The exact error message is not available now. (To solve this issue) I tried to revive the Mac, but it failed the first time and multiple tries also failed after that. The Mac is unable to boot into macOS and the Recovery. The MacUpdater.log shows the following: [12:13:52.3728] find_filesystem_partitions: recovery os container= volume= [12:13:52.3728] entering fsck_recovery_os_filesystems [12:13:52.3728] ramrod_display_set_granular_progress_forced: 29.000000 [12:13:52.3728] fsck_recovery_os_filesystems: No dev node for 'Recovery' partition [12:13:52.3728] leaving fsck_recovery_os_filesystems, returning 26 [12:13:52.3728] [04:13:49.0882-GMT]{3>6} CHECKPOINT FAILURE:(FAILURE:26) MOUNTED:[0x1605] fsck_recovery_volume [0]D(failed to fsck recovery OS filesystems) Since there are many important data on the Mac, I cannot do a restore on it. How should I restore the data?

Hello App Review Team, Our iOS app has been stuck in "Waiting for Review" for more than 12 days with no status change and no Resolution Center messages. App name: Express Evaluations Developer: Express Evaluations, Inc Platform: iOS Version: 1.0 Current status: Waiting for Review Submitted: July 30, 2026 at 11:52 AM We opened an App Review Status case on August 10, 2026 and have not received a reply yet. Case ID: 20000133168856 This delay is blocking our planned release and is affecting stakeholder trust in our launch timeline. Could someone from App Review please check whether this submission is stuck in the queue and advise on the current status? Thank you for your help.

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

The set bitrate is not respected when kVTCompressionPropertyKey_AverageBitRate is used. constant and variable bitrates seems to work, only average that is broken. All three modes works in iOS 26.

Hello, My Team ID: 536YC9W689 I submitted my App Store Small Business Program application on July 7, 2026. On the same day, I received the confirmation email titled "We’ve received your request to join the App Store Small Business Program". It has now been more than 30 days since submission. The application status still remains under review, and I have not received any follow-up emails, requests for additional documentation, or approval/rejection notifications. All items in my Paid Applications Agreement are fully completed and active: Contract status: Active Tax information: Submitted and verified Banking information: Verified Could anyone from the Apple team help check the current status of my application? Please let me know if there is any missing information or further action required on my end. Thank you.

I am having an issue with both In-App Purchases and auto-renewable subscriptions using the current App Store Connect submission workflow. My app was previously submitted for review along with its IAPs and first auto-renewable subscriptions. The app itself was approved, but the IAPs and subscriptions were not approved with it. Afterward, the IAPs/subscriptions showed “Developer Rejected.” I did not intentionally reject these products individually. Because App Store Connect states that the first auto-renewable subscription must be submitted with a new app version, I created a new version (1.1.8), uploaded a new binary, and added version 1.1.8 for review. I now have the following situation: • My In-App Purchases show “Ready for Review.” • My subscription group shows “Ready for Review.” • Both auto-renewable subscriptions show “Ready for Review.” • The Add for Review controls for these products are disabled, so I cannot add them to another submission. • App Store Connect shows only one Draft Submission. • When I open that Draft Submission, the only item listed is iOS App 1.1.8. • None of the IAPs, the subscription group, or the individual subscriptions appear in the Draft Submission. Therefore, App Store Connect appears to consider the IAPs and subscriptions Ready for Review, but they are not actually visible in any Draft Submission and I have no way to add them to the 1.1.8 submission. I have tried removing iOS App 1.1.8 from the Draft Submission and adding it again. This does not change the status of the IAPs or subscriptions and does not make them available to add to the submission. I have contacted Apple Developer Support twice, but so far they have not been able to provide a solution. Has anyone encountered this with the new App Store Connect IAP/subscription submission workflow? Is there a way to reset the review/submission state of IAPs and subscriptions that show “Ready for Review” but are not actually present in any Draft Submission? I would strongly prefer to keep the existing product identifiers rather than recreate all of the IAPs and subscriptions.

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.

App Store Connect will not let me attach the subscription to a version submission. App stack: React Native / Expo, EAS builds Subscription: monthly auto-renewable, single tier Payment integration: RevenueCat What is working: Subscription fully configured in App Store Connect (Prepare for Submission status) All metadata complete: localization, price, availability, App Review screenshot, review notes Paywall works on device: StoreKit fetches the product live, Apple purchase confirmation flow initiates correctly Paid Applications Agreement, banking, and tax info all Active RevenueCat integration validated (Valid credentials, price fetches at runtime) What is failing: App Store Connect submission UI shows: "Unable to Submit for Review - Your first subscription group must be submitted with a new app version. New subscription groups must be submitted with an auto-renewable subscription from within that group." No option to attach a version in the draft submission flow The rejected version's Edit flow does not offer an In-App Purchases and Subscriptions section Standard documented flow does not produce a bundling option What I have tried: 4 submissions across multiple builds and versions - all rejected under 2.1(b) with "app references pro features but the associated In-App Purchase products have not been submitted for review" 3 Developer Support cases - all responses confirmed this issue is outside Developer Support scope, pointed here Removed all previous rejected submissions to reset the version to "Prepare for Submission" - no change in behavior This matches known Apple Developer Forums threads 713221, 812514, 705460 where developers in the same stuck state required App Store Connect engineering to manually push the subscription to "In Review" on the backend. If any Apple engineers are able to look into this: happy to provide App ID, submission ID, and product IDs privately via DM. Requesting assistance getting the subscription attached to the pending version submission so review can complete.

I'm working on an iPhone app that continuously monitors device tilt with Core Motion. When the device has been held tilted forward past a threshold angle for a sustained period, the app raises a local notification. The detection has to keep running while my app is in the background. The situation I need to detect is, by definition, one where the user is looking at some other app — if my app were in the foreground, there would be nothing to detect. So a foreground-only implementation would not implement the feature at all. While testing this I ran into a behavior I would like to understand properly before I rely on it. What I observe CMMotionManager device-motion updates to a backgrounded app stop within a few seconds of the app leaving the foreground — unless a Core Location session is running at the same time. With location updates started under When In Use authorization and allowsBackgroundLocationUpdates = true, the device-motion callbacks continue for the whole time the app is backgrounded. Stop the location session, and they stop again. I built a focused sample to measure this. It starts device-motion updates at 10 Hz on a background OperationQueue and counts every callback, records the count on didEnterBackground, and on willEnterForeground logs how many arrived during the interval against how many would be expected at 10 Hz. Measured on an iPhone running iOS 26.5.2, launched from the Home screen with no debugger attached: location ON | background 137s | received 1366 / expected ~1373 (99.5%) location OFF | background 129s | received 2 / expected ~1286 (0.16%) Both callbacks in the second run arrived immediately after the transition to the background; nothing arrived over the remaining two minutes. One thing that cost me a test cycle, in case it saves someone else one: the difference only shows up when the app is launched from the Home screen. With the Xcode debugger attached the app is not suspended, and both cases deliver callbacks for the entire interval. The location session in the sample is configured as low as I can make it, since the app never reads the coordinates: manager.desiredAccuracy = kCLLocationAccuracyThreeKilometers manager.distanceFilter = 3000 manager.activityType = .other manager.pausesLocationUpdatesAutomatically = false manager.requestWhenInUseAuthorization() // started from the foreground, once authorization is granted manager.allowsBackgroundLocationUpdates = true manager.startUpdatingLocation() func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { // Intentionally empty. This sample does not use the location values. } My questions Is continuous CMDeviceMotion delivery to a backgrounded app dependent on an active Core Location session? Is that intended and expected behavior on current iOS versions, or an implementation detail I should not be relying on? If it is expected behavior, what configuration would you recommend for an app in this situation? Specifically, is kCLLocationAccuracyThreeKilometers with a large distanceFilter sufficient to sustain the session, or does reliable delivery require a higher accuracy or a smaller distance filter? Is there another supported API or background execution mechanism that delivers continuous device-motion or accelerometer data to a backgrounded app? I am aware of CMSensorRecorder for retrospective retrieval, but I need to react in near real time. I would like to be sure I am not overlooking a more appropriate API. Environment: iOS 18.0 and later, iPhone only, Swift / SwiftUI. I have the focused sample project available if it would be useful. Thanks very much for any help.

I’ve been trying to get this app through App Review for more than two months now. It was rejected a few times before. I changed what Apple asked me to change and submitted it again each time. The current version has now been sitting in Waiting for Review for quite a while and nothing is happening. I’m actually not very familiar with the App Store review process, so I’m not sure how long Waiting for Review is supposed to take. Do I just leave it there and wait? Or should I submit it again? I’m also wondering if I need to create a new submission / new ID at this point. I don’t want to keep changing things if that just sends me back to the beginning of the queue. The whole thing has already been going on for more than two months, so I’m a bit lost on what I’m supposed to do now. Has anyone run into this before?

Hi all, I hope someone from App Review can take a look My situation: QuidProQuote: Memory Keeper (app ID: 6791349683) is a simple cross-platform app where a single purchase unlocks both the macOS and iOS versions. Both versions were submitted from the same build/codebase. The problem is that while my macOS version has been approved and is now pending my release, the iOS version (submission ID: 9fba8d59-d9a7-4a09-bbbe-1d23035adbe1) has been "Waiting for Review" for 12 days now. 2026-07-30, ~4:30pm ET: Both macOS and iOS submissions entered "Waiting for Review" 2026-08-06, ~10am ET: macOS version approved, now Pending Developer Release 2026-08-11 (Today): iOS version still showing "Waiting for Review," 12 days with no status change This ends up being more than a normal wait because the purchase is shared across platforms... releasing the macOS version now would put it in front of customers without the iOS half of what they're paying for. I can't release the approved macOS build until the iOS version clears review, so the delay on one platform is effectively holding both hostage. I did file an expedited review request today (2026-08-11), received confirmation ("we'll expedite this review"). But I read advice that additionally it would be wise to register the problem here. Thanks for any visibility into this!

Hi everyone, First, some context and a genuine compliment: this is our first iOS submission, and overall the App Store Connect tooling and TestFlight have been a great experience — our beta reached 1,351 external testers organically, with 1,700+ sessions and a crash rate below 1%. That said, we're stuck in a loop we don't know how to break, and I'd love advice from anyone who has been through it. Our game, Truckers Brasil Online, is a truck simulator with proprietary real-time online multiplayer, 100% developed in-house in Unity by our Brazilian studio. Same game, same brand and same company operating on Google Play since 2024. Our official YouTube channel has 1.84M subscribers with years of public devlogs documenting the development. We own all source code, all 3D models (including the original Blender source files of every truck), and the dedicated servers that run the multiplayer. The review history: Jul 04 — rejected under 4.3(a) Spam ("similar binary, metadata, and/or concept"), no specific app named Jul 05 — we replied with a detailed originality dossier (PDF attached to the conversation) Jul 14 — next review did NOT raise 4.3(a); it moved to a connection bug and gameplay questions, which we fully answered with a corrected build and a step-by-step visual guide Aug 07 — the same generic 4.3(a) text returned, with no new facts and no reference to any of the evidence Each of the three reviews lasted under 20 minutes according to the activity log, so we suspect the attached evidence was never actually opened. We have already: replied in the conversation with a complete evidence dossier, filed a formal appeal to the App Review Board, and contacted Developer Support (case open). Questions for the community: Has anyone successfully overturned a repeated 4.3(a) on a genuinely original game? What ended up working? Is there anything else we can do while the appeal is pending — or anything we should avoid doing? For Unity games specifically: is there any known way to reduce false-positive binary similarity flags? We're happy to provide any verification — source code, Blender files, live server access, video demo. We just need the evidence to actually be looked at. Thanks in advance for any guidance! Thiago — LTDA VERA CRUZ (FG Games Entertainment)

Hi Apple DTS and community, My developer account's app has been granted the Default Mail App managed capability (com.apple.developer.mail-client). The capability works for Development and App Store Connect distribution, but it is not enabled for Ad Hoc distribution. This prevents us from using our Xcode Cloud “Archive & TestFlight” workflow: The archive succeeds. Development and App Store Connect exports succeed. Xcode Cloud then automatically attempts an Ad Hoc export. The Ad Hoc export fails, causing the entire archive action to fail and the TestFlight post-action to be skipped. The export log reports: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We have reproduced this in two consecutive Xcode Cloud runs. We also confirmed that: The App ID has the Default Mail App capability enabled. The entitlement is present and correctly spelled in the app’s entitlements file. The App ID’s provisioning support lists Development and App Store Connect, but not Ad Hoc. Our Xcode Cloud workflow does not expose an option to disable the automatically attempted Ad Hoc export. This appears to match these previous reports: https://developer.apple.com/forums/thread/774506 — a DTS engineer enabled Ad Hoc support for the entitlement, after which the developer confirmed the issue was resolved. https://developer.apple.com/forums/thread/800072 — DTS confirmed that the Ad Hoc distribution option must be enabled for the Default Mail App managed capability. We also opened an Apple Developer Support case (102945477410). Developer Support directed us to the forums and indicated that this issue would need to be handled by DTS engineers. I can provide our Team ID, Developer Support case number, Xcode Cloud run identifiers, and any other account details privately if needed. Thank you!

Hello everyone, I'm facing a frustrating issue with the new App Store Connect UI when trying to submit In-App Purchases alongside my app version. My Situation: App: Nagpur Prime Property (iOS) Rejected under Guideline 2.1(b) — App Completeness Reason: IAPs not submitted with the binary What I've Done: Uploaded new Build 7 (v1.0.1) ✅ Created 2 auto-renewable subscriptions: • Basic Plan (npp_basic_plan) — Ready for Review ✅ • Premium Plan (npp_premium_plan) — Ready for Review ✅ Added both to a Draft Submission (3 items total) ✅ Sandbox tester account added ✅ The Problem: The Draft Submission panel shows: ⚠️ "Unable to Submit for Review — To submit your items for review, add an app version for the selected platform." The "Submit for Review" button is permanently GRAYED OUT. The Draft Submission shows: Versions column: "-" (no app version linked) Items: 3 (Subscription Group + 2 subscriptions) The App Version (Build 7) is in a SEPARATE submission showing "Ready for Review" — but there is NO UI option to link the two submissions together. What I've Tried: Clicking "Add for Review" from Subscription Group page Clicking "Add for Review" from individual plan pages Clicking "Draft Submissions (1)" from version page Contacted Apple Review team — no solution provided Tried "Resubmit to App Review" on version — IAPs not included Question: In Apple's new App Store Connect UI, how do you correctly link an IAP Draft Submission to an App Version submission so they can be reviewed together? Is there a specific order of operations that needs to be followed? Or is there a known workaround for this issue? Thank you in advance!

Hi! I'd like to share an implementation of 2D soft shadows using SpriteKit and custom Metal rendering. GitHub Repo SpriteKit-SoftShadows The demo app runs on iOS and Mac Catalyst. The soft shadow implementation is based on Scott Lembcke's algorithm. Pipeline The app uses MTKView to drive the rendering loop at the desired frame rate. Each frame: SpriteKit renders the scene into a Metal texture using SKRenderer. The CPU sends each light's properties and the relevant shape edges to a Metal vertex shader. The vertex shader projects shadow geometry from each edge. A fragment shader calculates the shadow opacity at each pixel, producing a soft shadow mask for each light. A final fragment shader combines the SpriteKit texture, lights, and shadow masks to produce the displayed image. The SwiftUI controls update variables inside the SpriteKit scene through @Observable. The rendering loop consumes the new values on its next cycle. Let me know if you have any feedback!

Our initial release has been in "Waiting for Review" since July 29, 2026. As of today, August 11, it has never progressed to "In Review." App ID: 6771136749 Version: 1.0 Submitted: July 29, 2026 Support Case ID: 20000135031799 Details: Initial release, not an update Build has not been cancelled or resubmitted at any point Free Apps Agreement is active; no paid features or IAP Metadata, screenshots, and App Review Information (including demo credentials) are complete No messages in Resolution Center I filed a support case today but wanted to post here as well in case anyone from App Review can confirm whether the submission is correctly in the queue. Has anyone seen initial submissions sit this long recently without moving? Interested in whether this matches the backlog others have reported this year.

My app start up has became horrid. It takes 1 minute to open SQLlite database for my rust core. Impossible to work... I have Address Sanitizer, Thread Perf Checker and Thread Sanitizer disabled...

A build has been uploaded to TestFlight, and we have existing Internal Testing groups that have worked successfully in the past. However, when I click the blue + button under Groups, all groups are disabled and cannot be selected. The same issue occurs with a newly created group. I’m an Admin and have permission to manage testers and groups. Build Distribution is set to Automatic for Xcode Builds, as it was previously when this worked without issue. Is there a known workaround or setting that could resolve this? Thank you

In my apps, I have a requirement to display an image of the application icon is certain circumstances. This is fairly straightforward for iOS/iPadOS and it used to be straightforward for macCatalyst. For MacCatalyst, this is no longer true (at least since macOS 26). This is because the app icon is now stored as an .icns file and (in the case of using an IconComposer icon), the `'png' in the Asset Catalog now has an unknown name. So the following code no longer works: public extension Bundle { var icon: UIImage? { #if targetEnvironment(macCatalyst) guard let iconName = infoDictionary?["CFBundleIconName"] as? String else { return nil } return UIImage(named: iconName, in: self, compatibleWith: nil) #else guard let icons = infoDictionary?["CFBundleIcons"] as? [String : Any] else { return nil } guard let primaryIcon = icons["CFBundlePrimaryIcon"] as? [String : Any] else { return nil } guard let iconFiles = primaryIcon["CFBundleIconFiles"] as? [String] else { return nil } guard let file = iconFiles.last else { return nil } return UIImage(named: file, in: self, compatibleWith: nil) #endif } The obvious solution is to place an Image in the Asset Catalog which I can access, but this is a maintenance headache. What I would actually like to do is either create a UIImage directly from the .icns file, or access the .png file in the Asset Catalog (which has a name beginning with the icon file name, but has additional characters in its name that I don't know). Can you help?

I am unable to attach my In-App purchases and Subscriptions to my only Draft Submission for my app. My IAP and Subs say "Ready For Review" but Im not able to see or select them to submit them for review.