FB: https://feedbackassistant.apple.com/feedback/22556883 We're seeing a small number of production users where both Transaction.currentEntitlements and Transaction.all return zero transactions for a valid, active, non-refunded non-consumable IAP. This makes it impossible to restore the purchase via any StoreKit 2 API. Environment: Xcode 26.4 (Build 17E192) iOS 26.4.1 Direct call to SK2 Transactions.all & Flutter in_app_purchase package v3.2.3 (uses SK2 on iOS 15+) Non-consumable IAP (one-time purchase) What we observe: AppStore.sync() triggers but the purchase stream returns 0 transactions Transaction.all returns empty Transaction.currentEntitlements also returns empty User is confirmed on the correct Apple ID Issue reproduces on both iPhone and Mac for the same Apple ID Issue appears to have started recently for users who previously had no problems Debug log from affected production user: [2026-04-20T08:50:10.744115Z] init: iapAvailable=true [2026-04-20T08:50:10.744566Z] init: isPremium=false [2026-04-20T08:50:10.744567Z] init: triggering silent restorePurchases [2026-04-20T08:50:45.974566Z] restore: started [2026-04-20T08:50:45.986848Z] restore: sk2Transactions count=0 [2026-04-20T08:50:45.993004Z] restore: sk2Direct isVerified=false active=null [2026-04-20T08:50:45.993011Z] restore: sk2Direct inconclusive — falling back to standard restore [2026-04-20T08:51:16.000851Z] restore: timed out after 30s — fallback isPremium=false [2026-04-20T08:51:16.000910Z] restore: completed — succeeded=false foundPurchase=false Unable to reproduce in sandbox — Transaction.all works correctly there. Appears specific to production for a small subset of users. Has anyone else seen this?

When using AccessorySetupKit to remove accessories, a pop-up window appears when calling removeAccessory. However, the text in the pop-up window does not change according to my iPhone's language settings and remains only in English. Has anyone encountered this issue? Does Apple have any plans to address this compatibility issue?

Hello, everyone, I've started a thread and got a recommendation from DTS Engineer to move the conversation here. The sample code for https://developer.apple.com/documentation/coredata/sharing-core-data-objects-between-icloud-users is with Swift 5. I have a Swift 6 project and I'm running into issue porting the sample code. I've found that NSManagedObjectContext is sendable (https://fatbobman.com/en/posts/sendable-nsmanagedobjectcontext/). From it I can get the persistence controller, and from it I get the stores and this solves the Swift 6 migration path and looks good. i.e. not rely on the private and shared references to the persistence stores, I'll be getting them from the context. I've also notices that once I start to change the PersistenceController from lazy vars for lazy var previewContainer: NSPersistentCloudKitContainer and lazy var persistentContainer: NSPersistentCloudKitContainer to struct PersistenceController { static let shared = PersistenceController() @MainActor static let preview: PersistenceController = { let result = PersistenceController(inMemory: true) which is the default pattern for new CoreData applications (Xcode 26 / Xcode 27) I start getting preview crashes similar to https://developer.apple.com/forums/thread/654126. It turns out this is because of let persistenceController = PersistenceController.shared in the App. Quite unexpected. The persistence controller looks more suitable for actor based on the CloudKit sharing requirements. I saw such question on WWDC 26, however there was not enough time for an answer - is a good pattern to have the PersistenceController as an actor or in another way. Which is that most swiftly way for Swift 6?

Hi all, I'm building an iOS app extension using ExtensionKit that works exclusively with its containing host app, presenting UI via EXHostViewController. I'd like the extension to have read-only access to the host's task for process introspection purposes. I'm aware this would almost certainly require a special entitlement. I know get-task-allow and the debugger entitlement exist, but those aren't shippable to the App Store. I'm looking for something that could realistically be distributed to end users. My questions: Does an entitlement exist (or is one planned) that would grant an extension limited, read-only access to its host's task—given the extension is already tightly coupled to the host? If not, is this something Apple would consider adding? The use case is an extension that needs to inspect host process state without the ability to modify it. Is there a path to request such an entitlement through the provisioning profile process, or is this fundamentally off the table for App Store distribution? It seems like a reasonable trust boundary given the extension already lives inside the host's app bundle, but I understand the security implications. Any insight appreciated. Thanks!

I have seen this problem arise from multiple sources. I am trying to submit my app but a new app version must be bundled with the subscription. The guide consistently says (copy pasted from the "Submit an In-App Purchase" guide) _"On the right, scroll down to the In-App Purchases and Subscriptions section. Click Select In-App Purchases or Subscriptions, or if you’ve already started selecting In-App Purchases or subscriptions, click Edit."_ The problem is there IS NO In-App Purchases or subscription section in the the app section. I have submitted again but at this point I'm loosing hope. I am hoping that adding a StoreKit config file this time on the Xcode side will help however again reading "submission (1)" does not give much hope. Please help as this has delayed launch by quite a lot.

Pls apple i daily drive this and is a core part of the apple ecosystem i even bought my cousin a watch to solely talk to him whenever

This is a StoreKit / ExternalPurchaseCustomLink clarification. Apple DTS asked me to post the follow-up question here. We are designing an SDK for apps that support EU external purchase. In EU storefronts, the app will use ExternalPurchaseCustomLink only: No App Store In-App Purchase will be offered to users. No Product.purchase() will be called. No SKPaymentQueue.add(_:) will be called. The actual purchase will happen only on our external website through the ExternalPurchaseCustomLink flow. Question: In this EU ExternalPurchaseCustomLink-only setup, is it acceptable and supported to call Product.products(for:) / SKProductsRequest only to fetch product display metadata from App Store Connect? The metadata would only be used to display the product list UI, for example: product title / display name localized price currency / priceLocale formatting information The returned Product / SKProduct would not be used to start an App Store purchase. Or should apps avoid Product.products(for:) / SKProductsRequest entirely in EU storefronts where only ExternalPurchaseCustomLink is offered, and use their own product catalog instead?

Hello Apple Developer Support Team, We understand from the Declared Age Range documentation that, in some regulated regions, the system automatically provides the person’s age range and they can’t decline sharing it with the app. We have implemented the API as prescribed in the documentation. For certain users in Texas, the API returns: isEligibleForAgeFeatures == true declaredAgeRangeRequired == true However, in our testing we observe that these Texas users can still decline sharing their age range, either via the system prompt or later via Settings, which results in no age range being provided to the app. This behavior appears inconsistent with the documentation’s statement that, in regulated regions, the person “can’t decline” sharing their age range, and it also raises questions for us about how this aligns with the applicable legal requirements in Texas. Could you please clarify: Whether this behavior (Texas users being able to decline sharing their age range even when declaredAgeRangeRequired is true) is expected, and Under what exact conditions the “they can’t decline sharing” behavior is enforced for Texas accounts (for example, only for new Apple Accounts created in Texas after a certain date, or only for particular age categories)? Any guidance on how we should interpret isEligibleForAgeFeatures and declaredAgeRangeRequired in this scenario would be greatly appreciated. Thank you.

We are an Apple Pay consumer and observed elevated response times and intermittent timeouts affecting the create‑session API (apple-pay-gateway.apple.com/paymentservices/paymentSession) between approximately 8:01 PM and 8:35 PM PST today. We are reaching out to understand whether there were any service disruptions during this timeframe, as we do not see corresponding updates on the system status pages. We would like to confirm whether this behavior was related to a broader Apple Pay issue or specific to our integration.

Hello, I'm implementing an NSFileProviderReplicatedExtension (iOS 26 and macOS 26) and would like to validate my approach. What I do To make my uploads efficient I batch them: instead of uploading file-by-file inside each createItem / modifyItem, I ingest all local changes into my extension's local state quickly and upload the content blobs in the background in batches. Concretely, for both createItem and modifyItem: I persist the item to my local store, write its content blob to a local cache, and schedule the upload in my internal queue. I call the completionHandler right away before uploading the item, returning the NSFileProviderItem with isUploaded = false. Once the upload succeeds, I flip the item to isUploaded = true and call signalEnumerator(for: .workingSet) so the change is delivered through the working-set enumerateChanges. This works in my testing, but I'm unsure it is the intended approach, and I have the following questions. Question 1 — Honoring the Progress object I call the completion handler early (step 2) and run the upload afterwards. The convenient part for my batched uploads is that I don't seem to need to honor the returned Progress at all — I never report into it and I just drop it, yet in my testing the upload still completes. I'd like to confirm two things: (a) Can I ignore the Progress? I'd like to never report into the returned Progress and simply drop it: I coalesce uploads into batches drained from a persisted queue, so I can't map one Progress to one upload, and retaining thousands of them is itself a cost. Is that allowed? What makes me unsure is that the docs read a little asymmetrically — for createItem the progress is "presented in the user interface until the completion handler is called", whereas for modifyItem it is "expected to include the upload progress … even if the provider chose to call the completion handler before the upload finishes". (b) If I ignore it, am I still granted execution time to finish the upload? This is what worries me, because the "Execution time" clause couples the two: the system "will grant enough time … to upload the file" but "will interrupt the call if it stops making progress." If I report no progress, does the system stop granting runtime? Question 2 — Upload pipeline depth When calling the completion handler before finishing the upload, both createItem and modifyItem are no longer gated by the NSExtensionFileProviderUploadPipelineDepth limit, and I can have thousands of items pending upload. This is crucial for my approach. Is this behaviour correct and intended?

Our current business goal is to improve the success rate of iBeacon wake-up on iOS. Apple's official iBeacon specification recommends a standard broadcast interval of 100ms; Now we are planning to shorten the broadcast frequency to 50ms, and we would like to consult the full dimensional impact of this change, and whether it can really improve the success rate of beacon identification and pull trigger on iOS devices.

I activated the Paid Apps Agreement today along with banking and tax information. My app uses react-native-purchases (RevenueCat) with StoreKit 2. When tapping purchase buttons in TestFlight I still get "Product not available - Could not load this product." Products show "Waiting for Review" in App Store Connect. Sandbox tester is configured. Is there a delay after activating the Paid Apps Agreement before sandbox purchases work? How long should I expect to wait?

Environment: iOS 26.5, Message Filter app extension (IdentityLookup framework), offline filtering. Setup My Message Filter Extension performs offline string matching on the message body and returns one of: ILMessageFilterAction.allow / .junk / .transaction / .promotion In the Messages app the filtering UI shows these folders: Messages (the main/default folder), Transactions, Promotions, Junk. .allow is expected to surface a message in the main Messages folder. The documented behavior (API docs + WWDC22 "Explore SMS message filters") only describes a static mapping from action → folder. On iOS 26.5 I'm seeing what looks like a stateful, per-sender behavior that I cannot find documented anywhere, and I can't tell whether it is intended or a bug. Test methodology All messages in every sequence are sent from the same single phone number. Before each Case, I fully clear the receive history for that number, so every sequence starts from a clean slate with no prior state for that sender. The notation shows how many conversations/entries appear in each folder after each step. Case A — first message = allow allow → Messages: 1 promotion → Messages: 2 (allow + promotion), Promotions: 1 junk → everything collapses into Junk; Messages & Promotions become empty every subsequent message lands in Junk regardless of the action I return Case B — first message = allow, then transaction allow → Messages: 1 transaction → Messages: 2 (allow + transaction), Transactions: 1 junk → everything collapses into Junk; Messages & Transactions empty every subsequent message lands in Junk regardless of returned action Case C — first message = transaction transaction → Messages: 1, Transactions: 1 ← also appears in Messages allow → Messages: 2, Transactions: 1 promotion → Messages: 3, Transactions: 1, Promotions: 1 junk → Messages: 4, Transactions: 1, Promotions: 1, Junk: 1 (NOTE: here junk does NOT collapse the thread, and there is no "sticky junk") Case D — first message = promotion promotion → Promotions: 1 only (does NOT appear in Messages) allow → Messages: 2 (the earlier promotion now also appears in Messages), Promotions: 1 junk → everything collapses into Junk (sticky, same as Case A/B) every subsequent message lands in Junk regardless of returned action My core question: are the following two behaviors by design, or are they bugs? (1) "Sticky junk" after allow-first / promotion-first. In Cases A, B and D, once .junk is returned the whole sender thread collapses into Junk, and from then on every message is forced into Junk regardless of the action my extension returns. Is this expected/by-design, or a bug? If by design: is it permanent, and what resets it — does the extension have any control, or is it purely user-driven (e.g. the user moving the thread out of Junk)? What concerns me is that the system appears to ignore my returned action entirely once this state is entered. (2) .transaction-first behaving differently from .allow-first. A sender whose first message is .transaction (Case C) behaves differently: the message also appears in the main Messages folder, and a later .junk does not collapse the thread (no sticky junk). Is this .transaction-first behavior expected/by-design, or a bug? If by design, what is the underlying rule that makes .transaction-first confer this state while .allow-first does not? Since the history is cleared before each test, this is determined purely by the first action returned. Additional clarifying questions Is any of this per-sender state behavior documented beyond the static action → folder mapping in the API docs / WWDC22 "Explore SMS message filters"? If so, where? More generally, what determines whether a categorized (.transaction / .promotion) message is also mirrored into the main Messages folder? Thanks — I'd like my extension's return values to produce predictable categorization for users, and right now this first-message-dependent behavior makes that hard to reason about.

I’m developing a watchOS app that records outdoor soccer workouts using HealthKit. My app starts a workout session with: HKWorkoutConfiguration.activityType = .soccer HKWorkoutConfiguration.locationType = .outdoor HKWorkoutSession HKLiveWorkoutBuilder HKLiveWorkoutDataSource During the workout, I display distance from the live builder statistics: HKQuantityType.quantityType(forIdentifier: .distanceWalkingRunning) After the workout ends, I save the workout using finishWorkout(), and later read the saved distance from: HKWorkout.totalDistance?.doubleValue(for: .meter()) So the total distance shown in my app is not calculated manually from GPS route points. It comes from HealthKit’s workout distance. I noticed a difference between soccer workouts recorded by Apple’s built-in Workout app and soccer workouts recorded by my third-party watchOS app. Example comparison: Apple Workout app soccer: Active duration: about 88 min Steps: about 8,832 Distance: about 6.7 km No visible route/location data in Fitness My watchOS app soccer: Active duration: about 87 min Steps: about 8,998 Distance: about 5.6 km Includes route/location data Workout recorded through HKWorkoutSession + HKLiveWorkoutBuilder Distance read from HKWorkout.totalDistance The step counts and active durations are very close, but the distance differs by about 1.1 km. One important detail is that the Apple Workout app soccer workout does not appear to include visible route/location data in Fitness, while my third-party workout does include route/location data. Despite that, the Apple Workout app reports a longer distance. So the comparison is not simply “GPS route distance vs GPS route distance”. It looks like the built-in Workout app may be estimating soccer distance without exposing route data, while HKLiveWorkoutBuilder for a third-party .soccer workout may be producing a different totalDistance estimate. My questions are: When the built-in Apple Workout app records an outdoor soccer workout without exposing route data, how is totalDistance estimated? Is that distance estimation behavior available to third-party watchOS apps using HKWorkoutSession + HKLiveWorkoutBuilder with .soccer? If a third-party app records route data for the same soccer activity, can that change how HealthKit calculates totalDistance compared with a no-route built-in Workout app recording? For third-party soccer workouts, should developers expect HKWorkout.totalDistance to match the built-in Workout app, or is a difference expected? Is there any additional configuration, entitlement, data type, or best practice required to get more accurate distance estimates for soccer workouts? Any clarification on the expected behavior would be very helpful. Thanks!

We are using a Content Filter Network Extension to perform telemetry over the network activity of enterprise iOS devices. The filter itself is not blocking any connection. We encountered an issue where our Content Filter got stuck in a deadlock in the startFilter method of the NEFilterControlProvider. This resulted in a crash report where we see 64 threads stuck in the startFilter call. While the content filter was stuck in a deadlock, the device network connectivity was lost. We solved the deadlock issue coming from our logger, however, we would like to get a better understanding on the following points: What are the critical paths where a Content Filter can have a device wide impact on network connectivity? What is the behavior of the OS when the Content Filter is unresponsive (e.g. in startFilter, handle(Report), handleNewFlow)? Will it try to start the filter again? Force kill it ? We saw that startFilter was called multiple times in our crash reports whereas we expected it to be called only on vendor configuration changes. What is the lifecycle of the filter control provider and filter data provider ? When are the different methods like startFilter called ? We would like our Content Filter to never cause disruptions and implement a circuit breaker behavior in case any issue occurs. Do you have any recommendation on how to achieve this ?

Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!

We’re attempting to call the Apple Pay Web Merchant Registration API using our Platform Integrator flow and consistently receive 401 Unauthorized, despite successful TLS/mTLS. Details: Endpoint: https://apple-pay-gateway-cert.apple.com/paymentservices/registerMerchant (POST) Payload: { "domainNames": ["breakerfy.com"], "encryptTo": "platformintegrator.ai.packman", "partnerInternalMerchantIdentifier": "merchant.ai.packman.1", "partnerMerchantName": "breakerfy", "merchantUrl": "https://breakerfy.com" } Domain association: URL: https://breakerfy.com/.well-known/apple-developer-merchantid-domain-association What we tried: We created a Payment Platform Integrator ID (platformintegrator.ai.packman) We created a CertificateSigningRequest We used the certificate signing request to create an Apple Pay Platform Integrator Identity Certificate and downloaded the signed certificate. We exported the Private Key from keychain access in PKCS 12 format We converted both the private key and the signed certificate to PEM format We created a merchant id We used the converted keys to send requests to the API We received { "statusMessage": "Payment Services Exception Unauthorized", "statusCode": "401" } we also tried curl with the original p12 file and also had no luck. What could be the issue ?

I recently updated my iPhone SE (2020) to the iOS 27 beta, and initially the experience was excellent. The phone felt noticeably faster and more responsive, and I was genuinely impressed with the update. However, after about a day of usage, I started experiencing a charging-related issue. One night, I left my phone connected to the charger before going to sleep when the battery was at 55%. The next morning, I found that the battery had dropped to 42% instead of charging. I checked all connections and confirmed that the charger, cable, and power source were properly connected. When I disconnected and reconnected the charger, the charging lightning bolt icon would briefly appear, then turn grey after about two seconds, and finally disappear completely a couple of seconds later. The phone would not charge. Assuming it might be a faulty charger or cable, I tested with: A different Apple charger A different Lightning cable The same issue persisted. Next, I connected the phone to my Mac. Surprisingly, it started charging, and Finder recognized the device normally. Over the next few days, the behavior became inconsistent: Sometimes the phone would charge. Sometimes it would not charge at all. Connecting to the Mac worked most of the time, but occasionally even that failed. I also noticed another unusual behavior: If I unplugged the Lightning cable from the iPhone and plugged it back in, the charging symbol would briefly appear. However, if I left the cable connected to the iPhone and unplugged/replugged only the USB end from the power adapter, there would be no response whatsoever—no charging sound, no charging icon, nothing. I cleaned the charging port, cable connectors, and charger contacts, but the issue remained. At that point, I realized the problem started immediately after installing the iOS 27 beta. To verify whether it was software-related, I restored the device back to iOS 26.5. After downgrading, the charging issue completely disappeared, and the phone began charging normally again with the same charger and cable. Based on my testing, this appears to be a software-related issue introduced in the iOS 27 beta rather than a hardware problem. I am posting this in case other iPhone SE (2020) users are experiencing similar charging behavior after updating to the beta. Device: iPhone SE (2020) Issue: Intermittent charging failure after updating to iOS 27 beta Status: Resolved after restoring to iOS 26.5

Hello, Public documentation for NFCPaymentTagReaderSession states that it is currently limited to European Union (EU). Could you please advise when will this restriction be lifted and NFCPaymentTagReaderSession be made available outside of the EU? Are there any other capabilites available to be able to read EMV card data via NFC on a financial services or card issuer's iOS mobile app? Thank you!

I have a new app (first version, not yet approved) with one auto-renewable subscription. Earlier in development, the subscription loaded and I could complete a sandbox purchase (the StoreKit sheet showed "Sandbox", the price, and my sandbox account). To resolve an App Store Connect submission deadlock, I deleted that subscription and created a new one with a new Product ID. Since then, the new subscription does NOT appear in the sandbox: StoreKit returns no products, so getOfferings (via RevenueCat) returns 0 packages — both during App Review and on my own development build signed into a sandbox account. Configuration (all verified): Subscription is "Ready to Submit" / "Waiting for Review" Available in all territories Paid Apps Agreement active; banking and tax complete Bundle ID and shared secret unchanged from when it worked App Review keeps rejecting under Guideline 2.1(b) ("プレミアムをはじめる" / purchase button unresponsive) because the product never loads. Questions: For a newly created IAP on a not-yet-approved app, how long does it take to become available in the sandbox? Is there a known propagation delay (24h+)? Does re-creating the product with a new Product ID reset or delay sandbox availability? Is anything required for a new product to be served in the sandbox before the app's first version is approved? Any guidance appreciated. Thanks!