iOS app getting 2 iIPs for same service on bonjour. P2P replication

Hello, I have an iOS app that replicates P2P when there’s no internet connection. It works ok if bluetooth is disabled, but when it is enabled, bonjour is sending 2 different IPs for the same service: One corresponds to the wifi connection and the other to bluetooth connection.
How can I either disable bluetooth connection for my app or how can I tell my app to only pay attention to the wifi connection?
Any help is well appreciated,

What is the problem that occurs when Bluetooth is enabled?

Thanks for your quick response Jens, we implemented a mechanism (according to your suggestions long time ago) to select a schema to replicate with in order to avoid all devices replicating with all (star replication), so we are selecting the device with the higher ip number and it is set as the “server” and all the rest of devices connect with it.
The problem is, that the replication works good when all the IPs are wifi IPs, but not when they are bluetooth IPs, the connection gets hanging as the bluetooth connection does not sinchronize for a reason I don’t know.
This causes synchronization problems as some devices find the correct wifi server and others are trying to synchronize to the bluetooth one with no response.
So I’d either like to disable bluetooth sinchronization (or even disable bluetooth on the device for the app), or somehow discard any IP corresponding to bluetooth connection so that none bluetooth IP is considered as a p2p server.
Any idea is welcomed,

This sounds like a question about Bluetooth-based Bonjour and IP networking on iOS, which is something I’m not that familiar with. You should try asking on Apple’s developer forums, or on the macnetworkprog mailing list hosted at

One thing I’ve been told is that TCP over ad-hoc networks works best when you specify addresses as (.local) hostnames rather than as raw IP addresses. This allows the network stack to choose the best address/interface. So that implies you should use replication URLs of the form http://somephone.local:1234/db/ instead of You can get the NSNetService’s hostname from the API rather than resolving it down to an address.

we are selecting the device with the higher ip number and it is set as the “server”

Hopefully this takes IPv6 into account, instead of treating an IP address as a uint32_t :slight_smile: Apple’s being pretty aggressive about pushing developers to make apps work properly on all-IPv6 networks.

Thank you Jens, I’ll explore the .local hostnames and see what happens.