Hello, I am writing this because the behavior of the App Store Server Notification that our server receives is problematic in the Sandbox environment. I have two questions in total. When purchasing a Free Trial subscription, after receiving the SUBSCRIBED / INITAL_BUY Notification, DID_RENEW should be sent when it expires, but DID_FAIL_TO_RENEW/GRACE_PERIOD is sent. The EXPIRE Notification is sent after the subscription expires or DID_CHANGE_RENEWAL_STATUS/AUTO_RENEW_DISABLED is sent, but it does not arrive. The first problem is that I recently heard that automatic payments after a free trial require the user's consent via email. Is this the reason? If so, I am curious about how I can test it in the Sandbox environment. Is the second problem a bug?

I am building a widget with configurable options (dynamic option) where the options are pull from api (ultimately the options are return from a server, but during my development, the response is constructed on the fly from locally). Right now, I am able to display the widget and able to pull out the widget configuration screen where I can choose my config option . I am constantly having an issue where the loading the available options when selected a particular option (e.g. Category) and display them on the UI. Sometime, when I tap on the option "Category" and the loading indicator keeps spinning for while before it can populate the list of topics (return from methods in NewsCategoryQuery struct via fetchCategoriesFromAPI ). Notice that I already made my fetchCategoriesFromAPI call to return the result on the fly and however the widget configuration UI stills take a very long time to display the result. Even worst, the loading (loading indicator keep spinning) sometime will just kill itself after a while and my guess there are some time threshold where the widget extension or app intent is allow to run, not sure on this? My questions: How can I improve the loading time to populate the dynamic options in widget configuration via App Intent Here is my sample code for my current setup struct NewsFeedConfigurationIntent: AppIntent, WidgetConfigurationIntent { static let title: LocalizedStringResource = "Configure News Topic Options" static let description = IntentDescription("Select a topic for your news.") @Parameter(title: "Category", default: nil) var category: NewsCategory? } struct NewsCategory: AppEntity, Identifiable { let id: String let code: String let name: String static let typeDisplayRepresentation: TypeDisplayRepresentation = "News Topic" static let defaultQuery = NewsCategoryQuery() var displayRepresentation: DisplayRepresentation { DisplayRepresentation(title: LocalizedStringResource(stringLiteral: name)) } } struct NewsCategoryQuery: EntityQuery { func entities(for identifiers: [NewsCategory.ID]) async throws -> [NewsCategory] { let categories = fetchCategoriesFromAPI() return categories.filter { identifiers.contains($0.id) } } func suggestedEntities() async throws -> [NewsCategory] { fetchCategoriesFromAPI() } } func fetchCategoriesFromAPI() -> [NewsCategory] { let list = [ "TopicA", "TopicB", "TopicC", ....... ] return list.map { item in NewsCategory(id: item, code: item, name: item.capitalized) } }

I want to monitor again from the bellow function of DeviceActivityMonitorExtension. I have the function of startMonitoring like this. override func eventDidReachThreshold(_ event: DeviceActivityEvent.Name, activity: DeviceActivityName) { super.eventDidReachThreshold(event, activity: activity) startMonitoring() } public func startMonitoring() { let startTime = DateComponents(hour: 0, minute: 0, second: 0) let endTime = DateComponents(hour: 23, minute: 59, second: 59)//DateComponents(hour: 11, minute: 0, second: 0)// let schedule = DeviceActivitySchedule( intervalStart: startTime,//DateComponents(hour: 0, minute: 0, second: 0), intervalEnd: endTime, repeats: true //warningTime: DateComponents(minute:1) ) let selection: FamilyActivitySelection = savedSelection() ?? FamilyActivitySelection() let center = DeviceActivityCenter() let selections = self.savedSelection() ?? FamilyActivitySelection() let applications = selections.applicationTokens let categories = selections.categoryTokens let webCategories = selections.webDomainTokens let store = ManagedSettingsStore() store.shield.applicationCategories = ShieldSettings.ActivityCategoryPolicy.specific(categories, except: Set()) store.shield.applications = applications store.shield.webDomains = webCategories let scheduleHard = DeviceActivitySchedule( intervalStart: startTime,//DateComponents(hour: 0, minute: 0, second: 0), intervalEnd: endTime, repeats: true //warningTime: DateComponents(minute:1) ) let event = DeviceActivityEvent( applications: selection.applicationTokens, categories: selection.categoryTokens, webDomains: selection.webDomainTokens, threshold: DateComponents(minute: 0)//timeLimitToUseApp i.e for 15 mins ) do { try center.startMonitoring( .weekend, during: scheduleHard, events: [ .weekend: event, ] ) print("ScreenTime Monitoring Started") } catch let error { print(error.localizedDescription) } } Please provide us with a solution about starting monitoring from DeviceActivityMonitoringExtension's eventDidReachThreshold function or if there is any other way.

Platform and Version iOS Development Environment: Xcode 16.2.0, macOS 15.3 Run-time Configuration: iOS 18.3, 17.x Description of Problem We have started migrating some of the app’s core functionality over to App Intents. Our first release of App Intent support focused on two settings a user can modify on their Bose products, Audio Modes and Immersive Audio, giving users the ability to modify these settings via Siri and shortcuts. The implementation uses two separate shortcuts for each setting type, with each shortcut supporting a single phrase for Siri each: “Change my Bose mode to ” and “Change my Bose immersive audio to ”. Each shortcut uses their own App Intent, and each App Intent has support for optionally providing both a product and a setting when performing the intent. Failing to provide a device, which happens when the intent is performed via Siri, simply auto selects a currently connected Bose product. Failing to provide a setting, like in cases where a user says “Change my Bose ” without providing a setting will simply have Siri confirm the setting the user wants to change before changing the setting. We are using AppEntity to identify a Bose product for both App Intents. Because the App Intent for the Audio Modes setting has a larger number of supported values (up to 15 maximum), we are also using AppEntity to identify these settings. We are using AppEnum to identify available settings for the Immersive Audio App Intent, as only 3 static values are supported. Our original implementation of App Intent support had quite a few phrases supported for each shortcut. We had explicit support for direct synonyms of the verb “Change” in other phrases, supporting words like “Switch” and “Set”. We also had support for words that are like the word “Change”, but not directly related, like the word “Toggle” for instance. We also had support for phrases with or without the setting in each phrase. However, early on we had a lot of trouble with phrase detection with Siri. Siri had a hard time identifying what shortcut was being requested, as well as not being able to identify what settings the user was providing for the setting parameter of each App Intent. While researching potential fixes for this issue, we found a response to a thread in the Apple forums (https://developer.apple.com/forums/thread/759909) that seemed to indicate that Siri phrase recognition was very much an aggregate process. With the total number of phrases supported combined with the available settings for each phrase further compounding the total number of phrases Siri needs to learn to recognize for each shortcut. So, to hopefully improve Siri phrase detection, we added logic to limit the amount of Audio Mode settings supported based on what Audio Modes the user had setup on their Bose products. But, more importantly, we limited the number of explicit phrases supported for each shortcut to just a single phrase. In our testing, not only did this improve phrase recognition, but support for synonyms like “Set” or “Switch” seemed to implicitly still be recognized by Siri. The issues we ran into with Siri phrase detection above has us a bit concerned about scaling App Intent support to other settings and features for our products in the future. Our app supports the ability to modify a large number of settings on their Bose products, with support constantly expanding to new products as they are released. Our roadmap for App Intent support was initially very ambitious, supporting much more than just the two settings mentioned above. But our initial experience with App Intents has us tapering our expectations a little bit as far as how much can be supported in total for App Intents. One thing we also noticed is less than optimal display of default shortcuts in the Shortcuts app. The default shortcuts appeared like so, with shortcuts displayed based on available settings fro each shortcut: However, we could not find a way to indicate to users that one particular section pertained specifically to the Audio Mode setting and the other to the Immersive Audio setting. The only information the user has to make this determination for themselves is the available settings (or shortcuts) for each. This may not be immediately clear to a new customer who might be using one of our products for the first time. This display of default shortcuts in the Shortcuts app has us wondering if our shortcuts implementation is what is intended as far as support for the Shortcuts app is concerned. We did survey default shortcuts displayed by other third-party applications and they mostly dealt with navigation with a single section containing default options clearly indicating where the user can navigate with a shortcut. We couldn’t find an example of an application supporting the ability to change different setting types, with each setting type having their own available values for each. So, to summarize the questions we have concerning App Intent support: What can we do with our App Intents and Shortcuts implementation to guarantee optimal performance with Siri? What is an ideal number of phrases to support for each Shortcut. What limitations should we be placing as far as the total number of available settings for each Shortcut. Are there phrases that might work better than others for what we’re trying to achieve with App Intent support? i.e. Is “Change my Bose mode” or “Change my Bose immersive audio” a good phrase to use for this kind of functionality? Or should we be using different verbs or wording? Assuming optimal support of each Shortcut above. What is a reasonable expectation as far as how many different supported shortcuts we can scale to support at the same time. One issue we ran into early on was Siri confusing one shortcut with the other and triggering the wrong App Intent at times. While this was ultimately resolved, this outcome seems much more likely the greater the number of individual shortcuts supported. Are there any recommendations on how to display these App Intents to customers as far as default shortcuts in the Shortcuts app is concerned? Is what we currently display for default shortcuts in the Shortcuts app what was initially intended for third party support for App Intents? If what we are currently displaying is expected, would it be possible to support the ability to provide additional context to each section of default shortcuts displayed? We would like to indicate to the user that one set of shortcuts pertains to the Audio Modes settings, and the other to Immersive Audio. Something along the lines of a section header like some of the first-party apps use. Are there any recommendations or tips for supporting App Intents, particularly phrases for Siri, in other languages?

We're experiencing an issue with in-app purchases in our React Native iOS app where RNIap.getProducts() is consistently returning an empty array, preventing users from making purchases. Technical Details: Using react-native-iap library Product ID: '[REDACTED]' Platform: iOS Product Type: Consumable (one-time payment, NOT subscription) Error in logs: "No products returned from App Store. Check App Store Connect." Debugging shows: Products Fetched: [] Steps to Reproduce: Open app and navigate to the quiz feature Attempt to purchase additional quiz attempts Modal opens but fails to load product information What We've Confirmed: IAP Connection initializes successfully No error is thrown during product fetch, just an empty array returned App is configured with correct Bundle ID Using Apple Sandbox test account We are implementing consumable purchases (one-time payments) Potential Issues to Investigate: Product configuration in App Store Connect Ensure product is set as "Consumable" type in App Store Connect Sandbox tester account permissions/activation Bundle ID matching between app and App Store Connect Product ID case sensitivity or typos

Hi Guys, I am having an issue verifying a card when it is pending verification in the Apple Watch Wallet App and the iPhone Wallet. When the user verifies the card in the wallets, they are redirected to verification in my APP. However, the problem is that I don't know which application is calling, whether it is the Apple Watch or the iPhone, because the URL sends me the same serialNumber from the PKPASS. It is impossible to know if the user wants to verify and activate the card on the watch or the iPhone. Because I only receive the following information in the URL: myapp://app-url? passTypeldentifier=paymentpass.com.apple&action =verify&serialNumber=***** The serialNumber is the same from the iPhone Wallet and the Watch Wallet. func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool { let source = options[.sourceApplication] I try to retrieve the source, but it comes back null. It would be the only way to know the originating App. Can someone help me solve this problem?

We are experiencing an Unknown Error (error code 0) when testing purchases in the Apple Sandbox environment. The error does not occur every time, but it fails with an Unknown Error in approximately 8 out of 20 attempts. Due to this issue, our app is failing to pass Apple’s review. Issue Details This issue only occurs in the Apple Sandbox environment. After attempting a purchase, the Apple payment API returns SKPaymentTransaction Unknown Error. Returned error code: SKErrorUnknown (error.code 0). This problem is preventing us from conducting proper payment tests and getting approval from Apple. Would it be possible to receive support or any solutions for this issue?

I get crash reports which I can't reproduce when trying to present an SKStoreProductViewController : Fatal Exception: UIApplicationInvalidInterfaceOrientation Supported orientations has no common orientation with the application, and [SKStoreProductViewController shouldAutorotate] is returning YES No matter what app Deployment info orientation I try I can't get my SKStoreProductViewController shouldAutorotate property to return YES. It is always false. Does anyone knows why or how to get an SKStoreProductViewController to return shouldAutorotate YES?

I am able to block apps using FamilyControl and Shield. Unblocking is also simple—just assign nil to store.shield.applications. However, I want to unblock them even when the app is not open. Use case: Let's say the app allows users to create a session where a particular app is blocked for a specific duration. Once the session starts, the app should remain blocked, and as soon as the session time ends, it should automatically be unblocked. Please help me with this. Thank you!

Greetings, I recently submitted a request for the Location Push Service Extension Entitlement. Does anybody have insight into how long I would have to wait until Apple responds? Thanks

Hi team at Apple, here is a scenario we came across: The order of priority of payment methods in Apple Wallet follows: Credit Debit Apple Cash Our app displays a payment sheet that excludes credit cards. Instead of a debit card, the default payment option shown to the user on the payment sheet is Apple Cash. Is this a known issue or have we configured something wrong in our end?

I'm developing an iOS 18 app using Core Bluetooth on an iPhone 16 Pro to scan for BLE Extended Advertising packets. However, scanning behavior is inconsistent. Sometimes, the app detects extended advertising packets correctly, but other times, it fails to find them even when the advertiser is active. I tested using nRF Connect on both my iPhone 16 Pro and another Android device that I'm also developing an app for. The Android device consistently detects the extended advertising packets, but my iPhone 16 Pro has inconsistent results. Legacy advertising packets are scanned without any issues. The same peripheral is consistently detected on Android and other BLE scanners. I've tested with different scan settings, restarted Bluetooth, and rebooted the device, but the issue persists. Does iOS 18 have any known limitations with BLE Extended Advertising? Any workarounds to improve scanning reliability?

Is there any way I can get updates when I change CarPlay style settings? I've tried CPSessionConfigurationDelegate.contentStyleChanged and CPTemplateApplicationSceneDelegate.contentStyleDidChange, but they always produce the same result. When I choose: Automatic -> I receive light in case of daylight; Always Dark and Always Show Dark Map toggle on -> dark Always Dark and Always Show Dark Map toggle off -> light. But it seems to be wrong, b/c CarPlay's toolbar is still dark, and I receive light. Is there a way to get a dark style when choosing Always Dark and Always Show Dark Map toggle off? Or at least get updates when the Always Show Dark Map toggle changes?

on a span of 4 months we sent 2 for nfc entitlement requests and refused , no reason nothing . i mean all we want is the ability to use nfc on passes nothing else , no idea why this is so complex . with google you don’t even need a developer account and it’s for free , here we pay and we can’t even get the full functionality the passes offer , we got the hardware and the solution but we find out we need an nfc entitlement to allow passes to have nfc ? i mean our use case is very simple instead of having barcode on the passes we want them to be via nfc and we already got the nfc hardware but we find out we need nfc entitlement which we tried requesting but getting refused with no reason at all. at least tell u what is the problem what how to fix it not outright refuse without any reason at all. if anyone got any solution please provide.

Hi, I'm working on a game for the past few years using first Unreal Engine 4, and now Unreal Engine 5.4.4. I'm experiencingan unusual crash on startup on some devices . The crash is so fast that I'm barely able to see the launching screen sometimes because the app closes itself before that. I got a EXC_CRASH (SIGABRT) so I know that it's a null pointer reference, but I can't quite wrap my head about the cause, I think that's something messed up in the packaging of the app, but here is where I'm blocked, I'm not that accustomed with apple devices. If someone has some advise to give, please, any help will be very valuable. Many thanks. Log : Crash Log on Ipad

I'm developing an iPad app and encountered a strange issue with external Bluetooth keyboards. Issue: I have a Bluetooth keyboard set to JIS layout in Settings > General > Keyboard > Hardware Keyboard > Keyboard Type. If I connect the keyboard before launching the app, everything works fine, and the input follows the JIS layout. However, if I launch the app first and then turn on the Bluetooth keyboard, the input behaves as if the keyboard is in ANSI layout, even though the settings still show JIS. It seems like iPadOS defaults to ANSI if no external keyboard is connected when the app starts, and later connections do not update the layout properly. Has anyone encountered a similar issue, and is there a programmatic way to ensure that the correct keyboard layout is applied after the keyboard is connected? Any help or insights would be greatly appreciated!

I cannot test IAP using sandbox account that I logged on from settings, it keeps show my regular Apple ID when I try to test IAP from TestFlight This issue frustrate me and bunch of my colleagues, we cannot manage our subscription when sandbox account is default choosing Apple ID I've seen people complaining about this issue a lot Any help on resolving this issue would be really appreaciated

Hello, I am unable to figure out how I tell the FamilyActivityPicker whether it should show apps installed on my personal device (to be used with AuthorizationCenter.shared.requestAuthorization(for: .individual)) or apps installed on my child’s device (authenticated their phone via AuthorizationCenter.shared.requestAuthorization(for: .child)). Is there any parameter or SwiftUI modifier I need to apply? Otherwise, how does the user or the app know which token belongs to them and which token belongs to their child’s device? Radar: FB17020977 Thanks a lot for your help!

I have implemented the functionality to open my app when double-tapping the side button on an iPhone. However, whenever I double-tap the side button, my app always opens on the login screen. Instead of this default behavior, I want my app to navigate directly to a specific view when launched through the side button action. I am using SwiftUI and have already integrated HCE (Host Card Emulation) entitlements and also configured with contactless payment. How can I achieve this behaviour so that my app opens a specific screen instead of always showing the login page? Any guidance on handling this within SwiftUI would be greatly appreciated. Thank you!

Hello everyone, We're implementing Apple Pay on the web and are already live, processing transactions. However, we've noticed that occasionally the onlinePaymentCryptogram returned in the paymentData contains spaces, causing it to be rejected by acquirers. Has anyone else encountered this issue? Any insights would be greatly appreciated.