I've been investigating an issue with iOS Bluetooth scanning. When scanning for BLE advertisements on iOS the UUID of an iBeacon is not what I expect it to be (according to what the default UUID of the beacon according to Radius Networks, the provider of said beacon). In fact, it's completely unrelated. What's curious, though, is that the exact same code running under Mac OS X Mavericks works just fine. Because of this I'm starting to believe it's simply just something the OS is doing.
Here's the iOS implementation: https://github.com/syoutsey/iOSBLE
And the Mac OS X implementation: https://github.com/syoutsey/MacBLE
Both of those repos are Swift-based. I've coded the same ones in Objective-C with the same results.
I've read the Radius Networks post where it's not correctly returning the devices UUID (http://developer.radiusnetworks.com/2013/10/21/corebluetooth-doesnt-let-you-see-ibeacons.html) but it's curious that the RadBeacon Scanner app (by Radius Networks) is able to correctly identify the UUID. What is that application doing that mine is not?
You have stumbled upon a strange restriction in iOS that does not apply to OSX. On iOS only, CoreBluetooth blocks the ability to read the data of a Bluetooth LE advertisement if it meets the iBeacon specification.
It is unclear why Apple does this. Obviously folks can read the raw bytes on other platforms like Android, Linux and even OSX. (The latter of which you have demonstrated.) Perhaps they just do not want folks to bypass CoreLocation to look for iBeacons. Or perhaps they just did not think it through.
Whatever the reason, I am afraid you are out of luck on iOS.
The RadBeacon scanner connects to the device with CoreBluetooth and uses Gatt to read the identifiers. It does not get the identifiers from the advertisement.