I’m seeing a visual glitch in SwiftUI List on iOS 26 when row order changes after a swipeActions action. Setup: List + ForEach of items Items are sorted dynamically by isSelected (unselected first, selected last) Swipe action toggles isSelected Row should animate to new position Problem: On swipe select/unselect, the row sometimes appears to disappear briefly, then reappear in the new position Most visible when unselecting an item from the bottom selected group (it should move to top) Sometimes there is a temporary “empty gap” near the top during the move In some row styling setups, row corner masking also looks wrong during animation What I tried: Different animations (default, easeInOut, spring) Adding/removing small dispatch delay before state change Moving section header content outside List Using custom row backgrounds/corners vs system row styling Keeping stable IDs in ForEach Behavior still appears with native List + swipeActions on iOS 26. So my question is: Is this a known issue/regression with List row move animations on iOS 26? Recommended pattern to keep native swipe actions but avoid this visual artifact? This worked smoothly on iOS 18 with the same approach, and the visual glitch appears only after moving to iOS 26.

I'm using NEPacketTunnelProvider to intercept DNS queries, forward them upstream, and inject the responses back via writePacketObjects(). This works correctly for responses under ~500 bytes. For larger responses (~893 bytes, e.g. DNS CERT records), writePacketObjects() returns without error but mDNSResponder never receives the packet — it retries 3–4 times and then times out. What I have verified: IP and UDP checksums are correct UDP length and IP total length fields are correct Maximum packet size (MTU) set to 1500 in NEIPv4Settings/NEIPv6Settings Approaches tried: Injecting the full 921-byte packet — writePacketObjects() succeeds but the packet never reaches mDNSResponder IP-level fragmentation — fragments appear to be silently dropped Setting the TC (truncation) bit — mDNSResponder does not retry over TCP Truncating the response to ≤512 bytes — the packet arrives but the data is incomplete Questions: Is there a supported way to deliver a DNS response larger than 512 bytes through NEPacketTunnelFlow? Does NEPacketTunnelProvider impose an undocumented packet size limit below the configured MTU? Does mDNSResponder silently discard responses larger than 512 bytes when the original query had no EDNS0 OPT record? Is there a way to signal that larger responses are supported? Are IP-level fragments reliably delivered through writePacketObjects()? Tested on iOS 26.3, physical device.