Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello developers! Thank you for your dedication to creating apps with great performance. We’re excited to kick off another year of partnering with you on improving power and performance in your apps. At WWDC26, check out the following new things in the latest platform SDKs and Xcode 27 beta for performance. You can also join us online for a Power and Performance Group Lab on Tuesday, June 9 at 11 AM Pacific. Meet State Reporting and the new MetricKit State reporting: The new StateReporting framework lets your application express its state to downstream tools like Instruments and MetricKit. Make your telemetry and traces much more useful by adopting this simple API. MetricKit: In the 27 releases, the Swift-first MetricManager API replaces the MXMetricManager API. Combined with State Reporting, the new MetricKit provides more granular metrics to isolate performance problems faster. It also provides a more expressive API that is great to use in Swift, with improved Swift concurrency and Codable support. With this year’s releases, the MXMetricManager API is considered legacy. ▶️ To learn more, watch Meet the new MetricKit. Discover new features in Xcode organizer Metric goals: Xcode organizer now provides a goal metric for Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage metrics, allowing you to prioritize performance engineering across more areas. Generate recommendations: Quickly resolve the highest impact performance issues in your app by using Generate Recommendations for Crash, Energy, Disk Write, Hang and Launch diagnostics. Insights overview: The new insights overview in Xcode organizer summarizes high-impact performance regressions for metrics and diagnostic reports, helping you plan and prioritize performance engineering work. Storage metrics: Storage metrics are now available in Xcode organizer, allowing you to monitor your app's Documents & Data and App Size across releases and catch regressions in cache usage and bundle size. Hitches metric: The new Hitches metric replaces the Scrolling metric in the organizer and now displays hitches for all animations in your app, giving you a comprehensive view of animation performance. ▶️ To learn more about other advancements in Xcode, watch What’s new in Xcode 27. Improve app responsiveness with Instruments Foundation Models: The Foundation Models instrument is redesigned with a tree view that lets you drill into individual requests, inspecting tool call arguments and results, inference prompts and responses, and token statistics. Use it to understand caching behavior, measure latency, and optimize throughput. System Trace: System calls, VM faults, and thread states are now unified into a single plot, with a new blending algorithm that stays readable even at high density. Once you spot something worth investigating, left/right key navigation lets you follow a thread's activity step by step, and the inspector provides quick actions like pinning the thread that made another thread runnable. System Trace now also draws thread priority and QoS over time, making it easier to identify priority inversions and unexpected QoS degradations that affect responsiveness. Swift Concurrency: New Main Actor and Global Concurrent Executor tracks let you visualize running tasks and executor queue depth over time, making it easier to spot task scheduling delays and actor contention. Tasks are now grouped into collections for faster navigation. Swift Tasks, Actors, and Executors instruments can now surface Call Trees, Flame Graphs, and Top Functions scoped to each entity — so you can pinpoint exactly where concurrency overhead lives. Top Functions: Helper functions and runtime internals can be expensive but hard to spot in a standard call tree. The new aggregation mode in Top Functions surfaces any function's total execution time across the entire call stack, making it easy to identify and prioritize hidden hotspots. Run Comparison: Compare call tree data across builds to identify regressions and performance wins. Results can be explored as an outline, flame graph, or top functions — choose whichever view best fits your workflow. ▶️ To learn more about profiling your app with Instruments, watch “Profile, fix, and verify: Improve app responsiveness with Instruments” ▶️ To learn about Foundation Models optimization, watch “Debug and profile agentic app experiences with Instruments”. If you have any questions about using State Reporting or the new MetricKit, create a post on the forums. For help creating a post, see Tips on writing a forum posts.

After upgrading to iOS 27 Beta 3, iBeacon region monitoring no longer behaves as it did on previous iOS versions. Issue 1 – Never exits region After connecting to an iBeacon, I power off the beacon and move several kilometers away. The app never receives an Outside (didExitRegion) event. Even after force quitting the app, powering off the beacon, locking the screen, and turning the screen back on, iOS may relaunch the app as if it were still inside the beacon region. Is this an intentional change in iOS 27 or a bug? Issue 2 – Sometimes never enters region Occasionally, the app is not awakened when entering the iBeacon region. No Inside event is delivered. The only way to recover is to manually scan and reconnect to the beacon. Otherwise, the app is never awakened by the iBeacon again. This worked reliably on iOS versions before iOS 27.

Summary: In Sandbox, Product.products(for:) returns all 3 of my IAPs with correct JPY prices and Japanese localizations, but product.purchase() fails immediately — the payment sheet is never presented — with ASDServerErrorDomain Code=3504 (Product.PurchaseError.productUnavailable). All 3 products fail identically. Reproduction captured in the sysdiagnose attached to FB24067333: 2026-07-30 18:43:58 JST — in-app purchase() on app.negaiboshi.placement; 18:44:40 JST — OS-level test (Settings > Developer > Sandbox Apple Account > Manage > Start Transaction), same product ID. Server correlation keys from the device log: inAppBuy → AMSServerCorrelationKey HNB5UGLE72AXSMY5KY7G4NAXQY (failureType 3504); Start Transaction → FQN4Y4JOEHYBW2GIR7KPTYTB2A (AMSServerErrorCode 3766, "provided product ID or bundle ID is invalid"). Environment App: Negaiboshi — Apple ID 6794682125, Bundle ID app.negaiboshi, Team 778QPP83C4 App status: first submission in preparation (never reviewed); build 1.0 (1) on TestFlight IAPs (all "Ready to Submit" since 2026-07-27 JST, attached to the 1.0 submission): app.negaiboshi.pro.monthly (auto-renewable, ¥480, group 22264517), app.negaiboshi.placement (non-consumable, ¥720), app.negaiboshi.nightsky (non-consumable, ¥1,200) IAP base country: Japan (JPY); availability 145/175 countries Device: iPhone, iOS 26.5.2; development build from Xcode; StoreKit Configuration = None Sandbox Apple Account: (address in FB24067333), region Japan, no purchase history; signed in under Settings > Developer Storefront.current = JPN. No Screen Time restrictions. Actual error (verbatim): Error Domain=ASDServerErrorDomain Code=3504 "このアイテムは見つかりませんでした。" UserInfo={AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=JPN} TN3186 checklist fully verified, none apply (Paid Apps Agreement, banking, tax all active; bundle ID + IAP capability; signing; membership). Also tried: Sandbox sign-out/sign-in, device restart — no change. Consistent across all 3 products and relaunches. Reproduced with zero app code involved (decisive): Settings > Developer > Start Transaction with product ID app.negaiboshi.placement and bundle ID app.negaiboshi fails: "The provided product ID or bundle ID is invalid. [Environment: Sandbox]" — Apple's own OS-level tool, no third-party code. Calibration: a deliberately nonexistent ID (app.negaiboshi.zzz) yields the identical error — the backend treats my real product like a nonexistent one. A price change (¥720→¥700, "now", 2026-07-29) propagated to the sandbox metadata catalog within minutes (products(for:) returned "¥700") — purchase() still 3504. Reverted. A full base-country change (2026-07-30): Japan (¥720) → United States ($4.99) at 15:52 JST — this deletes and recreates the price schedule and is the exact operation that resolved the identical symptom in thread 839557. It propagated to the metadata catalog (auto-converted ¥800 shown in ~20 min), yet purchase() and Start Transaction still failed at 16:10 and 16:55 JST. Reverted to ¥720 at 16:59 JST. Every lever that rewrites the price schedule reaches the metadata catalog but never the commerce/purchase catalog. Timeline: the products reached Ready to Submit hours after the 2026-07-26 15:22–17:58 PDT In-App Purchases outage (Message ID 1000005803), and the failure still reproduces after the 2026-07-29 16:20–19:30 PDT emergency maintenance on In-App Purchases + Advanced Commerce API (messageId 1000005805). Peer reports with the same metadata-vs-commerce-catalog split in the same window: threads 839220, 839441, 839437, 839645, 839557. Questions: Why does purchase() fail server-side with 3504 ("item not found") while products(for:) succeeds for the same IDs in the same JPN storefront? Can someone check the sandbox commerce-catalog state of the 3 product IDs above (Apple ID 6794682125)? This looks like a server-side provisioning failure that no developer-side action can repair. Is any additional App Store Connect state required before sandbox purchases can complete for a never-yet-reviewed app?

I sent it for testing from the Choicely app. I have entered the downloaded key, opened it in Notepad, and pasted the long key; my team and distributor are right. But it seems like Apple always mentions build 1.0.2 (7) when I am actually sending (8). It'll say failed, then suddenly say ready to submit for review. So I will, and I'm waiting for review... then I get a red failed sometime later saying either certificates are not included ( I don't get all that... I'm using Windows, so I can't make them like they say I need to, and sometimes it says invalid binary...although if I look at app info and details... it says binary validated. It will make it to just before TestFlight sometimes, and sometimes it passes TestFlight... also it will say app synced successfully but failed to collect metadata. So many oddities... I don't know what to do!!

Is macOS 27 Public Beta 2 able to activate new non‑MDM CMIO system extensions that fail on macOS 26.5.2? I'm building a virtual-camera app with a CMIO camera system extension (Developer ID signed + notarized), for personal use on my own Macs — no MDM. On macOS 26.5.2 (25F80) I can't get a new activation to succeed, and I'm trying to find out whether macOS 27 resolves it. Two failure modes I've seen: With SIP enabled, OSSystemExtensionRequest reaches the daemon, then sysextd logs: "no policy, cannot allow apps outside /Applications" — even though the app is in /Applications (verified real path, single copy, running from there). This matches other reports (e.g. LuLu / network extensions). With SIP disabled + systemextensionsctl developer on, it now fails earlier, client-side, with OSSystemExtensionErrorDomain code 4 — "Extension not found in App bundle / Unable to find any matched extension with identifier" — the request never even reaches sysextd. Things I've already verified/ruled out: Product type com.apple.product-type.system-extension; extension embedded at Contents/Library/SystemExtensions/; matching CFBundleIdentifier and Team ID; CMIOExtensionMachServiceName = $(TeamIdentifierPrefix)$(bundle id). App has com.apple.developer.system-extension.install (with authorizing profile); shared App Group + camera entitlement on both app and extension. Valid codesign --deep --strict; notarized + stapled; single LaunchServices registration; running the correct bundle. Reproduces with both Developer ID and Apple Development signing, and running straight from Xcode with a signed-in account. So the app/extension appear structurally correct; this looks like an OS-side regression in 26.5.x. My question: Has anyone successfully activated a new Developer ID (non-MDM) CMIO / system extension on macOS 27 Golden Gate Public Beta 2? Is this sysextd / code‑4 activation regression fixed there, or is it still present? Trying to decide whether upgrading is worth it. Thank you!

The entitlement documentation page for com.apple.developer.driverkit.family.hid.virtual.device says "To request this entitlement, fill out the request form." I can't find any way to actually request it. In Certificates, Identifiers & Profiles there is no row for that key anywhere — not on an App ID's Capabilities tab, and not under Capability Requests. Capability Requests does list these, with the entitlement key shown in each info tooltip: DriverKit Transport HID — com.apple.developer.driverkit.transport.hid DriverKit Family HID Device — com.apple.developer.driverkit.family.hid.device DriverKit HID EventService — com.apple.developer.driverkit.family.hid.eventservice DriverKit UserClient Access — com.apple.developer.driverkit.userclient-access HID Virtual Device — com.apple.developer.hid.virtual.device So the only virtual-HID entry that exists in the portal is the CoreHID one. What I've built: a DriverKit dext that publishes a software-only HID game controller (no physical bus), so a macOS app can synthesise gamepad input for games that require a real controller. It builds against the DriverKit SDK and is signed. Its entitlements are com.apple.developer.driverkit, .transport.hid and .family.hid.virtual.device. The host-to-dext control channel is a vendor Feature report rather than a custom IOUserClient, so it needs no userclient-access. Questions: Is com.apple.developer.driverkit.family.hid.virtual.device still grantable? If a dext can no longer declare it for distribution, I would rather rebuild on CoreHID's HIDVirtualDevice now than keep building against a key I can't ship. If the DriverKit path is still supported for a virtual HID gamepad, what is the correct complete entitlement group? Karabiner-DriverKit-VirtualHIDDevice ships with com.apple.developer.driverkit + .transport.hid + .family.hid.device + .family.hid.eventservice + com.apple.developer.hid.virtual.device — i.e. a DriverKit dext holding the CoreHID virtual-device entitlement, and no .family.hid.virtual.device at all. Is that the supported shape? If .family.hid.virtual.device has been retired, should its documentation page be updated? Happy to file a Feedback if that's the right route. Not a status request: I do have a Virtual HID request queued and the portal shows it as Submitted, so I'm content to wait. I'd just rather find out now whether it's queued against the right key for what I've built.

Is anybody else having a probelm pairing an Apple Pencil. I insert it into my new 2gen iPad Pro 12.9 and it briefly shows the dialog to Pair and then shows it connected, but then disconnects, and then I get an Error that the Pencil took to long to pair. Then it doesn't work.Am I alone in having this issue.Thanks,Nick

We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?

Overview I would like to observe calendar changes using NotificationCenter.messages(of: for:) I want receive Sendable messages, not traditional Notification which is not Sendable Problem I can't seem to get the following code to compile import EventKit NotificationCenter.default.messages( of: EKEventStore.EventStoreChanged.Subject.self, for: .changed ) Reference https://developer.apple.com/documentation/foundation/notificationcenter/messageidentifier/changed-50yz5 Questions How can I use by using NotificationCenter.messages(of: for:) for Calendar changes?

Saving a CKShare together with its root record in a custom zone in the user's private database fails on every attempt. The client sees CKError .serverRejectedRequest / .invalidArguments. The CloudKit Console server log shows the failure is on the system record type _pcs_data, not on our own record type: { "database":"PRIVATE", "zone":"SharedStatusZone", "operationType":"RecordSave", "platform":"iPhone", "clientOS":"iOS;26.5.x", "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "requestId":"FDB0D10E-0B82-4C71-9262-90D9A2EA3787", "returnedRecordTypes":"_pcs_data" } In the same session, ZoneSave and RecordFetch SUCCEED. Only the RecordSave that carries the CKShare fails. Container: iCloud.com.nyeong.yakmeokping (Production) Device: iPhone, iOS 26.5.x What we do (simplified) let zone = CKRecordZone(zoneID: ownerZoneID) _ = try await db.modifyRecordZones(saving: [zone], deleting: []) // succeeds let record = CKRecord(recordType: "MedStatus", recordID: ownerRecordID) // plain String / Int64 / Date fields only let share = CKShare(rootRecord: record) share[CKShare.SystemFieldKey.title] = "..." as CKRecordValue share.publicPermission = .none _ = try await db.modifyRecords(saving: [record, share], deleting: [], savePolicy: .allKeys, atomically: true) // FAILS User-visible symptom: UICloudSharingController shows "Cannot add people / Unable to create a link for sharing", and a Messages collaboration attachment spins forever, because no share URL is ever minted. Already ruled out iCloud sign-in - accountStatus() == .available immediately before the call. iCloud Keychain - enabled on both the iPhone and a Mac on the same account. Advanced Data Protection - OFF. Leftover/broken share - also fails when no record exists yet (brand new). UICloudSharingController - reproduced with a code path that never presents the controller and only performs the CloudKit save. Schema - the record type and every field we write are deployed to Production. Entitlements - com.apple.developer.icloud-services: (CloudKit), icloud-container-environment: Production, CKSharingSupported = true in Info.plist. Zone is a custom zone, not the default zone. Record and share are saved together, atomically, as documented. Possibly related Two recent threads report CKErrorServerRejectedRequest limited to the PRIVATE database in Production, starting around July 25: "iCloud Dashboard returns Internal Error when querying records across all containers" - the author reported on July 30 that the service had been down for a few days and had since recovered. "CloudKit CKQueryOperation returns CKErrorServerRejectedRequest" (FB24046201) - failures since July 25, error code 15, CKInternalErrorDomain Code=2000, HTTP 500. Those are read operations rather than a CKShare save, so they may be unrelated. Our failure still reproduces on July 31, after the other report says the incident was resolved. Note that developer System Status showed green throughout. Questions What does a BAD_REQUEST on _pcs_data during a CKShare save indicate? It appears to be the encryption key material for sharing rather than our own record. Is there an account-level or container-level condition that can block PCS key provisioning? Has anyone else seen CKShare creation (not query) failing in the same period? Any pointer would be appreciated - the client-side CKError carries no server error description, so the console log above is all we can see.

Hi all, I've been debugging a persistent sandbox StoreKit issue for a while now and have ruled out everything I can check from my end. Posting the full picture here in case anyone recognizes this pattern or has advice — genuinely stuck. The core problem AppTransaction.shared (StoreKit 2) consistently fails with: Error Domain=SKServerErrorDomain Code=-1 "(null)" UserInfo={storefront-country-code=AUS, client-environment-type=Sandbox} A real purchase attempt separately fails with: Error Domain=ASDServerErrorDomain Code=3504 "This item cannot be found." UserInfo={storefront-country-code=AUS, AMSServerErrorCode=3504, client-environment-type=Sandbox} What's confirmed working (so I can rule these out as the cause) Product catalog/pricing fetch — real price, title, currency load correctly every time canMakePayments → true getStorefront → AUS, correctly App Store Connect account: Paid Apps Agreement Active, Free Apps Agreement Active, bank account Active, all 3 tax forms Active (ABN/GST, Certificate of Foreign Status, W-8BEN) The IAP itself: correctly configured (com.subwizard.subwizard.unlock, Non-Consumable, "Ready for Review" status) App code: verified twice independently — product ID, type, and registration are all correct, no bugs found Xcode's local StoreKit Configuration file (fully simulated, no network): confirms my purchase/entitlement code works correctly end-to-end when StoreKit cooperates — so this isn't a code bug What's confirmed failing — identically, across every method I've tried Raw Xcode Debug build, installed directly to a real device TestFlight (Internal Testing) install A fresh Xcode Release-configuration run Same error, same domain, same code, every single time: AppTransaction.shared fetch, receipt refresh, Restore Purchases, and the actual purchase attempt (different code, 3504, but same underlying pattern). The pattern that stands out Everything that's a simple read of the public catalog (what does this app sell, what's the price) works. Everything requiring Apple's servers to process something tied to my specific account's transaction/commerce state (transaction history, an actual purchase) fails. My leading theory This is a brand-new Individual Apple Developer account. The Paid Apps Agreement only went Active 5 days before I started testing this. First-ever IAP product, first-ever real purchase attempt on the account. I'm wondering if this is a propagation/settling delay on Apple's commerce backend that the "Active" UI status doesn't fully reflect — I found a few other forum threads where Apple's own response to error 3504 specifically was to double check the Paid Apps Agreement/tax/banking, even in cases where it already showed as complete. What I've already ruled out App Store submission status — per Apple's TN3186 doc and other DTS-engineer forum replies I found, sandbox purchases shouldn't require app/IAP submission or approval at all A raw Xcode install lacking a "real acquisition record" that TestFlight would have — tested directly, TestFlight failed identically Sandbox tester account misconfiguration — sign-in works fine, tester accounts are valid and usable Where things stand right now Given everything above checked out clean, I went ahead and submitted the app + this IAP for App Review, partly just to see whether that changes anything, and partly because I need to actually ship at some point regardless. If it gets approved and the purchase works for the reviewer, that would at least tell me production is fine even if sandbox stays broken — I can live with that. But if it comes back rejected specifically because the purchase doesn't work, I'm genuinely out of ideas on what else to check from my side.

Does FSKit support the ability to get the process information, such as the pid, when a process accesses a resource? Being able have the process context is important for implementing certain access patterns and security logging in some contexts. For instance, we have a system that utilizes (pre-FSKit) a FUSE mount that, depending on the process has different "views" and "access" based on the process id.

I recently noticed a UX inconsistency while using the battery charge limit feature on my MacBook with a MagSafe charger. With the optimized charging feature, users can set a custom maximum charging limit (for example, 95%) to improve battery health. However, the MagSafe LED indicator continues to show the charging state (amber) even after the device reaches this user-defined limit. Previously, the LED would turn green when charging reached 100%, clearly indicating a “fully charged” state. But now, when charging stops at a user-defined limit, there is no clear visual feedback that charging has effectively completed based on the user’s preference. This creates confusion, as the LED suggests that charging is still ongoing even though the system has stopped charging at the configured limit. A possible approach to improve this could be to treat the user-defined limit as an effective “fully charged” state during charging. For example: if is_charging: if battery_percentage < user_defined_limit: LED = AMBER else: LED = GREEN This would align the physical LED indicator with the system’s charging behavior and improve clarity for users without requiring hardware changes. Has anyone else observed this behavior, or is there any existing workaround?

MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?

Summary Sandbox purchases of our first auto-renewable subscription fail with "This item cannot be found". Product metadata loads correctly, so this looks specific to commerce. Our App Store Connect configuration is complete and has been verified exhaustively, and four other apps on the same team sell in-app purchases in production without issue. The affected app has never been submitted or released, and the subscription sits in "Ready to Submit". Symptoms On device (TestFlight build, purchasing with the tester's real Apple Account - no sandbox Apple Account is configured, per the documented TestFlight flow), a purchase attempt returns storeProductNotAvailable and the system alert "Item Unavailable". Device logs (idevicesyslog) show: mzstorekit-sb.itunes.apple.com/inApps/v2/history -> HTTP 404, (4040004) App not found sandbox.itunes.apple.com/.../inAppBuy -> AMSErrorDomain 305, AMSServerErrorCode=3504, "This item cannot be found" Product.products(for:) returns the product and the paywall renders product.displayPrice, so product metadata resolves. Only the purchase fails. Server-side observation Using the App Store Server API in the sandbox environment with our team key, requesting a deliberately non-existent transaction ID: GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/history/1234567890 App Products Released? Result The affected app 1 subscription, Ready to Submit never HTTP 401, empty body Another app, same team non-consumable, Approved yes 404 4040010 Transaction id not found Another app, same team 2 non-consumables, Approved yes 404 4040010 Transaction id not found Another app, same team 2 non-consumables, Approved yes 404 4040010 Transaction id not found Another app, same team non-consumable, Approved yes 404 4040010 Transaction id not found Same key, same issuer, same team, same request shape - only the bid claim differs. We note openly that this is not a clean experiment: all four comparison apps differ from the affected app in two ways at once (they are released, and they have approved products), so the 401 may simply reflect an app with no approved commerce products rather than a missing app record. We include it because the difference is stark and reproducible, not because we think it is conclusive. What makes this app different Being unreleased does not by itself appear to be the barrier: we were able to test the in-app purchases of the four apps above in the sandbox before those apps were released. The difference we cannot account for is product type and approval state - those were one-time non-consumables, whereas this is our first auto-renewable subscription, which App Store Connect tells us "must be submitted with a new app version" and which has therefore never been approved. Timeline 2026-07-30 ~00:30 CEST - Pricing and Availability set for the app (it had been unset; that was the cause of an earlier, separate failure). 2026-07-30 09:26 CEST - captured the device logs above. 2026-07-31 00:50 CEST - toggled a territory's availability off and back on to force a re-propagation of the availability record. No change. 2026-07-31 - still failing 24+ hours on. Automated probes every 30 minutes throughout have returned the same result without exception. This is well beyond the "up to 1 hour" propagation window documented in TN3186. Already verified Account level - four other apps on this same team currently sell in-app purchases in production: Paid Apps agreement: Active Banking and tax information: complete and active App Store Connect configuration for the affected app: App availability: 175 of 175 territories, none excluded Subscription availability: 175 of 175 territories Subscription priced in all 175 territories Four localizations and the review screenshot present; group localized; subscription state Ready to Submit App price: Free Every territory reads CANNOT_SELL / AVAILABLE_FOR_SALE_UNRELEASED_APP, consistent with an app that has not yet been released Client / build: Product ID in code matches App Store Connect exactly Explicit App ID (no wildcard), In-App Purchase capability enabled Build signed with Apple Distribution, delivered via Transporter, tested from TestFlight (not a development build) No StoreKit configuration file active in the scheme Bundle ID matches the App Store Connect record Questions Is the subscription provisioned for commerce in the sandbox environment? The (4040004) App not found response suggests the app or its commerce record is not present there. TN3186 states that sandbox testing does not require submitting in-app purchases for review. Does that hold for an app's first auto-renewable subscription, given that such a subscription must be submitted alongside an app version and so cannot reach an approved state beforehand? If submitting the app version together with the subscription is in fact the prerequisite, please confirm - we are currently holding our submission specifically so we can complete one successful sandbox purchase first, since App Review purchases through this same environment. If that ordering is not possible, we would rather submit and have App Review encounter the working production path than keep waiting on a sandbox purchase that cannot succeed. Happy to provide the app's Apple ID and product identifier privately if that helps.

I set up my developer account set up a few years ago using a business entity that is not longer active. I have a new business entity that I want to build for. I tried to change the my membership details but couldn't access the screen because my membership lapsed. I renewed my membership and now can't see a way to change the entity. I have all the numbers and documents ready. Is there a way to change the business entity on a developer account?

Across two completely separate App IDs under the same Apple Developer Team, calling registerForRemoteNotifications() (via a standard push-notification plugin wrapping this exact API) resolves successfully — but afterward neither application(:didRegisterForRemoteNotificationsWithDeviceToken:) nor application(:didFailToRegisterForRemoteNotificationsWithError:) is ever called. No token, no error. Registration just stalls permanently. Environment Xcode 26.4.1 Distribution: TestFlight (App Store distribution profile → production APNs environment) iOS on all test devices: current release The key finding This isn't specific to one app. I reproduced the identical failure on: Our primary app's App ID, which has existed for a while and had Push Notifications enabled after initial creation. A brand-new, throwaway App ID created from scratch specifically to test this, with Push Notifications capability checked at creation time (no toggling after the fact, no history at all). Both show the exact same symptom: register() resolves, then silence — no callback of either kind, ever. Since this reproduces identically on an App ID with zero prior history, it rules out anything specific to one app's configuration or App Store Connect record, and points at something at the Team level with APNs backend authorization. What I've ruled out Entitlements/provisioning are correct and matching, verified via direct inspection of the signed binary: codesign -d --entitlements :- MyApp.app and the provisioning profile's own entitlements: security cms -D -i MyApp.app/embedded.mobileprovision | plutil -extract Entitlements xml1 -o - - Both show identical, correct values — aps-environment: production, correct application-identifier, correct team-identifier. Reproduced identically across: 2 separate App IDs (one long-standing, one brand new) 2 different physical iPhones 2 different WiFi networks 2 different accounts/user sessions within the app Already tried with no change in behavior: Enabling Push Notifications after initial App ID creation, vs. checking it at creation time on the fresh App ID Toggling the capability off/on and regenerating the provisioning profile Generating multiple fresh App Store distribution profiles Confirmed the Distribution certificate referenced is correct and valid Client code confirmed correct via instrumented logging at every step (permission check → permission request → listener attachment → register() call). Every step up to and including register() resolving completes exactly as expected. The stall is strictly after that point, entirely on the OS/APNs side. What I'm trying to determine Given this reproduces on a completely fresh App ID with no history, I believe this points at something about how APNs backend authorization is provisioned for this Developer Team as a whole, rather than any individual App ID's configuration. Has anyone seen this exact symptom — registration call succeeding but zero callback of either kind — and found a resolution that wasn't visible from anything in the Developer Portal or Xcode? Filed as Apple Developer Support case 20000117948923 — happy to share any additional diagnostics.

Hello, We are using the UPI device validation APIs on iOS 26+ in a production banking/UPI app, and we are seeing a recurring failure from CoreTelephony that we need guidance on. API / entitlement Framework: CoreTelephony API: CTCellularPlanStatus.checkValidity(ofToken:) Related: CTCellularPlanStatus.token() Entitlement: com.apple.developer.upi-device-validation Availability: iOS 26.0+ Minimal call site do { let isValid = try await CTCellularPlanStatus.checkValidity(ofToken: token) // isValid == true/false -> expected outcomes } catch { // Unexpected: API throws instead of returning Bool print(error.localizedDescription) } Error error.localizedDescription is: English: Couldn't communicate with a helper application. Same failure also appears with a localized Hindi message on Hindi-locale devices. This is distinct from checkValidity(ofToken:) returning false (token/SIM mismatch). Here the API throws, so we cannot tell whether the token is valid. In production we currently only have this localizedDescription from telemetry. Production observations (large fleet, last few days) Observed only on production user devices so far; we have not reproduced it reliably on lab hardware. Occurs across multiple iOS 26.x builds (notably 26.5.2, 26.5, 26.6; also seen on 26.0-27.0). Not limited to a single patch. Seen on many iPhone models (not one SKU). Latency is bimodal for the same error string: large share fails in under 100 ms (immediate) another large share fails after about 2-10+ seconds (timeout-like) Observed under Wi-Fi, cellular (4G/5G), and No Connection / radio-not-ready conditions. Same device can emit many identical failures within about 1 second when validity is checked from multiple call sites concurrently. Token generation (CTCellularPlanStatus.token()) and successful checkValidity work for the vast majority of users; this throw is a smaller but material failure class. Questions for Apple Is "Couldn't communicate with a helper application." an expected / documented failure mode of checkValidity(ofToken:) (for example CommCenter/XPC unavailable, radio not ready)? What conditions typically trigger this error from checkValidity(ofToken:)? Recommended client handling: retry (with backoff)? treat as transient and skip forcing re-binding? surface to user? Does validation require cellular registration / SIM ready state even when docs indicate internet is not required? Any known issues on specific iOS 26.x builds, dual-SIM, eSIM, or airplane-mode transitions? Is concurrent checkValidity from multiple tasks unsupported / unsafe? Because this is currently production-only and not reliably reproducible on lab devices, we cannot attach a sysdiagnose or Instruments trace at this time. We can share aggregated production telemetry and API details via Feedback Assistant if helpful. Thank you.

Hello, I'm writing regarding the rejection of my app CCB Eventos (iOS App 2.3.3, build 32), Submission ID 380b6818-faed-4a2f-815f-e38bc4d8905b, under Guideline 5.1.1(v) - Legal - Privacy - Data Collection and Storage. The issue flagged was that the app requires users to provide their date of birth, which was considered not directly relevant to the app's core functionality. We collect this field for demographic statistics and to organize future age-specific church events (children's, youth, and adult programming). We understand the date of birth should not be a required field, and we commit to making it optional in our next update. However, this current build contains critical fixes for iOS-specific issues affecting our users, and we urgently need this version approved and published as soon as possible. I'd also like to note that this submission has been under review for more than 3 days, and each review cycle keeps returning with the same issue without resolution. This delay is significantly impacting our users, since the fixes in this build address problems specific to iOS devices. We kindly ask for your understanding and collaboration to release this update now, with the optional field change guaranteed in the following release. Thank you for your support. Best regards, Gabriel Ruiz CCB Eventos

We're currently having an issue with our app where the review prompt is displaying for the user too often. I know the documentation says that: If the person hasn’t rated or reviewed your app on this device, StoreKit displays the ratings and review request a maximum of three times within a 365-day period. If the person has rated or reviewed your app on this device, StoreKit displays the ratings and review request if the app version is new, and if more than 365 days have passed since the person’s previous review. From this post I can see that there's an updated API that is recommended AppStore.requestReview(in:). Is there a currently known bug with the SKStoreReviewController version that would cause the review prompt to display outside of the limitations? Locally we're seeing a limit of 3 prompts in the same session but a few days later, we get the same 3 prompt limit when it's should have been limited for another year. Does using the AppStore version just fix our issue? Is it actually a different API?

Filed as FB24069273. Sandbox POST /inApps/v1/notifications/test consistently returns 404 {"errorCode":4040007} for our app (Apple ID 6765662617), although GET /v1/apps via the App Store Connect API confirms both subscriptionStatusUrl and subscriptionStatusUrlForSandbox are set (V2). With the same JWT, sandbox POST /inApps/v1/notifications/history returns 200 with an empty history — so the key and app resolve correctly. No organic sandbox notifications have ever been delivered, despite active TestFlight sandbox subscription activity. Exhausted remediations (4040007 persists after each, with 30-60+ minute waits): Re-saving the URLs in the App Store Connect UI (two locales) Deleting and re-adding the Sandbox URL PATCH /v1/apps setting the sandbox URL + version V2 twice, with two different valid endpoints (verified by GET each time) Removing the Sandbox URL entirely to rely on the documented Production fallback Deleting BOTH URLs, waiting a full hour, and re-creating them from scratch Testing with both an App Store Connect team key and a freshly generated In-App Purchase key — identical results Endpoints are publicly reachable (HTTPS, TLS 1.2+, port 443). Production App Store Server API returns 401, which we understand is expected for an app not yet released. This looks like a desync between App Store Connect metadata and the notification delivery registry consulted by the test-notification endpoint. Any help would be appreciated.