Background We are developing Share&Share, an offline device-to-device content transfer application. An iPad automatically joins a nearby Samsung Android LocalOnlyHotspot. The hotspot credentials are delivered through an authenticated, encrypted Bluetooth Low Energy (BLE) session. On iPadOS, our application decrypts the credentials natively in Swift and uses NEHotspotConfigurationManager.apply() to join the hotspot. We are investigating an intermittent connection problem during the initial automatic join. We have also submitted a private report through Apple Feedback Assistant: Feedback ID: FB25408475 Test environment Receiver: Physical iPad with a Home button. Sender/hotspot: Samsung SM-E055F. Android version: Android 16. Hotspot security: WPA2/WPA3 transition configuration. iOS implementation: Swift and NetworkExtension. joinOnce = false. The hidden property is not explicitly set. Observed behaviour Two independently instrumented automatic-join sessions showed a similar sequence: A1: The iPad associates with the Samsung hotspot and completes the WPA3 authentication exchange recorded by the Samsung. Approximately 3.35 seconds after the iPad-side join completion, iOS records a beacon-loss/roam declaration and the connection drops. A2: iOS attempts to reconnect, but the authentication exchange does not complete. A3: iOS automatically reconnects successfully, obtains a DHCP address and remains connected during the observation period. The same encrypted credentials work during both the initial and subsequent successful attempts. The apply() completion handler returns without an error. We understand that this does not establish that the device has joined successfully or that local IP connectivity is ready. What we have investigated The first join used cached beacon information approximately eight seconds old; the subsequent successful join used fresh scan information. AWDL activity was observed, but we have not established a causal relationship. Location Services scanning does not explain the first failure in our second instrumented session. The diagnostic label "Beacons Lost" is not being treated as proof of actual missed beacon frames. We have not independently established which WPA mode the iPad negotiated. We have not yet measured TCP readiness during the failed and successful attempts. We do not currently have a standalone minimal Xcode reproduction project. The behaviour was observed using our Flutter-based iOS probe and physical devices. Questions for developers familiar with NetworkExtension Has anyone observed intermittent first-join instability with NEHotspotConfigurationManager when joining a newly created Android LocalOnlyHotspot using WPA2/WPA3 transition mode? Are there documented limitations or known issues involving the first automatic join to a newly created hotspot profile? What is the recommended supported approach for determining that the intended Wi-Fi network is genuinely connected after apply() completes? What is the most reliable way to establish that local TCP communication is ready before beginning an application-level transfer? Are there additional public diagnostic facilities or measurements that could help distinguish Wi-Fi association instability from DHCP or subsequent network-path problems? We are looking for a documented, App Store-compatible approach. We are not assuming a particular root cause and do not want to rely on private APIs or undocumented system behaviour. Any practical experience or pointers to relevant Apple documentation would be appreciated.