Some manufacturers offer SDKs to allow programmatic access to their beacons from iOS and Android.
Most SDKs tend to be poorly implemented/documented, tie your code into using that particular beacon and rarely get updated to use newer mobile platform APIs. They also tend to be thin abstractions over the Android and iOS Bluetooth APIs.
If you rely on a beacon manufacturer that doesn’t update their SDK, it’s eventually the case that the underlying Android and/or iOS API changes such that your solution becomes non-optimal and, in the worse case, breaks.
Instead, when you can, we recommend you use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type. In this way you don’t end up depending on intermediate code and this has the benefit that you can more easily change beacon providers.
However, there are some cases where you must use the manufacturer library. This is usually in cases where there the app needs to connect with the beacon (as opposed to only view advertising scans) to perform beacon specific things. The Sensoro SDK is an example where their private protocol (to prevent squatters) and sensor information can only be obtained via their SDK.