55

I am currently working on an iOS application based on bluetooth low energy devices. In order to get a unique identifier to compare the peripherals got, I have to get the MAC address of the peripherals.

It is observed that the UUID property of a peripheral device varies across iOS devices and also for the peripheral device to get a UUID, it will have to get connected to a master device at least once. Since I have to deal with check-in's I don't want to establish a connection. As I went through the bluetooth services portal, I found that the device information itself is a service, which couldn't be retrieved unless a connection has been established between the master iOS device and the peripheral bluetooth low energy device.

I found that in Android we get the entire information of the device, including its MAC address (using getAddress()) when we get the response from the device on scanning itself.

I didn't find any properties in CBPeripheral class related to the device address. Another way to get a unique parameter would be to customize the advertisement data to send additional information regarding the device, which requires more work on firmware side.

So is there any way in iOS that I could get the MAC address of the bluetooth low energy peripheral without establishing a connection?

Any help would be greatly appreciated.

Lilya
  • 495
  • 6
  • 20
Feby Sam
  • 793
  • 1
  • 6
  • 14
  • Note that there is no such thing as "pairing" in BLE, nor is there a "connection". The UUID can be used as unique identifier for a specific Bluetooth device, as explained by @Tarryn, and it assigned the first time iOS talks to the device, which is at the discovery phase. Can you share your reasons why you need that ID to be the same over multiple iOS devices? – fishinear Nov 21 '13 at 13:57
  • 18
    @fishinear your comment is either very wrong or you are just innocently using non-interchangeable terms interchangeably. Of course there is pairing in BLE (e.g. IO capabilities exchange) and of course there is a connection estabilished (when a master initiates towards an advertising slave). – Bogdan Alexandru Jul 03 '14 at 14:36
  • 2
    @BogdanAlexandru Sorry, I used the terms in the sense that most people are familiar with: "pairing" in the sense of exchanging pin codes to establish a long term security association between devices. And although BLE has the concept of "connection", it is much more light-weight and temporary than in traditional Bluetooth. – fishinear Jul 03 '14 at 15:49

5 Answers5

30

CBPeripheral's identifier property will serve your purpose, available from a still-unconnected device in CBCentralManager's didDiscoverPeripheral delegate method:

- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary *)advertisementData RSSI:(NSNumber *)RSSI

CBPeripheral *peripheral ...

NSUUID* serverId = [peripheral identifier];

I have a half dozen LE devices I'm experimenting with, including multiple sets of identical devices. I just confirmed that across two iOS devices, the identifiers for all of these LE widgets were different, but for EACH iOS device, the identifier for each widget was retained across application launches and even across app deletes and reinstalls. I would say this definitively proves that the OS is storing enough info internally that for a given iThing, you'll be able to distinguish between, and re-identify, all the peripherals your app encounters, without actually connecting to them. Also note that the advertisementData, also available before connecting, is full of useful info like CBAdvertisementDataLocalNameKey, CBAdvertisementDataManufacturerDataKey, CBAdvertisementDataServiceUUIDsKey, CBAdvertisementDataSolicitedServiceUUIDsKey, and others, although none as certain to uniquely identify the device as [peripheral identifier] is.

I didn't try doing a device backup and restore to prove the UUIDs were retained, but I'd wager they are, and if they're not, it's something Apple would consider a bug.

Falko
  • 17,076
  • 13
  • 60
  • 105
Taryn
  • 1,670
  • 1
  • 15
  • 22
  • 10
    The UUID you talk about is generated internally by Apple and then stored. So yes, it is unique to the device, and it is consistently used for that device. But for the same device, it differs between one iPhone/iPad and another, which is what the OP was after. – fishinear Nov 21 '13 at 13:55
  • 3
    also note that the otherwise unique generated UUID CAN change (rare case but it definitely CAN change) so you need your own method if you have to permanently identify a given peripheral – Hofi Aug 13 '15 at 09:02
  • @Hofi - do you know in what circumstances it can change? The documentation seems pretty clear that it is ok to store it... – Airsource Ltd Oct 23 '15 at 15:41
  • 1
    @AirsourceLtd - yes, the doc does not say a word about this very important thing, just turn off/on the otherwise advertising peripheral side device BT connection, after that you will see a new peripheral UUID in your central discovery for the same remote device (it is confirmed by the Apple engineers too, but you can test it easily) – Hofi Oct 23 '15 at 16:47
  • @Hofi - thanks. Not quite clear what you mean by "turn off/on the otherwise advertising peripheral side device BT connection". I presume you don't mean just power-cycling the device. Perhaps making the device temporarily non-connectable? Or something else? Could you elaborate - thanks in advance! – Airsource Ltd Oct 28 '15 at 18:04
  • 2
    @AirsourceLtd in the BT connection there is a central and the peripheral device as you already know, f.e if your advertising peripheral side is an iOS app than simply turn off and on again the device BT connection, you will see the newly discovered device on the central side will have a different, new peripheral UUID – Hofi Oct 29 '15 at 09:22
  • @Hofi I have reproduced the situation where the MAC address changes when I turn bluetooth off and on again (while the app is running). It seems to me likely that it IS perfectly safe to use the identifier as a unique identifying value when dealing with real embedded peripherals using BLE SoCs. – Airsource Ltd Nov 02 '15 at 14:14
  • When I say "real embedded peripherals" I mean where you control the peripheral as well. Obviously if the peripheral rotates MAC addresses, a different solution is needed. – Airsource Ltd Nov 02 '15 at 14:39
  • Power cycling bluetooth does not change UUID – Sentry.co Mar 15 '21 at 01:01
15

Updated Answer :-

After iOS 12 we can get UDID 

   print(UIDevice.current.identifierForVendor)

   print(UIDevice.current.identifierForVendor?.uuidString)

Before iOS 12**

There is no public API to get this information.

If this is an internal or jailbreak application you can get the value of the kLockdownBluetoothAddressKey key via liblockdown.dylib

Jogendra.Com
  • 6,394
  • 2
  • 28
  • 35
  • 4
    It is not meant to be a jailbroken application. So it seems there is no way to get the MAC address of the peripheral device in iOS unless it is paired. It is a big drawback. It would be lot more easier if we get a unique identifier. May be Apple have to look into it. – Feby Sam Sep 24 '13 at 05:28
  • 1
    @user1513623 If I remember correctly Apple consider getting MAC address of unpaired peripheral as potential security weakness, cannot find related documentation now though. – reTs Sep 24 '13 at 07:19
  • 1
    @reTs As you said security would be the main concern as for Apple. – Feby Sam Sep 24 '13 at 12:02
12

Low energy peripherals may use privacy feature which hides the MAC address, so it is not necessarily even possible to get the address before connection or bonding. If you somehow get the MAC address which goes over the air, you need to handle privacy or you have interoperability problems.

Apple uses UUIDs to abstract these privacy features out so users do not need to worry about those.

Correct way to do that like you wrote is to either add some vendor specific data to advertisement packet or use the Device Information service.

makkara
  • 130
  • 4
12

On-behalf of the discussion of the other professionals I've found some facts which says -

“iOS hides the MAC address of the device and generates a UUID. The UUID on iOS is generated by the iOS device. Different iOS devices will get different UUIDs for the same peripheral. The MAC address is usually based on the hardware. If we both have iPhones and scan the same peripheral, we'll see different UUIDs. iOS generates the UUID on the device and hides the MAC address.

Summary - iOS doesn't let you get the MAC address of a device, it gives you a random UUID instead.“


Source - https://github.com/don/cordova-plugin-ble-central/issues/77

As per above study I've found that there’s not such a unique way to get connect to the board so far, Every board has a MAC address, which Doesn’t changes and easy to access in (only) Android, while iOS doesn’t allow to access MAC Address of the peripheral, however iOS use this MAC address to create a peripheral identifier (UUID), which is unique on (unique) device only. The peripheral identifier for a single Board is different for different iPhones devices (but unique on single device).

However we can connect to a board by searching with Peripheral's Bluetooth Service UUID, but this service UUID is same for all the boards of a kind say- “Adafruit Feather M0”. It means the App will look around the BLE boards of the same type (“Adafruit Feather M0”) and will get connect to ANY one of them. In order to connect to a particular user to a specific Board doesn’t seems to be possible so far due to the inaccessibility of MAC and giving the random UUID in iOS.

Mohit G.
  • 1,157
  • 2
  • 12
  • 22
0

You can access to the MAC ADDRESS without problem in iOS 12. To get the mac address you have to follow the next steps.

  1. Parse the Data received by the BLE device to String.
extension Data{
func hexEncodedString() -> String {
        let hexDigits = Array("0123456789abcdef".utf16)
        var hexChars = [UTF16.CodeUnit]()
        hexChars.reserveCapacity(count * 2)

        for byte in self {
            let (index1, index2) = Int(byte).quotientAndRemainder(dividingBy: 16)
            hexChars.insert(hexDigits[index2], at: 0)
            hexChars.insert(hexDigits[index1], at: 0)
        }
        return String(utf16CodeUnits: hexChars, count: hexChars.count)
    }
}
  1. Add a separator ":" to the address.
extension String {
    func separate(every stride: Int = 4, with separator: Character = " ") -> String {
        return String(enumerated().map { $0 > 0 && $0 % stride == 0 ? [separator, $1] : [$1]}.joined())
    }
}
  1. In didReadValueForCharacteristic( characteristic: CBCharacteritic) you can use the previous 2 functions to get the mac address.
func didReadValueForCharacteristic(_ characteristic: CBCharacteristic) {
if characteristic.uuid == BleDeviceProfile.MAC_ADDRESS, let mac_address = characteristic.value?.hexEncodedString().uppercased(){
            let macAddress = mac_address.separate(every: 2, with: ":")
            print("MAC_ADDRESS: \(macAddress)")
        }
}
  1. enjoy your mac address: "MAC_ADDRESS: 00:0A:57:4E:86:F2"
jlandyr
  • 99
  • 1
  • 6
  • 1
    Is this consistent across devices? – redolent Jan 21 '20 at 04:55
  • 2
    This works only if the peripheral sends the MAC address as a characteristic. Which is not an option for everyone. That's what you compare as **BleDeviceProfile.MAC_ADDRESS** this variable simply consists of the UUID of the characteristic that provides a read-only value of peripheral MAC address. If you have this characteristic, then this will work on any iOS version as this is just yet another characteristic of the given peripheral. – Prasad De Zoysa Aug 22 '20 at 14:40