Hi everyone, I'm Alexsander. My friends call me Lexie. I have been working as software developer since 6 years ago, I have a lot of experience with Java and I started working with Angular since the last year. I am new in the Apple ecosystem and I have a question about best practices in full native Swift apps. There is any source (blogs, youtube channels, books, et al.) where I can understand the best practices? Like, I've heard about MVVM to scalable apps but I don't know exactly how to apply it. I think it's because usually I do not have my front-end components in the same project of my backend. I've been watching some videos from Apple Developer youtube channel and they are absolutely amazing, but they only keep teaching people to use the "raw" resources, not matching with the best practices. For example, I saw using swift data we do not need to write any SQL Query, unlike Java Ecossystem where even we use a ORM we usually write our queries natively, whether creating a table or fetching data.

Our app sells two auto-renewable subscriptions. Product loading succeeds and returns both products with correct localized prices, but every purchase attempt fails roughly one second later with "Item Unavailable". No purchase sheet is ever presented to the user. The app has not yet passed its first App Review. It was rejected under Guideline 2.1(b) because the reviewer encountered this same error on their device. MY QUESTION Under what conditions does StoreKit reject a purchase with "Item Unavailable" for a product that has just been returned successfully, with a valid localized price, by a product request? Is an auto-renewable subscription transactable in the sandbox environment for an app that has never had a binary approved by App Review? Question 2 is the one I most need answered. App Review's rejection states that In-App Purchase products "do not need prior approval to function in review", but neither we nor the reviewer can transact them. DIAGNOSTIC LOG Captured on-device during a failing session: 01:08:56 fetchProducts [com.aurascanner.app.pro.weekly, com.aurascanner.app.pro.annual] 01:08:56 fetchProducts -> 2 product(s): com.aurascanner.app.pro.annual=$39.99; com.aurascanner.app.pro.weekly=$6.99 01:08:56 requestPurchase sku=com.aurascanner.app.pro.weekly 01:08:57 purchaseError: code=purchase-error msg=Item Unavailable 01:08:57 error code=purchase-error, storefront=USA 01:09:05 fetchProducts -> 2 product(s), same prices returned again 01:09:05 requestPurchase sku=com.aurascanner.app.pro.annual 01:09:06 requestPurchase threw: Item Unavailable 01:09:06 error code=purchase-error, storefront=USA An introductory-offer eligibility check earlier in the session also succeeded, using the subscription group ID read from the loaded product. So product metadata, including the subscription group, resolves correctly. CONDITIONS Fails identically for both products, on every attempt. Reproduces in TestFlight on our own devices and Apple IDs. Also failed during App Review on iPad Air 11-inch (M3), iPadOS 26.5.2. Storefront reports as USA in every case. Real devices only. Not reproduced on Simulator. ALREADY VERIFIED Paid Applications Agreement: Active, banking and tax information complete. In-App Purchase capability: enabled on the App ID at Certificates, Identifiers & Profiles. Bundle identifier com.aurascanner.app matches the App Store Connect record. Both subscriptions: complete metadata, review screenshots uploaded, USD pricing set, United States availability. Both subscriptions and the subscription group are attached to the current submission, status "Ready for Review". Subscription group has a localized display name. Build distributed via TestFlight, which routes purchases to sandbox automatically. IMPLEMENTATION The app is React Native and uses a wrapper library over StoreKit 2, but the error text originates from StoreKit rather than the wrapper, and the call order follows the documented pattern: Initialize the StoreKit connection. Load products. This succeeds and returns both products. Register transaction update and error listeners. Request the purchase. This is where it fails. Purchases are verified server-side using Apple's App Store Server Library, and the transaction is finished only after verification succeeds. I am not asking anyone to debug the wrapper. My question is about StoreKit and App Store behaviour: what causes the store to quote a product and then decline to sell it? Any pointers appreciated. I can supply screenshots or the full log.

We submitted Live Caller ID Lookup requests for two apps and both remain “In Review.” Our PIR server, Privacy Pass issuer and OHTTP gateway are deployed, DNS TXT records are published for both bundle identifiers, and the test number returns correctly. Is there a way to verify from our side that Apple’s automated endpoint validation passes? Any common misconfiguration that causes a request to sit without feedback?

Beginning July 29, 2026, we noticed a higher number of error responses from api.sandbox.push.apple.com: http2: server sent GOAWAY and closed the connection; LastStreamID=2147483647; ErrCode=PROTOCOL_ERROR; debug="Stream 3 does not exist for inbound frame DATA, endOfStream = true" The errors: Occur across multiple independent applications and regions. Are concentrated on the APNs sandbox endpoint. Did not coincide with a deployment or configuration change in our service. Were not accompanied by other typical failures such as 400 BadDeviceToken. Also increased on the APNs production endpoint, though the large majority remain concentrated on the sandbox endpoint. Could Apple confirm whether APNs recently changed how notification requests are validated or rejected, particularly in the sandbox environment? We can provide exact UTC timestamps, source regions, request metadata, and logs privately if needed.

Environment macOS 14+ (Sonoma), Apple Silicon Background LaunchAgent installed at /Applications/.app, launched by a plist in /Library/LaunchAgents. LSUIElement = true (no Dock icon). Signed with a Developer ID Application certificate, hardened runtime, secure timestamp. Notarized. No provisioning profile embedded. Distributed outside the App Store (signed .pkg installer). Info.plist keys present in the installed bundle: NSLocationUsageDescription NSLocationWhenInUseUsageDescription NSLocationAlwaysAndWhenInUseUsageDescription Entitlements file: empty (I removed com.apple.developer.* entitlements because they require a provisioning profile that Developer ID distribution cannot ship.) What I need CoreWLAN's scanForNetworks(withSSID:) returns entries with nil ssid / nil bssid on macOS 14+ unless the process has Location authorization. I'm trying to obtain that authorization from the LaunchAgent so I can populate SSID/BSSID for a connectivity report. What I'm doing Instantiating CLLocationManager on the main thread (verified via Thread.isMainThread) from an NSApplication.shared.run() runloop. Setting a CLLocationManagerDelegate. Calling requestWhenInUseAuthorization(), requestAlwaysAuthorization(), and startUpdatingLocation(). Observed behavior No authorization prompt is ever displayed. authorizationStatus stays at .notDetermined across launches. locationManager(_:didFailWithError:) fires with kCLErrorDomain error 1 (kCLErrorDenied). System Settings → Privacy & Security → Location Services lists the app and its toggle can be flipped ON, yet the process still reads authorizationStatus == .notDetermined immediately after and on subsequent launches. locationd logs (Console) around the same time show: "#Warning #ClientResolution the passed keyPath is not registered. Resolving to #nullCKP" Things I've already tried Verified Info.plist keys are embedded in the installed bundle (defaults read /Applications/<app>/Contents/Info.plist). Verified codesign is valid and entitlements are preserved on install (codesign -d --entitlements - /Applications/<app>). tccutil reset All <bundle-id> and full reboot. Uninstall + reinstall. Toggling Location Services OFF and back ON, both globally and per-app. Ensuring all CLLocationManager interaction runs on the main thread. Verified CLLocationManager.locationServicesEnabled() returns true. Questions Is a Developer-ID-signed LaunchAgent (LSUIElement=true, no Dock icon) supposed to be able to trigger the standard Location prompt on macOS 14+, or is a foreground/UI process required to establish initial authorization? What does the locationd "keyPath is not registered / Resolving to #nullCKP" message indicate, and how do I diagnose which registration is missing? Is there an entitlement or Info.plist key I'm still missing for Developer-ID-distributed background agents to be recognized by locationd? Given that the Settings toggle appears to be ON but authorizationStatus still reports .notDetermined to the running process, is there a bundle identity / code-signing check I can run to confirm locationd is looking at the same identity Settings is showing? Any pointers appreciated - happy to share codesign output, sample entitlements plist, or the full locationd log excerpt on request.

I'm exploring the possibility of using Apple's SystemLanguageModel from the Foundation Models framework within a WidgetKit extension to generate a summary of today's activities from my app. The API works as expected when invoked from the widget extension. However, I'm looking for guidance on whether this is a recommended approach in production. Given the execution time and memory constraints of WidgetKit extensions, is it advisable to perform on-device inference directly in the widget? Or is the recommended pattern to generate the summary in the main app (or another process), store the result in an App Group/shared container, and have the widget simply read and display the precomputed output?

I provide a paid feature behind an annual auto-renewable subscription, using StoreKit 2 and Transaction.currentEntitlements. Many of my users work in remote places with no connectivity for days at a time, so I need to know what happens when a device is offline at the moment the current period ends. The renewal succeeds server-side, but the device cannot fetch the updated signed transaction, so the cached transaction still carries the previous expirationDate, now in the past. Does Transaction.currentEntitlements stop returning the subscription once the cached transaction's expiration date has passed, even though the renewal has already succeeded server-side? Is there any built-in tolerance window on the device that keeps the entitlement alive until the next successful sync with the App Store? Does grace period effect the outcome? I want to avoid revoking access from a paying subscriber who happens to be offline when renewal falls due. Many thanks.

Hi everyone, I am trying to wake up/relaunch an app that was force-quit by the user via a BLE advertisement packet. According to TN3115 ("App Force Quit by the user" section), an app generally cannot be woken up after a user force-quit. However, Note 5 states that starting in iOS 26, an app authorized via AccessorySetupKit can indeed be relaunched. Environment iOS Version: iOS 26.5 (Note: revised to standard versioning) Xcode Version: Xcode 26.3 Implementation Details 1. Info.plist Configuration <key>NSBluetoothAlwaysUsageDescription</key> <string>We need Bluetooth to discover and connect to your accessory.</string> <key>UIBackgroundModes</key> <array> <string>bluetooth-central</string> </array> <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> <key>NSAccessorySetupBluetoothServices</key> <array> <string>0000XXXX-0000-1000-8000-00805F9B34FB</string> </array> <key>NSAccessorySetupBluetoothNames</key> <array> <string>MyDeviceName</string> </array> 2. Workflow & Code Steps Initialize ASAccessorySession and call activate(). Pair/authorize the BLE peripheral using ASPickerDisplayItem. Initialize CBCentralManager with state restoration: let options: [String: Any] = [ CBCentralManagerOptionRestoreIdentifierKey: restoreIdentifier, CBCentralManagerOptionShowPowerAlertKey: true ] centralManager = CBCentralManager(delegate: self, queue: nil, options: options) Start scanning: let scanOptions = [CBCentralManagerScanOptionAllowDuplicatesKey: true] centralManager?.scanForPeripherals(withServices: serviceUUIDs, options: scanOptions) Handle state restoration: func centralManager(_ central: CBCentralManager, willRestoreState dict: [String : Any]) { if let services = dict[CBCentralManagerRestoredStateScanServicesKey] as? [CBUUID], let options = dict[CBCentralManagerRestoredStateScanOptionsKey] as? [String : Any] { central.scanForPeripherals(withServices: services, options: options) } } Receive discovery callback: func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { if peripheral.name == "MyDeviceName" { // Send a local notification } } Current Behavior Foreground: Local notification triggers as expected. Background: Local notification triggers as expected. Force Quit by User: No notification is received / App is not relaunched. Issue The app fails to relaunch when force-quit by the user, which seems to contradict the behavior described in TN3115 Note 5. Is there a specific configuration, entitlement, or additional CBCentralManager setup required to allow BLE advertisements to relaunch the app after a user force-quit via AccessorySetupKit? Any guidance would be greatly appreciated!

Beginning July 29, 2026, we observe communication erros while sending push notifications to https://api.push.apple.com like: Error in the HTTP2 framing layer Send failure: Connection reset by peer Also we ran tcpdump which clearly indicates that TCP RESET packets are coming from various APNS IP like 17.188.x.x. Errors mostly occure during traffic peak but also outside. We also did a test from different datacenter in other country and which resulted a same issue

General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post URL filter: WWDC 2025 Session 234 Filter and tunnel network traffic with NetworkExtension URL filters documentation Filtering traffic by URL sample code Setting up a PIR server for URL filtering sample code Using the Bloom filter tool to configure a URL filter sample code PIR Service Example open source server sample and specifically its documentation Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Saving a CKShare together with its root record in a custom zone in the user's private database fails on every attempt. The client sees CKError .serverRejectedRequest / .invalidArguments. The CloudKit Console server log shows the failure is on the system record type _pcs_data, not on our own record type: { "database":"PRIVATE", "zone":"SharedStatusZone", "operationType":"RecordSave", "platform":"iPhone", "clientOS":"iOS;26.5.x", "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "requestId":"FDB0D10E-0B82-4C71-9262-90D9A2EA3787", "returnedRecordTypes":"_pcs_data" } In the same session, ZoneSave and RecordFetch SUCCEED. Only the RecordSave that carries the CKShare fails. Container: iCloud.com.nyeong.yakmeokping (Production) Device: iPhone, iOS 26.5.x What we do (simplified) let zone = CKRecordZone(zoneID: ownerZoneID) _ = try await db.modifyRecordZones(saving: [zone], deleting: []) // succeeds let record = CKRecord(recordType: "MedStatus", recordID: ownerRecordID) // plain String / Int64 / Date fields only let share = CKShare(rootRecord: record) share[CKShare.SystemFieldKey.title] = "..." as CKRecordValue share.publicPermission = .none _ = try await db.modifyRecords(saving: [record, share], deleting: [], savePolicy: .allKeys, atomically: true) // FAILS User-visible symptom: UICloudSharingController shows "Cannot add people / Unable to create a link for sharing", and a Messages collaboration attachment spins forever, because no share URL is ever minted. Already ruled out iCloud sign-in - accountStatus() == .available immediately before the call. iCloud Keychain - enabled on both the iPhone and a Mac on the same account. Advanced Data Protection - OFF. Leftover/broken share - also fails when no record exists yet (brand new). UICloudSharingController - reproduced with a code path that never presents the controller and only performs the CloudKit save. Schema - the record type and every field we write are deployed to Production. Entitlements - com.apple.developer.icloud-services: (CloudKit), icloud-container-environment: Production, CKSharingSupported = true in Info.plist. Zone is a custom zone, not the default zone. Record and share are saved together, atomically, as documented. Possibly related Two recent threads report CKErrorServerRejectedRequest limited to the PRIVATE database in Production, starting around July 25: "iCloud Dashboard returns Internal Error when querying records across all containers" - the author reported on July 30 that the service had been down for a few days and had since recovered. "CloudKit CKQueryOperation returns CKErrorServerRejectedRequest" (FB24046201) - failures since July 25, error code 15, CKInternalErrorDomain Code=2000, HTTP 500. Those are read operations rather than a CKShare save, so they may be unrelated. Our failure still reproduces on July 31, after the other report says the incident was resolved. Note that developer System Status showed green throughout. Questions What does a BAD_REQUEST on _pcs_data during a CKShare save indicate? It appears to be the encryption key material for sharing rather than our own record. Is there an account-level or container-level condition that can block PCS key provisioning? Has anyone else seen CKShare creation (not query) failing in the same period? Any pointer would be appreciated - the client-side CKError carries no server error description, so the console log above is all we can see.

Hello, We operate an app that grants users credits after a successful in-app purchase. Our current purchase-processing flow is as follows: A user completes an in-app purchase. Our app or server receives the purchase-related information. Our server sends a transaction verification request to the App Store Server API. After verifying the transaction, our service marks the purchase as completed and grants credits to the user. However, we are intermittently experiencing connection timeouts and unidentified server errors when retrieving transaction information through the App Store Server API. One example of the timeout error is: HTTPSConnectionPool( host='api.storekit.itunes.apple.com', port=443 ): Max retries exceeded with url: /inApps/v1/transactions/330003085668123 Caused by ConnectTimeoutError: Connection to api.storekit.itunes.apple.com timed out. (connect timeout=3) We also intermittently receive the following error response: { "code": 5000001, "message": "An unknown error occurred. Please try again." } When this issue occurs, the payment may have been successfully completed through the App Store, but our server is unable to immediately verify the transaction. As a result, the user may not receive the purchased credits in our app. We would appreciate your guidance on the following questions: What are the common causes of connection timeouts or error code 5000001 when calling /inApps/v1/transactions/{transactionId}? What retry strategy does Apple recommend when these errors occur? Please advise whether there are recommended timeout values, retry limits, or exponential backoff parameters. Is there another reliable method to confirm a completed purchase when the transaction lookup API does not return a response immediately? Does Apple recommend using App Store Server Notifications V2 to process completed purchases asynchronously rather than relying solely on an immediate transaction or receipt verification response? For an app that grants consumable digital credits, which value should be used as the primary identifier for purchase completion and duplicate-grant prevention: transactionId, originalTransactionId, or the information contained in signedTransactionInfo? When a temporary API error occurs, is it recommended to store the purchase as pending and perform transaction verification again from our server until a definitive result is received? We would appreciate Apple’s recommended implementation approach for reliable transaction verification and recovery, particularly to prevent cases in which a payment is successfully completed but the purchased credits are not granted due to a temporary API communication error. Thank you.

Configuring a VPN with includeAllNetworks causes CarPlay / Netflix Cast. Even enabling excludeLocalNetworks does not resolve this issue. Is this a known issue and can we work around this?

Our app uses a Distribution.xml-based installer. Within the postinstall script, we attempt to untar a signed and notarized .app to the /Applications directory. On macOS 27 (tested up to Developer Beta 4), the tar command randomly fails to write random unpacked files with an I/O error; in the console there is "spolicyd[721] revoked access to "/Applications/XXX.app/file/within". It can be reproduced approximately every 4th install. Is this happening for anyone else? Any known workaround?

Subject: Clarification Request – Private Relay and Silent Network Verification (SNV) Hello, Context: our app uses Silent Network Verification (SNV), the standard carrier method where the network recognizes a subscriber's connection to verify their identity without needing an SMS code. When a user has iCloud Private Relay enabled, the request path changes in a way that breaks this recognition, and the user falls back to OTP instead. We're evaluating an approach where the app would handle DNS resolution itself for this specific verification request, so the request stays on a path our network can recognize — without the user having to turn Private Relay off. Before we go further with this, we'd like clarity on two things: Would this kind of app-level DNS handling, used only for this verification step, be acceptable under the App Store Review Guidelines — or would it likely be treated as working around a user's privacy setting (for example under 2.5.1, 2.5.9, or 5.1.1)? If we added an explicit, transparent consent step in the app — telling the user we're bypassing Private Relay for this one request so they can be verified without an SMS code — would that change how this is viewed? We'd rather get this in writing from Apple than build against an assumption, and we'll need to share your response with our internal IT and compliance team, so a written reply would be genuinely helpful. Happy to provide more technical detail if useful. Thank you,

Our macOS app makes an URLRequest (via URLSession) to an HTTP(S) server on the local network (a device at a private IP address, e.g. 192.168.x.x). The request fails with NSURLErrorNotConnectedToInternet (-1009) whose underlying error resolves to ENETDOWN (POSIX errno 50) at the socket/connection level — i.e. the failure happens before any TLS/HTTP exchange, at connect() time. This only reproduces on macOS 27 "Golden Gate" Public Beta. The exact same build/binary works correctly on: macOS 26 "Tahoe" (shipping release) macOS 27 "Golden Gate" Developer Beta Based on our diagnosis, we believe the Local Network permission prompt itself is never firing for direct-IP (non-Bonjour) connections on this Public Beta build, leaving the app's Local Network TCC grant permanently stuck in an "undetermined" state — which then surfaces as ENETDOWN. This is consistent with the app not appearing at all in System Settings → Privacy & Security → Local Network, and with tccutil reset LocalNetwork failing both per-app and system-wide (there's no grant to reset in the first place). We'd like a sanity check / to know if others are seeing this, and whether there's a known workaround. Environment App: com.example.Client, non-sandboxed Target: https://:/api/... macOS versions tested: macOS 26 Tahoe — OK; macOS 27 Golden Gate Developer Beta — OK; macOS 27 Golden Gate Public Beta (build: 26A5388g) — fails Mac model: Mac mini Xcode version used to build: 27 beta 2 Error details URLSession completion error: Error Domain=NSURLErrorDomain Code=-1009 "..." UserInfo={ _kCFStreamErrorCodeKey=50, NSUnderlyingError=0x... { Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo={ _NSURLErrorNWPathKey=..., _kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1 } }, ... } _kCFStreamErrorDomainKey=1 is kCFStreamErrorDomainPOSIX, and code 50 is ENETDOWN. Console log for the same request shows the failure at the connection layer, before any TLS/HTTP activity: Connection 1: received failure notification Connection 1: failed to connect 1:50, reason -1 Connection 1: encountered error(1:50) Task <...>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50]) What we've ruled out / tried Added NSLocalNetworkUsageDescription to Info.plist — no change in behavior. Confirmed via codesign -d --entitlements - and plutil -p Info.plist that the built/signed app bundle actually contains the key. Checked System Settings → Privacy & Security → Local Network — the app itself does not even appear in the list. Tried resetting the Local Network TCC grant: sudo tccutil reset LocalNetwork com.example.Client → tccutil: Failed to reset LocalNetwork approval status for com.example.Client Also tried a full reset for the service (no bundle id): sudo tccutil reset LocalNetwork → tccutil: Failed to reset LocalNetwork Confirmed tccutil itself is functioning normally on this machine — resetting other services succeeds, e.g.: sudo tccutil reset Camera → Successfully reset Camera So tccutil works in general, but the LocalNetwork service specifically cannot be reset, on this Public Beta build, either per-app or system-wide. Question for the forum Is there a known change/regression on the Golden Gate Public Beta where the Local Network permission prompt doesn't fire for direct-IP connections that don't go through Bonjour/NWBrowser? (The same code works fine on the Developer Beta.) Has anyone else seen tccutil reset LocalNetwork fail (while other services reset fine) specifically on the macOS 27 Golden Gate Public Beta? Any known workaround short of downgrading — e.g. restructuring the connection to use Bonjour/NWBrowser instead of a direct IP connection, or some way to explicitly trigger the permission prompt? We're also planning to file this via Feedback Assistant with a full sysdiagnose, but wanted to check here first in case this is already a known/tracked issue or someone has a workaround. Thanks in advance.

Hello, We are using the UPI device validation APIs on iOS 26+ in a production banking/UPI app, and we are seeing a recurring failure from CoreTelephony that we need guidance on. API / entitlement Framework: CoreTelephony API: CTCellularPlanStatus.checkValidity(ofToken:) Related: CTCellularPlanStatus.token() Entitlement: com.apple.developer.upi-device-validation Availability: iOS 26.0+ Minimal call site do { let isValid = try await CTCellularPlanStatus.checkValidity(ofToken: token) // isValid == true/false -> expected outcomes } catch { // Unexpected: API throws instead of returning Bool print(error.localizedDescription) } Error error.localizedDescription is: English: Couldn't communicate with a helper application. Same failure also appears with a localized Hindi message on Hindi-locale devices. This is distinct from checkValidity(ofToken:) returning false (token/SIM mismatch). Here the API throws, so we cannot tell whether the token is valid. In production we currently only have this localizedDescription from telemetry. Production observations (large fleet, last few days) Observed only on production user devices so far; we have not reproduced it reliably on lab hardware. Occurs across multiple iOS 26.x builds (notably 26.5.2, 26.5, 26.6; also seen on 26.0-27.0). Not limited to a single patch. Seen on many iPhone models (not one SKU). Latency is bimodal for the same error string: large share fails in under 100 ms (immediate) another large share fails after about 2-10+ seconds (timeout-like) Observed under Wi-Fi, cellular (4G/5G), and No Connection / radio-not-ready conditions. Same device can emit many identical failures within about 1 second when validity is checked from multiple call sites concurrently. Token generation (CTCellularPlanStatus.token()) and successful checkValidity work for the vast majority of users; this throw is a smaller but material failure class. Questions for Apple Is "Couldn't communicate with a helper application." an expected / documented failure mode of checkValidity(ofToken:) (for example CommCenter/XPC unavailable, radio not ready)? What conditions typically trigger this error from checkValidity(ofToken:)? Recommended client handling: retry (with backoff)? treat as transient and skip forcing re-binding? surface to user? Does validation require cellular registration / SIM ready state even when docs indicate internet is not required? Any known issues on specific iOS 26.x builds, dual-SIM, eSIM, or airplane-mode transitions? Is concurrent checkValidity from multiple tasks unsupported / unsafe? Because this is currently production-only and not reliably reproducible on lab devices, we cannot attach a sysdiagnose or Instruments trace at this time. We can share aggregated production telemetry and API details via Feedback Assistant if helpful. Thank you.

We're investigating an edge case around push/local notification handling on macOS when multiple instances of the same app are running simultaneously, launched via open -n /path/to/App.app. We're aware this isn't the standard/expected usage pattern for macOS apps, which are singleton by default, but we need to understand and correctly handle this case, so any clarity here would help. Setup: macOS app, AppKit, using NSApplicationDelegate and UNUserNotificationCenterDelegate. Two separate processes of the same app launched via open -n, each independently calling UNUserNotificationCenter.current().delegate = self and registerForRemoteNotifications() on launch. Questions: Device token : is the device token unique per device and app installation, or could two separately-running processes of the same installed app each be issued a different token? Our understanding from Apple's documentation is that the token identifies the app and device combination, not a specific process. Can you confirm this holds even in a multi-instance scenario? Notification tap routing : when a notification, local or remote, is tapped and both process instances have independently registered a UNUserNotificationCenterDelegate, which instance's delegate receives userNotificationCenter didReceive withCompletionHandler? Is this deterministic, for example the most recently registered instance, or the one most recently connected to usernoted? Is it arbitrary or undefined? Or does the system only allow one instance's delegate connection to be active at a time, silently disconnecting the other? Is there any documented or recommended way for an app to detect it's running as a secondary instance launched via open -n, and adjust its notification handling behavior accordingly, if relevant? We understand this falls outside the normal supported usage pattern for macOS apps, but since the behavior isn't documented for this scenario, any insight, even confirming this is undefined behavior, would be genuinely useful for us to plan around.

I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle of the DispatchQueue associated with an NWConnection instance. Let's assume I have an NWConnection instance, and I associate it with a dispatch queue using the start(queue:) API, such that network OS events for the NWConnection instance can be delivered to this queue. My understanding is that this association would result in NWConnection holding a strong reference to the DispatchQueue object. Now, I perform some I/O (send/receive) on the NWConnection instance and immediately perform the following steps. Also, assume that the completion closures for those I/O operations do not capture or otherwise retain the NWConnection. Call connection.cancel() and then release my last strong reference to the NWConnection. Without waiting for the connection to transition to the .cancelled state, I also release my last strong reference to the associated DispatchQueue. My question is: Does NWConnection, during its teardown, retain the DispatchQueue until the cancellation completions for all pending I/O operations associated with the connection have been delivered/executed, given that the application no longer holds any strong references to either the NWConnection or the DispatchQueue? Or, once cancel() is called, does NWConnection immediately release its reference to the DispatchQueue, in which case whether the pending callbacks are ultimately executed depends on whether the application has kept the queue alive?

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.