MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?

Summary Sandbox purchases of our first auto-renewable subscription fail with "This item cannot be found". Product metadata loads correctly, so this looks specific to commerce. Our App Store Connect configuration is complete and has been verified exhaustively, and four other apps on the same team sell in-app purchases in production without issue. The affected app has never been submitted or released, and the subscription sits in "Ready to Submit". Symptoms On device (TestFlight build, purchasing with the tester's real Apple Account - no sandbox Apple Account is configured, per the documented TestFlight flow), a purchase attempt returns storeProductNotAvailable and the system alert "Item Unavailable". Device logs (idevicesyslog) show: mzstorekit-sb.itunes.apple.com/inApps/v2/history -> HTTP 404, (4040004) App not found sandbox.itunes.apple.com/.../inAppBuy -> AMSErrorDomain 305, AMSServerErrorCode=3504, "This item cannot be found" Product.products(for:) returns the product and the paywall renders product.displayPrice, so product metadata resolves. Only the purchase fails. Server-side observation Using the App Store Server API in the sandbox environment with our team key, requesting a deliberately non-existent transaction ID: GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/history/1234567890 App Products Released? Result The affected app 1 subscription, Ready to Submit never HTTP 401, empty body Another app, same team non-consumable, Approved yes 404 4040010 Transaction id not found Another app, same team 2 non-consumables, Approved yes 404 4040010 Transaction id not found Another app, same team 2 non-consumables, Approved yes 404 4040010 Transaction id not found Another app, same team non-consumable, Approved yes 404 4040010 Transaction id not found Same key, same issuer, same team, same request shape - only the bid claim differs. We note openly that this is not a clean experiment: all four comparison apps differ from the affected app in two ways at once (they are released, and they have approved products), so the 401 may simply reflect an app with no approved commerce products rather than a missing app record. We include it because the difference is stark and reproducible, not because we think it is conclusive. What makes this app different Being unreleased does not by itself appear to be the barrier: we were able to test the in-app purchases of the four apps above in the sandbox before those apps were released. The difference we cannot account for is product type and approval state - those were one-time non-consumables, whereas this is our first auto-renewable subscription, which App Store Connect tells us "must be submitted with a new app version" and which has therefore never been approved. Timeline 2026-07-30 ~00:30 CEST - Pricing and Availability set for the app (it had been unset; that was the cause of an earlier, separate failure). 2026-07-30 09:26 CEST - captured the device logs above. 2026-07-31 00:50 CEST - toggled a territory's availability off and back on to force a re-propagation of the availability record. No change. 2026-07-31 - still failing 24+ hours on. Automated probes every 30 minutes throughout have returned the same result without exception. This is well beyond the "up to 1 hour" propagation window documented in TN3186. Already verified Account level - four other apps on this same team currently sell in-app purchases in production: Paid Apps agreement: Active Banking and tax information: complete and active App Store Connect configuration for the affected app: App availability: 175 of 175 territories, none excluded Subscription availability: 175 of 175 territories Subscription priced in all 175 territories Four localizations and the review screenshot present; group localized; subscription state Ready to Submit App price: Free Every territory reads CANNOT_SELL / AVAILABLE_FOR_SALE_UNRELEASED_APP, consistent with an app that has not yet been released Client / build: Product ID in code matches App Store Connect exactly Explicit App ID (no wildcard), In-App Purchase capability enabled Build signed with Apple Distribution, delivered via Transporter, tested from TestFlight (not a development build) No StoreKit configuration file active in the scheme Bundle ID matches the App Store Connect record Questions Is the subscription provisioned for commerce in the sandbox environment? The (4040004) App not found response suggests the app or its commerce record is not present there. TN3186 states that sandbox testing does not require submitting in-app purchases for review. Does that hold for an app's first auto-renewable subscription, given that such a subscription must be submitted alongside an app version and so cannot reach an approved state beforehand? If submitting the app version together with the subscription is in fact the prerequisite, please confirm - we are currently holding our submission specifically so we can complete one successful sandbox purchase first, since App Review purchases through this same environment. If that ordering is not possible, we would rather submit and have App Review encounter the working production path than keep waiting on a sandbox purchase that cannot succeed. Happy to provide the app's Apple ID and product identifier privately if that helps.

Across two completely separate App IDs under the same Apple Developer Team, calling registerForRemoteNotifications() (via a standard push-notification plugin wrapping this exact API) resolves successfully — but afterward neither application(:didRegisterForRemoteNotificationsWithDeviceToken:) nor application(:didFailToRegisterForRemoteNotificationsWithError:) is ever called. No token, no error. Registration just stalls permanently. Environment Xcode 26.4.1 Distribution: TestFlight (App Store distribution profile → production APNs environment) iOS on all test devices: current release The key finding This isn't specific to one app. I reproduced the identical failure on: Our primary app's App ID, which has existed for a while and had Push Notifications enabled after initial creation. A brand-new, throwaway App ID created from scratch specifically to test this, with Push Notifications capability checked at creation time (no toggling after the fact, no history at all). Both show the exact same symptom: register() resolves, then silence — no callback of either kind, ever. Since this reproduces identically on an App ID with zero prior history, it rules out anything specific to one app's configuration or App Store Connect record, and points at something at the Team level with APNs backend authorization. What I've ruled out Entitlements/provisioning are correct and matching, verified via direct inspection of the signed binary: codesign -d --entitlements :- MyApp.app and the provisioning profile's own entitlements: security cms -D -i MyApp.app/embedded.mobileprovision | plutil -extract Entitlements xml1 -o - - Both show identical, correct values — aps-environment: production, correct application-identifier, correct team-identifier. Reproduced identically across: 2 separate App IDs (one long-standing, one brand new) 2 different physical iPhones 2 different WiFi networks 2 different accounts/user sessions within the app Already tried with no change in behavior: Enabling Push Notifications after initial App ID creation, vs. checking it at creation time on the fresh App ID Toggling the capability off/on and regenerating the provisioning profile Generating multiple fresh App Store distribution profiles Confirmed the Distribution certificate referenced is correct and valid Client code confirmed correct via instrumented logging at every step (permission check → permission request → listener attachment → register() call). Every step up to and including register() resolving completes exactly as expected. The stall is strictly after that point, entirely on the OS/APNs side. What I'm trying to determine Given this reproduces on a completely fresh App ID with no history, I believe this points at something about how APNs backend authorization is provisioned for this Developer Team as a whole, rather than any individual App ID's configuration. Has anyone seen this exact symptom — registration call succeeding but zero callback of either kind — and found a resolution that wasn't visible from anything in the Developer Portal or Xcode? Filed as Apple Developer Support case 20000117948923 — happy to share any additional diagnostics.

We're currently having an issue with our app where the review prompt is displaying for the user too often. I know the documentation says that: If the person hasn’t rated or reviewed your app on this device, StoreKit displays the ratings and review request a maximum of three times within a 365-day period. If the person has rated or reviewed your app on this device, StoreKit displays the ratings and review request if the app version is new, and if more than 365 days have passed since the person’s previous review. From this post I can see that there's an updated API that is recommended AppStore.requestReview(in:). Is there a currently known bug with the SKStoreReviewController version that would cause the review prompt to display outside of the limitations? Locally we're seeing a limit of 3 prompts in the same session but a few days later, we get the same 3 prompt limit when it's should have been limited for another year. Does using the AppStore version just fix our issue? Is it actually a different API?

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.

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.

Hello Applet, I’m experiencing an issue with StoreKit on a TestFlight build. My app uses auto-renewable subscriptions through StoreKit and RevenueCat. Configuration already verified: App installed through TestFlight (not debug). Bundle Identifier: com.ciborgu.vytalai Paid Applications agreement is active. In-App Purchase capability is enabled. Three auto-renewable subscriptions exist in App Store Connect. Product IDs match exactly between App Store Connect, RevenueCat and the application. RevenueCat initializes successfully. A Sandbox test account has been created. Tested on a physical iPhone. Device restarted and app reinstalled from TestFlight. VPN and iCloud Private Relay disabled. When attempting to purchase a subscription, the Apple payment sheet never appears. Our diagnostics indicate that StoreKit does not return any available products for the configured Product IDs, preventing the purchase sheet from opening. Expected Product IDs: vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro Could you please verify if there is any issue with the App Store Connect configuration, StoreKit availability, or the processing state of these subscriptions on Apple’s side? If additional logs or diagnostics are required, I can provide them. Thank you. I have already contacted Apple Developer Support regarding this same issue. Previously, I was advised to schedule a technical support meeting. However, when I requested the meeting, my request was declined because of the subject of my issue, so I was unable to speak with an Apple engineer. Since I have now completed all the recommended troubleshooting and the issue still persists, I would greatly appreciate it if this case could be reviewed by the appropriate technical team or a StoreKit engineer. Thank you for your assistance.

Need to vent a bit before relaxing for Christmas... WatchOS IAP using Storekit 2 is such a mess...is nobody actually using this or does Apple just not care for the user experience here? Lots of users experience after the purchase confirmation double tap on the side button an instant return to the purchase screen with nothing actually happening. No error message whatsoever. There is just one remedy: users need to unpair and re-pair their watch, including restoring a backup and setting up their wallet again. Nobody really wants to do this, or doesn't believe me and think this is just typical support BS, because their watch is paired and most things just work as they expect. And it turns away a customer, often leaving a bad review. And I can't do anything about it. Other errors in the purchase process are reported, but like "process interrupted" in case the payment is not setup correctly (credit car no longer valid or sth.). How should the user know? There must be better ways of letting him know what exactly the problem is. You need to implement a "Restore Purchase" function, otherwise you're not passing the review. But it really asks every time for the AppStore password, and users with crazy passwords -- that they rightfully should have! -- have almost no chance of typing them successfully on the tiny AW keyboard. Why is it not also just a side button double tap like for purchase? At the very least you would need access to the keychain PWs or allow pasting of sth. copied on the paired iPhone. Promo Codes for IAP on AW-only apps just don't work. AW has no redemption at all, and on the iPhone the AppStore will try to talk to a companion app (which AW-only doesn't have) and the end up in a dead-end installation effort. This all feels like never really tested in the field, and people are of course blaming the 3rd party dev. for all these issues. And opening a ticket is just leading nowhere -- at best it's closed after months with the hint "duplicate" but w/o any chance for me to see that one that they then actually work on and track progress. It's all so frustratingly broken...

I'm testing an In-App Purchase for the Indonesian storefront. In App Store Connect, the price is configured as Rp 1,299,000, and it is displayed correctly there. However, in the Sandbox purchase sheet, the price is shown as "Rp 1,299 juta" instead. I understand that "juta" means million in Indonesian. However, I'm not sure whether displaying the price as "Rp 1,299 juta" is the expected localization for users. Any confirmation or experience would be appreciated. Thank you!

I want to know the right way/API/usage to use NWConnectionGroup to send both datagram and non-datagram stream. I am currently working on an P2P video streaming app. I want to leverage NWConnectionGroup over QUIC to handle both message channel (traditionally handled by a TCP connection) and media channel (traditionally handled by sth. over UDP) to transmit SRT packets back and forth. I created a NWConnectionGroup and it worked fine on non-datagram parts. The problems are with datagram part. I tried extracting a connection with datagram = true either from the group or from message, doesn't and in some cases it breaks other non-datagram connections. I currently send datagram directly using the NWConnectionGroup.send(content:completion). It kinda works but I keep seeing it canceled a lot of messages, which breaks SRT shortly after start. The warnings belong flooded my console. (Seems like want me to create a connection to transmit datagram, how?) nw_connection_create_with_connection [C1600] Original connection not yet connected nw_connection_group_create_connection_for_endpoint_and_parameters [G1] failed to create connection with parameters quic, local: fe80::439:68b4:6ec2:694%en0.60517, definite, attribution: developer, server I must use it in wrong way. What should I do to fix it?

Hi everyone, Have anybody faced with Core Data issues, trying to migrate the project to Xcode16 beta 4? We are using transformableAttributeType in some entities, with attributeValueClassName = "[String]" and valueTransformerName = "NSSecureUnarchiveFromData". It is working just fine for years, but now I am trying to run the project from Xcode16 and have 2 issues: in Xcode logs I see warning and error: CoreData: fault: Declared Objective-C type "[String]" for attribute named alertBarChannels is not valid CoreData: Declared Objective-C type "[String]" for attribute named alertBarChannels is not valid periodically the app crashes when we are assigning value to this attribute, with error: Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds' Once again, in Xcode 15 it works fine, and it was working for years. Cannot find any information about what was changed in the framework... Thank you in advance for any information, which could clarify what is going on.

I've been investigating memory consumption issues with a network extension. It seems as though the "leak" exists within the network extension framework. Looking at a memory graph, there appears to be a _socketFlows dictionary or similar in the network extension framework that holds all of the flows and they continue to pile up and consume memory. The problem seems to be particularly bad when I leave my MacBook plugged in and running over the weekend and come back on Monday. For instance, in that time period, the memory consumption grew from <100MB to >1GB. To try to narrow this down to see if it was an "us" problem or truly in the framework, I installed Objective-See Foundation's Lulu tool, which also uses a network extension. It similarly saw memory grow from around 30MB or less to 600MB in the same time frame. Has anyone else seen this? We do have an open feedback ticket FB18731867 that might be related that has to do with seeing multiple instances of the same data filter provider started and maybe running in a network extension.

Hi, Feedback: FB23494579 Using StoreView / ProductView on iOS 27.0 simulator / device hub throws the following error: Error: Accessing State<ProductViewEventConfiguration>'s value without being installed on a View. This will create a new ProductViewEventConfiguration instance each time. Environment macOS 26.5.2 (25F84) Xcode 27.0 beta 2 (27A5209h) Simulator / Device Hub - iPhone 17 Pro (iOS 27.0) Screenshot

Could you help clarify the expected behavior in downgrade scenarios during a Free Trial period? Does Apple trigger billing immediately for the downgraded plan, or does the change take effect only after the Free Trial window completes?

Our iOS app runs in the peripheral role. A hardware accessory acts as the central: it connects to the app and bonds in order to read and write characteristics we declare with encryption-required permissions. The app advertises so a previously bonded accessory can reconnect on its own. The problem is that the bond lives on both sides and we can only clear one of them. The accessory has its own "forget this phone" function, and it can also be told to do so remotely. iOS keeps its half, and we have not found any way for the app to remove or invalidate it. What we've checked: CBPeripheralManager and CBCentral expose no unpair or unbond operation. A CBCentral is only visible while connected or subscribed, and its identifier is a resolved handle. Questions: Is there a supported way for an app in the peripheral role to remove or invalidate the pairing keys for a bonded central? If we've missed an API, please point us at it. If not, what's the recommended approach when the peer has discarded its keys and the bond is no longer usable? Can a peripheral-role app detect that state — a distinguishable error or connection event when encryption fails — so we can tell the user something accurate instead of a generic connection failure?

I am developing a dext that is running into issues pertaining to IOConnectMapMemory (at least I think so). There are 3 parts of code that are involved, the dext (which allocates the memory in the first place), a user client library which is involved in connecting to the dext and releasing when the hardware is removed, and finally some processing code (at the user level) which executes on this shared block of memory from the dext. The shared memory is allocated using an IOBufferMemoryDescriptor: IOBufferMemoryDescriptor::Create(kIOMemoryDirectionNone, sizeof(sharedMemoryBlock), IOVMPageSize, &(ivars->mSharedMemoryBlockMemDesc)); The User Client Library acquires a mapped pointer to this memory by calling IOConnectMapMemory: IOConnectMapMemory(mConnect, kMemoryType_SharedMemoryBlock, mach_task_self(), (mach_vm_address_t*)&mUserClientSharedBlockPtr, (mach_vm_size_t*)&mSizeOfUserClientSharedBlock, kIOMapAnywhere); …which triggers the dext’s IOUserClient subclass' “CopyClientMemoryForType_Impl”. That code adds a retain and returns a pointer to the IOBufferMemoryDescriptor: case kMemoryType_SharedMemoryBlock: // error checks first (make sure it’s allocated and initialized, etc) ivars->mSharedMemoryBlockMemDesc->retain(); *memory = ivars->mSharedMemoryBlockMemDesc; break; IOConnectMapMemory returns the “mapped pointer” (in mUserClientSharedBlockPtr) to the User Client Library, which in turn provides it to the processing code. The processing code checks the pointer validity, and if valid, runs its processing. This worked fine with a kext implementation. This fails with dext implementation, because during the processing call (after validity check but during usage) the mapped pointer can become NULL, which seems to be against the design pattern, and causes the application to crash due to an access violation (dereferencing NULL). I assume I am doing something incorrect here, but I’m not seeing what it is. The memory was retained, so it should not be deleted until the User Client Library has released it, but the only release available would be IOConnectUnmapMemory, and that fails with “invalid argument” (0xE00002C2) after the device is hot-unplugged. I am not finding IOConnectMapMemory examples on developer.apple.com. I have verified via the forums that IOConnectMapMemory is still a recommended practice with DriverKit development: https://developer.apple.com/forums/thread/803947?answerId=862249022#862249022 . What’s the trick here for stability? The device is a peripheral which can be unplugged or turned off at any time, which would result in the dext and user client library code tearing down the structures and memory, but it should be able to do so safely without causing access violations. (Note, this has been simplified for the purpose of focusing the question, in reality there are 4 separate memory blocks which are shared in this fashion: two ring buffers, main engine status, and client status. They each use their own memory_type definition, but a general solution is needed and can be applied to all 4, and there can be multiple clients at any point in time).

I'm developing a macOS product that generates verifiable audit records of media-asset movement on endpoints, for professional media-production companies. It is not an antivirus or Data Loss Prevention product; it collects operating-system file-system events and converts them into tamper-evident audit evidence and audit reports. Target users need comprehensive endpoint audit trails for compliance with industry security standards, including Motion Picture Association Trusted Partner Network assessments. The product must reliably distinguish these operations: file copy, move, rename, and volume mount and unmount — including on external volumes. I've reviewed existing forum guidance, including Quinn's explanation that FSEvents only signals that "something changed" rather than the exact operation, and that it is designed around Spotlight and Time Machine semantics. In my own testing I've also seen inconsistent flags across cp, Finder copy, and application saves, and frequent kFSEventStreamEventFlagMustScanSubDirs events on external drives even when nothing along the path changed. Questions: Given the above, for an audit product that must reliably distinguish copy vs. move vs. rename, should FSEvents be treated as structurally unsuitable, with the Endpoint Security Framework adopted instead as the primary source? For capturing volume mount and unmount operations, is the Endpoint Security Framework the recommended source, or should this be combined with Disk Arbitration? Are there long-term supported APIs recommended for this type of endpoint audit product, to ensure compatibility with future macOS releases? Any recommended documentation, WWDC sessions, or sample code for this use case would be appreciated. For context, I'm building toward a System Extension using the Endpoint Security Framework and will file the entitlement request separately; this post is to confirm the architectural direction before committing. Thank you.

I am experiencing an issue with a non-consumable in-app purchase in my iOS app. The product loads correctly from the App Store and is displayed in the app, but when attempting to complete the purchase, StoreKit returns the following error: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3504 "This item cannot be found." UserInfo={ NSLocalizedFailureReason=This item cannot be found., AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=USA } The same issue was also encountered by the App Review tester when they attempted to purchase the non-consumable product during review. The product: Is correctly configured in App Store Connect Has active pricing Is available in the United States Was included in the app submission Loads successfully and displays the correct price Fails only when the purchase is initiated Since the product metadata can be retrieved successfully, but the transaction fails with “This item cannot be found,” this appears to be a possible inconsistency between the StoreKit product catalog and the purchase backend. Has anyone encountered ASDServerErrorDomain Code=3504 for a non-consumable product that loads correctly but cannot be purchased? Is there any known App Store sandbox or commerce backend issue that can cause this, or any additional App Store Connect configuration that should be checked?

I am unable to sign into my Apple account on a Golden Gate b1 VM. Thus, I'm unable to switch to the beta channel and upgrade this VM to the latest beta Golden Gate seed. The error I get is: Verification Failed An unknown error occurred. I've looked in Console.app for any clues and no luck so far. Is this a known issue and is there a workaround?

Hi all, I'm the developer of OV Message, an end-to-end encrypted SMS messaging app already shipped on Google Play (Android, where it natively encrypts SMS content). The iOS port aims to be the default carrier-messaging app, handling SMS, MMS, and RCS through TelephonyMessagingKit with the com.apple.developer.carrier-messaging-app entitlement under the EU programme. While testing the cold-launch flow on iOS 26.x, I've hit a reproducible bug that silently drops the first SMS/MMS/RCS that wakes the app, and I'd like to confirm whether other devs working with this API see the same. The bug When a default carrier-messaging app is force-killed and a message arrives, iOS correctly: Routes the message via CommCenter (IMS in my case — SFR France) Wakes the app in background (state = .background at didFinishLaunchingWithOptions) Acquires a TelephonyMessaging runningboard assertion on the app But CommCenter then pushes the pending message via XPC before the client TMK library has finished registering its messageHandlersByID dictionary. Result: client responds Received unhandled request, server logs TMKXPCError Code=2, message is dropped, never delivered to for await in incomingMessageNotifications. Subsequent messages (with the app warm) work fine. Native log sequence (from idevicesyslog with the Telephony logging profile) T+0.000 CommCenter: SMS arrives via IMS (k3GPP) T+0.003 CommCenter: Default app is set to com.example.app T+0.004 CommCenter: Attempting to launch and acquire process assertion T+0.083 CommCenter: Notifying SMS message received, target: bundleID=... T+0.085 CommCenter(TMK): There are no client connections matching, pending message [~125 ms — app boots] T+0.128 App(TMK): Configuring connection T+0.128 App(TMK): Pinging remote end T+0.130 CommCenter(TMK): Received new connection from PID T+0.130 CommCenter(TMK): New incoming connection, flushing pending messages (1) ← server flushes T+0.130 App(TMK): Received unhandled request ← client not ready T+0.131 CommCenter(TMK): Failed to send pending message: TMKXPCError Code=2 T+0.132 App(TMK): Registered for IncomingMessageNotification (smsReceived) ← ~2 ms too late The race window between Pinging remote end (client) and Registered for IncomingMessageNotification (client) is 2–7 ms across my measurements. CommCenter considers the connection ready as soon as the ping completes, but the client library populates messageHandlersByID slightly after, so the dispatch fails. Minimal reproduction I built a ~50-line Swift app to confirm this isn't specific to OV Message. UIKit AppDelegate, single for await in TelephonyMessagingSession.shared.smsService.incomingMessageNotifications started in didFinishLaunchingWithOptions. No SwiftUI, no other modules, no Darwin notifications. Just TMK. Steps: Build & install on iPhone iOS 26.x with carrier-messaging-app entitlement (auto-provisioned in iOS 26) Settings → Apps → Default Messaging → select the test app Force-kill, then send 2 SMS in rapid succession from another phone Wait 30 s, open the app — log shows only the 2nd SMS Same result: the 1st SMS is gone. I've reproduced this consistently dozens of times. Source code (Swift + xcodegen project.yml): https://gist.github.com/ovmessage/fbc529292a65222191bec6ce5e5a4275 What I've tried Task.detached(priority: .userInitiated) to decouple the for await from main thread scheduling — no effect (race is internal to TMK lib, before our scheduling) Pre-fetching cellularServices synchronously — no effect Subscribing MMS + RCS in parallel — no effect Direct XPCSession/xpc_connection_create_mach_service to com.apple.commcenter.tmk.xpc — Apple has marked these unavailable on iOS for 3rd-party apps (no public way to bypass the lib) I've also done runtime introspection of the TMK framework via Mirror, which confirms the architecture: a single XPCConnection.messageHandlersByID dict shared by smsReceived, mmsReceived, rcsReceivedNotification — all four entries (incl. serviceStatusNotification) are populated after the XPC ping. So the same race affects SMS, MMS, and RCS equally. Suggested fixes (Apple-side) Either: Server (CommCenter): defer flushing pending messages until the client confirms its handlers are registered (extra XPC handshake message) Client (TelephonyMessagingKit): register messageHandlersByID entries before sending Pinging remote end, so they exist when the server starts flushing Buffer client-side: cache messages received before handler registration completes, dispatch on attach Filed in Feedback Assistant FB[YOUR_FB_NUMBER_HERE] Question for fellow devs If you're also building with carrier-messaging-app entitlement (Beeper, Google Messages on iOS, anyone in the EU programme), can you confirm whether you see the same race? Especially interested in whether: It happens with non-IMS carriers (mine is SFR France, IMS-routed via SIP) iOS 26.1 / 26.2 changed the timing Anyone has found a workaround I haven't tried Thanks.