Overview

I’m trying to understand what guarantees CSSearchableIndex batching provides. beginBatch() // submit changes to searchable items (add/update/delete) endBatch(withClientState: newState) Two questions: 1. Persistence before endBatch If the app crashes after submitting changes to searchable items, but before calling endBatch, are those changes guaranteed not to be persisted? If the answer is yes, then the follow-up question is: 2. Atomicity of endBatch When endBatch(withClientState:) succeeds, is the batch atomic with respect to all submitted item changes, and the new client state? In other words, is it guaranteed that: either all submitted item changes and the new client state are persisted, or neither is persisted? Or is there any internal failure scenario in which the batch is only partially persisted – for example, some or all of the item changes persisted, but without the corresponding client state?

Hi all! I am struggling to make any app because reality composer pro freezes when I click on create new project, as well as it does not appear in Xcode at all. I have tried deleting and redownloading all versions of both Reality Composer Pro & Xcode, as well as restarting my computer. Kindly advise what else I can try. Thank you!

FB24536235 On Mac Catalyst under macOS 27, a plain CADisplayLink asking for CAFrameRateRange(minimum: 60, maximum: 60, preferred: 60) gets serviced at 30 Hz for as long as a RealityView is on screen in the same window. The link does nothing per tick but count, so there's nothing of mine to blame it on. RealityKit's own statistics overlay reads 60.41 fps in the same frame. Click a segmented control that removes the RealityView and the same link goes straight back to 60. Nothing else changes. That's the whole reproducer, and I've attached it to the radar. It only happens while the display panel is in ProMotion mode. Set the built-in to a fixed 60 Hz and it's correct again. With an external 60 Hz display attached the roles swap: the built-in is fine and the external drops to somewhere between 18 and 30, and setting the built-in to 60 Hz fixes that one too without touching the external's own settings. A raw MTKView presenting continuously at 60, at 120, and on a 120 Hz link presenting every second callback are all fine, so it isn't continuous presentation and it isn't the requested rate. It's RealityKit specifically. Worth knowing if you're testing: RealityView on Catalyst is an ARView underneath, so both paths give you the same answer. This is VERY rough for anything that puts RealityKit next to a UI. In an editor that's the sidebar, the inspector, gizmos, drag handles, every display-link-driven or UIKit animation in the window running at half rate around a viewport that stays smooth. Likely Related to FB24091347, which is the same defect seen as SwiftUI scroll judder. If you can reproduce either, please file a duplicate. Attached two screenshots; first with promotion enabled, second with promotion off. PLEASE fix this, it drives me crazy and there seems to be no workaround. On release day of macOS 27 our app will likely be blamed for it by users and my hands are tied. Thank you!

We are using an URLSessionDataTask to download some JSON from a server and lately we sometimes receive NSURLErrorCancelled (code -999) for no apparent reason. After enabling CFNetwork Diagnostic Logging I found that in these cases the request finishes with the error mentioned above instead of HTTP/1.1 200 OK even though the response body seems to be transferred in its entirety. What could be causing this? I am pretty certain that it is not us cancelling the task.

We are looking for guidance on a new app submission that has not moved from "Waiting for Review". Our first submission was rejected under Guideline 5.1.1(ii). We addressed the issue the same day by updating the purpose strings to clearly describe how the requested data is used, and resubmitted immediately. The status has not changed since. Why this is time-critical: the backend service our current users depend on is being shut down by our provider on August 28, 2026. The submitted app migrates to a new provider and is the continuation of that service. Without it, our existing users will be left without a working app. What we have already tried: Submitted an expedited review request on August 23, 2026 - no response Contacted Apple through the Contact Us module several times since then - no response beyond the automated acknowledgment each time We are not asking to skip the queue for convenience. We simply need to know whether the submission is progressing normally or whether something additional is required from us. We are ready to respond to any questions from App Review immediately, at any hour. Thank you.

Hello everyone, Our app has been stuck in "Waiting for Review" for 7 days now, and I'd like to check if this is expected given current queue times, or if something might be blocking it. App: Charry Up Submission ID: 419195e2-331c-4553-b290-fc06c3a89ea8 Version: 1.0.0 (6) Submitted: August 20, 2026 at 15:54 Current status: Waiting for Review (has not yet moved to "In Review") I've checked App Store Connect and don't see any messages, missing information, or action required on our side. This is our very first submission to the App Store, and the delay is affecting a planned launch. I've also just submitted a request for expedited review given the time-sensitivity. Has anyone experienced something similar recently? Any guidance on next steps would be greatly appreciated. Thank you!

In transitioning an existing privileged helper tool from SMJobBless to the new-ish SMAppService APIs, I ran into a problem. Registration via [SMAppService daemonServiceWithPlistName:...]; works and I get the green light via SMAppServiceStatusEnabled. Presumably that means my app’s bundle structure is correct, except that when my app creates a connection to the named mach service advertised by the helper tool, the helper tool process no longer launches on-demand. The client side (main app) uses: xpc_connection_create_mach_service("com.fxfactory.FxFactory.helper", queue, XPC_CONNECTION_MACH_SERVICE_PRIVILEGED); The listener / helper tool uses: xpc_connection_create_mach_service("com.fxfactory.FxFactory.helper", dispatch_get_main_queue(), XPC_CONNECTION_MACH_SERVICE_LISTENER); When installed via SMJobBless, the privileged helper tool would automatically launch when a connection attempt is made by the app. This no longer works. The app sits indefinitely, never receiving a reply on its otherwise "live" xpc_connection. The only useful hints on the Console seemed to be the following: taskgated-helper Checking profile: FxFactory Provisioning Profile 2026-1-15 taskgated-helper com.fxfactory.FxFactory.helper: Unsatisfied entitlements: com.apple.developer.service-management.managed-by-main-app taskgated-helper Disallowing: com.fxfactory.FxFactory.helper ...and: /Applications/FxFactory.app/Contents/MacOS/com.fxfactory.FxFactory.helper not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/FxFactory.app/Contents/MacOS/com.fxfactory.FxFactory.helper, unsatisfiedEntitlements=<CFArray 0x7b94c33a40 [0x200d1aab0]>{type = immutable, count = 1, values = ( 0 : <CFString 0x7b950305a0 [0x200d1aab0]>{contents = "com.apple.developer.service-management.managed-by-main-app"} )}, NSLocalizedDescription=No matching profile found} I'm testing this on macOS 27 Beta, not sure if that would/should make a difference. LLMs give a ton of contradicting advice on this topic. I would be great to clear some things out: In addition to having the launchd plist that describes the helper tool copied to /Contents/Library/LaunchDaemons, should the same plist also be embedded by the helper tool binary via -sectcreate __TEXT __launchd_plist? Is it true that XPC_CONNECTION_MACH_SERVICE_PRIVILEGED should be omitted from the client, when using the new SMAppService API? (the LLM surely insisted on this point, but passing 0 didn't fix anything.) What are the unsatisfied requirements of the com.apple.developer.service-management.managed-by-main-app that taskgated is referring to? Again LLMs insist that there are no additional requirements beyond code-signing by the same team, but this must be false. Could it be that helper tool needs to use the same provisioning profile as the main app? Could it be that it needs its own, tied to its own bundle ID? Here are the entitlements on the helper tool sitting in the /Contents/MacOS/ directory of the app bundle, presumably the result of the build process injecting them into their own __TEXT section, similarly to how one would inject __launchd_plist: [Dict] [Key] com.apple.developer.service-management.managed-by-main-app [Value] [Bool] true [Key] com.apple.security.app-sandbox [Value] [Bool] false [Key] com.apple.security.get-task-allow [Value] [Bool] true Assuming that my privileged helper tool is not launching simply because my bundle is violating the requirements for the com.apple.developer.service-management.managed-by-main-app entitlement, what exactly are these requirements? As a side question: if one needs these LaunchDaemons to perform some actions with root privileges, what exactly would enabling the App Sandbox (com.apple.security.app-sandbox = true) on the privileged helper tool accomplish? Is there any point in confining a process with root privileges inside a container? Thank you!

I'm seeing behavior similar to what was reported in this thread: https://developer.apple.com/forums/thread/816344 I read the discussion in the related thread (816320) as well, but I couldn't determine whether receiving the same transaction multiple times from Transaction.updates is considered expected behavior. In my case, I'm testing an auto-renewable subscription in the Sandbox environment. After successfully processing and calling finish() on a transaction, Transaction.updates sometimes provides another transaction with the same transactionId. I've also observed the same transactionId being delivered multiple times through Transaction.updates itself. I compared the JWS representations of these transactions. They are not byte-for-byte identical, but the transaction information appears to be the same. The only differences I've identified are: signedDate deviceVerificationNonce deviceVerification This looks as though the same transaction is being signed again at a different time. I'd like to clarify the intended way to handle this: Is it expected behavior for Transaction.updates to deliver the same transactionId multiple times in this way? If so, after an app has successfully processed and finished a transaction, is it safe to recognize subsequent transactions with the same transactionId as already processed, skip entitlement-related processing, and simply call finish() on them? In other words, can an app use transactionId to prevent duplicate processing of transactions that it has already successfully handled? I'm specifically interested in whether doing so could cause the app to miss any meaningful update that StoreKit might later deliver using the same transactionId.

Solo first-time developer here, hoping to hear from anyone who's actually gotten past this. My app (a personal finance app, no IAP, no payments) was rejected under Guideline 5.6 - Developer Code of Conduct: "a pattern of unusual behavior... commonly associated with fraudulent activity... features that appear to have been intentionally hidden during the review process." No sub-section named, no specifics. I audited my own build and found two things that could honestly fit: an update banner whose text and URL came from my server at runtime, and low usage caps on the guest/demo mode reviewers use. I disclosed both to App Review myself, fixed both (store URL compiled into the binary, server only answers "is there a newer build number", caps raised with wording cleaned up), and resubmitted the new build. The new build got the word-for-word identical 5.6 rejection. There's genuinely nothing left: no OTA updates, no WebView, no region/date/device checks, nothing server-configurable. Which makes me think the flag is on my account's history, not the binary — earlier I had a second App Store Connect record for the same app under an old bundle ID (never released anywhere), which I removed to resolve a 4.3(a), plus several resubmits in a short window while I learned the process. What I've done so far: replied in Messages asking them to name the specific feature (offering a screen recording and a phone call), resubmitted so the reply actually gets read, and filed an App Review Board appeal. Questions for anyone who's been here: Did you ever get them to name the actual behavior, and how? If it was account-level, what finally cleared it — the appeal, a phone call, time, or something else? Did removing an old app record / resubmitting quickly ever turn out to be the trigger for you? Anything you'd do differently in my position right now? Not looking to bash App Review — I just want to comply and can't find out with what. Thanks.

Hello everyone, My new app was reviewed and rejected on August 25. I replied to the App Review team in the Resolution Center on the same day with clarification regarding the issue. It has now been about two days, but I haven’t received any response or status update from App Review. I also contacted Developer Support, and they confirmed that they can see my reply and advised me to wait for the App Review team to respond. They also mentioned that I could submit a new version addressing the issue. In this situation, would you recommend continuing to wait for the reviewer’s response, or submitting an updated build for review? Has anyone recently experienced a similar delay after replying in the Resolution Center? Thank you for any advice.

My widget uses the @Environment(.isActivityFullscreen) variable. When running on ios 17, it will crash and report an error: dyld[55031]: Symbol not found: _$s7SwiftUI17EnvironmentValuesV9WidgetKitE20isActivityFullscreenSbvg Expected in: /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/WidgetKit.framework/WidgetKit

In the WWDC talk: https://developer.apple.com/videos/play/wwdc2026/305/?time=350 "Enhance RAW image processing with Core Image" there is a section on the new RAW9 processing APIs and how to enable them. First off, the sample code compiles on iOS18 but causes a runtime exception because the .version9 symbol cannot be found, looks like the header definition is missing a version check for this value, so I'm not sure how to use this code if you need to support iOS18. Also on later dev betas (I tried the latest beta7) now trying to check if version9 is available the value is no longer present in the supported list: guard filter.supportedDecoderVersions.contains(.version9) else { ... There is another value .version9DNG that resolves to true but if I try to use that decoder the colors on the RAW image are wrong and the image becomes corrupted. How to use the RAW9 decoder in the latest dev betas, what should the final code before production because the WWDC sample now seems out of date and was always wrong wrt. iOS18.

When tapping on Info.plist the editor area stays completely empty and doesn´t show Info.plist

After tapping topmost project name in navigator area xCode won´t show the editor area to update the Project / Target pages and General tab

Hi, Overview: I have a project in which: Some files are only in the app target Some files are only in the widget target Some files are in the app and widget target (both targets) Now I would like to add string catalog for localization where strings would automatically detected from the project. Questions: Should I add a separate strings catalog for app target and widget target? What about the code shared between the 2 targets, do I have to do the translations twice for strings corresponding to files belonging to both app and widget target? What is the best approach for my project?

Wi-Fi connectivity issues on iPhone 17 Pro running iOS 27 Developer Beta. The device randomly disconnects from Wi-Fi, while all other devices on the same Wi-Fi 6 network remain connected normally. The network uses fiber-optic internet. The issue appears to be isolated to the iPhone 17 Pro and may be related to the current iOS 27 Developer Beta.

Hi all, We're seeing an issue where Live Activity content-state push updates sent via PushType.channel(_:) are not consistently delivered to all devices subscribed to the same channel — even though Activity.request() succeeds on every device, and the affected/unaffected devices are both on recent iOS versions well above the 18.1 minimum for channel-based push. Setup: Our backend broadcasts content-state updates to all devices subscribed to a given channel. Activity creation succeeds normally on the affected device, but it never receives a single subsequent update — the activity eventually goes .stale after its staleDate elapses, despite our backend confirming it sent an update to that channel. What we've verified so far: Activity.request() succeeds locally on the affected device, no error thrown. We instrument ContentState's Decodable init(from decoder:) to log every time ActivityKit attempts to decode an incoming push. On the affected device, this log never fires — so no push payload is ever being handed to ActivityKit at all on that device. It's not a decode/payload-format issue. A second device on the identical app build and channel setup receives updates normally in the same window — rules out a backend-wide outage. Both devices are on recent iOS (affected: iPhone 13 Pro Max, iOS 26.5.2 / unaffected: iPhone 15 Pro Max, iOS 26.6) — rules out OS version threshold. No logs, crash reports, or console output of any kind on the affected device around when the update should have arrived — completely silent failure. Question: Has anyone run into a device silently failing to receive PushType.channel broadcast updates like this? Are there known conditions (notification permissions, Low Power Mode, Background App Refresh, channel subscription expiry/limits, etc.) that could cause this? Is there any client-side API to check the health/status of a device's channel subscription, to distinguish "not subscribed," "subscription expired," and "subscribed but delivery failed"? Any pointers appreciated — happy to share more details if useful.

Hello Apple Team, We are seeking assistance regarding our app 健康行動go (App ID: 1437488996, Case ID: 20000146721382). Timeline: August 14: We received feedback regarding Guideline 4.3(a). August 21: We resolved the issues by providing detailed business differentiation, UI comparison documentation, and submitting an updated build. Status: The submission has remained in "Waiting for Review" since August 21. Today, August 27, 2026, is our scheduled public release date with external commitments. Could an Apple representative please check if our submission is held in a specialized queue and assist in escalating it to the App Review team for review? Thank you very much for your time and support.

Hello, Our app has been in "Waiting for Review" since August 23, 2026, with no status change and no messages in App Store Connect. App Name: Voxen AI Apple ID: 6790147633 Version: 1.0.0 (165) Submission ID: c827b3a4-5237-4b52-8225-d94be2b94016 Date Submitted: Aug 23, 2026 at 12:08 AM Could someone from App Review check whether this submission is stuck in the queue, or let us know if any action is needed on our side? Thank you.

I’m trying to determine the supported submission path for the first non-consumable IAP in a watchOS-only app. Configuration The app uses a standard watch-only container: Container: com.seanfu.safe Watch app: com.seanfu.safe.watchkitapp ITSWatchOnlyContainer = true WKWatchOnly = true WKApplication = true It offers one non-consumable “Full Version” unlock and uses StoreKit 2: Product.products(for:) Product.purchase(options:) Transaction.currentEntitlements Transaction.updates The product ID in the Release binary exactly matches App Store Connect. Paid Apps agreements, banking, tax, pricing, and territory availability are active. The Release archive contains no local .storekit configuration or test bundle. TestFlight works, but App Review receives no product In TestFlight, using the real App Store sandbox and App Store Connect product configuration, Product.products(for:) returns the correct product, localized price, and title. The purchase sheet can be presented. During App Review, the same request repeatedly returns an empty array without throwing an error. The reviewer sees this application-defined diagnostic: IAP-L-01(empty x5) This is not an Apple or StoreKit error code. It means: Five separate Product.products(for:) calls completed without throwing. Every call returned an empty product array. The diagnostic appears only after the initial request and limited retries are exhausted. Thrown StoreKit errors use different diagnostics. The app does not locally filter a successfully returned product. Therefore, the screenshot means StoreKit returned no matching product in five consecutive requests. This has happened in multiple review attempts, while the same Release code path works in TestFlight. An App Review representative contacted us and explicitly stated that a watchOS-only app can be reviewed and tested with IAP. They suggested investigating our StoreKit integration, but our audit found no code path that could transform a non-empty response into this diagnostic. Submission behavior changed Earlier watchOS-only builds could be submitted with both: The app version The “Full Version” IAP Those submissions reached App Review, where the product was empty: Submission accepted → Review starts → Product array is empty For build 23, we explicitly added the In-App Purchase capability to the Watch target in Xcode. The project now records the IAP capability and explicitly links StoreKit.framework. This did not add an IAP entitlement to the signed app. The bundle IDs, watch-only packaging, product ID, StoreKit code, pricing, availability, agreements, banking, and tax status remained unchanged. After uploading build 23, App Store Connect no longer allows the app version and IAP to be submitted together. The draft contains: iOS App 1.0, build 23 The “Full Version” non-consumable IAP App Store Connect blocks the submission and says IAPs and subscriptions are not supported on Apple Watch and must be removed from the submission. The behavior is now: App version + IAP selected → Submission blocked before review This timing does not prove that adding the Xcode capability caused the change. App Store Connect may have changed its validation, or the new build may have caused its watch-only classification to be reevaluated. However, the transition is notable: earlier submissions were accepted but the product was unavailable during review; the current submission is blocked entirely. Contradictory documentation StoreKit documentation says the Swift IAP API is available on watchOS 8+: https://developer.apple.com/documentation/storekit/choosing-a-storekit-api-for-in-app-purchases The documentation for purchase(options:) specifically says to use it for apps running on watchOS: https://developer.apple.com/documentation/storekit/product/purchase(options:) However, App Store Connect documentation says IAPs are not supported on Apple Watch and must be removed before submitting an Apple Watch app version: https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase/ The same page says the first non-consumable IAP must be submitted with a new app version. This creates a circular requirement: The first non-consumable IAP must accompany an app version. An Apple Watch app version cannot include an IAP. A watchOS-only app therefore appears unable to submit its first IAP. Questions What is the supported path for submitting the first non-consumable IAP of a watchOS-only app? Can Apple review the first IAP separately, or apply a backend override, despite the requirement to include it with an app version? Is an iPhone companion app required, with watchOS IAP support intended only for Watch apps associated with a regular iOS app? Could the unsupported submission association explain why TestFlight sandbox returns the product while App Review receives an empty array? Why were earlier watchOS-only submissions accepted with the IAP attached, while build 23 is blocked despite unchanged bundle IDs and watch-only packaging? Does App Store Connect use the Xcode IAP capability or explicit StoreKit linkage when validating the submission? Clarification from a StoreKit or App Store Connect engineer would be greatly appreciated. The StoreKit documentation, App Store Connect validation, and guidance from App Review currently describe different behaviors.