Body: I’m building a Developer ID app (distributed outside the Mac App Store) that ships a packet-tunnel system extension. The extension fails at activation with: Extension not found in App bundle. Unable to find any matched extension with identifier: com.hawksnestsoftware.securityhawkvpn.tunnel Setup App: com.hawksnestsoftware.securityhawkvpn, Developer ID Application, team A5WW6PA8WT, hardened runtime, notarized and stapled, installed at /Applications/SecurityHawk VPN.app Extension: Contents/Library/SystemExtensions/PacketTunnel.systemextension, identifier com.hawksnestsoftware.securityhawkvpn.tunnel, CFBundlePackageType = SYSX. codesign --verify --strict passes, and the signature matches its designated requirement. Entitlements: the app has com.apple.developer.system-extension.install, and its embedded provisioning profile grants it. The extension has com.apple.developer.networking.networkextension = packet-tunnel-provider-systemextension. The app calls OSSystemExtensionRequest.activationRequest(forExtensionWithIdentifier:queue:) and the request fails with the error above. Machine: MacBookPro15,3, macOS 15.8.2 (24H232), Xcode 16.4. What I’ve ruled out Sandbox on and off (the error is the same either way) Signing and strict verification The embedded profile’s system-extension entitlement A duplicate Debug copy of the app elsewhere on disk (Spotlight finds only the /Applications copy) A restart before retesting Observed systemextensionsctl list shows no registration for the extension after the failed request. log show and log stream filtered on sysextd show no entries for the request. Question: What causes sysextd to report that it cannot find an extension in the app bundle when the bundle, identifier, and signature all look correct? Is there a required build setting or Info.plist key for a Developer ID system extension that I may be missing? Error seen: Error: “Extension not found in App bundle. Unable to find any matched extension with identifier: com.hawksnestsoftware.securityhawkvpn.tunnel” App: com.hawksnestsoftware.securityhawkvpn, Developer ID, team A5WW6PA8WT, notarized and stapled, installed at /Applications/SecurityHawk VPN.app Extension: Contents/Library/SystemExtensions/PacketTunnel.systemextension, identifier com.hawksnestsoftware.securityhawkvpn.tunnel, CFBundlePackageType SYSX, valid and matching its designated requirement Entitlements: app has com.apple.developer.system-extension.install and the embedded profile grants it; the extension has packet-tunnel-provider-systemextension Machine: MacBookPro15,3, macOS 15.8.2 (24H232), Xcode 16.4 Observed: systemextensionsctl list shows no registration; sysextd logs show nothing for the request Codesign command: denisarsenault@Deniss-MacBook-Pro-2 ~ % codesign -d --entitlements :- "/Applications/SecurityHawk VPN.app/Contents/Library/SystemExtensions/PacketTunnel.systemextension" Executable=/Applications/SecurityHawk VPN.app/Contents/Library/SystemExtensions/PacketTunnel.systemextension/Contents/MacOS/PacketTunnel warning: Specifying ':' in the path is deprecated and will not work in a future release <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.application-identifier</key><string>A5WW6PA8WT.com.hawksnestsoftware.securityhawkvpn.tunnel</string><key>com.apple.developer.networking.networkextension</key><array><string>packet-tunnel-provider-systemextension</string></array><key>com.apple.developer.team-identifier</key><string>A5WW6PA8WT</string><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.network.client</key><true/><key>com.apple.security.network.server</key><true/></dict></plist>denisarsenault@Deniss-MacBook-Pro-2 ~ %

Filed as FB_______. Related to thread 841386 ("iOS 27: Malicious link blocked") and FB25102183, but this case involves no link at all. The user pastes the code into the Phone keypad themselves. Setup: iPhone 17 Pro Max, iOS 27.2, Verizon (forwarding code *72 + 10-digit number; GSM carriers use **21* + number + #). What our app does: our customers forward their own cell to their own business number on our service. The app never opens a tel: link, never dials and never uses Shortcuts. It shows the carrier's forwarding code, copies it to the pasteboard only when the user taps "Copy code", and guides them to paste it into Phone > Keypad and tap call themselves. That normally works. Steps to reproduce: Copy a forwarding code (e.g. *72 + a 10-digit number). It can come from any app; Notes reproduces it. Open Phone > Keypad and paste it. Don't tap call. Leave the Phone app. Come back. The keypad is empty, so tap the green call button. Redial fills the code back in. Tap call. Result: "Call Forwarding Link Blocked", with only OK and Learn More. From then on, clearing the field and pasting the same code again is also blocked, every time, until the Phone app is force-quit from the app switcher. After a force-quit, paste + call works again. To be clear: a normal paste works every time. Paste the code and tap call right away, without leaving the Phone app, and it dials and the carrier confirms forwarding. Typing the code by hand also always works. Only the leave-and-redial path triggers the block, and it then sticks until force-quit. Expected: consistent behavior. A code the user pastes or types into the keypad and dials themselves should not be treated as a "link" depending on whether redial filled the field, and the block should not persist across fresh pastes. Questions for DTS: Is a user pasting a forwarding code into the keypad and dialing it themselves a supported flow going forward, or should apps tell iPhone users to type these codes by hand? Is there, or is there planned, a supported way for an app to ask iOS to set up call forwarding to a given number, with the user approving it in system UI? Legitimate services where customers forward their own number to their own account currently have no path that doesn't look like the scam pattern this protection targets. Happy to provide a sysdiagnose or a screen recording.

Feedback ID: FB25090184 I've been tracking recurring fseventsd memory growth and slow file-change notifications on macOS 26.7.1 (25G241), with massive Bazel build trees. There seems to be a repeatable boundary inside event-table cleanup. I may be missing another reset path, but the live observations match the disassembly closely. In fseventsd 1413.160.2, ARM64E UUID CDD7E21B-7F60-3DD4-AA03-8B36745DC0F4, cleanup at RVA 0x4604 uses a 32-bit scan cursor at table+0x14. The guard at 0x464c/0x4650 skips scanning above 0xfffffdff. Each complete pass advances by 512. Bucket indexing masks the cursor, but the stored cursor keeps increasing. Starting at zero, it stops at 0xfffffe00 after 8388607 complete passes. Table resize resets the cursor. Two observed October 3 episodes reached exactly that value, accumulated zero-reference records, and recovered without a restart when the table doubled. The resize loop rehashes records rather than freeing them, so resumed cleanup after the reset seems to explain the recovery. The reviewed resize limit is 262144 buckets. On October 6, after the table reached that size, the next cursor exhaustion persisted. Physical footprint grew from 26.6 MB to 2.31 GB in about six minutes, and fresh FSEvents probes reached an 8-second timeout. A bounded walk found 199944 zero-reference records among 200000 visited. The walk was partial and unsuspended, with linkage errors; that is not a whole-heap count. Restarting only fseventsd restored advancing cleanup, approximately 5 MB footprint and millisecond probes. The client mix changed after restart, so this is not a controlled fixed-client comparison. Finder stayed running, and Desktop add/delete checks worked on both sides. An earlier stale-Desktop symptom may be a separate issue. The boundary and table-size prediction were recorded before the live observations. The Feedback report has the timeline, graphs, counter snapshots, record walks, stack excerpts, disassembly and read-only sampler source. No daemon binary or target memory was changed. Live counter access used a temporary SIP debugging exception; a severe memory/notification failure was also captured before that exception. There is not yet a small standalone workload reproducer or a patched-build comparison. Is the scan cursor supposed to wrap or reset independently of table growth? If this is the expected mechanism, is there another cleanup path that should keep reclaiming zero-reference records once the table can no longer resize?

I’m developing a watchOS application for Apple Watch Ultra 2 that continuously monitors heart rate during non-sporting activities, such as driving. The application uses: ● HKWorkoutSession ● HKLiveWorkoutBuilder ● HKAnchoredObjectQuery to retrieve heart rate samples I have observed that starting a workout session allows frequent heart rate measurements to continue even when the Apple Watch display becomes dimmed. However, this creates an unwanted side effect: although the user is not exercising, the session contributes to the Activity rings. In my tests, a workout recorded as type .other generated Exercise Minutes and Active Energy, even though the saved workout itself reported 0 active calories. The problem occurs when deleting the workout. After selecting Delete Workout & Data in the Health/Fitness interface: 1. The workout disappears from the workout history. 2. The Exercise Minutes generated during the session remain in HealthKit. 3. The Active Energy samples generated during the same interval also remain. 4. The corresponding Activity ring totals are not immediately corrected. I subsequently deleted the Exercise Minutes samples manually from the Health app. This corrected the numerical Exercise Minutes total. The Active Energy samples required separate handling. In some tests, the numerical values and the graphical representation of the Activity rings also appeared temporarily inconsistent. My questions are: 1. Is this the expected behavior of HealthKit when deleting a workout created using HKWorkoutSession and HKLiveWorkoutBuilder? 2. Why does Delete Workout & Data leave Exercise Minutes and Active Energy samples generated during the workout interval? 3. Are these samples considered independent system-generated measurements rather than data associated with the workout? 4. Is there a supported way to prevent a monitoring session from contributing to the Activity rings while still maintaining frequent heart rate acquisition in the background? My objective is to monitor physiological parameters during activities that are not exercise, without modifying the user’s fitness statistics. I would appreciate clarification about the intended behavior of these APIs and the recommended implementation approach.

I have not seen a clear answer about this: https://developer.apple.com/forums/thread/776657 https://developer.apple.com/forums/thread/743639?answerId=775701022#775701022 Thus, I would like to pose: Is there any way to install a DriverKit extension locally for development and testing using a free developer account, or is development of DriverKit extensions gated behind a paid developer account? Thank you!

I have two apps that both use Core Data. Since updating to XCode 27.1 and iOS 27 one works and one does not. Both apps have AppDelegates, SceneDelegates and CoreDataStacks that are the same, except for data entity names, etc. With App A, this works: extension StartViewController { func importJSONPlaceSeedDataIfNeeded() { let fetchRequest: NSFetchRequest<Places> = Places.fetchRequest() let count = try? coreDataStack.context.count(for: fetchRequest) guard let placeCount = count, placeCount == 0 else { return } importJSONPlaceData() } With App B, this does not work: extension StartViewController { func importBirdsJSONSeedDataIfNeeded() { let fetchRequest: NSFetchRequest<Birds> = Birds.fetchRequest() let count = try? coreDataStack.context.count(for: fetchRequest) guard let birdCount = count, birdCount == 0 else { return } importBirdsJSONData() } I get the error: Kafue_Birds/StartViewController.swift:77: Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value The line that throws the error is: let count = try? coreDataStack.context.count(for: fetchRequest) Any suggestions?

I'm developing a low-latency USB audio-MIDI driver using AudioDriverKit and USBDriverKit for macOS and iPadOS. I've observed occasional delays in USB completion callbacks. The manufacturer's official macOS driver uses IOUSBHost to queue longer isochronous transfers and update their mapped OUT buffers as audio samples become available. I've reviewed the relevant IOKit and IOUSBHost documentation, but haven't established whether USBDriverKit supports an equivalent approach. Does USBDriverKit permit modifying portions of a CreateIOBuffer OUT buffer while an IsochIO request is still pending, specifically to supply audio for future USB frames? If so, what synchronization requirements and controller-prefetch guarantees determine the latest safe time to update those regions? If this isn't supported, is there a recommended alternative for maintaining low-latency isochronous audio despite delayed completion callbacks? Thanks.

The company I work for sends large amount of traffic to APNs on behalf of our customers, with rates up to 50k/second at peek times. While a vast majority of the messages are successful or return a proper error code that we can parse and honor, roughly 1.5 million times per day our connections are being closed without warning. The networking library we use, https://github.com/hyperium/h2, is exposing these as ErrorKind::ConnectionReset or ErrorKind::BrokenPipe. From our reading of the APNs documentation, it is unclear what the correct response is when this occurs. There is no idempotency key included with our messages, so attempting to resend the message again seems frought with the potential for double sends. However, it some cases it seems clear that at least some of the messages in flight over that connection where never sent out at all. We found this open source project unconditionally retrying messages in this case. https://github.com/rpush/rpush/pull/734 Could someone from the APNs team please lay out the expected behavior a client should have when our connection is unexpected closed in this manner?

I'm building a sandboxed macOS app (Developer ID, App Sandbox enabled) with a File Provider extension that exposes on-demand placeholder files under  ~/Library/CloudStorage/<domain>/ . Expected: The app writes the placeholder file URLs to  NSPasteboard.general . The user presses ⌘V in Finder, and Finder fetches the contents on demand via  fetchContents . Observed: • Finder's own copy and paste of the same placeholders works, and  fetchContents  is called at paste time as expected. • When the sandboxed app writes the URLs to the pasteboard,  CFPasteboard  logs:  Sandbox extension creation failed ... (error -20) . The paste does not happen. • Writing  NSPasteboardItem  with  .fileURL  strings instead of  NSURL  objects produces the same error. • Adding  com.apple.security.temporary-exception.files.absolute-path.read-only  for the CloudStorage domain path fixes it. Questions: Is there a supported way for a sandboxed app to put File Provider placeholder URLs on the pasteboard without the temporary-exception entitlement? Is the temporary-exception entitlement acceptable for Mac App Store distribution, or is it only viable for Developer ID builds? Should the app grant itself access another way, for example through a security-scoped bookmark or by using  NSFileProviderManager  APIs?

We ship two iOS apps from the same team that are designed to work together: App A – uses CloudKit container "Container A" App B – uses CloudKit container "Container B" Until App B version 1.5, App B also had Container A in its com.apple.developer.icloud-container-identifiers entitlement, because it read a few records from App A's container directly. App B called registerForRemoteNotifications() for its own container's subscriptions. App A creates a CKDatabaseSubscription on the shared database (and CKQuerySubscriptions on the private database) with notificationInfo.alertBody set, so that a participant gets a visible push when the owner shares something. Problem: on devices where App B 1.5 (or earlier) had run, every push generated by App A's subscriptions is delivered to both App A and App B. App B shows a banner with App A's alert text under App B's name. This still happens after we shipped App B 1.6, which removed Container A from App B's entitlements entirely (App B 1.6 never touches that container). What we have tried on an affected device, none of which stopped the deliveries to App B: Updating App B to 1.6 (entitlement removed). Deleting App B and reinstalling it from the App Store. In App B, calling unregisterForRemoteNotifications() and then registerForRemoteNotifications() again on next launch. Rebooting the iPhone. Devices that installed App B 1.6 fresh (never ran 1.5) do not receive these pushes, so the behavior seems to come from a registration that was created while App B still had the entitlement and that is not being cleaned up. Questions: Is the association "APNs token of App B ↔ Container A" kept on the CloudKit server side, and is there any way for the app (or for us as the developer) to remove it once the entitlement is gone? If it cannot be removed explicitly, does it expire? Roughly how long after the app stops registering for that container? Is there a recommended way to design this (two apps, one container) so that alert pushes from one app's subscriptions are not shown by the other app? We would rather not switch App A to content-available pushes with local notifications, because silent pushes are not delivered reliably when the app has been force-quit. Environment: iOS 26, App A 4.7.x, App B 1.6.x, Production CloudKit environment. We have also filed a DTS request with the actual identifiers and can provide device logs or a sysdiagnose if helpful. Thank you.

I am developing a CarPlay navigation app using only public CarPlay APIs. During active turn-by-turn guidance, the app needs to keep the next planned charging stop visible and interactive so the driver can open it and review the remaining planned stops. The root template is a CPMapTemplate. The app starts a CPNavigationSession, supplies the current CPManeuver through upcomingManeuvers, and shows a CPMapPanel containing one interactive CPListItem for the next stop. let mapTemplate = CPMapTemplate() let session = mapTemplate.startNavigationSession(for: trip) session.upcomingManeuvers = [currentManeuver] let stopItem = CPListItem( text: "1. Charging stop", detailText: "4/6 available · 320 kW · 13% arrival" ) stopItem.handler = { _, completion in // Push a CPMapPanel containing the planned-stop hierarchy. completion() } let panel = CPMapPanel( title: nil, sections: [ CPMapPanelSection( title: nil, items: [CPMapPanelItem(listItem: stopItem)] ) ], buttonConfiguration: nil ) mapTemplate.showPanel(panel, completion: nil)On a wide CarPlay host, both the system-rendered maneuver/trip-estimate cards and the app's map panel occupy the leading side while a large trailing area remains free. CPMapPanel does not appear to expose a preferred side, layout priority, safe region, or collision policy. Changing the panel content and the navigation-bar buttons has not provided a vehicle-independent solution. Reproduction: Use a navigation-entitled app with a CPMapTemplate root. Start a trip and a native CPNavigationSession. Publish a CPManeuver in upcomingManeuvers. Show the interactive CPMapPanel above. Observe the system maneuver card, trip-estimate card, map controls, and map panel on a wide CarPlay host. Environment: Xcode 27.1 / iOS 27 SDK App build used for the latest vehicle reproduction: 69 A minimal UIKit/CarPlay/MapKit reproduction project is available and contains no credentials, user data, or third-party SDKs. Questions: Is a persistent interactive CPMapPanel supported while a CPNavigationSession displays maneuver guidance? Is there a documented layout contract that prevents a CPMapPanel from conflicting with system maneuver and trip-estimate cards across hosts? If panel placement is intentionally host-controlled, which public template or API is intended for a next-charging-stop entry that remains visible and interactive during guidance? Is CPMultiStopCardConfiguration in the ETA tray the intended architecture, even when the next stop should remain visible at a glance? Are there documented content or update-frequency limits that influence the panel layout? I do not want to use fixed coordinates, a custom touch overlay, or private APIs. The goal is a supported, driver-safe solution that works across different CarPlay hosts.

Environment: Sandbox Bundle ID: com.fosssocial.app Key ID: L7DZYHGM62 Issuer ID: cf1f7bc7-452f-4bb8-a925-31ca29175fac Summary Our In-App Purchase key is accepted by the App Store Server API but rejected by the Advanced Commerce API, using the exact same bearer token. This appears to be an authorization grant that was never applied to the key, rather than a signing or request-format problem on our side. Reproduction — one token, two API families GET /inApps/v1/subscriptions/1 -> 404, errorCode 4040010 (token ACCEPTED, resource simply not found) POST /advancedCommerce/v1/subscription/changeMetadata/1 -> 401, errorCode 4010000 (token REJECTED) Same JWT, same key, issued seconds apart. A 401 on one family and a 404 on the other isolates this to key authorization. On-device symptom A signed SubscriptionCreateRequest passed to StoreKit as advancedCommerceData fails with StoreKitError.unknown / "Unable to Complete Request". No payment sheet appears and no InvalidRequestError is returned, so there is no field-level error to act on. What we have already verified JWS header: alg ES256, kid, typ JWT Claims: iss, iat, aud "advanced-commerce-api", bid, nonce, request No exp claim (per Apple's documentation) The request claim uses standard padded base64, not base64url Key ID and .p8 file confirmed to be a matching pair Key regenerated after receiving the Advanced Commerce access-granted email; the 401 is unchanged AdvancedCommerceProduct(id:) resolves successfully on device, which confirms the PRODUCT has Advanced Commerce access Question Does the In-App Purchase key require a separate authorization for the Advanced Commerce API beyond the product-level access we were granted? If so, how is that applied to an existing key?

We are implementing StoreKit External Purchase Link for an iOS app distributed in the European Union and are trying to determine whether we are missing a configuration step or encountering a StoreKit server-side eligibility issue. The failure is reproducible in a focused native Swift Xcode project that directly calls StoreKit: let eligible = await ExternalPurchaseCustomLink.isEligible The sample contains no Flutter code, PayPal SDK, networking, or application business logic. Configuration we have verified: The Account Holder accepted the StoreKit External Purchase Link Entitlement Addendum for EU Apps. StoreKit External Purchase Link is enabled and shown as Assigned for the App ID. The regenerated Development provisioning profile contains com.apple.developer.storekit.external-purchase-link = true. The installed app's signed entitlements contain the same value. The application-identifier and team-identifier match the intended App ID and team. The compiled Info.plist contains SKExternalPurchaseCustomLinkRegions with all 27 lowercase EU region codes, including "de". Germany is available for the app in App Store Connect. No local StoreKit Configuration file is enabled. Test environment: Physical iPhone running iOS 26.5.2 (23F84) Xcode 26.6 (17F113) Real German Media & Purchases Apple Account German Sandbox Apple Account StoreKit 2 storefront ID 143443, country code DEU StoreKit 1 also reports country code DEU AppStore.canMakePayments = true AppTransaction verifies in the Sandbox environment Clean build and reinstall using the regenerated Development profile Observed result: ExternalPurchaseCustomLink.isEligible = false For diagnostic purposes only, after observing false eligibility, we also requested both token types: ACQUISITION: StoreKitError.notAvailableInStorefront SERVICES: StoreKitError.notAvailableInStorefront A delayed recheck still reports storefront DEU and isEligible=false. Our production flow does not request tokens unless eligibility is true. We found the similar thread "Unable to enable eligibility for External Purchase Link APIs" (https://developer.apple.com/forums/thread/808349). In that case, the production Media & Purchases account had an unsupported storefront. In our case, both the real Media & Purchases account and the Sandbox account are German, and StoreKit itself reports DEU. We also found "External Purchase in Japan" (https://developer.apple.com/forums/thread/822618), where an Apple App Store Commerce Engineer requested a Feedback Assistant report with a sysdiagnose and screen recording for isEligible=false. Questions: Should ExternalPurchaseCustomLink.isEligible return true in a developer-signed Sandbox build when the entitlement, compiled Info.plist, German storefront, and account conditions are all satisfied, or is TestFlight/App Store approval required? Is there any additional App Store Connect storefront election, entitlement approval, or server-side activation step required beyond the EU addendum, Assigned capability, signed entitlement, and SKExternalPurchaseCustomLinkRegions? If this configuration is complete, could Apple verify whether eligibility has not propagated correctly for the German Development/StoreKit Sandbox environment, and which diagnostics should be included in a Feedback Assistant report? We have also opened a code-level support request and prepared a minimal native Swift reproduction project. Any guidance from StoreKit engineering would be appreciated.

I'm implementing Wallet order tracking for a shop and have run into an update problem that I haven't been able to explain. This is the Wallet Orders web service and signed .order packages, not .pkpass passes or orders found in Mail. I've filed FB25380857 with a detailed timeline and a redacted sender example. I'm posting here because I would also like someone to check whether there's a mistake or unsupported assumption in our integration. If there is a parameter or response we should change, I'd much rather find it now than blame the OS. The short version: the phone receives our APNs message almost immediately, but sometimes doesn't ask our server for the updated order for hours. Once it finally makes the request, the package downloads, applies and produces the expected notification normally. How the service is set up Orders are added from Safari using the Wallet button. There is no separate native app. Registration succeeds, and the phone initially downloads and displays the order. We send to the production APNs endpoint over HTTP/2, using the Order Type certificate and key. The topic matches the Order Type ID. The request body is exactly {}. Our normal sender leaves the priority at its default of 10, and for the tests below I explicitly set it to 10. The push-type header is omitted. TLS verification is enabled, and apns-expiration is set to the current time plus one hour. The effective request is: POST https://api.push.apple.com/3/device/<registeredPushToken> apns-topic: <orderTypeIdentifier> apns-priority: 10 apns-expiration: <currentEpochPlus3600> content-type: application/json {}Each update keeps the same order ID, authentication token, webServiceURL and createdAt. updatedAt is an RFC 3339 timestamp and strictly increases. The device registration endpoint returns 201/200. The changed-orders endpoint returns lastModified and the registered orderIdentifiers, or 204 if nothing has changed. The package endpoint returns the signed .order with the finance.order MIME type, Last-Modified and conditional 304 support. The changed-orders response is no-store, and the package response is private, max-age=0, must-revalidate. One detail I'm unsure about: our isolated test orders share one Order Type ID, but each test has its own stable webServiceURL. Is that supported, or should all orders under an Order Type use the same service URL? The affected phone's diagnostic build is 24B119, listed in Feedback Assistant as iOS 27.2. The Wallet logging profile was already installed before these tests, and the phone had been restarted. These are synthetic orders, with no real purchase or carrier operation. The longest delay we captured Times below are local, Europe/Budapest, UTC+01:00, on October 30–31, 2026. October 30, 18:43:56: the screen is off. 18:44:16: we change the order from ready for pickup to picked up/completed and send the update signal. APNs returns 200. 18:44:16.903: apsd receives the message. At .905, financed logs receipt in both its Push and Orders handlers for our exact Order Type. No immediate Orders task or changed-orders request follows. Normal confirmation retries go out at 18:55:02 and 19:05:02. October 31, 10:53:22–23: Wallet enters the foreground and becomes active. 10:53:25.884: pending Orders work starts. 10:53:26: the phone asks for changed orders and downloads the pending package with HTTP 200. 10:53:27: the phone logs that it applies the update and schedules the notification. The picked-up notification appears. That is 16 hours, 9 minutes from the first signal to the package response. There was no new signal from our server that morning. I had opened Wallet, but did not deliberately pull to refresh; I can't completely rule out an accidental gesture. I therefore don't want to claim that opening Wallet alone is a reliable workaround. We have also captured a shipping update that took about 41 minutes, and another completion update that took almost two hours despite the phone being locked before the send. In that second case, the logs show a previously scheduled Orders task running just before the successful fetch, rather than a new push arriving then. An explicit manual pull can fetch the same pending package promptly. For comparison, a new order on another iPhone made its changed-orders request and downloaded an update within three seconds. We have not yet confirmed the visible result on that phone, and it was only a processing-description change, so it isn't an equivalent fulfillment-notification test. We tried explicit priority 10, an alert push-type control, and one background/priority-5 control. They did not produce an immediate fetch in the captured windows. A separate content-available payload experiment also reached the handler without starting a fetch; that is not our normal payload and hasn't been deployed as a fix. The full report keeps these controls and normal retries separate. What I'd like to understand Is the APNs request above correct for Wallet Orders? Are we missing a required header, payload detail or registration step? Could the shared Order Type with different webServiceURLs cause this, even though the same order updates successfully after a manual pull or later task? Is there a supported way to recover when a received update signal leaves the changed-orders request pending for hours? What conditions should we check before sending more signals or asking users to re-add an order? What further diagnostic would be useful? We have retained the original phone's sysdiagnose and separate log archives for these events and can provide them privately through the Feedback report. A 15–30 minute delay would be acceptable for our parcel-status use case. An order still showing ready for pickup the next morning is a different problem. I'm not suggesting Apple promises a particular delivery time; I'm trying to find out whether we can make this integration reasonably dependable, and what we need to correct on our side. No keys, device/push tokens, customer information or full device logs are included in this post.

Hello, I’m investigating a persistent StoreKit 2 restoration issue in My Drop Music. I would appreciate help identifying the cause or collecting more useful diagnostics. Environment: iPhone 17, iOS 26.6.2 TestFlight version 6.22.60 (62260.12) Transaction environment: Sandbox Storefront: USA, currency: USD What works: Product.products(for:) returns both expected non-consumable products. The full-unlock product returns a price of USD 6.99. The free trial product returns a price of 0. Transaction.currentEntitlements returns verified transactions for both products, with no unverified transactions reported. The app recognizes full access. What fails: When I tap “Restore purchases,” AppStore.sync() fails with StoreKitError.unknown. An Apple authentication prompt appears during restoration, but the operation still fails after submitting credentials. Latest diagnostic output: My Drop Music 6.22.60 (62260.12) iOS 26.6.2 Storefront=USA; currency=USD AppStore.sync=failed Kind: StoreKitError.unknown Reference: StoreKit.StoreKitError:2 Before: cached app state: full=true; trialPresent=true After: full=1; trial=1; unverified=0; environment=Environment(rawValue: “Sandbox”) Tests already performed: Reproduced over both Wi-Fi and cellular. Signed out of and back into Media & Purchases. Modified the restoration flow so AppStore.sync() is the first awaited operation after the user taps Restore. Entitlement and storefront diagnostics are collected afterward. The failure persists. Created a separate Sandbox tester. Attempting authentication with that tester produced a system alert saying “Verification Failed — An unknown error occurred.” I have not established whether that is the same underlying issue. I currently have only one iPhone available for testing. Does this pattern suggest any specific account, device, or integration checks? Which device logs or additional error details would help distinguish a Sandbox authentication issue from an app integration issue? I am not assuming this is an Apple bug; I’m trying to determine the cause. Thank you!

I would like to understand the relationship between an iOS app's memory footprint and the memory limit used by os_proc_available_memory(). Device: iPhone 15 Pro Max (iPhone16,2). The reported OS is iOS 18.5 (22F76), but the accompanying diagnostic metadata lists iOS 17.5.1 (21F90). The OS version for this incident is not yet confirmed. This was a very rare occurrence. We do not have reliable reproduction steps. In the first 26 recorded samples, footprint + os_proc_available_memory() is approximately 6,442,450,944 bytes (6 GiB). In the final four samples, os_proc_available_memory() is 0, but footprint continues to increase. From the first zero-available-memory sample to the last sample: Elapsed time: 2.928 seconds. Footprint: 6,510,375,920 to 7,245,821,920 bytes. Additional footprint: 735,446,000 bytes (735.446 MB). Questions: Why could the app continue allocating memory after its footprint exceeded the apparent memory limit, with footprint continuing to increase for the interval shown above? The os_proc_available_memory() documentation says the function returns 0 if the process has already exceeded its memory limit. Under what circumstances can a process exceed that limit and still continue running and calling this function? The documentation also says memory limits can change during the app life cycle and do not necessarily correspond to the physical memory available on the device. What specific conditions cause this limit to change? Documentation: https://developer.apple.com/documentation/os/os_proc_available_memory All 30 samples are below. Timestamps are Unix milliseconds; both memory columns are in bytes. Commas within numbers are thousands separators. timestamp_ms | footprint (bytes) | os_proc_available_memory (bytes) 1,793,468,915,891 | 2,107,497,360 | 4,334,953,584 1,793,468,916,891 | 2,035,637,136 | 4,406,813,808 1,793,468,917,891 | 1,931,844,544 | 4,510,524,480 1,793,468,918,891 | 1,311,349,696 | 5,131,101,248 1,793,468,919,891 | 1,310,268,352 | 5,132,182,592 1,793,468,920,891 | 1,297,144,768 | 5,145,306,176 1,793,468,921,891 | 1,315,003,328 | 5,127,447,616 1,793,468,922,891 | 1,330,895,856 | 5,111,489,552 1,793,468,923,891 | 1,783,930,080 | 4,658,504,480 1,793,468,924,891 | 2,133,515,728 | 4,308,836,912 1,793,468,925,891 | 2,441,863,040 | 4,000,571,520 1,793,468,926,891 | 2,710,790,352 | 3,731,611,440 1,793,468,927,890 | 3,127,452,336 | 3,314,933,072 1,793,468,928,890 | 3,348,341,760 | 3,093,961,728 1,793,468,929,891 | 3,573,834,992 | 2,868,615,952 1,793,468,930,891 | 3,918,456,384 | 2,523,879,872 1,793,468,931,891 | 4,149,520,272 | 2,292,815,984 1,793,468,932,891 | 4,449,937,680 | 1,992,513,264 1,793,468,933,891 | 4,729,449,104 | 1,713,001,840 1,793,468,934,891 | 4,902,857,600 | 1,539,478,656 1,793,468,935,891 | 5,146,340,608 | 1,295,733,504 1,793,468,936,891 | 5,348,453,920 | 1,093,997,024 1,793,468,937,891 | 5,625,376,624 | 816,976,016 1,793,468,938,891 | 5,820,412,000 | 621,580,192 1,793,468,939,891 | 6,099,595,696 | 342,855,248 1,793,468,940,891 | 6,284,112,592 | 158,272,816 1,793,468,941,963 | 6,510,375,920 | 0 1,793,468,942,890 | 6,765,426,032 | 0 1,793,468,943,891 | 7,088,387,872 | 0 1,793,468,944,891 | 7,245,821,920 | 0

Does Apple provide a supported public API or entitlement for an App Store iPhone app to simulate the system location consumed by other apps entirely on-device? Would using a bundled Network Extension and on-device developer pairing remain restricted to development/testing workflows?

We run a live App Clip used by cafes in Saudi Arabia. Customers scan a QR code at the counter to follow their order. Some customers stay on the blurred loading screen for about a minute, then get App Clip Unavailable. One cafe reported more than five cases in its first days, and I watched another happen at a cafe today, on an iPhone showing 5G with Low Power Mode on. Try Again did nothing when we tested it, and a new scan opened the clip at once. I reproduced it in 1 of 6 fresh downloads on an iPhone 17 Pro Max (build 23F84) on mobile data. The log shows: appstored starts the download from iosapps.itunes.apple.com over HTTP/1.1 on IPv6, with timeouts(60.0, 604800.0). TCP and TLS succeed and the request is sent. 71 ms later a TCP RST arrives with a stale sequence number, and the stack drops it as out of window. Retransmits go unanswered. response_bytes=0, then NSURLErrorDomain -1001 after 60.4 s. The install is cancelled, with no second attempt. A parallel HTTP/3 request finished in 414 ms, so the network was up. The clip is about 0.7 MB, and both App Clip experiences are published. Today I got the same stall without an iPhone. A Mac on an iPhone hotspot on STC mobile (AS39386) ran curl, opening a fresh HTTP/1.1 connection each time: iosapps.itunes.apple.com: IPv6 17 of 231 stalled, IPv4 0 of 89 stalled updates.cdn-apple.com: IPv6 5 of 60 stalled, IPv4 0 of 60 stalled www.apple.com, on a different CDN: IPv6 0 of 115 stalled, IPv4 0 of 85 stalled Each stall looks the same: TCP and TLS finish, the request goes out, and no response byte comes back. The stalls hit many edge addresses. One edge, frmrs1-vip-bx-005, answers on both 2a01:b740:a11:f000::203 and 17.253.122.203, and it stalled on IPv6 only, so this looks like the IPv6 path rather than a bad node. This is one SIM over 17 minutes, and I haven't tested other carriers yet. Repro from a Mac on an STC mobile hotspot: for i in {1..60}; do curl -6 --http1.1 -s -o /dev/null -m 10 -I -w '%{http_code} %{time_starttransfer}\n' https://iosapps.itunes.apple.com/; sleep 4; doneMy questions: Is there anything a developer can do to avoid this or recover from it? Is this a known issue with IPv6 to Apple's edge from Saudi mobile networks? Could someone from the App Clips or edge network team look at FB25380604? It stops real customers at the counter, so it's urgent for us.

Filing this for engineering visibility and to ask whether the observed behavior matches expected M5 Pro DCP architecture. FB22701284 contains full sysdiagnose and supporting data. Hardware Configuration MacBook Pro 16-inch (Mac17,8) M5 Pro chip, 18-core CPU 64GB unified memory (highest M5 Pro memory tier) 1TB SSD macOS Tahoe 26.4.1 (build 25E253) AppleDCP-1041.100.97~429-t605xdcp.RELEASE Display Configuration Two identical LG UltraGear 27GM950B monitors: 27" Mini LED panels, native 5120x2880 DisplayPort 2.1 UHBR20 (80 Gbps capable) 165Hz native refresh, HDR-capable Connection topology (all third-party display software removed for clean test): Mac TB5 port 1 → Silkland DP80 USB-C cable (VESA-certified) → Monitor #1 USB-C input Mac TB5 port 2 → Silkland DP80 USB-C cable (VESA-certified) → Monitor #2 USB-C input DisplayLink Manager fully uninstalled No dock, no MST hub, no signal converters Apple Specification Context Per the MacBook Pro user guide, M5 Pro supports dual displays at 5K@120Hz (support.apple.com/guide/macbook-pro/apd8cdd74f57/mac), with the documented instruction to "connect the display with the highest resolution first." Observed Behavior Solo connection (either monitor) Either monitor in isolation: 5120x2880 @ 144Hz, Maximum Source Bandwidth 27,400 Mbps, 10-bit, HDR enabled. Dual connection (BetterDisplay 4.3.3 diagnostic) Monitor on dispext0@B0000000: 5120x2880 @ 144Hz, Maximum Source Bandwidth: 27,400 Mbps, HDR enabled Monitor on dispext1@90000000: Degraded from native 5K, Maximum Source Bandwidth: 13,700 Mbps, HDR disabled The 27,400/13,700 split is deterministic and follows connection order. Hardware substitution (cables, ports, monitor positions) confirmed the allocation follows position in connection order, not specific hardware. Each monitor achieves full 27,400 Mbps when solo. Per-pipe budget structure exposed in BetterDisplay 4.3.3 Recent BetterDisplay versions expose allocation limits in display reports: Allocation limits - horizontal: 3360, 3840 pixels HiDPI (6720, 7680 pixels LoDPI) Allocation limits - vertical: 2304 pixels HiDPI (4608 pixels LoDPI) This matches the per-sub-pipe budget structure documented in third-party M5 Max DCP firmware analysis, where M5 Max shows MaxSrcRectWidthForPipe = (6720, 7680, 7680, 7680). M5 Pro appears to expose only two values (6720, 7680). WindowServer assertion failure WindowServer crash on 2026-05-16 with assertion failure in the function calculating per-pipe maximum source rectangle widths: Thread 16 Crashed: com.apple.coreanimation.render-server CA::WindowServer::AppleDisplay::max_src_rect_width_by_pipes(unsigned char) const + 92 CA::WindowServer::AppleDisplay::max_src_rect_pixels() const + 60 CA::WindowServer::Server::get_display_info() + 1812 Exception: EXC_CRASH (SIGABRT), Abort trap 6. This is the same function third-party DCP firmware analysis identifies as governing the per-sub-pipe budget calculation. Reference to Existing Thread Apple CoreOS DTS Engineer Kevin Elliott in thread 814201 (https://developer.apple.com/forums/thread/814201) described M5 MacBook Pro display architecture: "Driving the display at 240Hz require both of the two display 'pipes' and the system ends up allocating both pipes to the first monitor it discovers. That prevents it from lighting up the second monitor, as there isn't currently any way for software to shift allocations of display pipes between machines." That thread addressed a single-display 4K@240Hz scenario where the second display failed to initialize. The underlying allocation mechanism (first-come-first-served pipe assignment, no dynamic reallocation) appears consistent with the dual-display configuration I'm observing, with the manifestation differing (both displays initialize but the second is bandwidth-constrained rather than absent). Specific Technical Questions Is the 27,400/13,700 Mbps asymmetric allocation observed on dual 5K configurations the expected manifestation of the two-pipe architecture described in thread 814201, or a distinct allocation policy specific to dual-display scenarios? The advertised dual 5K@120Hz capability requires approximately 28 Gbps per stream. The observed allocation appears insufficient to drive both displays at this specification simultaneously. Is there a configuration approach that allows both displays to receive adequate bandwidth allocation? Multiple sources document that M5 Max has more display engine output channels than M5 Pro. Is the architectural difference between M5 Pro and M5 Max sub-pipe count (per the BetterDisplay allocation limits and third-party firmware analysis) the underlying explanation for the differential dual-display capability? The WindowServer assertion failure in max_src_rect_width_by_pipes() — is this a known edge case for dual high-bandwidth display configurations on M5 Pro, or should this be filed as a separate issue from the bandwidth allocation behavior? Supporting Data Available BetterDisplay 4.3.3 diagnostic reports for both monitors WindowServer crash report (2026-05-16) ioreg output showing DCP unit assignments sysdiagnose attached to FB22701284 Happy to provide additional FB tickets with focused diagnostic captures if specific data would help engineering investigation.

Filed as FB24069273. Sandbox POST /inApps/v1/notifications/test consistently returns 404 {"errorCode":4040007} for our app (Apple ID 6765662617), although GET /v1/apps via the App Store Connect API confirms both subscriptionStatusUrl and subscriptionStatusUrlForSandbox are set (V2). With the same JWT, sandbox POST /inApps/v1/notifications/history returns 200 with an empty history — so the key and app resolve correctly. No organic sandbox notifications have ever been delivered, despite active TestFlight sandbox subscription activity. Exhausted remediations (4040007 persists after each, with 30-60+ minute waits): Re-saving the URLs in the App Store Connect UI (two locales) Deleting and re-adding the Sandbox URL PATCH /v1/apps setting the sandbox URL + version V2 twice, with two different valid endpoints (verified by GET each time) Removing the Sandbox URL entirely to rely on the documented Production fallback Deleting BOTH URLs, waiting a full hour, and re-creating them from scratch Testing with both an App Store Connect team key and a freshly generated In-App Purchase key — identical results Endpoints are publicly reachable (HTTPS, TLS 1.2+, port 443). Production App Store Server API returns 401, which we understand is expected for an app not yet released. This looks like a desync between App Store Connect metadata and the notification delivery registry consulted by the test-notification endpoint. Any help would be appreciated.