I am testing auto renewing subscriptions for a macOS program in Xcode with a local Storekit file. I have renewals set to occur every minute for testing. I quit the app, and watch renewals appear in the Debug transaction manager window. Each is marked unfinished. When I start the app, I call a function that is supposed to get unfinished transactions and finish them. In one of those "I swore it worked the other day", I am now finding it isn't working. The unfinished transaction remain marked as unfinished. func getUnfinished() async { for await verificationResult in Transaction.unfinished { guard case .verified(let transaction) = verificationResult else { continue } await transaction.finish() } } If I add an AppStore.sync() right before looping on Transaction.unfinished, it works (i.e., cleans up unfinished transactions), but I get an alert I have to click through. do { try await AppStore.sync() } catch { print("DEBUG UNFINISHED: AppStore.sync() failed: \(error)") } Any idea why Transaction.unfinished isn't fetching unfinished transactions for me (without the AppStore.sync)?

I've read several topics on cancelling subscriptions in sandbox environment, but it seems to me that it could not be applied to TestFlight. I can cancel sandbox subscriptions through Settings > App Store > Sandbox account But since TestFlight does not use sandbox account I cannot cancel a sub from there. Also, TF purchase does not appear in the list of regular subscriptions (Settings > Profile > Media & Purchases). So my question is: is there any way to manually cancel auto-renewable subscription bought in TestFlight build of the app?

I have a VoIP app, now try to implement the new method which support the "PKVoIPPushMetadata" in iOS 26.4. Code as below: /// iOS 26.4+ (SDK with `PKVoIPPushMetadata`): prefer this path for VoIP per Apple; completion is `@Sendable` on supported SDKs. @available(iOS 26.4, *) func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingVoIPPushWith payload: PKPushPayload, metadata: PKVoIPPushMetadata, withCompletionHandler completion: @escaping @Sendable () -> Void) { print("willtest: didReceiveIncomingVoIPPushWith: metadata=\(metadata)") handleVoIPPush(payload: payload, metadataMustReport: metadata.mustReport, completion: completion) } func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { print("willtest: didReceiveIncomingPushWith: PKPushType=\(type)") handleVoIPPush(payload: payload, metadataMustReport: nil, completion: completion) } But the voip push only goes to the old method on my iOS26.4 device(iPhone17). And it will go to the new method after I delete the old method. So how can I use this method in my app? I must support iOS16+ versions.

I'm working on a MailKit extension and I'm getting a full Mail crash every time I click the Primary Action button in my message banner. I have filed a feedback: FB22513160 Apple's own unsubscribe banner successfully presents a confirmation modal when its primary action is clicked, demonstrating that this flow is intended to work. That behavior does not appear to be accessible to third-party extensions via the documented EMessageSecurityHandler API. Or if it is and I'm missing something, I'd love to know. Thanks!

Hi, I am looking for help. I submitted my request for Family Conotrols Distribution using the form. I have been waiting for days and didn't get any reply or confirmation email. Thanks.

I'm developing a spatial tracking app using a Qorvo DWM3001CDK (MFi-certified UWB accessory) with NINearbyAccessoryConfiguration. On iPhone 15 (iOS 26.3.1, second-generation UWB chip): supportsDirectionMeasurement = false NINearbyObject.direction is always nil NINearbyObject.distance works correctly (~63Hz) Camera Assistance (isCameraAssistanceEnabled=true) provides horizontalAngle only after ARKit convergence (~10s), and only while the phone is moving On iPhone 12/13 (first-generation UWB chip), direction works correctly with the same accessory. My questions: Is the removal of instantaneous direction measurement for third-party accessories on second-generation UWB devices intentional? Or is this a regression that will be fixed in a future iOS update? If intentional, what is the recommended approach for apps that need real-time direction to a UWB accessory on iPhone 15/16? Camera Assistance requires phone movement and only works with stationary targets, which doesn't work for our use case (tracking a moving object with the phone mounted on a gimbal). Are there any plans to provide instantaneous direction measurement for NINearbyAccessoryConfiguration on second-generation UWB devices? Environment: iPhone 15, iOS 26.3.1 Qorvo DWM3001CDK (FiRa + MFi certified) NINearbyAccessoryConfiguration with isCameraAssistanceEnabled=true Shared ARSession Thank you.

model : iphone 17 ios version: 26.2 app used: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps Here is our observation when we tried to make wifi aware connection between iphone and our wifi device. note : we used iphone as subscriber ( view simulation) 1.pairing & bootstrapping was successfully done 2.Data path was successfully established between iphone and our device. after data path establishment ,within few seconds , DATA PATH TERMINATION was sent from iphone which leads to pairing verification with new NMI address. Same behaviour is noticed even when we try to establish connection between two iphone devices. Here we have few questions. Once we establish data path , Why iphone initiates data path termination instead using the same service for data path exchange. 2.Why do we go for PAIRING VERIFICATION everytime.

I’m investigating Core Data lightweight migration behavior with SQLite and ran into a performance issue. Scenario: Model V1: EntityA has one fetchIndex Model V2: EntityA adds a new optional attribute timestamp (Integer 64), with no changes to existing attributes or fetchIndex definitions From a SQLite perspective, this change should be handled by a simple: ALTER TABLE ZENTITYA ADD COLUMN ZTIMESTAMP INTEGER But I observe that Core Data rebuilds the existing index, which becomes a significant performance issue for large databases. CoreData: sql: DROP INDEX IF EXISTS Z_EntityA_id CoreData: sql: ALTER TABLE ZENTITYA ADD COLUMN ZTIMESTAMP INTEGER CoreData: sql: CREATE INDEX IF NOT EXISTS Z_EntityA_byID ON ZENTITYA Question: Is there any way to avoid or bypass index rebuilding for this kind of schema changes?

In the WWDC 2019 session "Extended Runtime for WatchOS apps" the video talks about an entitlement being required to use the HR sensor judiciously in the background. It provides a link to request the entitlement which no longer works: http://developer.apple.com/contect/request/health-monitoring The session video is also quite hard to find these days. Does anyone know why this is the case? Is the API and entitlement still available? Is there a supported way to run, even periodically, in the background on the Watch app (ignoring the background observer route which is known to be unreliable) and access existing HR sensor data

I’m trying to submit the first release of my iOS app together with the app’s first consumable in-app purchases, and I’m stuck in what looks like an App Store Connect state issue. My app was already rejected by App Review because the in-app purchases did not appear inside the app when the reviewer opened the paywall. Current setup: First app release Current app version page: iOS App Version 1.0.2 Current attached build: 5 App has never been released before 4 consumable IAPs: com.glowup.credits.100 com.glowup.credits.500 com.glowup.credits.1000 com.glowup.credits.2500 What I see in App Store Connect: All 4 IAPs show Waiting for Review On the iOS App Version 1.0.2 page, the In-App Purchases and Subscriptions section does not appear at all Because of that, I cannot explicitly select or attach the IAPs from the version page What I’ve already done: Uploaded a new build and attached build 5 to version 1.0.2 Removed my local StoreKit configuration file so the app now uses live App Store / StoreKit only Confirmed RevenueCat is configured correctly and sees the offering/packages RevenueCat logs show the products exist remotely, but StoreKit cannot fetch any live products and returns an “offerings empty / none of the products could be fetched” type error RevenueCat also reports the products are still in WAITING_FOR_REVIEW My questions: If the IAPs already show Waiting for Review, are they automatically linked to the current app submission? Is it expected that the In-App Purchases and Subscriptions section can disappear from the app version page in this state? For a first-release app that was already rejected, is attaching a new build and clicking Update Review enough, or is there another step required to associate the IAPs with the resubmission? Has anyone seen App Review reject an app for missing IAPs while the IAPs were still pending review and not yet fetchable from StoreKit? Any guidance from someone who has dealt with this exact first-release + first-IAP submission flow would help a lot.

Hello Apple Developer Support / StoreKit Team, We recently observed a behavior regarding the appAccountToken in App Store Server Notifications v2 that seems to completely contradict the official documentation. According to the Set App Account Token documentation: The same appAccountToken continues to apply to renewal transactions if the customer upgrades, downgrades, or cross-grades the subscription. However, we encountered a scenario where an active in-app crossgrade resulted in an updated/overwritten appAccountToken inside the subsequent JWSRenewalInfoDecodedPayload, despite our backend never calling the Set App Account Token REST API. Our Observation: A user subscribes to our 1-month plan (Product A). Apple generates an originalTransactionId bound to their initial appAccountToken (Token A). Later, a crossgrade to a 1-year plan (Product B) is initiated from within the app while the user is logged into a different account in our system (Token B), but using the same underlying Apple ID on the device. When the crossgrade takes effect at the next renewal date, we receive a DID_RENEW webhook. The Anomaly (See Attached Screenshots): Upon decoding the JWSRenewalInfoDecodedPayload from the webhook, we noticed that the appAccountToken had unexpectedly changed to the new token (Token B). As shown in the attached redacted screenshots: Screenshot 1 (Before/Original): JWSRenewalInfoDecodedPayload for Product 00001 shows the appAccountToken ending in ...e9a. Screenshot 2 (After Crossgrade): JWSRenewalInfoDecodedPayload for Product yearly_saver shows the appAccountToken has mutated to ending in ...507, even though the originalTransactionId remains exactly the same. To reiterate, our server did not call the POST /inApps/v1/subscriptions/appAccountToken/{originalTransactionId} endpoint to manually overwrite this token at any point. Our Questions: Is this the intended StoreKit 2 behavior? Does Apple automatically overwrite the base appAccountToken in the RenewalInfo if a new token is somehow associated during an active in-app crossgrade transaction? If this is intended, could the documentation be clarified? The current phrasing strongly suggests the token is permanently locked to the initial purchase and will never change during crossgrades unless the REST API is explicitly called. While this behavior is actually quite helpful for our backend to track multi-account users, we want to ensure we aren't relying on an undocumented bug that might be patched unexpectedly. Any insights from the StoreKit engineering team would be highly appreciated. Thank you!

Hi everyone, I’ve been encountering a recurring issue with the App Store Server API over the past 48 hours, specifically regarding the Get Transaction Info endpoint. Endpoint: GET /inApps/v1/transactions/{transactionId} Environment: Production Error Code: 4040010 (TransactionIdNotFound) The Issue When a user completes a purchase in our app, the client-side sends the transactionId to our backend for validation. However, when our server immediately calls the Get Transaction Info API using that ID, it frequently returns a 4040010 error, stating that the transaction ID cannot be found. Key Observations Eventual Consistency Delay: If we implement a retry logic and wait for 2 to 5 minutes, the exact same transactionId eventually becomes queryable and returns a valid signedTransactionInfo. Notifications vs. API: Interestingly, our server receives the App Store Server Notifications V2 (webhook) for these transactions almost instantly. The notifications contain the correct data, but the "Pull" API seems to lag behind the "Push" notification system. Recent Spikes: This behavior started occurring frequently within the last 2 days. Prior to this, the API was almost always near-instant. Questions Has anyone else noticed a spike in 4040010 errors or increased indexing latency in the Production environment recently? Is there a recommended "grace period" or backoff strategy when querying for a new transactionId? Apple's documentation doesn't explicitly mention an expected delay between a successful purchase and its availability via the Server API. Any insights or confirmation of similar issues would be greatly appreciated!

Hello, with macOS' and iOS' recent updates (26.4.x), Handoff in my app appears to have become dysfunctional, as I receive the following message in the logs: getContinuationStreamsWithCompletionHandler(), inputStream=(null) outputStream=(null) error=Error Domain=NSPOSIXErrorDomain Code=94 "Bad message" UserInfo={NSLocalizedDescription=Could not set up internal streams} It ONLY works: From a Mac with 15.x to other Macs or iOS devices (on 26.4.x). All other combinations (see below) do NOT work: iOS (26.4.x) > iOS (26.4.x) iOS (26.4.x) > Mac (26.4.x) iOS (26.4.x) > Mac (15.x) Mac (26.4.x) > iOS (26.4.x) The Handoff prompt is shown in the Dock on Mac, in the app switcher on iOS, and in the Dock on iPadOS, but once I click/press it, I get the continuationStreams error. Now, is it my app, or the OS? Thank you kindly, – Matthias

When use Q-encoded to handle non-ASCII characters, if raw characters start with non-ASCII, we will get encoded like '=?UTF-8?Q?=XX=XX?='. IOS(>26) Mail App may think the first '?=' end of the '=?UTF-8?Q?=' is then end flag, so show incorrectly.

Hello Apple Developer Forums, We are building an iOS app that needs to receive images and PDFs shared from the system share sheet. The sources include Screenshots, Photos, Files, and third-party apps. The desired user experience is similar to apps such as ChatGPT or Claude: when the user taps our app in the share sheet, the main containing app opens and starts importing or uploading the shared image or PDF. We are trying to understand the supported public API for this behavior. Why opening the containing app is important For our use case, it is important that the containing app opens during the share flow. The import/upload operation depends on the user’s authenticated session. If the Share Extension attempts to upload the file directly, the auth token available to the extension could be missing, expired, or invalid. We would prefer not to make the Share Extension responsible for authentication-dependent behavior such as: validating the user session refreshing tokens handling expired credentials presenting login or re-authentication UI owning upload retry logic tied to auth state In our architecture, authentication and token refresh are owned by the containing app. The Share Extension should ideally only receive the shared file, persist it in an app group container, and hand off to the main app. The main app would then validate auth state, refresh tokens if needed, and perform the import/upload. So the desired flow is: Share Extension receives image/PDF → Share Extension stores file in app group container → Containing app opens → Containing app validates auth/session state → Containing app imports/uploads the file The alternative flow is problematic for us: Share Extension receives image/PDF → Share Extension attempts upload directly → Upload may fail if auth token is expired or unavailable → Share Extension would need auth/session responsibilities We are trying to avoid having an authentication dependency inside the Share Extension implementation. What we have tried CFBundleDocumentTypes We added document type support for: public.image public.png public.jpeg public.heic public.heif com.adobe.pdf This works for some document-open flows, such as opening files from Files or Photos in certain cases. However, it does not make the app appear reliably as a share target from Screenshot Share or from some third-party app share sheets. App Intents We tried using App Intents with IntentFile and: static var openAppWhenRun: Bool = true However, this does not seem to create a general-purpose share-sheet receiver for arbitrary image or PDF NSItemProvider payloads. Share Extension We also implemented a Share Extension that: Receives the shared NSItemProvider. Stores the image or PDF in an app group container. Attempts to open the containing app. However: NSExtensionContext.open(_:completionHandler:) does not appear to foreground the containing app from a Share Extension in the way we need. We also tested responder-chain openURL: trampoline approaches, but those do not work reliably and appear to be unsupported as a public API contract. Questions Is there a supported public API for an iOS app to appear as a share target for arbitrary image/PDF NSItemProvider payloads and then directly open the containing app? If apps such as ChatGPT or Claude appear to switch directly into the main app from the share sheet, is that behavior achievable using public APIs available to third-party developers? If directly opening the containing app is not supported, what is the recommended architecture when the import/upload depends on authenticated app state? Is Apple’s recommended design that the Share Extension itself must perform the full import/upload operation, even when that operation depends on auth validation or token refresh? Is there a supported handoff mechanism where the Share Extension can persist the file in an app group container and then ask the system to open the containing app to continue the flow? Are App Intents intended to support this kind of share-sheet attachment import flow, either currently or in a future iOS version? Reproduction Steps We created a focused sample project to reproduce the issue. Build and run the app on a physical iPhone. Leave the app installed. Capture a screenshot. Tap the screenshot thumbnail. Tap the Share button. Choose the app’s Share Extension from the share sheet. Observe that the Share Extension receives the image payload. Attempt to open the containing app from the extension. Expected Result The Share Extension receives the shared image or PDF, stores it in an app group container, and the containing app foregrounds. The containing app then validates the user’s authenticated session, refreshes tokens if needed, and performs the import/upload. Actual Result The Share Extension receives the image payload and logs the provider type identifiers, but the containing app does not reliably foreground. NSExtensionContext.open does not provide the desired transition, and responder-chain URL-opening workarounds do not appear to be supported or reliable. Minimal Question For image/PDF imports from the iOS share sheet, where upload/import requires authenticated app state, what is the supported implementation? Is it expected to be: Share Extension receives the file → Share Extension performs auth-dependent upload/import itself or is there a supported way to implement: Share Extension receives the file → Share Extension stores the file in app group container → Share Extension opens or hands off to containing app → Main app performs auth validation and upload/import Any guidance on the supported architecture would be appreciated. Thank you.

Our app runs offline-first focus sessions using FamilyControls / ManagedSettings shielding and DeviceActivity monitoring. The in-app session timer is protected against wall-clock manipulation by using monotonic elapsed time, and the shield remains active correctly when the user manually changes the iPhone clock. However, the Live Activity and Dynamic Island countdown appear to use the device's wall clock for their timer rendering. If the user changes the device time from Settings during an active session, the Live Activity / Dynamic Island countdown immediately jumps forward or backwards, even though the underlying session has not changed. Is there a recommended ActivityKit approach for rendering a Live Activity / Dynamic Island countdown that is resistant to manual device clock changes? If not, is this an expected limitation of Live Activity timer rendering? And is there any supported way for the host app or widget extension to detect wall-clock manipulation so the Live Activity can be corrected, dismissed, or replaced with a safer non-countdown state?

Hi, Overview: I get the following error when trying to save / read from SwiftData It happens when I try to save color to SwiftData (code below) Error 'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release Questions How can I resolve the error? I am not directly using data, I am using just Float values, swift types. Why am I getting this error? Is there a way to add a breakpoint to stop at the exact type causing the error? (Symbolic breakpoint doesn't seem to help) Or is the below code ok and not responsible for the error? Code import SwiftUI nonisolated struct ColorRepresentation: Codable { let red: Float let green: Float let blue: Float let opacity: Float init(colorResolved: Color.Resolved) { red = colorResolved.red green = colorResolved.green blue = colorResolved.blue opacity = colorResolved.opacity } func color() throws -> Color { Color( red: Double(red), green: Double(green), blue: Double(blue), opacity: Double(opacity) ) } } extension ColorRepresentation: Equatable {}

Hi, We are seeing a reproducible issue when presenting SKStoreProductViewController in our production app context. For a quick summary, presenting and dismissing SKStoreProductViewController on iOS 15/16 can leave our app in a visually corrupted state (black/empty/orphaned-looking UI). On iOS 18/26 (presumably every iOS version in between), the same flow works correctly. What we verified dealloc is not called for our affected view controllers. During StoreKit lifecycle, VC hierarchy is logically valid: window.rootViewController remains stable. presented chain remains expected. SKStoreProductViewController becomes top-presented and dismisses normally as logged in the delegate. In the xcode view hieararchy, only the UITransitionView and UIDropShadowView are present. Our app content VCs are no longer attached to the visible hierarchy. This is the code we used: SKStoreProductViewController *storeVC = [SKStoreProductViewController new]; storeVC.delegate = self; [storeVC loadProductWithParameters:@{ SKStoreProductParameterITunesItemIdentifier: @(APP_ID) } completionBlock:^(BOOL result, NSError *error) { if (result) { [presenter presentViewController:storeVC animated:YES completion:nil]; } }]; -- (void)productViewControllerDidFinish:(SKStoreProductViewController *)viewController { [viewController dismissViewControllerAnimated:YES completion:nil]; } We also observed that presenting SKStoreProductViewController appears to trigger memory-intensive behavior in this runtime context. Shortly after presentation, UIApplicationDidReceiveMemoryWarningNotification is frequently emitted on affected OS versions. However, even when this happens, our VC ownership remains intact (dealloc not called, root/presented chain still valid), while the visible UI and View Hiearchy is left with just the UIWindowScene. Moreover, to verify and confirm that this is an OS issue and not a hardware issue. We also tried using 2 iPhone 12 devices, one running on iOS 16 and one on iOS 18. The iOS 18 one works flawlessly but the iOS 16 device produces the same behaviour Is this a known StoreKit/UIKit issue on iOS 15/16/17? Any recommended mitigation or perhaps alternatives to using SKStoreProductViewController on these OS versions? Thanks.

Hello, I want to echo the DeviceActivityReport "concurrency" problems flagged in https://developer.apple.com/forums/thread/720549, and ask a related question. (Thanks to Kmart and other Apple dev support folks who have been monitoring these forums and responding diligently.) I would like to display daily and weekly stats in the same view, broken down by specific apps (as in the native Screen Time). However, instantiating multiple DeviceActivityReport objects with different filters and/or different contexts leads to confusion, where the two views will incorrectly and intermittently swap data or duplicate data where it shouldn't (seemingly upon some interval when the extension provides fresh data). There isn't documentation on how to display multiple reports at once. Is the idea that logic for multiple reports should be embedded within the extension itself in the makeConfiguration() function and there should only be a single DeviceActivityReport in the main App, or is this a bug? Even with a single DeviceActivityReport, I run into inconsistencies where the View provided by the extension takes multiple seconds to load or fails to load altogether. The behavior seems random...I will build the application with the same code multiple times and see different behavior each time. Finally, a plug for better support in the Simulator for the entire set of Screen Time APIs. Thanks!

Hello, I submitted a request for Family Controls (Distribution) approval, and it has now been over 4 days without any update on the status. I understand that review times can vary, but I wanted to check if this delay is expected or if there’s anything I might need to do on my end to help move the process forward. Could anyone from the Apple team or the community provide insight into: Typical processing times for Family Controls distribution requests Whether delays beyond a few days are common Any steps I should take to follow up or expedite the review For reference: Status: Submitted Submission time: April 21, 2026 Any guidance would be greatly appreciated. Thank you!