Recommendation for best stack for new mobile app project

[Jchristf]

We have a Nordic 52840 based product which today we support with a custom gateway hardware.  Now we want to write mobile apps (Android and IOS) to talk to this directly.

We are wondering if the older Xcode and Java projects written for Thingy:52 is still a good place to start?

We are concerned if we start there, it will be outdated before release due to ongoing development like Kotlin BLE library (but on the other hand the v2 Kotlin library says not ready for production yet).

What is the best starting point for new project today?

Thanks,

Jacob

[Hieu]

Hi Jacob,

We have a few libraries to support app development right now, but unfortunately not a production ready level Kotlin library. Below is a list:

Production ready:
Android: https://github.com/NordicSemiconductor/Android-BLE-Library
iOS: https://github.com/NordicSemiconductor/IOS-BLE-Library

Work-in-progress:
Kotlin Multiplatform https://github.com/NordicSemiconductor/KMM-BLE-Library
Kotlin on Android: https://github.com/NordicSemiconductor/Kotlin-BLE-Library

Hieu

[Jchristf]

Do you have an estimate of first production version of espc. the KMM library?

Also what is the benefit of your BLE libraries vs. using e.g. Android own BLE library?  Is there something about Nordic chips that works better with your libraries?

[Aleksander Nowakowski]

Hello!

Our BLE libraries are just wrappers around the native API. They simplify code (better API), un-spaghettiify the code (callbacks vs suspend/enque) and internally do some workarounds that help with connection stability. You can achieve the same level of robustness as the native API when it comes to BLE.

Currently we are working on the Kotlin BLE Library which at some point in the future should transition to Kotlin Multiplatform, but I can't promise any specific date. The KMM project was a bit of an experiment, that put us to redesign the API which led to change from v1 to v2 of Kotlin BLE Library. With the new modules it should be easier to keep common implementation in core modules and platform specific separately.

If you need KMM now, I would suggest looking https://github.com/JuulLabs/kable from JuulLabs.

The choice of BLE library is not related to our chips. They all use the underlying native API and just differ with API and available set of features. Nordic has some other mobile libraries that offer higher-level API for specific usecases, like Device Firmware Update, Memfault integration, Wi-Fi provisioning, etc., but the basic BLE ones work on GATT level.

[Jchristf]

Thanks, this is very helpful.

It seems multiplatform is like the holy grail (for the 20 years I've followed). Everyone is working on it, but it never quite materializes 100%.   

[Aleksander Nowakowski]

For us it's just a matter of prioritization, as we are a very small team doing mobiles. But eventually we will be there! Holy Grail will be ours!

[nicolask]

Hello Aleksander!

You mentioned that the KMM experiment led to the v2 redesign to better separate core and platform modules. Beyond that modularity, what were the specific limitations or issues in the v1 API that you needed to fix?

best regards

Nicolas

[Aleksander Nowakowski]

Hello,
Comparing to the Java Android BLE Library, the main improvements are:
* Kotlin implementation
* Making it ready for Kotlin Multiplatform
* Testability, option to mock Bluetooth LE devices with the same app-facing API
* Waaaay easier maintenance and option for future improvements (improved code structure)

Kotlin lib v1 was an experiment that we learned what we actually need. I believe that v2 has more readable API. Change of the API led to v2.