Hello, Since updating to iOS 26 Beta 3, I’ve been experiencing an issue where transactions purchased through the normal in-app purchase flow continue to be reported as updated and unfinished—even after calling the finish() function. Please resolve this promptly.

This error occurs in Apple Pay Wallet In-App Provisioning Flow for Credit / Debit Cards When the data received from the PNO (Visa) is passed to PKAddPaymentPassRequest this error is seen in addPaymentPassViewController, in the finalize stage. Docs provide no clue as to what could be wrong. iOS 18.2.1 XCode 15.2 Error description mentions "unsupportedVersionError" Is the pass version not supported? Is the wallet version not supported? Is it an app implementation error or error in the data received from the PNO?

When setting up a packet tunnel with a profile that has includeAllNetworks set to true, we seemingly cannot send any traffic inside the tunnel using any kind of an API. We've tried using BSD sockets, as we ping a host only reachable within the tunnel to establish whether we have connectivity - this does not work. When using NWConnection from the Network framework and specifying the required interface via virtualInterface from the packet tunnel, the connection state never reaches ready. Our interim solution is to, as ridiculous as it sounds, include a whole userspace networking stack so we can produce valid TCP packets just to send into our own tunnel. We require a TCP connection within our own tunnel to do some configuration during tunnel setup. Is there no better solution?

We are currently experiencing a very interesting issue when accessing the location in the background with CLLocationManager. The user has given our app the "whenInUse" permission for locations and in most cases the app provides location updates even when it's in the background. However, when we started to use other navigation apps in the foreground we saw that the func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) method was called with (kCLErrorDomain error 1.). The user hasn't changed the location permission and we saw that locations were delivered once the user opened the app again. I don't see anything in the documentation explaining this issue, but I chatted with other developers that confirm that specific behavior. Am I missing something here?

I have an odd issue I'm trying to troubleshoot. I have an app that is deployed to our enterprise and works on almost all of our devices. Lately, I have devices (very small number) where the app installs from our MDM and it crashes upon launch, it does not get past the launch screen. If I remove and reinstall the app from the MDM it still crashes. I decided to put the devices in developer mode and if I run the App from Xcode on the device it works fine. If I stop it and run it right from the device it also works. If I do a final build of the app and install it using "Devices and Simulators", the app crashes upon launch. Using "Devices and Simulators" I check for crash log for the app and no file. I am stumped as to whats going on.

I'm encountering an issue with the App Store Server API where the appAccountToken is not preserved when users migrate their Apple ID email addresses. I've submitted Feedback Assistant ticket FB18709241 but wanted to check if anyone else has experienced this and get community input on best practices. The Issue When a user migrates their Apple ID from one email to another (e.g., from olduser@example.com to newuser@icloud.com), the App Store creates a new subscription transaction with a different originalTransactionId, but the appAccountToken is not carried forward from the original transaction. What I'm Seeing note: these values are fake When querying /inApps/v1/subscriptions/{originalTransactionId} with the either post-migration transaction ID or the pre-migration transaction ID, the API returns both transactions: Pre-migration transaction (status: 2 - inactive): originalTransactionId: "12345678910111" Contains: "appAccountToken": "abc123-def456-ghi789" Post-migration transaction (status: 1 - active): originalTransactionId: "67891011121314" Missing: appAccountToken entirely The Problem The appAccountToken is our only way to link App Store subscriptions to user accounts. Without it on the new transaction: Users lose access to premium features despite having valid subscriptions Server-side renewal notifications can't be matched to user accounts Manual support intervention is required for each affected user Questions for the Community Has anyone else encountered this issue with Apple ID migrations? What's the recommended approach for handling this scenario? Is there an alternative mechanism to maintain the subscription-to-user linkage across migrations? Questions for Apple Engineers Is this the expected behavior, or should the appAccountToken be preserved? Are there any planned improvements to handle this migration scenario? What's the best practice for developers to handle this case? Interestingly, both the old and new transaction IDs return the same JSON response from the App Store Server API, suggesting Apple maintains internal linkage between these transactions, but the appAccountToken isn't carried forward to the active transaction. Any insights or similar experiences would be greatly appreciated! Thank you!! Feedback Assistant: FB18709241

I’m testing an auto-renewable subscription on TestFlight. Now the user can't re-purchase the same product – Apple just restores the old (expired) one, and no payment sheet appears. How can I let the same TestFlight user re-subscribe to an expired product? Do I have to create a new productId for every test cycle?

Our app provides a calendar that integrates with the default calendar app. Specifically, we use iOS EventKit to perform CRUD operations on calendar data. Recently, we have received reports from users that all of their events have disappeared. However, after reviewing our implementation and logs, we have not been able to identify the cause. Some users have also reported that all data in their default calendar app has disappeared as well. Does anyone have any idea what might be causing this? To delete an event within our app, users must press the delete button and then confirm the deletion in a dialog. Additionally, it is not possible to delete more than two events at once. We've seen many people in the community discussing a bug where calendar events disappear after updating to iOS 18. If you have any information about when or why this happens, we'd appreciate it if you could share your insights.

Some paid users are unable to use the paid features unlocked by purchasing our subscription plan. It seems that this is due to StoreKit 2's Transaction.currentEntitlements not working the way we would expect it to work. Are you also encountering this issue? Do you have any idea to improve this situation? At launch, our app checks if the user is subscribed to the plan, using Transaction.currentEntitlements. As a result, the currentEntitlements array was empty. Our app then fetches the products from StoreKit 2 using Product.products(for:). As a result, the Product.SubscriptionInfo.RenewalState value of the corresponding Product (product.subscription.status.first.state) is subscribed, which confirms that the user has indeed purchased our plan, but seems to contradict the absence of the corresponding transaction in Transaction.currentEntitlements. Proactive in-app purchase restore and a restore purchase button calling the AppStore.sync() method are implemented, but using the button did not solve the issue.

Apple Feedback Ticket: FB16804936 Background We develop a parental control application called Adora Kids (https://apps.apple.com/us/app/adora-kids/id6443787669) that requires "Location Always" permission to function properly. Our app has Screen Time authorization and provides monitoring services for parents. Issue We are experiencing a recurring problem where child users receive the system notification "Adora accessed your location in the background" every few days. This frequently results in children disabling location permissions, which prevents our app from functioning as intended. Current Approach and Limitations We have explored using Content & Privacy Restrictions for Location Services as a potential solution, but have encountered two significant limitations: These restrictions cannot be accessed programmatically via the ManagedSettings framework (unlike AppStoreSettings and other restrictions). The current implementation is "all-or-nothing" - enabling location restrictions blocks permission changes for ALL apps on the device, preventing children from granting legitimate location access to other applications. Questions Is there a way to programmatically access and manage Content & Privacy Restrictions for Location Services through the ManagedSettings framework that we might have overlooked? Are there any recommended approaches for apps with Screen Time authorization to prevent users from changing specific permissions (particularly location) while still allowing them to manage permissions for other apps? Does Apple have plans to implement app-specific permission locking for apps with Screen Time authorization in future iOS releases? Are there any alternative approaches or workarounds that other developers have successfully implemented for this use case? Any guidance from the developer community or Apple engineers would be greatly appreciated. This is a critical functionality issue affecting the reliability of our parental control service. Thank you in advance for your assistance.

All the cards seem to have expired in Dec 2024: https://developer.apple.com/apple-pay/sandbox-testing/ Are there updated cards? Some gateways only support Mastercard and Discover which all appear expired.

I'm working on an XPC server and need to determine the owner of the client process that connects to it. Specifically, I'd like to retrieve details such as the fully qualified user name or other identifying information from the XPC client connection.I'm considering using xpc_connection_get_pid() to get the client’s process ID, but I’m unsure of the best way to map this to the user who owns the process. Is there a recommended API or approach to capture this information securely?

I'm reaching out to see if anyone else is experiencing issues with the Live Caller ID feature on iOS. We recently encountered a problem where the feature stopped working entirely. Here's a brief overview of the situation: We were monitoring test traffic on our backend and noticed everything came to a halt around 1:00 AM UTC on November 15th. After this time, any attempts to reach our backend through calls failed completely. I tested this across multiple devices running iOS 18.2 and iOS 18.0. I used both TestFlight builds and development builds via Xcode, which should communicate directly with our backend. I experienced the problem on our main application as well as a dedicated test app. To troubleshoot further, I even set up a local server on localhost and tried directing requests there, but the requests did not reach the local server when a call was received. Further debugging in Console.app revealed the following error: identity request returned error: Error Domain=com.apple.CipherML Code=400 "Error Domain=com.apple.CipherML Code=401 "Unable to request data by keywords batch: failed to fetch token issuer directory" However, when I manually tried to hit our server endpoint using curl, the request successfully reached the server: curl https://our_server/something hb_method=GET hb_uri=/something [Hummingbird] Request -- log on backend This suggests that while our backend is responsive, the requests from the iOS client side are simply not being initiated.

I am pretty sure iOS 13.4 (beta and later) did support Coded PHY (Long Range). Tested devices are iPhone SE2 and iPhone 11 Pro. However, it seems iOS 14 removed the support of Coded PHY, accidentally or on purpose, I don't know? The same PHY update request returns "1M PHY" in iOS 14, but "Coded PHY" in iOS 13 (13.4 beta and later). Anyone knows why? Samson

For years our iOS apps have experienced a networking problem, which blocks them connecting to our servers via their API endpoint domains. How can we recover after the scenario described below? Using 3rd party error logging solutions, which have different endpoint domains, we can record the error: NSUnderlyingError": Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9816, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816, _NSURLErrorNWPathKey=satisfied (Path is satisfied), viable, interface: pdp_ip0[lte], ipv4, dns, expensive, uses cell}, "_NSURLErrorFailingURLSessionTaskErrorKey": LocalDataTask <DEDBFA4D-810D-4438-A6A0-95E3B9668B9E>.<308>, "_kCFStreamErrorDomainKey": 3, "_NSURLErrorRelatedURLSessionTaskErrorKey": <__NSSingleObjectArrayI 0x301f82e60>( LocalDataTask <DEDBFA4D-810D-4438-A6A0-95E3B9668B9E>.<308> ) "NSLocalizedDescription": An SSL error has occurred and a secure connection to the server cannot be made., "NSLocalizedRecoverySuggestion": Would you like to connect to the server anyway? -9816 is the "server closed session with no notification" error based on comments in CoreFoundation source files. Subsequent API endpoint calls to the same domain return the same error. The SSL error occurs most prevalently after a server outage. However, despite our best efforts, we have been unable to replicate triggering the problem for development purposes via experiments with our server. When the error occurs the users report that: Fully closing (i.e. not just sending to background) and reopening the app does NOT clear connectivity to our server being blocked. Problem seems more prevalent when using mobile/cell data. Switching from mobile/cell data to WIFI resolves the connection problem and then switching back to mobile/cell data shows the problem again. So the underlying problem is not cleared. All other apps on the same device and mobile/cell data or WIFI connection, like Safari, have no problems connecting to the Internet. Deleting and reinstalling, or updating (when an update is available) resolves the problem. Or after waiting a few days the problem seems to resolve itself. The last two point above suggest that something is persisted/cached in the app preventing it from connecting properly with subsequent network attempts. Notes: We have one shared instance of the URLSession in the app for its networking because we are aware of the perils of multiple URLSession instances. We recently added conditions to call the URLSession await reset() method when detecting the SLL errors before repeating the request. It is debatable whether this reduces the problem as we still see logged cases with the subsequent requests hitting the same -9816 error. URLSession configuration: let config = URLSessionConfiguration.default config.timeoutIntervalForResource = 22 config.timeoutIntervalForRequest = 20 config.requestCachePolicy = .reloadIgnoringLocalCacheData config.urlCache = nil

Hey! We're implementing In-App Purchase Subscriptions and we were able to receive "App Store Server Notifications" on our "Sandbox Server URL". But the last event we received 22 hours ago. We are able to verify transactions and finish them, but receive no webhooks. We changed nothing on our server or its configurations but the notifications stoped to come. We consulted the API (https://api.storekit-sandbox.itunes.apple.com/inApps/v1/notifications/history) and it says the same as we see - the last event was 22hrs ago. I checked all the advices from here as well (https://developer.apple.com/forums/thread/805806?answerId=864483022#864483022). Is there any Status page for the Store Kit Sandbox services? Was there any outage? Sincerely, Konstantin

Hello, I use Storekit2 to test the purchase of subscription products. After purchasing a subscription product in the sandbox, it will automatically renew 12 times, and then it will no longer automatically renew. When I click to purchase again, calling the try await product.purchase() method does not pop up the purchase pop-up window. In fact, it will directly go to the case let .success(.verified(transaction)): step, and the Transaction.currentEntitlements is empty

Hello, I’m building a health-related app for both watchOS and iOS, which needs to monitor certain health data (e.g., heart rate, active energy). Before updating to watchOS 26, the queries worked reliably without any issues. However, after adapting to watchOS 26, some users have reported that health data updates stop being delivered. What I’ve observed: HKObserverQuery with enableBackgroundDelivery is set up normally. On WatchOS 26, the query sometimes stops delivering updates entirely after a certain point, and once an update is missed, it may stop delivering further updates completely. Restarting the Apple Watch temporarily restores delivery, but the problem reoccurs after some time. This makes background health data monitoring unreliable for my app. Here’s a simplified version of the code we are using: guard let heartType = HKObjectType.quantityType(forIdentifier: .heartRate) else { return } let query = HKObserverQuery(sampleType: heartType, predicate: nil) { query, completionHandler, error in if let error = error { logEvent("Observer error: \(error.localizedDescription)") return } logEvent("Heart rate changed") MyNotificationManager.shared.sendNotification() // Send a local notification completionHandler() } healthStore.execute(query) healthStore.enableBackgroundDelivery(for: heartType, frequency: .hourly) { success, error in if success { logEvent("Background heart rate delivery enabled") } else { logEvent("Failed to enable background heart rate delivery: \(error?.localizedDescription ?? "Unknown error")") } } Could you please clarify: Is this a known issue with HKObserverQuery and enableBackgroundDelivery on watchOS 26? Are there any recommended workarounds or best practices to ensure continuous background delivery of health data? Thank you in advance for your help.

I have added an "App Intents Extension" target to my main application in macOS. This generated the below two files: TWAppIntent.swift import AppIntents struct TWAppIntent: AppIntent { static var title: LocalizedStringResource = "TWAppIntentExtension" static var parameterSummary: some ParameterSummary { Summary("Get information on \(\.$TWType)") } //launch app on running action static var openAppWhenRun: Bool = true // we can have multiple parameter of diff types @Parameter(title: "TWType") var TWType: String func perform() async throws -> some IntentResult & ReturnsValue<String> & ProvidesDialog { return .result(value: TWType, dialog: "Logged break.") } } TWAppIntentExtension.swift import AppIntents @main struct TWAppIntentExtension: AppIntentsExtension { } I m able to build the extension target and I my intent action is available in the shortcuts app. However, on launching a shortcut with the above created intent action. I m getting the below popups: I have identified what is causing this error. Setting the openAppWhenRun to true is causing this error. I don't get this when it is set to false. This property is supposed to launch the application, but can someone help me understand why is it happening? This is only causing the error when using this property for AppIntent Extension and not for In app handling for the AppIntent. Can we not launch our application from AppIntent extension?

Hello developers, We're facing a critical issue with our app and need your insights: Since today, 3 specific IAP products return empty data when calling Product.products(for: [productId]). This affects all users, preventing any successful purchases of these items. Other IAP products seem unaffected. let products = try await Product.products(for: [productId]) Key details: Production environment Issue started: 2025.6.17 No recent app updates All products show as "Approved" in App Store Connect Questions: Has anyone experienced similar issues recently? Could this be a StoreKit or App Store system problem? Any suggestions for diagnosing or resolving this, besides contacting Apple Support? Recommendations for temporary workarounds? This is severely impacting our business. Any help is greatly appreciated! Thank you!