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.

I have 2 iOS app products. One can fetch subscription product information normally, while the other fails with the error errorCode 4040004 'App not found' in Sandbox. The App Store Connect backend configuration should be fine, and the subscription code on the app side is the same codebase for both. I really can't find the root cause anymore — if anyone knows what's going on, please point me in the right direction. Also, I'm able to sync/download the StoreKit product configuration file from App Store Connect directly in Xcode, which should also confirm that my App Store Connect backend configuration is correct.

We have a new iOS app in App Store Connect with six consumable in-app purchases. Environment: Bundle ID: live.mymi.ios TestFlight version: 1.0.4 (70) Storefront: KOR Environment: Sandbox Example product ID: ios_spark_5000 StoreKit product queries return all six products with localized KRW prices. For example, ios_spark_10000 is returned as ₩12,000. However, requesting a purchase fails with Product.PurchaseError.productUnavailable / “This item is not available.” The issue can also be reproduced independently of the app: Settings > Developer > Sandbox Apple Account > Test Transactions Entering bundle ID live.mymi.ios and product ID ios_spark_5000 is rejected with a message stating that the product ID or bundle ID is invalid. The previous app/product pair live.mymi.app + spark_5000 still works on the same device and with the same Sandbox tester. We verified the following: Paid Apps Agreement, banking, and tax information are active The explicit App ID has the In-App Purchase capability enabled The TestFlight build uses the correct bundle ID Product pricing, localization, and availability in all 175 storefronts are configured All six IAPs are attached to the first app version review submission No local StoreKit configuration is involved This has persisted for multiple days. It appears that the product-query catalog contains the products, while the Sandbox transaction service does not recognize the product-to-bundle association. Has anyone seen this with a newly created App Store app/IAP catalog? Did Apple need to re-index the products?We have a new iOS app in App Store Connect with six consumable in-app purchases. Environment: Bundle ID: live.mymi.ios TestFlight version: 1.0.4 (70) Storefront: KOR Environment: Sandbox Example product ID: ios_spark_5000 StoreKit product queries return all six products with localized KRW prices. For example, ios_spark_10000 is returned as ₩12,000. However, requesting a purchase fails with Product.PurchaseError.productUnavailable / “This item is not available.” The issue can also be reproduced independently of the app: Settings > Developer > Sandbox Apple Account > Test Transactions Entering bundle ID live.mymi.ios and product ID ios_spark_5000 is rejected with a message stating that the product ID or bundle ID is invalid. The previous app/product pair live.mymi.app + spark_5000 still works on the same device and with the same Sandbox tester. We verified the following: Paid Apps Agreement, banking, and tax information are active The explicit App ID has the In-App Purchase capability enabled The TestFlight build uses the correct bundle ID Product pricing, localization, and availability in all 175 storefronts are configured All six IAPs are attached to the first app version review submission No local StoreKit configuration is involved This has persisted for multiple days. It appears that the product-query catalog contains the products, while the Sandbox transaction service does not recognize the product-to-bundle association. Has anyone seen this with a newly created App Store app/IAP catalog? Did Apple need to re-index the products?

I'm developing an Accessibility-enabled app that includes a helper app registered as a launch daemon using SMAppService. This daemon will connect to HID which requires both being root as well as having Accessibility (or Input Monitoring) permissions. I want this app to have as little friction for the user as I can manage. One friction I'd like to avoid is requiring the user to grant more than one application permission to use Accessibility features. So I'm wondering if I can set up the launch daemon so that it inherits the TCC permissions of its parent bundle. I'll note that the one way I've found that works is to not have the helper app have its own app bundle, but rather just have it be an executable placed alongside the main executable in enclosing bundle's Contents/MacOS directory. This has the disadvantage though of having the helper process and main process have the same name in Activity Monitor, which I think will be confusing to users. So in short, is there a supported way for a bundled application with its own CFBundleName / CFBundleDisplayName key to run as a launch daemon and also inherit Accessibility permissions from its parent app bundle?

We build an internal on-call pager app for our engineers, distributed through TestFlight only. Our server sends a heartbeat push to each device every 4 hours. The Notification Service Extension uses it to re-arm a dead-man's-switch alarm on the device: if heartbeats stop arriving, the alarm goes off and the engineer knows the paging pipeline is down. The heartbeat has to be an alert push with mutable-content, because that is the only push type that reliably launches the extension, including when the user has swiped the app away. Background pushes don't work here: they are throttled and are not delivered to an app the user has force-quit, so the dead-man alarm would fire falsely. The problem is that every heartbeat leaves an entry in Notification Center. It carries nothing actionable, and it teaches on-call engineers to ignore notifications from a pager app. Real alerts are always shown, and the extension still shows a visible notification when a heartbeat detects a problem (missed alerts, failure to re-arm). We already send heartbeats with interruption-level passive and an apns-collapse-id, so it is a single quiet entry, but it is still there. com.apple.developer.usernotifications.filtering would solve this exactly. However, the request form requires picking one of four use cases (end-to-end encrypted messaging, earthquake warnings, education alerts, healthcare alerts), and ours is none of them. An earlier reply on this forum said other use cases are welcome to apply (https://developer.apple.com/forums/thread/676672), but the form no longer offers a way to describe one. Questions: Can an app whose use case is outside the four listed apply for the entitlement? If so, how should we fill in the required use-case field? If not, is there a supported way to have an alert push launch the extension without leaving an entry in Notification Center? For example, is it supported for the extension to remove its own delivered notification with removeDeliveredNotifications(withIdentifiers:) after calling the content handler? Thanks!

Reference environment: macOS 26.7.1, build 25G241, arm64, local APFS. Consistent capture of a source file We are evaluating NSFileCoordinator with the forUploading and withoutChanges options for a single regular file. Does the resulting snapshot guarantee byte contents corresponding to a single point in time, even if another process writes during capture without file coordination, using write/pwrite or a shared writable memory mapping? We need to establish the scope, conditions, and limitations of this guarantee. We do not require capturing an editor’s unsaved changes or application-level database consistency. If any of these concurrent writing methods are not covered, please identify them explicitly. Durability of the final filename after a rename We are evaluating the following sequence: a verified temporary file has successfully completed strong synchronization, and is then renamed using renameatx_np with RENAME_EXCL. The temporary and final names are in the same directory on the same volume. Next, fsync_volume_np is called with SYNC_VOLUME_FULLSYNC and SYNC_VOLUME_WAIT. Under what conditions does a successful return confirm that the final filename and its association with the prepared file contents will survive a system crash or power loss? We also need clarification on whether all relevant data and metadata write errors are propagated to the caller, or whether an earlier error might remain unreported by this operation. Please provide the documented scope and limitations for this environment.

Since we configured App Store Server Notifications V2 on 15 October 2026, every notification for our app is recorded as TIMED_OUT, with the attemptDate equal to the signedDate (same second), and no HTTP request ever reaches our server. 35 Sandbox notifications (TEST, SUBSCRIBED, DID_RENEW, EXPIRED): one attempt each, TIMED_OUT. 2 Production TEST notifications: retried 5–6 times over a week, all TIMED_OUT. Our endpoint is public, TLS 1.3, valid certificate, answers in < 400 ms, and processes the signedPayload correctly when we POST it ourselves. Today we pointed the Sandbox URL to a webhook.site URL and requested a test notification: TIMED_OUT within 10 s, nothing received on webhook.site either. The app (com.virginactive.revolution, appAppleId 1620160868) was transferred to our current developer account on 2 October 2026; notifications have never been delivered under the new team, so we suspect a server-side state issue after the transfer. Latest test tokens: Sandbox: be12b40b-19a7-4723-aebf-764db83b4690_1793289992274 (29 Oct 2026 16:06 UTC) Production: 80597167-2939-4cc9-a43c-2c3c29c6a161_1792741270174 (23 Oct 2026 07:41 UTC) Feedback Assistant: FB25363489 Is there anything on our side that could make the App Store server fail before attempting the connection, or does this need to be fixed on Apple's side?

Title: AccessorySetupKit picker only reports 3 accessories when using filterDiscoveryResults Tags: AccessorySetupKit, Core Bluetooth Hi all, We recently migrated our BLE accessory pairing from our own CoreBluetooth scan flow to AccessorySetupKit. Since this is the new framework Apple recommends for accessory pairing (and with the new Bluetooth privacy model), we wanted to move fully to it. The migration went well overall, but we hit a limit in production that we couldnt find documented anywhere and it's now affecting real users. What we are doing We use .filterDiscoveryResults so we can set our own name and image for each accessory in the picker. For every .accessoryDiscovered event we create an ASDiscoveredDisplayItem and pass the full list to updatePicker(showing:completionHandler:). let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothCompanyIdentifier = ASBluetoothCompanyIdentifier(rawValue: [ID]) descriptor.supportedOptions = .bluetoothPairingLE let item = ASPickerDisplayItem(name: "[Name]", productImage: image, descriptor: descriptor) let settings = ASPickerDisplaySettings() settings.options = .filterDiscoveryResults settings.discoveryTimeout = .long session.pickerDisplaySettings = settings session.showPicker(for: [item]) { _ in } // In the event handler, for every .accessoryDiscovered event: session.updatePicker(showing: allDiscoveredItems) { _ in }The problem We only ever get 3 .accessoryDiscovered events in one picker session, doesnt matter how many of our accessories are advertising nearby. Since the picker shows only what we pass to updatePicker, the sheet never shows more then 3. Our own code has no limit, every discovered item goes to updatePicker. If we remove .filterDiscoveryResults and keep everything else same, the picker shows more than 3 accessories in the same room. So it looks like the limit only applies when filtering is on. How it affects users When there are lot of accessories around (offices, events, households with more than one), the one the user actually want to pair is often not in those 3. Users don't know there is a limit, so they keep dismissing the picker and opening it again hoping their accessory shows up this time. Understandably this is very frustrating for them, and with our old scan flow this wasn't a issue because we could list every accessory nearby. To reproduce Turn on more than 3 accessories matching the descriptor within few metres of the iPhone, present the picker with the above configuration and log every .accessoryDiscovered event. Only 3 arrive, any accessory turned on after the first 3 never shows up. Questions Is this limit of 3 intended? If yes, is there a way to raise it or reset it during the session (for example after calling updatePicker)? How the picker decides which accessories gets reported? Is there a recommended approach for crowded environments? If it's intended, can it be added to the documentation? Environment iOS Version 27.1 (27A9269), iPhone 16 pro(MYNR3HN/A), Version 27.1 (27A9269) We have filed this as FB25362032. Thanks!

We're building a SaaS that lets independent businesses issue Apple Wallet stamp-card passes. Our server signs every pass with a single Pass Type ID from our developer account. Each pass shows the merchant's own name and branding, and the back says "Issued by our platform" with a support contact. Updates use the standard web service plus an empty APNs push. Two questions: 1. Is it acceptable for one Pass Type ID to issue passes for many independent merchants, or should each merchant have its own? If a merchant sent abusive promotions, could Apple revoke the shared Pass Type ID and affect all merchants? 2. We use changeMessage on a back field to show merchants' occasional promotions (max one every 48 hours, reviewed by us), as well as on stamp and reward updates. The Wallet HIG discourages changeMessage for marketing. Is a promotional message on a loyalty pass acceptable, and what's the recommended mechanism? Has anyone running a multi-merchant platform dealt with this? Thanks!

iOS Background Location / Geofencing for Automatic Attendance — App Not Triggering Reliably We are developing an enterprise attendance application called Attendo, which uses location-based geofencing for automatic employee check-in/check-out. Business requirement The application needs to work as follows: An employee is assigned an office/work location with a defined radius. When the employee enters the configured radius, the application should automatically record a Check-In. When the employee leaves the radius, the application should automatically record a Check-Out. This should happen without the employee having to open the application. The functionality needs to work even when the application is in the background and, where supported by iOS, after the application has been terminated. For example: «Office geofence = 200 meters Employee enters the 200 m radius → automatic Check-In Employee leaves the 200 m radius → automatic Check-Out» Current iOS implementation We are using iOS location services with: Location permission: Always Precise Location: enabled Background Location capability enabled Background location updates enabled Geofencing / region monitoring The application is intended to respond to location/geofence events without requiring the user to open the app. However, we are seeing cases where the application does not reliably receive/process the required location/geofence event when the application has been in the background for an extended period. The same business workflow works more reliably while the application is active. Our concern Our understanding is that iOS does not allow an application to maintain a continuously running background service in the same way that Android can. However, our requirement does not necessarily require continuous GPS polling if there is an Apple-supported mechanism that can reliably wake/relaunch the application when a user crosses a geofence. We would therefore like to understand the recommended architecture for this use case. Questions Is Core Location Region Monitoring the recommended mechanism for an enterprise geofencing application that needs to detect entry/exit while the app is not running? Can iOS relaunch the application after it has been terminated by the user/system when a monitored region is entered or exited? Is there any supported way to guarantee that an application will continue receiving location/geofence events after it has been in the background for a long period? Does enabling: "UIBackgroundModes = location" "allowsBackgroundLocationUpdates" "CLLocationManager" Region Monitoring provide the expected behavior, or are there additional requirements/configurations we should consider? Are there known limitations regarding: Low Power Mode device movement speed GPS/location accuracy stationary devices iOS terminating/suspending the application force-quitting the application from the App Switcher large/small geofence radius multiple monitored regions Is it possible to use significant-change location updates + region monitoring together for this type of attendance workflow? For an enterprise application where the user explicitly grants Always Allow Location permission and Precise Location is enabled, what level of reliability can realistically be expected from iOS geofencing? Important business constraint We cannot require employees to manually open the application every time they arrive at or leave the workplace. The objective is an automatic attendance system, where the employee's entry and exit from the workplace geofence is detected by iOS and the application records the corresponding attendance event. We understand that iOS is designed to protect battery life and user privacy and that continuous background execution may not be permitted. We are therefore looking for the Apple-recommended architecture for achieving this requirement using supported iOS APIs, rather than trying to circumvent iOS background execution policies. Any guidance from Apple engineers or developers who have implemented reliable enterprise geofencing would be greatly appreciated.

For an application supporting iOS 16 and later, is there a supported public API that exposes a monotonic timestamp for the original determination of a CLLocation, rather than the time it is delivered to CLLocationManagerDelegate? The requirement is to reject observations whose original acquisition age exceeds 10,000,000,000 ns at the final native transport-dispatch check. Exactly 10 seconds is allowed; 10 seconds plus 1 ns is rejected before conversion to milliseconds. This is an arithmetic boundary requirement, not an assumption that location measurements have nanosecond physical accuracy. CLLocation.timestamp is a Date for when the location was determined. Sampling a continuous monotonic clock in didUpdateLocations instead measures callback receipt. Cached observations, batched updates and delayed background delivery can separate those events. Does a public API provide either: A monotonic acquisition/determination timestamp associated with that same CLLocation; or A documented finite uncertainty bound and supported method for relating its Date timestamp to a sleep-inclusive monotonic clock at dispatch? How do the documented guarantees handle wall-clock adjustments between determination and delivery, device sleep, suspension, queued updates and process restarts? If a newer API supplies stronger evidence, what is its minimum supported iOS version? If neither mechanism is available, is there a supported request or delivery mode that establishes a documented lower bound on the original determination time and can reliably reject older cached observations? A recent callback or request by itself would not establish that relationship. I would appreciate documentation describing the guarantees, limitations or supported alternatives. I have not established that such a mechanism is impossible; this is a capability clarification, not a claim of a reproduced operating-system defect.

On watchOS 27, a third-party watch app that advertises an application service with NWListener (default NWParameters.applicationService, service declared in NSApplicationServices → Advertises) is never advertised: the advertiser path is denied by NECP policy. As a result, when a tvOS app presents DDDevicePickerViewController and the user selects the watch and taps Connect on the watch, sharingd finds no listener (listenerID (null)), the pairing times out after ~30 s, and the tvOS picker's endpoint never returns — neither an endpoint nor an error. Raw lines: watchOS 26.6 (success, pid 267) 16:00:55.891 AppleWatch[267] -[_NWAdvertiser start] [L1] Starting advertiser 16:00:55.891 AppleWatch[267] -[_NWAdvertiser updateFlows:]_block_invoke [L1] Added listener flow ID 667B9945-… 16:00:55.926 rapportd[48] Found registered listener RPNWListener[…][com.fitonapp.fiton.FitOnWorkout]=0A1149F2-… : ageOut=179s agentClient=0x0 { 'kebike' } 16:00:55.927 rapportd[48] Updated RPNWAgentClient[0x176cc550] (LSTNR): < appSvc=com.fitonapp.fiton.FitOnWorkout PID:267 entitled=0 … browseToken=[pid:267,id:667B9945] … > 16:00:55.930 rapportd[48] [pid:267,id:A20E8919] createListenerFramer calling assign with local endpoint=::.51714 16:01:09.956 rapportd[48] [pid:267,id:F7883D0D] ADVERTISE: Start advertise 'FitOnWorkout' request QUIC=NO isTCP=YES params:[tcp, pid: 267, local: ::.51714, …] 16:01:29.352 rapportd[48] Created incoming RPNWConnection[CONN[5BCD2213-…] (IN): … appSvc=com.fitonapp.fiton.FitOnWorkout … EP={kebike:…}] 16:01:29.399 rapportd[48] [pid:267,id:3346E704] assigning connection ::.51714 <-> app_svc: com.fitonapp.fiton.FitOnWorkout, service_id: D2D4D049-… 16:01:29.404 AppleWatch[267] nw_connection_report_state_with_handler_on_nw_queue [C2] reporting state ready Raw lines: watchOS 27 (failure, 10-21) 16:00:48.761 AppleWatch[556] -[_NWAdvertiser start] [L1] Starting advertiser with descriptor: FitOnWorkout scope:3f … 16:00:48.761 AppleWatch[556] -[_NWAdvertiser updateFlows:] [L1] Listener skipping advertise flows due to unsatisfied path with policy drop 16:00:48.760 rapportd[98] [pid:556,id:C1D4B82D] createListenerFramer: incorrect agent type ← never upgraded to LSTNR afterwards … 16:05:37.919 sharingd[458] setupDDUIListenerIfNeeded, incoming pairing session … ← TV's pairing request did arrive 16:05:40.538 sharingd[458] Attempting to launch application com.fitonapp.fiton.watchkitapp 16:05:40.688 rapportd[98] Searching for listener agent client with appSvc='com.fitonapp.fiton.FitOnWorkout' 16:05:40.688 rapportd[98] Created new listener RPNWListener[…][com.fitonapp.fiton.FitOnWorkout]=F625EFB1-… : ageOut=180s agentClient=0x0 { } ← no FitOnWorkout ADVERTISE afterwards; the listener never gets the app's agent client

Hi. It is not as much as widgets itself but it goes along with live activities for sure I believe. Question 1: Hybrid Intelligence & Proactive Context How can developers leverage the Intelligence Platform (specifically intelligenceplatformd) to ensure 3rd-party apps provide the same deep proactive context as first-party services like Spotlight, but strictly through on-device processing to maintain total user privacy? Question 2: Autonomous Diagnostics & Private Reporting Is there a roadmap for Feedback Assistant to autonomously aggregate complex system-level interactions—using spindump or system_profiler—to generate "ready-to-implement" solutions for users, while ensuring these diagnostic insights remain local and are never transmitted to Apple or Google without explicit, granular consent? Question 3: Deep Indexing for Hybrid Data Sources With the shift toward ecosystem-wide intelligence, are there upcoming APIs that will allow Siri or App Intents to more deeply index "hybrid" private data sources—such as external databases or complex Markdown structures in Obsidian—without compromising the local-first security model?

I am evaluating a local macOS C XPC design. The target under consideration is macOS 27.0.1, build 26A434, on Apple silicon. This is a source-design question; I have not run a reproducer or established that the public source below matches that OS build. The public SecCode.h comment describes SecCodeCreateWithXPCMessage as obtaining a code reference for the sender of the supplied XPC message using associated audit identity. The implementation at Apple Security commit 97c3a4296c1ea06b0fe1877a7e616aa84450b5b2 obtains the dictionary's remote connection, takes that connection's audit token, and uses it for code lookup: https://github.com/apple-oss-distributions/Security/blob/97c3a4296c1ea06b0fe1877a7e616aa84450b5b2/OSX/libsecurity_codesigning/lib/SecCode.h https://github.com/apple-oss-distributions/Security/blob/97c3a4296c1ea06b0fe1877a7e616aa84450b5b2/OSX/libsecurity_codesigning/lib/SecCode.cpp Function anchor in both files: SecCodeCreateWithXPCMessage. I am treating this as a question about the supported API contract, not evidence of a vulnerability or proof of installed implementation. For an actual received C XPC dictionary M, retained for deferred processing, I need to understand the supported identity and reply guarantees: Does SecCodeCreateWithXPCMessage(M, ...) resolve audit identity fixed to M's original sender occurrence, or can the associated connection's identity at lookup time differ? In particular, what is guaranteed if another message arrives or processing occurs concurrently on another queue? If the sending process performs exec before the lookup, or after lookup but before a reply, what does the resulting SecCode reference identify? Is there a documented supported way to distinguish the original message-sending occurrence and executable from a later executable or replacement peer without using PID-based reconstruction or private XPC APIs? If I retain M and later use its supported C reply context, does the reply remain addressed to that same original sending occurrence? What are the documented effects of connection invalidation, exec, forwarding/delegation of relevant rights and outstanding aliases? I am not assuming that retaining M or the returned SecCode reference locks peer identity or revokes other holders. If these APIs do not jointly provide those guarantees, which public API and ownership pattern should a design use to validate the actual eventual reply recipient before sending sensitive data? A statement that a guarantee is unavailable or requires a different design would also help. Please distinguish C XPC behavior from Swift XPCReceivedMessage; I am not assuming an undocumented conversion between them. Could you point to the applicable documentation and supported macOS versions, and clarify whether the cited public source revision is representative of the target? If exact-build behavior cannot be established publicly, please identify that limitation. This question concerns transport identity and context lifetime only. A valid code identity would still need separate application authorization; I am not asking XPC to issue role, run or resource authority. I would prefer a documented contract over an inference from a successful test. I can prepare a separately scoped minimal example if one is necessary, but no executable example is included in this question.

Hello Apple networking team and fellow developers, Summary We are investigating increased Wi-Fi login and reconnection timeouts after users upgrade to iOS 27. Some players report repeated reconnection failures during battles, preventing completion and potentially losing Star Hunt points. The root cause is not confirmed. 1. Wi-Fi timeout rates by OS version +------------+------------------------+--------------+ | OS version | Timeouts / online hour | Dates (2026) | +------------+------------------------+--------------+ | iOS 26.x | 0.086 | Oct 8-21 | | iOS 27.0 | 1.779 | Oct 8-21 | | iOS 27.0.1 | 1.737 | Oct 8-21 | | iOS 27.2 | 1.437 | Oct 26-28 | +------------+------------------------+--------------+The 27.2 observation cutoff is October 28, 14:15 UTC+8. The earlier iPhone comparison showed approximately 20 times as many Wi-Fi login/reconnection timeout records per online hour on 27.0/27.0.1 as on 26.x. Comparison limit: The 27.2 row uses a different population and observation window. It is not a direct before/after upgrade comparison. 2. Paired comparison: 27.0.1 → 27.2 We separately compared 51 paired iPhone account/device samples: the same account and device, game package version 1.9.1, and 24 hours before and after the first observed 27.2 event. Each side required at least 30 minutes of Wi-Fi online time. These samples first reported 27.2 on or after October 26. +------------------------+----------------+-------------+ | Metric | Before: 27.0.1 | After: 27.2 | +------------------------+----------------+-------------+ | Wi-Fi online hours | 96.69 | 91.05 | | Timeout records | 142 | 45 | | Timeouts / online hour | 1.47 | 0.49 | | Samples with timeouts | 17 / 51 | 6 / 51 | +------------------------+----------------+-------------+This small paired sample suggests an initial improvement of approximately 66%, but failures remain. Measurement limits: Both tables count application-level timeout records, including repeated retries, rather than independent disconnections. The 27.2 sample and observation period are limited. Our OS-version telemetry does not distinguish beta/RC builds from final builds sharing the same version string. 3. Other observations Earlier cohort comparisons did not show a comparable increase over 4G/5G. Wi-Fi-only iPad models are also affected, so switching to the device's own cellular connection cannot explain all cases. Ordinary request errors did not increase to the same extent as login/reconnection timeouts. Connection recovery is an investigation lead, not a confirmed cause. Our iOS HTTP requests use NSURLSession. Current application telemetry does not retain enough native NSError details to identify whether DNS, TCP, TLS, or another stage is responsible. 4. Questions for Apple Are there known iOS/iPadOS 27 changes or regressions involving Wi-Fi connection recovery or NSURLSession that could fit this pattern? Are there relevant fixes in 27.2, or specific OS builds we should compare? Which diagnostics should we collect from affected physical devices (for example, a CFNetwork diagnostic profile, sysdiagnose, or URLSessionTaskMetrics), and how should we submit them privately? We are looking for a systematic way to isolate the cause rather than assuming all cases share one OS bug. Any guidance would be appreciated.

For an application supporting iOS 16 and later, including iOS 18 and newer releases, I would like to clarify the supported guarantees for deciding whether persisted monotonic time evidence belongs to the current boot. I have read the DTS reply in “Time verification in iOS 18+” and the linked recommendation to use CLOCK_MONOTONIC with an exclusively created POSIX named semaphore: https://developer.apple.com/forums/thread/774658?answerId=825483022#825483022 https://developer.apple.com/forums/thread/110044?answerId=754364022#754364022 That recommendation describes semaphore cleanup on restart as a reasonable assumption. My question is specifically about the documented guarantees and safe failure conditions of that approach, rather than another request for a replacement for kern.bootsessionuuid. The required distinction is between process or application-engine restarts during the same boot and an actual device reboot. A continuity mechanism should remain valid across the former and distinguish, or safely invalidate, observations retained across the latter. It must not depend on an assumed-stable wall clock or on comparing uptime magnitudes that could overlap after a reboot. For an App Group-namespaced semaphore on supported iOS versions: Is cleanup at every device reboot, and persistence across ordinary process termination or suspension within a boot, a documented guarantee that an application may rely on? What sandbox, resource-limit, lifecycle or name-reuse conditions can invalidate that inference? Is there a supported way to avoid treating a recreated or unrelated same-name semaphore as proof that older persisted observations belong to this boot? If those guarantees cannot be established, is there another supported boot-continuity mechanism? Please identify its OS availability and applicable privacy or required-reason API constraints. No raw boot identifier or raw uptime needs to be sent off-device. If supported cross-process continuity cannot be established, is a continuously alive native process's sleep-inclusive monotonic clock a documented comparison domain until that process ends? In that narrower design, all previous-process observations would be invalidated, accepting the loss of same-boot recovery. A process UUID or application-engine identity would not be treated as an operating-system boot identity. I am seeking documented guarantees, limitations or supported alternatives, not an undocumented sysctl or an inference from macOS behavior. This question concerns clock-domain continuity; it does not assume that continuity alone proves when a location observation was originally acquired.

Since the framework manages the lifetime of an instance of a type conforming to NWProtocolFramerImplementation, plus the streaming of input and output into/from the instance, how can testing be done? My example type needs a StreamProtocol object for the underlying bytes; can mocks be created?

We have an app which uses a DriverKit-based driver to communicate with an external device. In multiple iPadOS versions, users have been facing this issue where the option/toggle to enable/disable the Driver is not appearing in the App Settings. As a result, users have to uninstall/install the app to get the option again. Ideally, the option should always appear in the App Settings so that users can freely toggle it according to their needs. Due to this, the external devices connected to the iPad will not be detected. I have not seen this happen during development or in any of the iPad(s) that I have tested the app on. Has anyone seen this happen with their apps and if so, what is the issue/workaround? Is this a known bug only in some specific versions of iPadOS? Also, I have raised a feedback for the same here but there has been no reply. Thanks, Abishek.

Hello, We are investigating a discrepancy during an auto-renewable subscription test in Apple’s Sandbox. We would appreciate guidance on read-only diagnostics that preserve the original attempt. Environment: A development-signed, unpublished QA app on a physical iPhone, separate from our production app. A monthly auto-renewable subscription. The original purchase flow uses RevenueCat. The Apple purchase sheet displayed “Environment: Sandbox” and indicated that no charge would occur. Observed behavior: After entering the Sandbox account password, the tester reported seeing a purchase-completion message. The app subsequently displayed a cancellation message. We did not capture a verified StoreKit success transaction, so we cannot establish that the purchase actually completed. The dedicated QA RevenueCat project showed no purchases or subscriptions, and no actual purchase webhook arrived. The next day, subscription management for the same Sandbox account showed no subscription for this QA app. Read-only investigation: RevenueCat’s purchase and subscription queries returned HTTP 200 with empty results and no additional page. We updated the same app, retaining its bundle identifier and installation, with a native StoreKit diagnostic. Enumerating StoreKit.Transaction.all completed normally with zero results. There were no unverified results, filtered-out transactions, timeouts, or count limits. This diagnostic did not invoke purchase, synchronization, or transaction-finishing operations. One earlier restore attempt also returned no purchase. We have not made another purchase, cleared purchase history, or recreated the Sandbox account. We understand that an empty result in this app context does not prove that no transaction exists anywhere in Apple’s systems. No transaction identifier or signed transaction has been recovered. Questions: What read-only checks can distinguish an incomplete or cancelled purchase from an account/environment mismatch or a transaction-delivery issue? Is there a supported way to investigate the original attempt without a transaction identifier and without making another purchase? Which existing device logs or diagnostic captures would be useful? If investigation requires identifiers or unredacted diagnostics, what private Apple reporting channel should we use? Our goal is to investigate the original attempt while preserving purchase history and leaving production untouched. Thank you.

We’re using an Enhanced Security helper extension with AppExtensionProcess and XPCSession to isolate native zero-knowledge proof generation from wallet and signing code. On an iPhone 15 Pro running iOS 26.6.2 (23G90), the helper terminates with: EXC_RESOURCE RESOURCE_TYPE_MEMORY: high watermark memory limit exceeded (limit=35 MB) Terminated due to memory issue Our current prover requires substantially more memory: its public proving key is approximately 402 MiB, and its witness workspace alone is approximately 69 MiB. The same proof engine has completed successfully in a standalone iOS app process. The helper currently processes only synthetic test inputs. We want to preserve the helper’s sandbox and Enhanced Security protections and use a configuration supported for App Store distribution. Is there a supported way to increase the memory limit for this specific helper extension type? Does com.apple.developer.kernel.increased-memory-limit apply to Enhanced Security helper extensions? If so, what provisioning, target configuration, and device/OS requirements apply?