Hacker News Reader

Comment by pedalpete | Hacker News Reader

So a bit different from the other comments. We're a wearable company which of course pairs with an app.

We built iOS first because that's what most of our users have, though the team is mostly on Android.

We built our logic in Rust, so that compiles cross platform. It's really just the UI layer that is per platform.

Though I had initially written our first demo in React-Native, the team wanted to go with native UI.

Lately we've been talking about moving the timeline for our Android app up because we can get AI to help using the iOS app as a foundation.

I haven't seen anything really new and compelling in iOS/Android land. The promise of right once run anywhere continues to be a promise, and the bluetooth libraries across different devices (particularly in Android land) has me concerned.

View on HN

> and the bluetooth libraries across different devices (particularly in Android land) has me concerned.

I work on the Android side for a company that develops an external bluetooth device (not a wearable, but similar enough) and the bluetooth library situation has certainly been an issue to be concerned about.

Using the default Android bluetooth SDK "raw" is fraught with potential problems, at the very least you need some sort of added message-queue-like system built on top since it does none of this for you. You also have to contend with a lot of strange device specific issues (of the type "works fine on 99% of Android devices, this one Samsung device has a driver quirk we need to work around", etc).

Things looked pretty good with the Jetpack androidx.bluetooth library as a higher level abstraction, but Google suddenly deprecated it and stopped working on it before it left alpha.

After lots of investigations and iterations I ended up using Nordic Semiconductor's 2.0 Kotlin BLE Library, which is technically also still in alpha release, but is much more stable than that designation suggests.

https://github.com/nordicsemi/Kotlin-BLE-Library

After having messed with all of the options, I highly recommend Nordic's library as a solid basis for using Bluetooth in modern Android/Kotlin, but in your specific situation I'm not sure if bridging it to Rust would be less or more painful than having an LLM generate a Rust wrapper and message queue system over the raw android.bluetooth library.

Thanks for the info. We're using https://buttplug.io/ currently.

After reviewing a bunch of packages, one of our devs decided this was probably the best available. I'll mention the new Nordic, as we are based on nrf chips.

> the bluetooth libraries across different devices (particularly in Android land) has me concerned

At Google IO 2026 there little discussion of core improvements to Android as a platform. It was mostly AI related, nothing about Gabeldorsche etc, which I find more interesting.

why was your team against react native? (for mobile app right that goes along with the wearable right?)

you can ship the actual UI stuff in seconds.

you can write your own plugins for anything native and just call it. we have a app that uses many native SDK calls which we write plugins for and call.

not to mention that once the native work is done you can deploy ui level changes and new features, bug fixes to users over OTA.

i’m just an outsider so i know my lane. but

whatever you do, do not allow bike shedding and ultra opinionated tech nerds to derail company vision timelines.

I've used react native a bunch. When you've got custom elements it isn't always the cross-platform write once you think it is. I've always had custom components across iOS and Android.

The big complaint is that the amount of work to get the level of polish needed in premium apps just isn't there. Or you need to do a bunch more work and it isn't significantly different than the amount of work of getting a native iOS and native android dev.

> We built our logic in Rust, so that compiles cross platform. It's really just the UI layer that is per platform.

Having never created a mobile app, how's that work exactly?

We define our API into the Rust via protobufs[0] and some codegen.

The wrapper around these is very lean, FFI-based[1], it's abstracted to a library so Android devs never need to know there's rust/codegen involved.

We then define a light Kotlin-based wrapper around the protobuf-generated API[2]. This is a candidate to move to Kotlin multiplatform in the near future (mostly for test speed improvements).

[0] https://github.com/ankitects/anki/tree/main/proto

[1] https://github.com/ankidroid/Anki-Android-Backend/blob/a0428...

[2] https://github.com/ankidroid/Anki-Android/blob/68192585a7ae4...

FFI. For example in Flutter, there are packages like flutter_rust_bridge that allow you to write Rust that then interacts with the host OS.

Check out tauri.

Tauri is not even remotely an appropriate answer to this question.

Reply on news.ycombinator.com