We make a BLE peripheral that streams continuously. It's been running against Android, Windows, macOS and iOS for years. Android and Windows sit at ~1000 kbps and stay there — many host devices, many OS versions, no per-host tuning. macOS and iOS give us about half that. We've sniffed the BLE link using a Bluetooth sniffer to find out where it goes. Same board, same firmware, every session. Read off the air trace, not from host APIs: 2M PHY both directions (LL_PHY_UPDATE_IND 0x02 / 0x02) DLE max_tx_octets = 251 ATT MTU 247 15.00 ms interval, peripheral latency 0 no encryption no other BLE or BT Classic connections active during the session (all other devices removed and forgotten) WiFi turned off for around half of the sessions, didn't seem to make any difference Peripheral airtime per connection event: central airtime/event duty @ 15 ms throughput Android 11.14 ms 74% 995 kbps, sustained Windows ≥10.70 ms ≥71% ~1000 kbps, sustained macOS 6.96 ms 46% 561 kbps iOS 6.96 ms typical 46% ~560–600 kbps macOS comes out median 6.96, p90 6.96, max 7.09 across a whole session. Same number every time. iOS normally sits in the same place, with occasional brief excursions up to Android-like performance before dropping back down. Those excursions are worth describing, because they're the interesting part. In a handful of sessions out of many, iOS runs at 12.53 ms, 84% duty, ~1030 kbps. It never holds. It drops back inside 150 ms, with no renegotiation, no parameter change and no channel-map change anywhere in the trace. Sometimes it parks at 8.35 ms for ten seconds before moving again. This isn't us saying iOS is fine in practice — it clearly isn't, we can't ship against it. The point is that the radio and the stack demonstrably can fill a 12.53 ms event when they're allowed to, so whatever is holding them to 6.96 ms isn't a hardware ceiling. "It's a factor of ability" doesn't fit. This has been asked before and answered. In thread 774487, asked directly whether iOS limits packets per connection event to 4: "there is no 'limiting' going on as it is commonly understood ... We find that 4 is a more commonly true number than 6 or more some chipsets claim." In thread 770717, to a developer on iOS 18.2 running the same parameters we are: "iOS does not 'limit' the number of writes. It is just a factor of ability." Both answers need the accessory to be the variable. Ours isn't — same board, same firmware, minutes apart, and two non-Apple hosts take it to 1000 kbps and hold it indefinitely. The only thing that changes is which OS is acting as central. We don't think this can be explained by chipset capability when the chipset is the one thing held constant. It's airtime, not packet count. The "4 packets per connection event" number people quote here is the wrong unit, and we think that's why these threads go nowhere. Within one regime, as PDUs per event go up, PDU size goes down and the airtime doesn't move: iOS 9 PDUs @ 250.4 B -> 12.51 ms 10 PDUs @ 211.1 B -> 12.32 ms 11 PDUs @ 186.4 B -> 12.47 ms macOS 5 PDUs @ 239.4 B -> 6.73 ms 6 PDUs @ 178.1 B -> 6.60 ms Nothing is counting packets. The event closes on a clock. Count and airtime were the same measurement back when everything was 1M PHY and 27-byte PDUs — with 2M and DLE they aren't, and quoting a packet count now hides the mechanism instead of describing it. The peripheral isn't the limiter. The MD bit was set on the peripheral's last PDU in 2147 of 2148 connection events. It always had more data queued, and the central closed the event anyway. This isn't a new report. The same mechanism has been described here before. Thread 133092 (2019) reports macOS closing the connection event while the peripheral still has MD set — exactly what we measure. Thread 713349 reports "about 5 response packets per connection event," which is the same budget: 6.96 ms is 5 full-size PDUs. Thread 6025 reports a drop from 7 packets to 3. None of those received a reply. We're not raising them to relitigate old threads. The point is that three independent reports arriving at the same number across several years, on different accessories, points at a property of the scheduler rather than of anyone's hardware. On iOS, this looks like it changed in iOS 18. macOS has apparently behaved this way for years, going by the threads above. On iOS it's recent. We have video and screen recordings of this same peripheral tested on iOS 17, documented at the time as running consistently at around 1000 kbps. The behaviour described here started appearing when we moved to iOS 18. The firmware and the negotiated parameters are the same now as they were then, which points at a change in radio scheduling rather than anything on our side. What we're asking: Is the per-event airtime budget deliberate? ADG §55.6 and QA1931 cover interval, latency and timeout only. Neither mentions connection event length. Why do macOS and iOS give roughly half what Android and Windows give for the same accessory, and why can iOS reach 12.53 ms without staying there? Did anything change in iOS 18 around connection event scheduling? Is there anything we can do from the accessory or app side? We're already at 2M PHY, DLE 251, MTU 247 and the 15 ms floor. If the answer is "design for a floor, not a peak" — what's the floor? Right now we plan for ~560 kbps on Apple and roughly double that everywhere else, and that decides what we can ship, and whether we can count on Apple devices as a reliable platform for our product. Captures, recordings and analysis available if they're useful.

I have a watchOS app on a cellular Apple Watch (Series 11, watchOS 26.6) that periodically uploads small HTTPS payloads to a backend. It needs to keep working when the paired iPhone is absent and the watch is on its own cellular connection. What I observe: Foreground, no phone, cellular: uploads work. Background, no phone, cellular-only (no Wi‑Fi): nothing uploads for hours. The instant the watch joins Wi‑Fi (app still in background): the whole backlog flushes at once via my background URLSession. My questions: Is a background URLSession transfer over cellular ever expected to run without Wi‑Fi (e.g. while charging), or is Wi‑Fi effectively required in practice? Any configuration that improves the odds? 2. During an active HKWorkoutSession (which keeps the app executing), will a high-level URLSession data task reliably complete over cellular with the phone absent? And is using a workout session to keep a non-fitness background uploader alive acceptable, or is there a sanctioned alternative? 3. Is there any other supported mechanism for periodic background cellular upload from a phoneless watch that I'm missing? Any help would be greatly appreciated. Thank you!

We ship a consumer VPN app on iOS, iPadOS and tvOS using a Personal VPN configuration: NEVPNManager with NEVPNProtocolIKEv2, EAP-MSCHAPv2, no MDM profile installed. After exactly 120 seconds with no traffic, iOS destroys the Child SA and disconnects the tunnel. I would like to know whether that timer is configurable, and if not, what the intended mitigation is. From a device sysdiagnose (iPhone, iOS 26.6, build 23G71): NEIPSecDBStatsUpdate: SA is idle for past 120 secs KernelSASession[1, IKEv2 Session Database] idle timeout SA Internal SAID = 2 SPI = C53320D1 Direction = Outbound ChildSA[1] state Connected -> Disconnected error Domain=NEIKEv2ErrorDomain Code=15 "IdleTimeout" <NEIKEv2Provider: Primary Tunnel>: stopping tunnel since Child disconnected nesessionmanager: plugin disconnected with reason "Tunnel was idle for too long" This happened 12 times across a 9.2 hour overnight capture on one idle device. Median time before the tunnel re-established was 14m35s. DISCONNECT-ON-IDLE IS NOT ENABLED The same sysdiagnose shows the plugin's own configuration as: disconnectOnIdle = NO disconnectOnIdleTimeout = 0 These are the stock defaults. There is no disconnectOnIdle property on the public NEVPNProtocol, so a Personal VPN app cannot set them either way. The installed SA parameters contain no idle field at all, only "Lifetime Seconds = 1800", which is honoured correctly: the same capture shows 20 clean rekey cycles. WHAT I HAVE RULED OUT iOS logs a distinct stop reason for each of the following, and none of them occurred across 24 teardowns: "On Demand Disconnect rule matched", "Tunnel was terminated by the server", "Server is not responding", "Network changed, tunnel no longer viable", "Device went to sleep", "Stop command received". The only reason recorded was "Tunnel was idle for too long". On the gateway (strongSwan), IKE rekey and reauth are disabled, uniqueids is never, and DPD is answered in roughly 200ms right up to the teardown. The gateway considers the tunnel healthy at the moment iOS tears it down. DPD does not reset the timer, which makes sense: DPD is an INFORMATIONAL exchange on the IKE SA, whereas the log shows the timer measuring the OUTBOUND Child SA (SAID 2). THE APP CANNOT SEE THIS HAPPEN NEVPNConnection.fetchLastDisconnectError() returns nil for this teardown, because the error is in NEIKEv2ErrorDomain rather than NEVPNConnectionErrorDomain. The app has no supported way to detect that the tunnel dropped for this reason, or to distinguish it from a user-initiated disconnect. It is only visible in a sysdiagnose. TRAFFIC IS NOT HELD DURING THE RECONNECT With Connect On Demand enabled (NEOnDemandRuleConnect, interfaceTypeMatch .any), traffic after the teardown does not wait for the tunnel. On device wake following one of these drops: 01:32:43 device wakes 01:32:43 [C331 ... :443] path:satisfied @0.001s, interface: en0[802.11], uses wifi 01:32:44 [C331 ... :443] flow:finish_connect @0.623s (over en0) 01:32:47 tunnel status changed to connected so flows complete over the physical interface for several seconds before the VPN re-establishes. On-demand triggered the reconnect but did not delay the traffic. For a VPN product this window is the part that concerns me most. QUESTIONS Is the 120 second Child SA idle timeout configurable for a Personal VPN using NEVPNProtocolIKEv2, from the app or from a configuration profile? If DisconnectOnIdle / DisconnectOnIdleTimer are meant to control it, why does the teardown occur when they are NO / 0? If it is not configurable, is application-generated keepalive traffic the intended workaround? If so, how is that expected to work while iOS has the app suspended, which is exactly when a tunnel goes idle? Would server originated traffic that elicits a client response be a supported approach? Is there any supported way for an app to be notified of this teardown, given that fetchLastDisconnectError() returns nil for it? Is the behaviour in "traffic is not held during the reconnect" expected for NEOnDemandRuleConnect, or should matching flows be delayed until the tunnel is up? Is includeAllNetworks the only supported way to close that window? Happy to supply the full sysdiagnose privately.

For a given instantiation, is the Instance object passed to each method of NWProtocolFramerImplementaion the same? If that includes the initializer, why do the other methods still want it?

Hi, Shortly: On iPadOS27, when changing the color of a PKInk programmatically, it doesn't reflect in PKDrawing on screen. In all previous versions of iPadOS I was able to change the color of a PencilKit stroke via: canvasView.drawing.strokes[0].ink.color = .red And it changed on screen. As of iPadOS 27 - it doesn't. However, the underlying data is changing correctly: print(canvasView.drawing.strokes[0].ink.color) //prints: "UIExtendedSRGBColorSpace 0 0.533333 1 1" - blue color. canvasView.drawing.strokes[0].ink.color = .red print(canvasView.drawing.strokes[0].ink.color) //prints: "UIExtendedSRGBColorSpace 1 0 0 1" - red color, good. But the stroke stays blue on screen. I've filed a Feeback at FB24771438. And am using a temp workaround to "refresh" the drawing with: let current = canvasView.drawing canvasView.drawing = PKDrawing() //blank one canvasView.drawing = current IMHO, it should be possible to change the color like that and re-render it in the View right away, since the PKInk's .color property is a { get set } property. Is this the intended behavior? A bug or a feature? Thanks!

Hi everyone, We have recently started distributing iOS 26 Apple Wallet boarding passes, which support new features such as: Live Activities Automatic updates for flight-related information (e.g., gate changes, departure time updates) While these features are useful, we are looking for ways to control or limit some of this behavior. Our requirements Live Activity Control We would like to prevent Live Activities from being automatically shown when a boarding pass is added to Wallet. Automatic Flight Data Updates We would like to control or disable the automatic updates performed by Wallet for flight information. Reason for this requirement We already provide our own Live Activity implementation with more customization, and having two Live Activities leads to a poor user experience. We have observed that Wallet’s automatic updates can sometimes be delayed, and since Wallet overrides our data, we lose control over the displayed information. Question Is there any supported way to: Disable or control Live Activities triggered by Wallet passes? Disable or override Wallet’s automatic flight updates? Or are these behaviors managed entirely by the system with no developer control? Any guidance or documentation references would be greatly appreciated. Thanks in advance! Regards,

I've just shipped a signed NetworkingDriverKit driver for the Realtek RTL8127 10GbE PCIe NICs on Apple Silicon, source at https://github.com/stefb69/RTL812xLucy (directory RTL8127Dext). It runs at line rate (9.4 Gbit/s each way at MTU 1500, 9.9 with jumbo frames) with TSO, checksum offload and four TX queues by service class. Since there are very few public NetworkingDriverKit drivers to learn from, here is what cost me the most time, in case it saves someone else a week. Three of these are filed as feedback. TX packets from native Skywalk flows have a 2-byte data offset (FBxxxxxxxx). getDataVirtualAddress() / getDataIOVirtualAddress() return the buffer base; the frame starts at getDataOff(). BSD-path packets (ping, curl, ssh, DHCP) have offset 0, Network.framework flows (Safari, URLSession, App Store, codesign --timestamp) have offset 2. If you DMA from the base, everything "works" except every modern client, which sits in SYN_SENT. The headers don't mention it. getMaxTransferUnit() is the maximum MTU, not the current one (FBxxxxxxxx). It is read once at registerEthernetInterface() and becomes the hard ceiling for ifconfig mtu; return your current 1500 and jumbo frames fail with EINVAL before your dext is called. Don't call bpfAttach() on macOS 26.6 (FBxxxxxxxx). It worked once, then panicked the kernel inside IOSkywalkFamily when the dext was replaced while tcpdump was attached. Without it, tcpdump on your interface only sees host-path frames, not native flows, so debugging point 1 is done from the peer side. Smaller ones: the personality needs IOClass = IOUserNetworkEthernet and CFBundleIdentifierKernel = com.apple.iokit.IOSkywalkFamily, not IOUserService, or super::Start fails with 0xe00002bc. All queues are created disabled: setEnable(true) in setInterfaceEnable(), plus requestDequeue() on the TX queues when the link comes up. setMulticastAddresses() must be implemented or no multicast group is ever joined (mDNS and IPv6 solicited-node are silently dead). Release dispatch sources from the Cancel() completion block, not right after Cancel(), or the dext crashes at every upgrade. The dext bundle must be named .dext or the host app reports "Extension not found in App bundle". Dext os_log lines show up as kernel: messages with the .dext bundle as sender; use %{public}s. Performance question for Apple engineers: with eight or more parallel TCP senders at MTU 1500 the stack emits ~3 KB TSO packets at ~160k packets/s and the dext saturates one core around 4.5 Gbit/s (fine at MTU 9000, fine with one to four streams). Is IOUserNetworkPacketPoller the intended answer for per-packet cost in a NIC dext, and is there any guidance on batch sizes for IOUserNetworkTxSubmissionQueue dequeues?

I am developing an iOS app that uses Core NFC to communicate with an ISO 14443 / ISO 7816 smart card. For security reasons, I would like to minimize or temporarily prevent other external communications while an NFC read/write session is active. My questions are: Is there any supported iOS API or entitlement that allows an app to temporarily disable or block Wi-Fi, cellular, or Bluetooth communication while a Core NFC session is active? If device-wide communication cannot be controlled by a third-party app, is there a supported way to guarantee that the app’s own process performs no network communication during that NFC session? Does Apple recommend any architecture or security practice for implementing an offline-only Core NFC read/write operation? The NFC communication itself must remain available during the operation. Thank you.

I am trying to understand one supported iOS lifecycle guarantee. Consider a generic app that stores a single SQLite database in its private Library/Application Support directory and keeps one SQLite connection open while its process is alive. During a supported platform operation such as iCloud restore that continues after setup, Finder or Apple Devices restore, Quick Start direct transfer, Quick Start using iCloud, reinstall or offload recovery, or an app update, can the app become or remain running, background executing, or suspended while iOS restores, replaces, or rebinds its data container or a file within it? More specifically, can an existing open file descriptor or SQLite connection continue to reference an old filesystem object while a later lookup of the same Application Support path resolves to a restored or replacement object? If iOS does not permit that condition, what supported lifecycle invariant prevents it? For example, does iOS terminate the app before restored data becomes visible, gate launch until the complete per-app restored container is finalized, or keep the container binding stable for the lifetime of the process? If the behavior differs by mechanism, please distinguish iCloud restore after setup, Finder or Apple Devices restore, Quick Start direct transfer, Quick Start using iCloud, reinstall or offload recovery, and app update. • Does the platform's restore ordering depend on SQLite locks? • Does NSFileCoordinator participate when platform services restore private Application Support files? • Is there Apple documentation or an Apple-staff explanation that defines this ordering, including supported versions, conditions, or exceptions? The POSIX issue is that an open descriptor may continue to reference an old object after pathname replacement while a new lookup reaches a different object. SQLite also documents risks when an open database file is renamed or unlinked. I am not treating a raw rename or unlink test as equivalent to an Apple restore. I am explicitly excluding arbitrary unlink, rename, overwrite, or other direct same-container filesystem attacks. My question is only whether Apple's supported restore and container services can create an equivalent old-open-object versus newly-resolved-path condition while the same app process survives.

I’m developing a macOS menu-bar app intended for distribution on the Mac App Store. Is there a supported public API or an available entitlement that allows a sandboxed macOS app to read the built-in ambient light sensor in real time? The feature would be optional, process readings locally, and adjust display dimming and warmth. It would not use the camera or transmit sensor data. SensorKit’s ambient light API is unavailable on macOS in our SDK, and its research-only access and delayed data do not meet this use case. We want to avoid private APIs. Could you confirm whether a supported approach exists, or advise how to submit an enhancement request?

I have written a small Python program that needs to continuously listen on port 2237. The packets are received from one program, which I will call P1. There is also another program, P2, that receives commands from P1. Both P1 and P2 use port 2237. My problem is that when I start my Python script, it successfully receives data from P1, but it fails to receive data from P2. The functionality only works again after I stop my program. The Python script for receiving the packets is: def run(udp_port: int): logger.info("Starting listener on port %d", udp_port) client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) client.setsockopt() client.bind(("", udp_port)) while True: data, addr = client.recvfrom(4096) src_ip, src_port = addr logger.debug("Received %d bytes from %s:%d", len(data), src_ip, src_port) hexdump(data, logging.DEBUG) try: payload = parse_message(data) if payload is not None: logger.info("%r", payload) except Exception as e: logger.error("Failed to parse header: %s", e) Does anyone know what the root cause of this issue is, and how we can fix it?

I have written a small Python program that needs to continuously listen on port 2237. The packets are received from one program, which I will call P1. There is also another program, P2, that receives commands from P1. Both P1 and P2 use port 2237. My problem is that when I start my Python script, it successfully receives data from P1, but it fails to receive data from P2. The functionality only works again after I stop my program. The Python script for receiving the packets is: def run(udp_port: int): logger.info("Starting listener on port %d", udp_port) client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) client.setsockopt() client.bind(("", udp_port)) while True: data, addr = client.recvfrom(4096) src_ip, src_port = addr logger.debug("Received %d bytes from %s:%d", len(data), src_ip, src_port) hexdump(data, logging.DEBUG) try: payload = parse_message(data) if payload is not None: logger.info("%r", payload) except Exception as e: logger.error("Failed to parse header: %s", e) What could be causing this conflict? Is there a known issue where an active UDP listener process interferes with two other applications (P1 and P2) communicating on the same port? Any ideas or suggested workarounds would be helpful!

Hello, I am working on network traffic analyser for DLP. The solution is based on NETransparentProxyProvider due to necessity data modifying. To my knowledge, the Transparent Proxy API does not have a concept of an "asynchronous/delayed verdict" for flow authorization. The handleNewFlow(_:) method appears to be invoked sequentially for each new network flow that matches our interception rules. The challenge we are facing is that a portion of our proxy rules and configurations resides in a LaunchDaemon, which the Network Extension communicates with via XPC. Such separation is required by our cross-platform code base. Thus, we are forced to make a synchronous XPC call within handleNewFlow(_:) and block the thread while waiting for the interception verdict from the daemon. This creates a significant bottleneck when establishing new network flows. The current implementation works without issues, but we are always looking for ways to improve performance. Are there any best practices or recommended approaches for parallelizing handleNewFlow(_:)? Thank you in advance.

I’m using Virtualization.framework on Apple silicon with a Linux guest (VZGenericPlatformConfiguration + VZLinuxBootLoader). The VM is intentionally minimal: 2 vCPUs, 2 GiB RAM 1 virtio entropy device 2 virtio block devices (base read-only, scratch read-write) 1 virtio console with 2 ports, both isConsole = false no serial, network, sharing, socket, USB, audio, graphics, keyboard, pointing, balloon, or custom virtio devices no EFI variable store nested virtualization disabled On the normal success path the host does not call requestStop(). A destructive host stop is tracked separately and treated as failure. I need a supported way for the host to distinguish: a clean Linux guest shutdown intentionally issued by the guest after its application protocol and cleanup have completed, from an abnormal or independent shutdown path such as kernel panic, watchdog, thermal / hardware-protection shutdown, emergency shutdown, or another kernel/platform-triggered stop. guestDidStopVirtualMachine tells me that the guest stopped, but I cannot find a public contract that says which Linux/kernel/platform histories can produce that callback, nor a public shutdown reason/initiator value. My specific questions are: For VZGenericPlatformConfiguration + VZLinuxBootLoader, what is the documented complete guest-visible shutdown/reset event surface, including implicit platform events not represented by explicitly configured device arrays? What Linux-facing mechanism does VZVirtualMachine.requestStop() use in this configuration? Can guestDidStopVirtualMachine also be emitted after panic, watchdog, thermal/hardware-protection shutdown, emergency shutdown, or another guest-kernel/platform shutdown source? Are those abnormal cases guaranteed to arrive through virtualMachine(_:didStopWithError:) instead? If guestDidStopVirtualMachine can represent multiple terminal histories, is there any supported public API or documented guarantee that lets the host distinguish a clean guest system-off from the abnormal/platform-triggered cases? If not, is it correct to treat this distinction as unspecified by the public Virtualization.framework contract? I do not need private implementation details. A public/supported contract describing which terminal histories can produce each delegate callback would be enough. This matters because the host is fail-closed: it must accept PASS only after an application-level success condition and a clean guest shutdown. A successful runtime observation alone is not enough for the qualification. Environment: Apple silicon / arm64 macOS 26.6.2 (25G83) public Virtualization.framework APIs

Hello, I'm currently refactoring my app to use the new Core Location APIs introduced in iOS 17 (CLLocationUpdate) and iOS 18 (CLServiceSession). I'm not quite sure how best to reproduce the current flow I've in my app right now: At app launch: If location services are authorized when in use + full accuracy: get the user current location then stop. If the services are not yet determined or denied, do nothing. Later in the app, when a user taps on a button to get its current location: Not determined: prompt and get the user current location if authorised when in use with full accuracy, then stop. Denied: present an alert (open Settings). Authorised when in use Full accuracy: get the user current location then stop. Not full accuracy: present an alert (open Settings). My issue is that I can't find a way to determine the authorisation status without prompting the user. As soon as I create a CLServiceSession to inspect the diagnostics (CLServiceSession.Diagnostic), the user is prompted. So I can't use this at app launch as I want to delay the prompt until the user first interacts with the feature actually requiring location services. Do I still need to use CLLocationManager().authorizationStatus and CLLocationManager().accuracyAuthorization at app launch? Or am I missing something in the new APIs that allow me to check a session status without prompting? Thank you!

I've filed FB24763792 about numeric JSON reserialization and the Live Activity content-state size limit. A compact JSON content-state can be below 4,096 bytes but expand beyond that limit when Foundation parses and reserializes its numbers. Here is an entirely synthetic Foundation reproduction: import Foundation let row = #"{"a":1.91,"b":1.91}"# let rows = Array(repeating: row, count: 100).joined(separator: ",") let input = Data("{"sequence":1,"readings":[(rows)]}".utf8) let object = try JSONSerialization.jsonObject(with: input) let output = try JSONSerialization.data(withJSONObject: object, options: []) print(input.count, output.count) On macOS 26.6.2 and the iOS 26.5 simulator, this prints 2027 4827. Foundation writes 1.91 as 1.9099999999999999. Change both values to 1.95 and it prints 2027 2027. In a separate local ActivityKit test, we passed the Foundation-reserialized data through a Decimal-based Codable state that preserved the expanded byte count: The 1.95 control remained at 2,027 bytes and applied successfully. The 1.91 case expanded to 4,827 bytes and was rejected with "Payload maximum size exceeded." The activity retained its previous state. We also tested the exact boundary: a 4,096-byte encoded dynamic state applied, while 4,097 bytes was rejected. Static attributes did not count toward that tested local-update boundary. This investigation began with remote Live Activities remaining stale while APNs returned HTTP 200 for dispatched updates. The device logged "Error extracing payload from incoming message" (spelling as logged). We are confident numeric expansion is the mechanism behind our issue. The tests above reproduce expansion and rejection locally; they do not replay an exact captured failed remote push. The ContentState documentation specifies a 4KB limit but doesn't make remote JSON normalization clear: https://developer.apple.com/documentation/activitykit/activityattributes/contentstate Questions for Apple: At what stage is remote content-state size measured? Can internal reserialization preserve compact numeric representations, or can the limit use the supplied content-state bytes? Can rejected incoming updates expose the underlying size error and measured byte count? The synthetic reproducer and a simulator diagnostic collected immediately after the local rejection are attached to FB24763792. verified-results.txt control-content-state.json expanding-content-state.json

After upgrading to macOS 27.0, I noticed a specific issue in Find My > People. Two people who share their location with me use iPhone 6 devices. Their locations are unavailable in Find My on my Mac running macOS 27.0. The same location-sharing relationships work correctly on my other devices: iPhone running iOS 26: locations are visible iPad running iPadOS 26: locations are visible Mac running macOS 27.0: locations are unavailable Other people using newer iPhones are displayed correctly on the same Mac. This suggests that location sharing itself and my Apple Account are working correctly. The issue appears specific to Find My > People on macOS 27 when receiving location shared from older iPhone/iOS devices. I can reproduce this independently with two different iPhone 6 users. macOS 27.0 is the public release, not a beta. I have submitted this to Apple through Feedback Assistant: FB24761605 Has anyone else seen this specifically with iPhone 6 or devices running older iOS versions after upgrading to macOS 27?

Filing this as a public thread to try to get DTS attention, similar to how thread 821372 (skmem_slab_free_locked double-free) got resolved - accumulated cross-referenced reports there are what got that one fixed in 26.5/26.6. Panic signature (identical every time): panic(cpu N caller 0x...): m_copym_with_hdrs n 0x... copy overflow @uipc_mbuf.c:3268 My own occurrences: 5 panics over 2 days on a MacBook Pro (Mac16,7 / M4 Pro), macOS 26.5.2 build 25F84, kernel Darwin 25.5.0 (xnu-12377.121.10~1/RELEASE_ARM64_T6041). Filed as Feedback Assistant report FB24343421 (5 panic logs + a full sysdiagnose attached). Why this looks like a generic kernel bug, not app-specific: I initially suspected a third-party VPN NetworkExtension (Tailscale) since it appeared in the full stackshot of every one of my panics. Ruled that out: That NE is a userspace-only component - cannot execute kernel code. Two other reporters have hit the identical panic string via completely different, unrelated paths: One reproduced it with no VPN/tunnel software running at all (engine stopped, sysext idle) - see FB24333740, cross-referenced at https://github.com/tailscale/tailscale/issues/20864 Another hit the same panic string on an Intel Mac via a third-party Ethernet kext, no VPN/utun involved at all - https://github.com/SongXiaoXi/AppleIGC/issues/34 So this reproduces through at least 3 independent producer paths (a NetworkExtension, no tunnel software at all, and a third-party Ethernet driver), which points to something generic in the TCP send path (tcp_output -> m_copym_with_hdrs) rather than anything specific to one app or extension. Known non-workarounds: net.inet.tcp.tso=0 does not avoid the code path (checked against the last public xnu source drop). No sysctl or config change has stopped recurrence for anyone who's tried. Related public reports: https://github.com/tailscale/tailscale/issues/20864 https://github.com/tailscale/tailscale/issues/20612 https://github.com/SongXiaoXi/AppleIGC/issues/34 FB24333740 (independent Feedback Assistant report, same signature) FB24343421 (mine, this thread) Still reproducing on the latest public release (26.6.1 / 25G76) per the other reporters. Happy to provide more diagnostics - this is easy to reproduce on my end, roughly every few hours to once a day under normal use.

I’m working on an open-source React Native library for Wi-Fi Aware / NAN: https://github.com/dcavalcante/react-native-wifi-aware The Android implementation has already been physically validated for capability detection, discovery, follow-up messaging, and data paths. The Apple implementation is in place and passes the current simulator/static compilation gates, but I don’t currently have the Apple hardware and Developer Program setup needed to validate it on physical devices. I’m looking for someone with an Apple Developer account and preferably two iOS/iPadOS 26 devices who can help test: Wi-Fi Aware entitlement/signing declared WiFiAwareServices publish / subscribe discovery system pairing Apple-to-Apple connectivity Android ↔ Apple discovery and interoperability The biggest unknown I want to validate is the cross-platform path between Android Wi-Fi Aware and Apple’s iOS 26 implementation. Testing results, fixes, documentation, and implementation contributions are all welcome.

Deployment scope: macOS 26 and macOS 27, Apple silicon / arm64 only. Intel / x86_64 and Rosetta behavior are outside this inquiry. Please distinguish applicability and limitations for each named macOS version; support for one version must not be assumed to establish support for the other. We are evaluating a directly created child's lifecycle in a continuously living original parent, using documented posix_spawn, kill and wait interfaces. This is a support-contract clarification, not a report of a reproduced OS defect. We have not conducted a process experiment. The proposed parent would serialize every action against every potentially consuming wait, exclude competing waiters, retain SIGCHLD status (no SA_NOCLDWAIT or explicit SIG_IGN), and permanently revoke further actions before permitting final reap. Parent loss or uncertain ownership causes refusal, with no adoption or respawn. We are not asking for private interfaces or implementation internals. POSIX.1-2024 XBD 4.17 prohibits PID reuse before process lifetime ends. Its _exit description connects normal zombie lifetime to collection of status, with explicit automatic-disposal exceptions. We recognize that UNIX 03 certification is a different edition/profile and do not assume POSIX.1-2024 applicability to macOS. For the specified deployment range, please identify the applicable supported documentation/standard profile and clarify: Under the stated exclusions, is a directly created child's positive PID reserved against reassignment through exit/zombie state until a defined consuming wait boundary? Which documented exceptions or ownership transitions defeat that premise? What is the supported consuming boundary for wait/waitpid, including WNOHANG, EINTR, stopped status and concurrent waiters? Does excluding all consuming waits during an action close the numeric-replacement risk, or is another supported condition required? Please identify the documented effects of explicit SIG_IGN versus SIG_DFL, SA_NOCLDWAIT, exec and parent death that are relevant to that exact reservation claim. We do not infer unchanged executable identity, permissions or successful termination from unchanged PID. We are asking for version-applicable supported semantics, including any limits on the conclusion, rather than empirical plausibility or absence of a known counterexample. If this guarantee is not supported, please say so. We are not asking you to certify our implementation, cleanup of descendants, or full supervisor correctness. Primary references: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/_exit.html https://www.opengroup.org/openbrand/register/apple.htm