Hello, I’m experiencing a strange issue with a newly created Subscription Group in my iOS app. For all my existing subscription groups, everything works perfectly — initial purchase, renewals, cancellations, all notifications arrive normally. But for this one newly created group, the first purchase never triggers any server notification from App Store Server Notifications (ASSN). ⸻ 📘 Problem Summary • I created a new Subscription Group in App Store Connect. • The products are all Approved and Published for over a week. • Users can successfully purchase the subscription in production. • The purchase is shown as Purchased in the App Store purchase UI. • The receipt can be fetched locally on device. • But my server receives no notifications, including: • DID_RENEW • DID_CHANGE_RENEWAL_STATUS • SUBSCRIBED • ONE_TIME_CHARGE • CONSUMPTION_REQUEST • etc. The old subscription groups still send notifications normally, so the notification URL and server infrastructure are correct.

Honestly, don't know how to test it in sandbox. I'm confused on if I need a sandbox to actually test out my in app purchase. Do I need to download something? Someone please help.

We have an app in Swift that uses push notifications. It has a deployment target of iOS 15.0 I originally audited our app for iOS 26 by building it with Xcode 26 beta 3. At that point, all was well. Our implementation of application:didRegisterForRemoteNotificationsWithDeviceToken was called. But when rebuilding the app with beta 4, 5 and now 6, that function is no longer being called. I created a simple test case by creating a default iOS app project, then performing these additional steps: Set bundle ID to our app's ID Add the Push Notifications capability Add in application:didRegisterForRemoteNotificationsWithDeviceToken: with a print("HERE") just to set a breakpoint. Added the following code inside application:didFinishLaunchingWithOptions: along with setting a breakpoint on the registerForRemoteNotifications line: UNUserNotificationCenter.current().requestAuthorization(options: [.badge, .alert, .sound]) { granted, _ in DispatchQueue.main.async { UIApplication.shared.registerForRemoteNotifications() } } Building and running with Xcode 26 beta 6 (17A5305f) generates these two different outcomes based upon the OS running in the Simulator: iPhone 16 Pro simulator running iOS 18.4 - both breakpoints are reached iPhone 16 Pro simulator running iOS 26 - only the breakpoint on UIApplication.shared.registerForRemoteNotifications is reached. Assuming this is a bug in iOS 26. Or, is there something additional we now need to do to get push notifications working?

I just saw another post regarding bookmarks on iOS where an Apple engineer made the following statement: [quote='855165022, DTS Engineer, /thread/797469?answerId=855165022#855165022'] macOS is better at enforcing the "right" behavior, so code that works there will generally work on iOS. [/quote] So I went back to my macOS code to double-check. Sure enough, the following statement: let bookmark = try url.bookmarkData(options: .withSecurityScope) fails 100% of the time. I had seen earlier statements from other DTS Engineers recommending that any use of a URL be bracketed by start/stopAccessingSecurityScopedResource. And that makes a lot of sense. If "start" returns true, then call stop. But if start returns false, then it isn't needed, so don't call stop. No harm, no foul. But what's confusing is this other, directly-related API where a security-scoped bookmark cannot be created under any circumstances because of the URL itself, some specific way the URL was initially created, and/or manipulated? So, what I'm asking is if someone could elaborate on what would cause a failure to create a security-scoped bookmark? What kinds of URLs are valid for creation of security-scoped bookmarks? Are there operations on a URL that will then cause a failure to create a security-scoped bookmark? Is it allowed to pass the URL and/or bookmark back and forth between Objective-C and Swift? I'm developing a new macOS app for release in the Mac App Store. I'm initially getting my URL from an NSOpenPanel. Then I store it in a SQLite database. I may access the URL again, after a restart, or after a year. I have a login item that also needs to read the database and access the URL. I have additional complications as well, but they don't really matter. Before I get to any of that, I get a whole volume URL from an NSOpen panel in Swift, then, almost immediately, attempt to create a security-scoped bookmark. I cannot. I've tried many different combinations of options and flows of operation, but obviously not all. I think this started happening with macOS 26, but that doesn't really matter. If this is new behaviour in macOS 26, then I must live with it. My particular use requires a URL to a whole volume. Because of this, I don't actually seem to need a security-scoped bookmark at all. So I think I might simply get lucky for now. But this still bothers me. I don't really like being lucky. I'd rather be right. I have other apps in development where this could be a bigger problem. It seems like I will need completely separate URL handling logic based on the type of URL the user selects. And what of document-scoped URLs? This experience seems to strongly indicate that security-scoped URLs should only ever be document-scoped. I think in some of my debugging efforts I tried document-scoped URLs. They didn't fix the problem, but they seemed to make the entire process more straightforward and transparent. Can a single metadata-hosting file host multiple security-scoped bookmarks? Or should I have a separate one for each bookmark? But the essence of my question is that this is supposed to be simple operation that, in certain cases, is a guaranteed failure. There are a mind-bogglingly large number of potential options and logic flows. Does there exist a set of options and logic flows for which the user can select a URL, any URL, with the explicit intent to persist it, and that my app can save, share with helper apps, and have it all work normally after restart?

I want to detect if the adapter is connected to the iPhone even if no IP has been given to the iPhone. I can detect that the interface is connected when the iPhone has been given an IP address, but how can I detect the adapter when not?

After reading the news below, we are currently working on updating our app in preparation for the enforcement of Texas SB 2420. https://developer.apple.com/news/?id=2ezb6jhj Based on the information in the announcement, we understand that parents will be able to revoke their consent for apps. However, we are unsure how an app is supposed to obtain or verify the parent’s consent status in the first place. We reviewed the Declared Age Range API and PermissionKit’s Significant Change API, but could not find any functionality related to this. If anyone with expertise on this topic has insight, we would greatly appreciate your guidance. Thank you in advance.

We attempted to run a burn-in test while connected to our MacBook Pro M4 Max, but this crashed about 10 minutes into testing. Can Action Star see if you are able to run a 2-hour burn-in on your own M4 Max host while charging the battery from below 5%, running six bus-powered drives (via ATTO/Black Magic/IOmeter), hitting the RJ45 port for 2.5Gbps (via JPerf), and streaming at least 4K60Hz video content to two displays? Please measure the outer temperature on the hottest part of the enclosure as well.

We are facing a DNS resolution issue with a specific ISP, where our domain name does not resolve correctly using the system DNS. However, the same domain works as expected when a custom DNS resolver is used. On Android, this is straightforward to handle by configuring a custom DNS implementation using OkHttp / Retrofit. I am trying to implement a functionally equivalent solution in native iOS (Swift / SwiftUI). **Android Reference (Working Behavior) : ** val dns = DnsOverHttps.Builder() .client(OkHttpClient()) .url("https://cloudflare-dns.com/dns-query".toHttpUrl()) .bootstrapDnsHosts(InetAddress.getByName("1.1.1.1")).build() OkHttpClient.Builder().dns(dns).build() **Attempted iOS Approach ** I attempted the following approach : Resolve the domain to an IP address programmatically (using DNS over HTTPS) Connect directly to the resolved IP address Set the original domain in the Host HTTP header **DNS Resolution via DoH : ** func resolveDomain(domain: String) async throws -> String { guard let url = URL( string: "https://cloudflare-dns.com/dns-query?name=\(domain)&type=A" ) else { throw URLError(.badURL) } var request = URLRequest(url: url) request.setValue("application/dns-json", forHTTPHeaderField: "accept") let (data, _) = try await URLSession.shared.data(for: request) let response = try JSONDecoder().decode(DNSResponse.self, from: data) guard let ip = response.Answer?.first?.data else { throw URLError(.cannotFindHost) } return ip } **API Call Using Resolved IP : ** func callAPIUsingCustomDNS() async throws { let ip = try await resolveDomain(domain: "example.com") guard let url = URL(string: "https://\(ip)") else { throw URLError(.badURL) } let configuration = URLSessionConfiguration.ephemeral let session = URLSession( configuration: configuration, delegate: CustomURLSessionDelegate(originalHost: "example.com"), delegateQueue: .main ) var request = URLRequest(url: url) request.setValue("example.com", forHTTPHeaderField: "Host") let (_, response) = try await session.data(for: request) print("Success: \(response)") } **Problem Encountered ** When connecting via the IP address, the TLS handshake fails with the following error: Error Domain=NSURLErrorDomain Code=-1200 "A TLS error caused the secure connection to fail." This appears to happen because iOS sends the IP address as the Server Name Indication (SNI) during the TLS handshake, while the server’s certificate is issued for the domain name. **Custom URLSessionDelegate Attempt : ** class CustomURLSessionDelegate: NSObject, URLSessionDelegate { let originalHost: String init(originalHost: String) { self.originalHost = originalHost } func urlSession( _ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void ) { guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust, let serverTrust = challenge.protectionSpace.serverTrust else { completionHandler(.performDefaultHandling, nil) return } let sslPolicy = SecPolicyCreateSSL(true, originalHost as CFString) let basicPolicy = SecPolicyCreateBasicX509() SecTrustSetPolicies(serverTrust, [sslPolicy, basicPolicy] as CFArray) var error: CFError? if SecTrustEvaluateWithError(serverTrust, &error) { completionHandler(.useCredential, URLCredential(trust: serverTrust)) } else { completionHandler(.cancelAuthenticationChallenge, nil) } } } However, TLS validation still fails because the SNI remains the IP address, not the domain. I would appreciate guidance on the supported and App Store–compliant way to handle ISP-specific DNS resolution issues on iOS. If custom DNS or SNI configuration is not supported, what alternative architectural approaches are recommended by Apple?

As per the US state law including SB2420 in Texas. We are suppose to meet their compliance. We have following queries Could you please confirm whether the provided Declared Age Range API framework is available for sandbox testing How does the API respond for a region other than Texas

We tested call blocking on iOS 26 and noticed something strange: the call will not be blocked if an outgoing call was made to its number before. Nevertheless, it will be blocked if we delete the outgoing call record from the Phone.app Recents. This behavior looks like a bug and is unexpected when using our application. Was this a planned callkit change in iOS 26? Is it possible to get the correct call blocking behavior back? We set blocking rules with addBlockingEntry(withNextSequentialPhoneNumber:) and this problem is not present in iOS 18 and earlier. Thank you in advance

Hello, I have an app that was using the iOS 18 Network Framework APIs. It used Peer to Peer, QUIC and Bonjour. It was all working as expected. I wanted to upgrade to the new iOS 26 Network Framework APIs (NetworkBrowser, NetworkListener, NetworkConnection...). I have things working (multiple devices can discover each other, connection to each other and send messages to each other) but my app crashes when I go to toggle of all the networking stuff. In the iOS 18 Network Framework API NWConnection had a .cancel() function I could use to tell the other side the connection was done. I dont see a cancel function for NetworkConnection. My question is - how do I properly close down a NetworkConnection and also properly tell the other side the connection is done.

On my iPhone 16 Pro and iPhone 16 Pro Max devices, running iOS 26.0, 26.0.1, and 26.1, Wi-Fi raw socket communication works flawlessly. Even after keeping the connection active for over 40 minutes, there are no disconnections during data transmission. However, on the iPhone 17 and iPhone 17 Pro, the raw socket connection drops within 20 seconds. Once it disconnects, the socket cannot reconnect unless the Wi-Fi module itself is reset. I believe this issue is caused by a bug in the iPhone 17 series’ communication module. I have looked into many cases, and it appears to be related to a bug in the N1 chipset. Are there any possible solutions or workarounds for this issue?

I am developing a running training app that coaches can use to create interval workout plans. I can use HKWorkout to get information about Splits similar to that in Fitness app, but I can't get information about Intervals. My idea is to show interval details when users view their completed custom interval workout plans. Can I use Healthkit (or another feasible method) to get the actual distance or time of exercise in intervals workout ? (I know the workoutPlan property, but it doesn't reflect the segments of a real interval training workout.) Any insights or suggestions would be greatly appreciated! Thanks in advance!

Hello, I am developing with the Nearby Interaction framework using third-party UWB accessories (Murata SR040/SR150). I observed a difference between U1-based and U2-based iPhones: iPhone 12 Pro (U1 chip) NINearbyObject.direction returns valid 3D vector (x, y, z). Distance and direction both work as expected. iPhone 15 Pro and iPhone 16 Pro (U2 chip) NINearbyObject.direction is always nil. Only distance is returned (around 0.35–0.40 m in my test). Effectively behaves as "distance-only mode". Environment: Hardware: iPhone 12 Pro, iPhone 15 Pro iOS version: 18.5 Accessory: Murata UWB SR040 / SR150 App: Using NINearbyAccessoryConfiguration with BLE-based discovery Info.plist includes NSNearbyInteractionUsageDescription Camera assistance was tested both ON and OFF Expectation: I expected the U2 chip to behave consistently with U1, i.e. provide direction vectors when possible. Instead, on iPhone 15 Pro, direction is always unavailable (nil) while distance is returned correctly. Questions: Is this an intentional limitation for U2 chip + third-party accessories? Is there a new requirement (e.g. certification, firmware update, capability flags) to enable direction on U2 devices? Could this be related to NIDeviceCapability or the new Extended Distance Measurement (EDM) mode in U2? Thanks in advance for any clarification.

Hi, I am experiencing an issue where my in-app purchase products cannot be fetched from App Store Connect during sandbox testing, despite all products being properly configured. ERROR MESSAGE: When testing on a physical iOS device, I receive the following error: "Error fetching offerings - The operation couldn't be completed. (RevenueCat.OfferingsManager.Error error 1.) There's a problem with your configuration. None of the products registered in the RevenueCat dashboard could be fetched from App Store Connect (or the StoreKit Configuration file if one is being used)." All products show status "READY_TO_SUBMIT" with the warning: "This product's status (READY_TO_SUBMIT) requires you to take action in App Store Connect before using it in production purchases." I have 2 subscriptions and 4 Consumable in-app purchases set up in App Store Connect. VERIFICATION COMPLETED: Bundle ID matches exactly in App Store Connect, Xcode project, and RevenueCat dashboard Product IDs match exactly between App Store Connect, RevenueCat, and application code Paid Applications Agreement is signed and active (Signed on 12/9 morning, everything shows as active) All products are in "Ready to Submit" status with complete metadata All products are properly linked to the app in App Store Connect Testing on physical iOS device (not simulator) with sandbox account signed in via Settings > Developer section Products have been in "Ready to Submit" status for 8 hours I have researched this error and verified the common causes (Paid Agreements, Product ID mismatches, Bundle ID mismatches) are all correctly configured on my end. QUESTION: Is this an issue on Apple's end, or are there additional requirements for products in "Ready to Submit" status to be available in sandbox testing? I have been unable to test my in-app purchases despite all configuration appearing correct. Thank you for your assistance.

I have a watch only app that display an open/close park status and the current temperature with a current condition icon. That's it. On second submission the watch app was rejected due to no WeatherKit attribution. I have a lack of clarity of what's needed. With my single view that display my content I don't want WeatherKit attribution to overwhelm what's being presented to the user. I've tried looking for watch apps in the store that provide attribution and I'm not finding any. Looking for advice on how to meet this requirement without attribution overpowering my content.

Hi everyone, I’m currently experimenting with App Intents and I’m trying to customize the section titles that appear at the top of groups of intents inside the Shortcuts app UI. For example, in the Phone shortcut, there are built-in sections such as “Call Favorite Contacts” and “Call Recent Contacts” (see screenshot attached). Apple’s own system apps such as Phone, Notes, and FaceTime seem to have fully custom section headers inside Shortcuts with icon. My question is: 👉 Is there an API available that allows third-party apps to define these titles (or sections) programmatically? I went through the AppIntents and Shortcuts documentation but couldn’t find anything. From what I can tell, this might be private / Apple-only behavior, but I’d be happy to know if anybody has found a supported solution or a recommended alternative. Has anyone dealt with this before? Thanks! Mickaël 🇫🇷

I'm trying to test the update process for an app containing an FSKit module that I'm distributing on the Mac App Store. (I'm also distributing the same app directly with Developer ID, but here I'll focus on App Store because that's the behavior I've been looking at first.) To do that I'm using an internal tester group on TestFlight and then testing an update with TestFlight. Below is the behavior I'm seeing on macOS 15.7.2 (24G325). I've noticed that if an app update is triggered while a disk is mounted using the FSKit extension, the disk is automatically unmounted without warning (FB21287341). That's already undesirable itself in my opinion, but on top of the unmount, there are two other problems: That unmount doesn't seem to be a "clean" unmount and doesn't call functions like synchronize (FB21287688). Now, in my case, my app only provides read-only access, so that doesn't actually matter much in my case. However, I'd imagine if I were to add write access at some point in the future, this would go from "doesn't matter" to "very bad." I've seen a few cases where quitting or crashing the FSModule process while a volume is mounted without actually doing a clean unmount causes a lot of "disk-related actions" (for lack of a better term) to freeze (FB21305906). For example, a use of the mount(8) command or trying to mount a disk at all freezes, and opening Disk Utility stalls on a "Loading disks" spinning indicator. This happens until the Mac is rebooted. I did notice this issue once while testing updates via TestFlight a few times. The same applies if I simply delete the app with Finder instead of updating it. Is there a way to prevent the extension's process from terminating in this case and/or another workaround I could use without waiting for a macOS update to hopefully change this behavior? And does observing this kind of behavior with TestFlight's update behavior suggest the same thing could happen on the App Store with its automatic updates? I'm concerned that pushing an update via the App Store will unexpectedly unmount disks or cause the system-wide issues described in FB21305906 at a random time, which is a pretty big disruption for users.

If I have two iOS apps, with bundle ids com.mycompany.A and com.mycompany.B, and they both have the shared group id of group.com.mycompany.B, then they can read/write data to same file (in shared defaults or, for example, a Realm database saved to the same shared group location). What I have noticed is that if both apps get installed and some data X written to shared defaults (but data which isn't accessed by both apps i.e. if only app A uses this data), then if app A is deleted and reinstalled then X is not deleted in this situation (unless both apps A and B are deleted). I guess that is to be expected as they both use the same group id and the OS won't clear that area out unless both apps are deleted. However I think I am seeing a situation where if app A has group.com.mycompany.A as its group and app B has group.com.mycompany.B as its group, then this is still the same situation - data written by app B for doesn't get deleted if only app B is deleted/reinstalled on the phone. It won't get deleted unless both app B and A are deleted from the phone. This is not what I was expecting. I need to perform some more checks (its more complex to verify as app A is developed by one company and app B by another), but if this were to be the case would this be unexpected behavior by the OS? Presumably it would be unexpected as the container should be identified by the full group id and not a partial portion of the group id right?

We're developing an Electron app for MacOS App Store. When updating our app through TestFlight, TestFlight prompts "Close This App to Update", and when I click "Continue" our app would be "Terminated" for update. Now this is where things go wrong. On MacOS 15 our app seems to be gracefully terminating (We attached it with lldb and it shows that our app returns with 0 when we click "Continue") which is fine. However for MacOS 26 though, it seems that TestFlight just directly SIGKILLs our app (indicated by lldb), which means that all of our app's child processes are left orphaned. Even worse, our app is singleton, which means that when the app relaunches it fails, because the leftover child processes from the previously SIGKILLed session is still alive, and even if we want to kill those orphaned child processes we can't because our app is sandboxed thus cannot kill processes outside of the current sandbox. We captured output from log stream (app name redacted): 12-02 22:08:16.477036-0800 0x5452     Default     0x5a4a7              677    7    installcoordinationd: [com.apple.installcoordination:daemon] -[IXSCoordinatorProgress setTotalUnitsCompleted:]: Progress for coordinator: [com.our.app/Invalid/[user-defined//Applications/OurApp.app]], Phase: IXCoordinatorProgressPhaseLoading, Percentage: 99.454 123: Attempt to set units completed on finished progress: 214095161 2025-12-02 22:08:16.483056-0800 0x53ba     Default     0x5a5c9              167    0    runningboardd: (RunningBoard) [com.apple.runningboard:connection] Received termination request from [osservice<com.apple.installcoordinationd(274)>:677] on <RBSProcessPredicate <RBSProcessBundleIdentifierPredicate "com.our.app">> with context <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N re portType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:08:16.488651-0800 0x53ba     Default     0x5a5c9              167    7    runningboardd: (RunningBoard) [com.apple.runningboard:ttl] Acquiring assertion targeting system from originator [osservice<com.apple.installcoordinationd(274)>:677] with description <RBSAssertionDescriptor| "installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N" ID:167-677-1463 target:system attributes:[ 2025-12-02 22:08:16.489353-0800 0x53ba     Default     0x5a5c9              167    0    runningboardd: (RunningBoard) [com.apple.runningboard:process] [app<application.com.our.app.485547.485561(501)>:2470] Terminating with context: <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N reportType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:10:23.920869-0800 0x5a5a     Default     0x5a4c6              674    14   appstoreagent: [com.apple.appstored:Library] [A95D57D7] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:32.027304-0800 0x5ae5     Default     0x5a4c7              674    14   appstoreagent: [com.apple.appstored:Library] [BEB5F2FD] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:36.542321-0800 0x5b81     Default     0x5a4c8              674    14   appstoreagent: [com.apple.appstored:Library] [185B9DD6] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} The line "Terminating with context" seems suspicious. This line is not seen on MacOS 15, only MacOS 26. Is this documented behavior? If so, how can we handle this?