Hi, my app was rejected because IAP were not present in the app. I followed guidelines more carefully and filled all buisness detail since then. And now I have: StoreKit Configuration in XCode is set to None, Products (subscription + consumable product) are already approved (from the previous review) Paid Apps Agreement - active Bank account - active Tax forms - active Compliance - active Problems: When trying to test it with TestFlight + sandbox account, StoreKit is returning zero products. When trying to check my products by "initiate transaction" from Sandbox App Store manage dashboard I am getting an error "This item is not available" I am totally stuck and don't know what to process next. Unfortunately API.

We are implementing Apple Pay In-App Provisioning in our issuer iOS application and are encountering a HTTP 500 error returned from Apple servers during the provisioning flow. The issue occurs after generating the encrypted payload and attempting to complete the provisioning process. The Apple service responds with 500 Internal Server Error, preventing the card from being added to Wallet. We would appreciate assistance identifying whether this is caused by: • a payload formatting issue, • cryptographic material mismatch, • entitlement / configuration issue, • or a server-side issue. Environment Platform • iOS: 26.3.1 • Device: iPhone 13 mini • Xcode: 26.3.1 Apple Pay configuration • In-App Provisioning entitlement enabled • Issuer app authorized by Apple for provisioning • Payment Network: Mastercard • Token Service Provider (TSP): MDES Testing environment • Production • App distribution method: TestFlight Provisioning Flow Overview Our implementation follows the standard Apple Pay In-App Provisioning flow: 1. User taps Add to Apple Wallet in issuer app. 2. App presents PKAddPaymentPassViewController. 3. App receives: • Apple public certificates • nonce • nonceSignature 4. Issuer backend generates: • encryptedPassData • activationData • ephemeralPublicKey 5. These values are returned to the app. 6. App constructs PKAddPaymentPassRequest. 7. Wallet attempts provisioning. At this point the request fails and Apple servers return HTTP 500. We see this in the system console, with the phone having Wallet debugging profile installed. Checklist – Common Issues Verified Based on the Apple Pay In-App Provisioning demo guidance, we verified the following configuration items. Entitlements • com.apple.developer.payment-pass-provisioning enabled • Apple Pay capability enabled in Xcode • Correct Team ID and bundle configuration App configuration • PKAddPaymentPassViewController used for provisioning • PKAddPaymentPassViewControllerDelegate implemented • generateRequestWithCertificateChain implemented correctly Cryptographic data • encryptedPassData • activationData • ephemeralPublicKey All values are generated by our issuer backend and returned to the app Feedback ID: FB22249031 (In app provisioning error 500)

Hello everyone, We've encountered a blocking issue while integrating Apple Pay on the Web within a Salesforce Commerce Cloud (SFCC) environment. The session fails immediately after a successful user authentication. Problem Summary: After a user authenticates a payment with Touch ID or Face ID, the Apple Pay sheet showing error "Payment not completed" message. The core of the issue is that the onpaymentauthorized event handler is never invoked in our client-side JavaScript. As a result, the corresponding server-side SFCC paymentAuthorized hooks are never triggered, and we cannot obtain a payment token to complete the transaction. Also, No console logs are observed. Observed Flow of Events: The ApplePaySession proceeds correctly through the initial callbacks. We have verified through server-side logs that the corresponding SFCC platform hooks (getRequest, prepareBasket, shippingContactSelected, shippingMethodSelected) fire and complete successfully. The payment sheet correctly updates with shipping costs and the final transaction amount. Failure Point & Steps to Reproduce: A user initiates an Apple Pay transaction within our SFCC site. They select their shipping contact and method. The payment sheet updates the total amount. The user taps the "Pay" button and authenticates successfully via Touch ID / Face ID. Failure: The sheet immediately displays "Payment not completed" error. The onpaymentauthorized event is never fired on the client, and no paymentAuthorized calls reach our SFCC backend. We have confirmed this behavior is reproducible even when using the standard plugin_applepay provided by SFCC. There are no associated errors in the browser's JavaScript console or any server-side logs, as the process appears to fail within the native Apple Pay session before control is returned to our client-side code. Our Questions: Given this is occurring within an SFCC integration, we are trying to understand what could cause the session to terminate at this specific point. Are there internal validation checks that occur after successful user authentication but before the onpaymentauthorized event is dispatched? What configuration issues (e.g., in the ApplePayPaymentRequest, merchant identity certificate, etc.) are known to cause a failure at this exact step, especially within a platform integration like SFCC? Is there any additional client-side logging or debugging we can enable to get more insight into the internal state of the ApplePaySession? Any guidance from Apple engineers or other developers who have integrated Apple Pay with SFCC would be greatly appreciated. Thank you

Hello, I am investigating a case where two different transaction IDs appear to refer to the same purchase, and I would like clarification on whether this behavior is expected. Additional context StoreKit version: StoreKit 1 (SKPaymentTransaction) Environment: Production Product type: Auto-renewable subscription Transaction sources The values are obtained from the following APIs: transaction_id from SKPaymentTransaction https://developer.apple.com/documentation/storekit/skpaymentqueue receipt_data from the App Store receipt https://developer.apple.com/documentation/foundation/bundle/appstorereceipturl Observed behavior After an In-App Purchase completes, the app receives: a transaction_id from SKPaymentTransaction the corresponding receipt_data for the purchase When inspecting the receipt, the transaction_id inside latest_receipt_info differs from the transaction_id received directly from the purchase transaction. For clarity: A = transaction_id received from the purchase flow (SKPaymentTransaction) A' = transaction_id found in receipt_data.latest_receipt_info The two values are different, but they differ only by 1. Additional observation The original_transaction_id for A and A' is identical, which suggests that both transaction IDs belong to the same subscription purchase chain. Pattern observation on the ID difference We have observed that the difference between A and A' is consistently exactly 1 (i.e., A' = A + 1) across multiple transactions, not just a single case. This appears to be a reproducible pattern rather than a coincidence. This observation raises an additional question (Question 6 below). API verification When calling: GET /inApps/v1/transactions/{transactionId} Both A and A' return what appears to be the same purchase record. The response data is effectively identical except for the transactionId field. However, when calling: GET /inApps/v2/history/{transactionId} A does not appear in the transaction history only A' appears in the history response Questions If A does not appear in transaction history, where does this transaction ID originate from? Why does Get Transaction Info (/inApps/v1/transactions/{transactionId}) return a valid response for A even though it is not present in the transaction history? Why do A and A' both resolve to what appears to be the same purchase? In this situation, which transaction ID should be treated as the canonical transaction ID for server-side validation? Is this difference related to how StoreKit 1 (SKPaymentTransaction) and the App Store Server API represent transactions? Is the consistent off-by-one difference between the transaction_id from SKPaymentTransaction and the one recorded in latest_receipt_info an intentional behavior of StoreKit 1's internal transaction ID assignment? Specifically, we are wondering whether StoreKit 1 applies some form of internal offset when delivering the transaction ID to the client, while the App Store server records a different (adjacent) ID in the receipt. If so, is this documented anywhere? Note We are currently in the process of migrating to StoreKit 2, but this behavior was observed while investigating our existing StoreKit 1 implementation. Any clarification would help us better understand the correct transaction model during the migration.

I am developing an app used by public safety agencies. Part of the app is used to determine live agency staffing using geofences. For example, a geofence exists around a station, and when a user enters or exits that geofence, the app updates the staffing count at that station in real time. The issue I am having is reliably detecting when a user enters or exits the geofence while the app is killed (meaning the user force quit the app from the app launcher). I understand that iOS can relaunch an app in the background if the system terminated the process using Region Monitoring, but I haven't gotten a clear answer about whether or how this is possible if the user kills (force quits) the app. Thank you in advance for your assistance.

We are evaluating the new behavior mentioned in the Nearby Interaction documentation for iOS 18.4+, which states: “In iOS 18.4 and later, your app can continue ranging in the background with any supported device if the app starts a Live Activity as it goes to the background." Could you clarify what situations are considered “can continue ranging” versus cases where it will not continue? Specifically, if my app: starts a NISession in the foreground starts a Live Activity with that data then the app goes to background should the NI session still deliver ranging updates so the app can update the Live Activity? also, my app already enable Background Modes capability

While I welcome the arrival of a userspace implementation of drivers, DriverKit as it stands has some notable flaws. My main concern is the ability of open-source projects like HoRNDIS being able to access paid developer accounts and the limited entitlement scope (plus the waiting period) for what is essentially a hobbyist free project. Even if the developer is a professional company, some legacy hardware will go unsupported because of a lack of support from the vendor. Providing a way for users who need access to older hardware would be needed. Three concrete requests: A class-level or wildcard VID/PID entitlement for open source projects with a verifiable public repository A free or reduced-cost entitlement path for non-commercial volunteer-maintained drivers Published approval criteria and timelines so projects can plan accordingly Depreciating kexts without providing an accessible successor for community projects isn't security, it is gatekeeping access to hardware that is critically needed. Is this use case on the roadmap at all? Developers deserve a clear answer.

According to the release notes for macOS Tahoe 26.4 beta, a warning dialog should appear when launching apps that require Rosetta 2, informing users that these apps will stop working in a future macOS release. However, on my MacBook Air M1 running Tahoe 26.4 Beta 4 (25E5233c), no such warning appears when launching Intel (x86_64) apps. Test case: VLC media player Downloaded from the official VLC website: https://www.videolan.org/vlc/ Selected the Intel 64-bit version (vlc-3.0.21-intel64.dmg) Copied VLC.app to /Applications Code signature verified: Identifier: org.videolan.vlc Format: Mach-O thin (x86_64) Team ID: 75GAHG3SZQ Timestamp: June 2024 Flags: hardened runtime Notarization: accepted (Notarized Developer ID) spctl --assess --verbose /Applications/VLC.app → accepted, source=Notarized Developer ID Launched VLC.app — no Rosetta deprecation warning appeared System log findings: The following entry was repeated many times in the system log: Sandbox: oahd-helper deny(1) file-read-data /usr/libexec/rosetta/oahd-helper This suggests that oahd-helper is being blocked by the Sandbox from reading its own binary, which may be preventing the warning dialog from appearing. My questions: Is this a known bug in Beta 4? Does the absence of a warning mean the app will continue to work in macOS 28 and beyond? Should I file a Feedback report for this? Any insights would be appreciated. Thank you. Environment: Device: MacBook Air 2020 M1 OS: macOS Tahoe 26.4 Beta 4 (25E5233c) Test app: VLC 3.0.21 Intel 64-bit (org.videolan.vlc, Team ID: 75GAHG3SZQ) Source: https://www.videolan.org/vlc/

I'm running into a problem in my attempt to clear CKAssets on the iCloud server. The documentation for CKAsset says: If you no longer require an asset that’s on the server, you don’t delete it. Instead, orphan the asset by setting any fields that contain the asset to nil and then saving the record. CloudKit periodically deletes orphaned assets from the server. I'm deleting image file assets which are properties on an ImageReference type (largeImage and thumbNailImage properties). When I delete an image, I am setting those properties to nil and sending the record for the ImageReference to iCloud using the async CKDatabase.modifyRecords method. This always results in an error: <CKError 0x600000d92a60: "Asset File Not Found" (16/3002); "open error: 2 (No such file or directory)"> And of course the assets still appear in the CloudKit dashboard. What is the proper way of orphaning the assets on the CloudKit server?

We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: the user taps Stop in the Live Activity the system expires the task due to time expiration the task is terminated due to system resource pressure (CPU, memory, battery, etc.) other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? If so, is there any official or supported way for the app to distinguish between these reasons? For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device

We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: • the user taps Stop in the Live Activity • the system expires the task due to time expiration • the task is terminated due to system resource pressure (CPU, memory, battery, etc.) • other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: 1. In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? 2. If so, is there any official or supported way for the app to distinguish between these reasons? 3. For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? 4. If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device

I have a watchOS WidgetKit complication that needs the user's location to show the nearest transit station, but the widget never gets location permission and CLLocationManager times out. Setup: NSWidgetWantsLocation = YES in Widget Extension's Info.plist NSLocationWhenInUseUsageDescription and NSLocationAlwaysAndWhenInUseUsageDescription in Widget Extension's Info.plist Watch App successfully has location authorization Problem: The system never presents a location permission prompt for my widget. Apple's own World Clock widget does get one on watchOS (see screenshot) — I can't figure out what triggers it. When the widget tries to get location via CLLocationManager, the request times out and never returns a location. Questions: What triggers the system location prompt for a watchOS widget? Is NSWidgetWantsLocation sufficient or is something else required? Why would CLLocationManager time out and never return a location inside a widget extension? Is there a specific pattern required for requesting location in a WidgetKit timeline provider? Screenshots Sorry for swedish, but it says "Do you allow widgets from World Clock to use your location services?"

Hi everyone, We are currently working on improving our subscription backend integration with Apple’s App Store Server API and StoreKit, and had a few questions around StoreKit 1 vs StoreKit 2 behavior and server-to-server notifications. Looking for clarification on the following points: /inApps/v1/subscriptions/{originalTransactionId} response compatibility Does the App Store Server API endpoint /inApps/v1/subscriptions/{originalTransactionId} return consistent response structures for subscriptions created via StoreKit 1 and StoreKit 2, or are there any differences we should account for when parsing the response? Transaction format in S2S notifications for StoreKit 1 purchases If a user initially purchases a subscription using StoreKit 1, and the subscription renews later, what transaction format is sent in server-to-server notifications? Does Apple still maintain StoreKit 1 style transaction payloads, or Are they converted into StoreKit 2–style signed transactions? Validation of signedTransactionInfo and signedRenewalInfo In App Store Server Notifications V2, the payload includes signedTransactionInfo and signedRenewalInfo. Is there an official Apple API endpoint that can be used to validate these tokens? Offer / coupon identification from S2S notifications Can server-to-server notifications reliably indicate which offer was applied (intro offer, promotional offer, or offer code)? If yes, which fields in the transaction payload should be used to identify this? Trial period identification in StoreKit 2 In StoreKit 1, the field is_trial_period was commonly used to detect free trials. Since this is deprecated in StoreKit 2, which field or transaction property should be used to identify whether a purchase corresponds to a trial period?

I am building an automation using Shortcuts. The shortcut reads text from my Notes, sends it to Apple Intelligence, converts the result into dictionary values, and then saves those values into a Numbers sheet by adding rows through a form. The problem is that when the automation processes multiple lines and adds multiple rows, the Numbers app opens every time a row is added. I would like this process to run automatically at a scheduled time without opening the Numbers app repeatedly on my iPhone. Is there a way to update the Numbers sheet in the background without launching the Numbers app? Please let me know if there is a solution.

Hi, I’m building an iOS app called SocialLite using Apple’s Screen Time APIs, primarily FamilyControls and ManagedSettings. My goal is to block access to the Instagram app itself, while still allowing the user to receive and see Instagram notifications. Right now, when I apply the shield/block using the Screen Time API, the Instagram app is blocked as expected, but its notifications also appear to be blocked/suppressed at the same time. What I’m trying to achieve: Block the Instagram app from being opened Still allow Instagram notifications to come through normally Current behavior: The app is blocked Notifications are also blocked or no longer visible My question: Is there any supported way with Apple’s Screen Time API / ManagedSettings to shield or block an app while still allowing that app’s notifications? Or are app access and notifications tied together by design when a shield is applied? If this behavior is expected, I’d appreciate confirmation from Apple or guidance on whether there is another supported approach. Thanks.

Hello, Can someone please tell me why the unlock button was unresponsive when tapped? The restore button worked. if let price = store.product?.displayPrice { Text(price) .font(.title2.bold()) .padding(.top, 4) } Button { Task { await store.purchase() } } label: { ZStack { if store.isLoading { ProgressView() .tint(.white) } else { Text("paywall.buy") .font(.headline) } } .frame(maxWidth: .infinity) .padding() } .background(.blue) .foregroundStyle(.white) .clipShape(RoundedRectangle(cornerRadius: 14)) .disabled(store.product == nil || store.isLoading) Button { Task { await store.restorePurchases() } } label: { Text("paywall.restore") }

Hello, I'm trying to develop a driver that uses PCIe through the mac's thunderbold ports. I requested a PCI entitlement, and it's just an empty array in the entitlements file by default. I was wondering if the vendor ID submitted with my entitlement request is supposed to populate this dictionary? I'm currently getting an entitlement check failed from kernel: DK: IOUserServer and was unsure if the PCI entitlement configuration was incorrect. Default entitlement: <key>com.apple.developer.driverkit.transport.pci</key> <array> </array> I'd be happy to provide more information as needed, but any guidance would be much appreciated. Thanks in advance.

We already have an apple pay integration with a psp.
We have a merchant id with an identity certificate, a processing certificate and merchant domains. We are working to integrate an other psp. This psp have one csr (processing certificate) by customer. All the payment will be processed on the same domain. We have understood that it is not possible to have different processing certificates for a merchant id. So we can not reused our existing merchant id.

 On the other hand, it seems that it is not possible to have different merchant ids on the same domain (because of the domain verification). But all payments are processed on the same domain.

 Do you think there is a solution ?
Is there a recommended workaround for this scenario?

We are building an AI-powered smart glasses companion app, similar to Meta Ray-Ban. We want to provide true hands-free calling support. Right now, whenever the app tries to dial a native cellular call, iOS shows a confirmation screen that requires the user to tap to start the call. If the user always has to confirm/tap on the phone screen, there is no real point in using smart glasses for making calls. How can we initiate a native outgoing call without any confirmation dialog or extra tap, exactly like Siri does it, or like the Meta Ray-Ban glasses do when the user says “Hey Meta, call [name]” Please guide us on the correct APIs, entitlements, or integration path to achieve this behavior. Thank you.

I have a messaging app that has been working successfully for several years. It still works for most users, but about one month ago one of my users started experiencing issues receiving notifications. From my investigation, the user's Notification Service Extension (NSE) has not been triggered since they started reporting the issue. I was able to access the user's phone and connected it to the console to check for any logs related to the NSE being triggered or a push notification being received, but there were no relevant logs. I have already verified that notifications are enabled for the app and that Do Not Disturb is not active. I also tried sending a test notification using the CloudKit Console. The notification was successfully delivered to other push notification tokens, but it did not work for this specific device’s token. I have also confirmed that the push token on the server matches the one on the device and that it is being used with the APNs production environment. The issue for this user started in iOS version 26.2 and are still ongoing in version 26.3.1 . Has anyone encountered a similar issue or have suggestions on how to further diagnose this?