No. Could you expand on this a little bit? I’ve seen mixed thoughts online about Multipeer Connectivity, and would love to hear yours. Unfortunately, I won’t have physical access to the other device - this is going to be a proximity-based data transfer, kind of like NFC (which I can’t use for various reasons). That’s why I’m using CLBeacon - each phone acts as an iBeacon advertiser and an iBeacon detector, and when it finds a beacon in its immediate proximity, tries to initiate a peer-to-peer connection with them using Network.framework. Maybe the key negotiation could happen during that iBeacon detection phase, where if it detects an iBeacon, it sends it a UInt64 over Bluetooth and receives another UInt64, and then both peers combine them to create the key. Problem is, anyone could just eavesdrop eavesdrop on the Bluetooth connection and gain access to the key. Is there some other form of key negotiation I could do during the iBeacon phase?

I see. Implementing this kind of lazy encryption myself would exponentially increase complexity, and I'm not sure it's worth it. I'm using the Network framework for two-device peer-to-peer connectivity since I've been advised to stay away from Multipeer Connectivity. However, it seems like Multipeer Connectivity implements its own encryption and all I need to do is specify .required in the argument. My needs are quite simple – only two devices need to share a peer-to-peer connection, and only an image and some text being is sent over that connection. But encryption is a must. Do you think Multipeer Connectivity may be a better fit for my needs?

It seems like Paul from Hacking with Swift has come once again to save the day - just found his article on how to detect whether the device is facing upwards or downwards through a notification! (can't post the link, Apple, or at least the forum text editor, doesn't seem to like it)

Ok, I'll look into that, thanks!

Thanks a lot! NWProtocolWebSocket seems perfect for the transmission of data. From what I understood, I can: Have the device create their unique ID (UUID?) Make the device be a browser and listener (while emitting a Bluetooth signal) simultaneously. If the device's browser detects a listener (who's BLE signal RSSI passes a certain threshold, meaning the device is right next to/on top of the first), they cancel their own listener and send their unique ID. Conversely, if the device's listener is connected to by another device's browser, the first device cancels their browser, and once they have received the other end's unique ID, they send their own unique ID. The device makes a sanity check using your clever method by making sure that this unique ID pair doesn't already exist (which would otherwise mean that this connection has already been made by their opposite browsers and listeners during steps 2-4). If this pair already does exist, the new connection is cancelled. Once the sanity check is passed, a WebSocket connection is made, and the data is transferred wirelessly between the two phones.