iOS

On iOS, the end user needs to actively use the bluetooth audio for the connection to be detected reliably. The list of available devices (bluetooth) can report the same device twice: once as an audio device and once as a BLE. There is currently no way to filter them.

Please always check where and when you initialise the SDK. The SDK should be initialised as soon as the app finishes launching (inside the host app's AppDelegate.didFinishLaunchingWithOptions). After initialising the SDK the first next thing should be enabling the trip detection. Also please make sure that you're doing this setup and all these initialisations on the same thread, specifically on the main thread.

There were issues in the past where some host applications that were using cross-platform solutions were jumping from one thread to another, which in most cases was the culprit for all the issues. This relates to the correct initialisation of the SDK itself. NOTE: Starting with SDK v1.17 in the initialisation function we check if the current thread we are performing the current operation is the main thread. Although that is a public function that any host application can use to perform the same check: ThreadChecker.validateMainThread which is going to log a warning if we're not on the main thread.

It was also very helpful in other host applications' cases to also print the current thread they're on before, during and after each step of the SDK setup. In a few cases we noticed there were certain jumps from the main thread to a new thread and back to the main one, which was again the culprit in that specific situation.

In the IMS iOS SDK project, in the integration tests for the TripService we initialise the SDK in the same manner as we initialise it in the Example app, inside AppDelegate. For example in the TripServiceTests if we change the order in which we initialise the SDK and the TripService and if we initialise the TripService (.init with identity) before initialising the SDK, it results in a crash (this one to be more specific: "Portal/Container+Network.swift:27: Fatal error: 'try!' expression unexpectedly raised an error: Common.InjectionError.invalid"). This is because when we initialise the SDK we initialise the parent container (Common container) which then initialises and registers multiple resolvers and identifiers, required and that are used afterwards in the next containers. After this when we initialise a certain service class from the Portal module, that service gets initialised under the hood by creating or grabbing the network container (Portal container). This network container gets created by using the common container and when it's initialising new resolvers and identifiers it's injecting objects from the common container, so if that one's missing then we're going to miss them in the network container, which in turn will result in unexpected behaviour or most likely in a crash. You should check if you initialise the SDK in the AppDelegate, then you should enable trip detection and only after doing so should you initialise a certain service from the Portal module.