This post comes straight from the Bluetooth Developer Academy community forums.
It all started with this simple question from one of the Academy members:
The information contained in the thread has so much value that I decided to summarize and publish it as a blog post here.
I won’t bore you with all the details of the thread and every individual response, instead, I will be summarizing the responses in a more organized manner below.
Note: The opinions below are those of the authors of each post, so others may have different opinions based on their experiences. Author initials were used in the post instead of full names to protect privacy.
Reasons you should not use a third-party BLE cross-platform framework (React Native, Flutter, etc.)
One Academy member (A. I.) responded with the following:
…this is always an interesting discussion in any project deciding the language and tools to be used and usually there is a lot of bias in opinions. For example, personally, I’d be heavily biased towards using Swift for iPhones and Kotlin for Android because my experience (at the time of making this decision few years ago) is that the libraries for Bluetooth management in React Native were very limited…
The thing I would consider thinking about is the throughput and importance of Bluetooth connection reliability is in your app. Most libraries (even for Swift and Kotlin) are fine for general purpose usage but when you work at the limits then you might need functions that are unavailable in 3rd party libraries or in some cases the overhead may be too much.
To which the original author (M. K.) responded:
For my devices, the throughput is quite low and not really worried about it and also the connection is only a few minutes a day and close range so usual connection reliability should be fine. But one thing is DFU. We do need DFU function and I wonder if those commonly used BLE libraries of React Native (e.g ble-manager, ble-plx) are ok or glitchy. Currently we are also having some issue connecting Android 12 phones (I don’t know the detail) and that makes me wonder if some issues/bugs like cybersecurity happen in the future, how quickly those get fixed compared to Android/iOS Kotlin/Swift environment.
To add to this thought, you might want to reconsider using third-party frameworks if you’re looking to implement over-the-air device firmware updates (OTA DFU). If your peripheral’s chipset vendor provides OTA DFU iOS or Android (such as in the case of Nordic Semiconductor), then you are probably better off using their provided SDK than implementing your own using the third-party frameworks.
One Academy member (B. S.) who is an experienced BLE app developer summarized his thoughts in the following great set of guided points:
What is the desired user experience?
A. Is this a “quick check” app? By quick check, I mean – does the user open the app once in a while to take a Blood Pressure reading or turn a light on/off? If so, I wouldn’t be afraid to use a generic BLE plugin on a Hybrid platform. (e.g. BLE Plx on React Native)
B. Does the app need to maintain a connection to the device at all times, even when the app is in the background?
C. Is the app time critical? e.g. does the app need to connect and transmit data in a small window of time?
If yes to either B or C, you will find it less error-prone to make your own ‘plugin’ to wrap the Bluetooth and background processing.
Communication between the device and app
A. Is there a lot of back and forth between the app and the device?
B. Are the data structures complicated?
C. Are you streaming files/data?
If yes to [any] of these, you will find it easier (e.g. less error-prone) to make your own ‘plugin’ to wrap the Bluetooth and communication. This is especially true if you are doing things like OTA or log transfer.
Is getting a product to market or proving a concept more important right now than a good user experience? e.g. can you tolerate possible less than desired App Store reviews? If you have anything more than just a simple “quick check” Bluetooth app, then you will want to write your own iOS and Android plugins to handle the Bluetooth communication. This will help improve the performance and reliability of the hybrid app.
But if the app is more complex and requires good throughput and constant background connectivity, I’d strongly recommend going 100% native.
GUI Elements and the impact of using third-party frameworks vs. native development
A follow-up question from the original author (M. K.):
Do you think user will have a much better experience from the native app than React Native (not just BLE but just all GUI aspects)?
To which B. S. responds:
To answer your last question – I’ve seen some good React Native apps that have used Bluetooth. It can be a great tool because you get some re-use from GUI and other common business logic (e.g. network connectivity or data processing).
It sounds like a React Native demo would be a good first step.
When you get to the point where you need DFU code – I would recommend using Swift/Kotlin, and exposing a simple API to the rest of the app.
If you stick with R/N, you would expose an API over the React Native bridge. This API may be very simple (e.g. all you do is pass a filename that the Swift/Kotlin code will load and send to the device).
I think it’s possible to create pretty good apps with React Native, but also bad ones 🙂 And the same goes for Swift/Kotlin 🙂
Then the conversation shifted to another interesting aspect asked by another member (T. H.):
I am kind of a newbie IoT developer at present, actually new to software development in general. I am currently learning Flutter based BLE development using some third party plugins like flutter_blue and flutter_reactive_ble, for experimentation purposes mostly. Do you have experience in this arena, I mean flutter based BLE development? If you do have experience, can you share your two cents in this regard? The company I work for has a BLE product, which has an associated mobile app built in flutter. As far as I can remember for OTA DFU part, they had to use native Java code and swift code, as OTA DFU implementation in flutter was very error prone in the experimentation stage.
To which B. S. responded:
I have not worked on any Flutter apps. But I have talked to a few teams that are using Flutter to communicate with BLE devices.
I get the sense that the Flutter BLE plugins are more stable than the React Native BLE plugins. These Flutter teams tend to use flutter_blue/flutter_reactive_ble for simple apps and then write their own native plugins for things like DFU.
Purely my opinion here – if I had to choose between React Native and Flutter, I would lean toward Flutter.
To which A. I. weighs in:
I recently worked on a Flutter project and although it didn’t have DFU I felt like it was very stable and with a solid backing of community behind it there is a lot of support out there too.
T. H. then responds:
I also felt the same, the plugins for BLE in flutter are much stable and the community support is increasing gradually. Can you please share your personal preference between the two most prevalent packages in flutter, flutter_blue and flutter_reactive_ble?
A. I. responds:
There is very little separating the two and they seem to have feature parity as well. I went with flutter_blue as it appears to have a stronger community backing on GitHub.
One Academy member (C. G.) who is a security expert in the medical field then weighs in with his thoughts:
As a general ‘thought exercise’, you might want to wonder why if you can really write one code base (react, flutter, etc.) to function on all platforms why is this rarely done?
Unless it is a simple app (no BLE, no sensors, etc.) these frameworks introduce a lot of problems, and ‘yes’ cybersecurity could be one of them as well.
I am always reminded of how HTML5 was supposed to be the one language to run on all browsers, because almost all browsers were based on Apple’s Webkit engine, yet you can’t find any complete HTML5 apps that don’t have browser specific exceptions coded into it!
And that should have been simple, it’s just a browser, not something as complicated as a smartphone.
The original author (M. K.) responds:
If I were to develop the app (and have to use cross platform framework), I would choose Flutter rather than React Native because it seems to be getting more traction these days and nice to know BLE seems to be stable.
I agree with you. Cross-platform sounds good but of course there is a catch.. Do you have any specific concern on Cybersecurity for using cross platform development or just a general concern? I am in medical industry so I am pushing Java/Kotlin/Swift to our colleagues to be on the safe side but they are against it…
To which C. G. responds:
We also are medical device developers, including medical device apps. And [you’re] right to move them to the more modern languages. As for cybersecurity, if you are working one additional level from the “real” code, then you have no idea what good or bad practices are being created under the ‘covers’. and if they are there is nothing you can do it fix it short of creating a bunch of native code wrappers, and by then the question is [why] did I use this framework? 🤣
B. S. also weighs in:
Good points. Another reason for going native, especially on iOS, is that Apple will actually help you with issues (via the paid dev account). Good luck getting help for non-Appley platforms like React Native or Flutter.
That said, I have been surprised by some of the larger medical device organizations using hybrid (R/N or Flutter) for BLE apps. @C.G may have more insight, but it’s not like they are not used in the medical industry. But using them just adds additional complexity to an already complex/regulated software dev process.
It’s just good to make the decision with eyes wide open.
The original author (M. K.) responds:
It is a bit of a surprise some medical device organizations use hybrid but it is good to know. And also support and surrounding community is an important aspect to go with the native.
Yeah, if you end up making lots of wrappers for each platform, you will wonder what you are doing..😀
Flutter will be a nice hobby project for me. It sounds fun. 😀
Finally, C. G. weighs in:
No surprise why some MedDevs use a framework, the development team is being lead by people who think that a single app is cheaper to develop and maintain than two native apps.
These folks are wrong, but even in MedDev money is almost always the deciding factor and that’s what those frameworks are selling…
Fortunately we don’t see it that often.
Closing & Summary
As you can see, lots of really valuable information and insight in this single community thread!
And this is just one of the hundreds of threads that have provided valuable insights into many different aspects of Bluetooth Low Energy development.
Even as someone who has worked with Bluetooth Low Energy development for years, I, myself, learned a lot from this thread, and I’m very grateful to be a part of this great community of Bluetooth developers and experts within the Bluetooth Developer Academy!
I hope you found some helpful insights and information in this post.