Post

Replies

Boosts

Views

Created

iOS Local Network Discovery (UDP Multicast / SSDP) Not Working – Works on AndroidiOS Local Network Discovery (UDP Multicast / SSDP) Not Working – Works on Android
Title: iOS Local Network Discovery (UDP Multicast / SSDP) Not Working – Works on Android Hi everyone, I’m facing an issue with local network device discovery on iOS. The same implementation works perfectly on Android, but fails (or behaves inconsistently) on iOS. What I’m trying to do I am building a React Native app that discovers Wi-Fi audio devices (Arylic / Linkplay-based speakers) on the same local network. The discovery flow: Send SSDP (UDP multicast) M-SEARCH request to 239.255.255.250:1900 Listen for device responses Fetch device description via HTTP (LOCATION header) Parse and store discovered devices What works ✅ Android: Device discovery works reliably (multiple devices detected) ❌ iOS: No devices are discovered (or discovery is very inconsistent) iOS Configuration I have already added the required permissions in Info.plist: NSLocalNetworkUsageDescription NSBonjourServices (including _http._tcp, _airplay._tcp, _spotify-connect._tcp, etc.) NSAppTransportSecurity with local network exceptions The app correctly prompts for Local Network permission, and permission is granted. Implementation Details Using UDP sockets (react-native-udp) Joining multicast group: 239.255.255.250 Sending SSDP M-SEARCH requests every few seconds Listening for responses via socket on('message') Observed Behavior on iOS UDP socket initializes successfully No errors thrown No SSDP responses received devices array remains empty HTTP-based direct calls to known device IPs work fine Additional Notes The same network, same devices, same code works on Android iOS device is on the same Wi-Fi network Tried both real device and simulator (expected simulator limitations) Questions Is UDP multicast (SSDP) restricted or unreliable on iOS for third-party apps? Are there additional entitlements required to receive multicast responses? Is there any official Apple-recommended approach for discovering LAN devices (other than Bonjour)? Is this a known limitation of iOS networking stack? As a fallback, I’m considering scanning the local subnet via HTTP requests, but that’s less efficient compared to SSDP. Any guidance or clarification from Apple engineers or others who have faced similar issues would be greatly appreciated. Thanks in advance.
0
0
22
2w
Local Network Discovery Works in Debug but Not in TestFlight (Wi-Fi Speaker Connection Issue)
Hi team, I’m having an issue with my iOS app related to local network communication and connecting to a Wi-Fi speaker. My app works similar to the “4Stream” application. The speaker and the mobile device must be on the same Wi-Fi network so the app can discover and connect to the speaker. What’s happening: When I run the app directly from Xcode in debug mode, everything works perfectly. The speaker gets discovered. The speaker gets connected successfully. The connection flow completes without any problem. But when I upload the same build to TestFlight, the behaviour changes completely. The app gets stuck on the “Connecting…” screen. The speaker is not discovered. But the same code is working fine on Android It never moves forward from that state. So basically: Debug Mode: Speaker is detected and connected properly TestFlight: Stuck at “Connecting…”, speaker does NOT get connected This makes me believe something related to local network access, multicast, Wi-Fi info permissions, or Bonjour discovery is not being applied correctly in the release/TestFlight environment. Below is my current Info.plist and Entitlements file, which already include Local Network Usage, Bonjour services, Location usage for SSID, multicast entitlements, wifi-info, etc. My Info.plist <key>CADisableMinimumFrameDurationOnPhone</key> <true/> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>Wanwun</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>$(MARKETING_VERSION)</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>$(CURRENT_PROJECT_VERSION)</string> <key>LSRequiresIPhoneOS</key> <true/> <!-- Allow HTTP to devices on LAN --> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <key>NSExceptionDomains</key> <dict> <key>local</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> <key>localhost</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> </dict> </dict> <!-- Local Network Usage --> <key>NSLocalNetworkUsageDescription</key> <string>This app needs local network access to discover and control your sound system device over Wi-Fi.</string> <!-- Bonjour services for discovery --> <key>NSBonjourServices</key> <array> <string>_http._tcp.</string> <string>_wrtn._tcp.</string> <string>_services._dns-sd._udp.</string> </array> <!-- Location for SSID Permission --> <key>NSLocationWhenInUseUsageDescription</key> <string>This app requires location access to read the connected Wi-Fi information.</string> <!-- Camera / Photos --> <key>NSCameraUsageDescription</key> <string>This app needs camera access to capture attendance photos.</string> <key>NSPhotoLibraryAddUsageDescription</key> <string>This app saves captured photos to your gallery.</string> <key>NSPhotoLibraryUsageDescription</key> <string>This app needs access to your gallery to upload existing images.</string> <!-- Bluetooth --> <key>NSBluetoothAlwaysUsageDescription</key> <string>This app uses Bluetooth to discover nearby sound system devices.</string> <key>NSBluetoothPeripheralUsageDescription</key> <string>This app uses Bluetooth to connect with your sound system.</string> <!-- Launch screen --> <key>UILaunchStoryboardName</key> <string>LaunchScreen</string> <!-- Device Capabilities --> <key>UIRequiredDeviceCapabilities</key> <array> <string>arm64</string> </array> <!-- Orientation --> <key>UISupportedInterfaceOrientations</key> <array> <string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string> </array> <key>UIViewControllerBasedStatusBarAppearance</key> <false/> My Entitlements What I need help with: I want to understand why the app behaves correctly in debug mode (where the speaker connects without issues), but the same functionality fails in TestFlight. Is there something additional required for: Local network discovery on TestFlight? Multicast networking? Reading the Wi-Fi SSID? Bonjour, service scanning? Release build / TestFlight network permissions? If any extra entitlement approval, configuration, or specific service type is needed for TestFlight builds, please guide me. Thank you for your help.
1
0
358
Dec ’25
Local Wi-Fi UDP discovery works in Debug but stops working in TestFlight (React Native app)
Hi everyone, I am building a React Native iOS app that discovers audio devices on the local Wi-Fi network using UDP broadcast + mDNS/Bonjour lookup (similar to the “4Stream” app). The app works 100% perfectly in Debug mode when installed directly from Xcode. But once I upload it to TestFlight, the local-network features stop working completely: UDP packets never arrive Device discovery does not work Bonjour/mDNS lookup returns nothing Same phone, same Wi-Fi, same code → only Debug works, TestFlight fails react-native-udp for UDP broadcast react-native-dns-lookup for resolving hostnames react-native-xml2js for parsing device responses
1
0
112
Nov ’25
iOS Local Network Discovery (UDP Multicast / SSDP) Not Working – Works on AndroidiOS Local Network Discovery (UDP Multicast / SSDP) Not Working – Works on Android
Title: iOS Local Network Discovery (UDP Multicast / SSDP) Not Working – Works on Android Hi everyone, I’m facing an issue with local network device discovery on iOS. The same implementation works perfectly on Android, but fails (or behaves inconsistently) on iOS. What I’m trying to do I am building a React Native app that discovers Wi-Fi audio devices (Arylic / Linkplay-based speakers) on the same local network. The discovery flow: Send SSDP (UDP multicast) M-SEARCH request to 239.255.255.250:1900 Listen for device responses Fetch device description via HTTP (LOCATION header) Parse and store discovered devices What works ✅ Android: Device discovery works reliably (multiple devices detected) ❌ iOS: No devices are discovered (or discovery is very inconsistent) iOS Configuration I have already added the required permissions in Info.plist: NSLocalNetworkUsageDescription NSBonjourServices (including _http._tcp, _airplay._tcp, _spotify-connect._tcp, etc.) NSAppTransportSecurity with local network exceptions The app correctly prompts for Local Network permission, and permission is granted. Implementation Details Using UDP sockets (react-native-udp) Joining multicast group: 239.255.255.250 Sending SSDP M-SEARCH requests every few seconds Listening for responses via socket on('message') Observed Behavior on iOS UDP socket initializes successfully No errors thrown No SSDP responses received devices array remains empty HTTP-based direct calls to known device IPs work fine Additional Notes The same network, same devices, same code works on Android iOS device is on the same Wi-Fi network Tried both real device and simulator (expected simulator limitations) Questions Is UDP multicast (SSDP) restricted or unreliable on iOS for third-party apps? Are there additional entitlements required to receive multicast responses? Is there any official Apple-recommended approach for discovering LAN devices (other than Bonjour)? Is this a known limitation of iOS networking stack? As a fallback, I’m considering scanning the local subnet via HTTP requests, but that’s less efficient compared to SSDP. Any guidance or clarification from Apple engineers or others who have faced similar issues would be greatly appreciated. Thanks in advance.
Replies
0
Boosts
0
Views
22
Activity
2w
Local Network Discovery Works in Debug but Not in TestFlight (Wi-Fi Speaker Connection Issue)
Hi team, I’m having an issue with my iOS app related to local network communication and connecting to a Wi-Fi speaker. My app works similar to the “4Stream” application. The speaker and the mobile device must be on the same Wi-Fi network so the app can discover and connect to the speaker. What’s happening: When I run the app directly from Xcode in debug mode, everything works perfectly. The speaker gets discovered. The speaker gets connected successfully. The connection flow completes without any problem. But when I upload the same build to TestFlight, the behaviour changes completely. The app gets stuck on the “Connecting…” screen. The speaker is not discovered. But the same code is working fine on Android It never moves forward from that state. So basically: Debug Mode: Speaker is detected and connected properly TestFlight: Stuck at “Connecting…”, speaker does NOT get connected This makes me believe something related to local network access, multicast, Wi-Fi info permissions, or Bonjour discovery is not being applied correctly in the release/TestFlight environment. Below is my current Info.plist and Entitlements file, which already include Local Network Usage, Bonjour services, Location usage for SSID, multicast entitlements, wifi-info, etc. My Info.plist <key>CADisableMinimumFrameDurationOnPhone</key> <true/> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>Wanwun</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>$(MARKETING_VERSION)</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>$(CURRENT_PROJECT_VERSION)</string> <key>LSRequiresIPhoneOS</key> <true/> <!-- Allow HTTP to devices on LAN --> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <key>NSExceptionDomains</key> <dict> <key>local</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> <key>localhost</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> </dict> </dict> <!-- Local Network Usage --> <key>NSLocalNetworkUsageDescription</key> <string>This app needs local network access to discover and control your sound system device over Wi-Fi.</string> <!-- Bonjour services for discovery --> <key>NSBonjourServices</key> <array> <string>_http._tcp.</string> <string>_wrtn._tcp.</string> <string>_services._dns-sd._udp.</string> </array> <!-- Location for SSID Permission --> <key>NSLocationWhenInUseUsageDescription</key> <string>This app requires location access to read the connected Wi-Fi information.</string> <!-- Camera / Photos --> <key>NSCameraUsageDescription</key> <string>This app needs camera access to capture attendance photos.</string> <key>NSPhotoLibraryAddUsageDescription</key> <string>This app saves captured photos to your gallery.</string> <key>NSPhotoLibraryUsageDescription</key> <string>This app needs access to your gallery to upload existing images.</string> <!-- Bluetooth --> <key>NSBluetoothAlwaysUsageDescription</key> <string>This app uses Bluetooth to discover nearby sound system devices.</string> <key>NSBluetoothPeripheralUsageDescription</key> <string>This app uses Bluetooth to connect with your sound system.</string> <!-- Launch screen --> <key>UILaunchStoryboardName</key> <string>LaunchScreen</string> <!-- Device Capabilities --> <key>UIRequiredDeviceCapabilities</key> <array> <string>arm64</string> </array> <!-- Orientation --> <key>UISupportedInterfaceOrientations</key> <array> <string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string> </array> <key>UIViewControllerBasedStatusBarAppearance</key> <false/> My Entitlements What I need help with: I want to understand why the app behaves correctly in debug mode (where the speaker connects without issues), but the same functionality fails in TestFlight. Is there something additional required for: Local network discovery on TestFlight? Multicast networking? Reading the Wi-Fi SSID? Bonjour, service scanning? Release build / TestFlight network permissions? If any extra entitlement approval, configuration, or specific service type is needed for TestFlight builds, please guide me. Thank you for your help.
Replies
1
Boosts
0
Views
358
Activity
Dec ’25
Local network permission working in Debug but not in TestFligh
I am developing a React Native app that uses UDP broadcast and device discovery over the local Wi-Fi network (similar to 4Stream). In Debug mode everything works, but after uploading to TestFlight the local network communication stops working. I have already added the following to Info.plist:
Replies
1
Boosts
0
Views
249
Activity
Nov ’25
Local Wi-Fi UDP discovery works in Debug but stops working in TestFlight (React Native app)
Hi everyone, I am building a React Native iOS app that discovers audio devices on the local Wi-Fi network using UDP broadcast + mDNS/Bonjour lookup (similar to the “4Stream” app). The app works 100% perfectly in Debug mode when installed directly from Xcode. But once I upload it to TestFlight, the local-network features stop working completely: UDP packets never arrive Device discovery does not work Bonjour/mDNS lookup returns nothing Same phone, same Wi-Fi, same code → only Debug works, TestFlight fails react-native-udp for UDP broadcast react-native-dns-lookup for resolving hostnames react-native-xml2js for parsing device responses
Replies
1
Boosts
0
Views
112
Activity
Nov ’25