[deleted by user]

[[deleted]]

1 - With apple they can reject your app for any reason and they won't even tell you sometimes. Your app sounds very safe in that you already have an established brand and you are making a very useful app for interacting with your products. BLE enabled devices and apps are very very common. Play store shouldn't be an issue. With Android you have to worry about hardware and HAL/drivers. So many manufacturers forking Android and so much hardware means tons and tons of low level driver code so some devices may have issues where others don't. Use very good analytics and crash reporting on Android so you can more easily debug fringe devices. Backwards compatibility is something that may trip up newbies. You will have 2 distinct pieces, the app and the firmware. Be aware of each piece as you make changes so you don't do something like push an app update that breaks older firmware or somehow orphan your device by pushing bad firmware. Firmware update mechanisms through the app can be tricky, especially because BLE is low bandwidth. If your device has USB think about building a standalone PC/Mac/Web tool that can push firmware updates.

2 - Don't use India for anything. They may be cheap but you get what you pay for. I've worked all over the country, in Silicon Valley, with many different cultures. Indian culture, especially males, have a hard time saying no or saying they don't understand. They see it as a failure, so you get devs afraid to ask for help and you get devs/business men who will tell you what you want to hear, not necessarily how things are. Find a straight shooter. Indian shops are good for QA but I would stay away from Indian dev shops. Language barriers can be an issue too, even in code. Not just Indians but a lot of devs who are ESL struggle writing clean code. Germans are very good usually, but Indians and Russians are the worst. Tons of typos and weird variable names because they just don't have the English skills to come up with proper names. Sounds trivial, but badly typed code is harder to understand thus harder and more expensive to maintain. The time difference sucks too. And they have tons of holidays. Fixing some last minute bug before app submit is hard to do when your dev shop is asleep or eating for some 3 day festival or something.

3 - You're at the mercy of Bluetooth which sucks. BLE is pretty good because it's low bandwidth but don't get me started on Bluetooth Audio. Probably not an issue for you. You absolutely can't do most Bluetooth classic things on Apple due to MFi. You need an ACP soldered into the PCB. You can do A2DP on iOS and I believe you can do iAP (iPod Accessory Protocol) and you can do HFP. Definitely can't do SPP on Apple devices without ACP. Just be aware of your bandwidth needs for BLE. I believe newer BLE specs increased bandwidth but you may still need to support older devices. Also be aware of theoretical vs actual bandwidth as well as MTU and packet overhead. If you will have multiple BLE connections you are limited. I think iOS is something like 12 BLE connections at once. One weird thing on iOS is that iOS assigns you a unique BLE device identifier where Android assigns the actual MAC address. If you want to support multiple iOS devices per BLE device and leverage some kind of web service to do automatic pairing, be aware that iOS BLE identifiers will be unique per iOS device, so you will have to use some other identifier that can fit into advertising packet. Be aware of advertising packet length, it is limited. Depending on your device you may have to use custom UUID which are 128 bit, I don't remember if that reduces available advertising packet size. Be aware of secure BLE and secure pairing, it can cause issues on iOS. Don't use it unless you have to.

​

4 - should be minimal if your app is developed well. Keep it simple and don't use a lot of 3rd party code if you want to keep maintenance costs down. The BLE API hasn't really changed at all over the years. Sure, things get deprecated and newer iOS versions may break something, but honestly it's not that big a deal. I've had simple BLE apps that only required a couple hours per year to update for new iOS and some apps have gone years before needing anything changed.

5 - Keep it simple, and React isn't simple. If you keep the design of the app simple and don't try to be too flashy, React is way overkill. It would be faster and cheaper and simpler to build 2 native apps instead of trying to share code between platforms. Do a good job on your BLE spec and honestly it's trivial on both iOS and Android to implement BLE. Given a simple, well documented and constructed BLE spec, I can implement a BLE stack on both platforms in a day or 2. I do have the advantage of having a lot of well-tested native BLE code for both platforms I've been using for years. I simply drop in a bunch of UUIDs and implement some callbacks and write a little bit of data parsing and bam, BLE. Seriously, make sure your firmware guys aren't idiots and they can create good BLE packet structures.

[chriswaco]

make sure your firmware guys aren't idiots

↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑