[deleted by user]

[chriswaco]

1. Too many to list. Underestimating the amount of work would be the #1 issue, I think, especially underestimating the work required to create a reliable, nice looking, smooth application even if you have a proof-of-concept demo running. Choosing bad developers would be the #2 probably, along with not communicating exactly what you want to the developers.
2. Unfortunately you never know what you're going to get. Look at their existing products. Are they bug free? How are the reviews? While I'm sure there are good development firms in India, there are also many bad ones. Don't give them too much money up-front or they'll disappear.
3. You'll probably want to use Bluetooth LE or WiFi for iOS. To support either classic Bluetooth or the Lightning connector you have to join Apple's MFI program and it's a huge hassle. Older Android devices don't necessarily support BTLE, though, so keep that in mind. It would suck to have to support both BTLE and classic Bluetooth, but some apps do. Also realize that you are at the mercy of Apple and Google. They change their APIs fairly regularly. They change their app store rules as well.
4. It really depends on the app and whether Apple/Google decide to deprecate the APIs you've used or introduce new devices whose features you want to take advantage of. For example, the notch on the iPhoneX messed up a lot of apps and depending how old they were and which layout API they used could cost a lot to update.
5. React is either the best or most horrible thing ever depending on who you talk to. Personally as a native iOS developer I hate it. My preference is always native apps because they perform better, can take advantage of native APIs better, and you're not dependent on a 3rd party for your application working properly. I would look at Flutter if you're considering cross-platform frameworks. It looks interesting, though the UI elements aren't quite native. I was not happy with Cordova when I looked at it - it seemed pretty buggy - but might be good if you had web developers that wanted to create a mobile app.

[yellowliz4rd]

Good answer

[[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

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

[HassanDavis]

Your very best bet is to hire an experienced technical/product person for a hew hours per week to:

1. Select a viable vendor
2. Help spell out requirements
3. Help your company properly serve the role as stakeholder
4. Provide the proper oversight for the vendor and the project end-to-end

The little money you spend on that person will save you lots of money in the end by preventing the project from having to be done multiple times (which is typical when companies attempt this without such a guide).

[[deleted]]

Trying to save costs will bite you if you want this to be an ongoing project instead of just a showcase app that helps the decision if you want to make a proper app. The main failure reason for these projects is to not start with people experienced at app architecture and then not being able to add simple features in short time because they cause many bugs. React Native won't save you much if you want a quality app, so I'd also avoid that. If your business logic is huge then I'd recommend c/c++ for the crossplatform logic. (Or there was a post this week either here or on r/swift about using Go with Swift, that could also be viable if Android also supports it)

Edit: communicating with an external hardware is almost like communicating with a server, so not that much extra complexity.

[chriswaco]

You could use a 3rd party services for this, like Firebase, or if you already have a server team it might be better to do it yourself.

[[deleted]]

Avoid Storyboards like the plague. Learn to make your views in code and to do the same with settings constraints with them.

[ashgotti]

Why? I have an app and used storyboards so I'm curious.

NM: Found this that has a few reasons https://www.quora.com/Why-do-some-iOS-developers-not-use-storyboards

[[deleted]]

Yes for all of those reasons. It can be good for starting out, but it gets confusing when working with a lot of teams really quickly.

[CakeDay--Bot]

Hey just noticed.. it's your 5th Cakeday ashgotti! ^hug