As a solo Nostr developer, it’s becoming hard for me to justify continuing to develop Comingle using native frameworks. I’m normally a proponent for native frameworks for the look and feel, but that can arguably scale well only with a team of developers, which I don’t have. I shipped the iOS app (backed by Nostr SDK for Apple Platforms) a couple months ago, but it’s very difficult for me to spend time to write a duplicate version in Android and Web, especially with the limited amount of time I have as is. Olas by nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft makes a compelling case for using React Native / NDK Mobile to ship fast — it’s slick and performs reasonably well in the brief time I’ve spent with it. I’m going to play around with NDK Mobile to see how far I can get with it.
Discussion
Hey nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0dv4ph5 what are the advantages of going for react native? Aren't web apps equally equipped to perform as apps nowadays? 🤔
React Native components communicate directly with the native platform, which give it a closer look and feel on a mobile device than a PWA (or any kind of web app) ever will.
Yes. This. I tried everything I found that didn’t require reinventing NDK. React native gets really close to the metal; you can always go down to implement what you need in C++, the new architecture stuff makes a significant difference because now you can write native code and not pay an overhead payload penality with serialization/deserialization when you write to the UI.
It’s really annoying and far slower than web development though
Maybe use React Native (Expo?) initially and only go native after you get funding?
nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft Why React Native over other tools like Kotlin Multiplatform Mobile or Flutter? I’ve heard that some people hate React Native, though I suppose that would be true of any tool.
There’s nothing wrong with Kotlin Multiplatform or Flutter. I’ve used the former a bit, haven’t used the latter. Each have their own tradeoffs. I personally love Kotlin.
One main selling point for React Native is that there’s NDK support, which has arguably the largest developer community supporting and using it on multiple platforms. It’s been battle tested.
There is a Kotlin Nostr library - Quartz by nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z (lives inside the Amethyst repo), though I haven’t used it personally and I’m not sure if it supports Kotlin Multiplatform or not.
Not yet. But I want to restructure it to a KMP lib
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z that would be really cool; seems like it would encourage more KMP/KMM development.
Ah, yes, good NDK support seems like an excellent reason to choose it over others. I wonder how challenging it might be to take Quartz — maybe in a fork of Amethyst — and wrap it up in a KMP package/framework so it could be used from a KMM app. Not that I really know anything about that — just thinking out loud.
I don't think it makes any sense for single-dev teams to develop multiplatform Nostr Clients.
The Client needs to be EXTREMELY simple/small to allow the dev to spend time integrating and testing in all OSs.
Maintaining multiplatform apps (either native or via NDK) takes time because both OSs and their libraries will update separately, with stuff that will break your app all the time and you will keep running after those fixes. It's a massive time sink.
Most multiplatform apps end up becoming too shallow to be useful because the dev is spending too much time trying to make things work everywhere.
you is not wrong friend
You’re not wrong. Depends on how much time the developer wants to spend to make it work, what their tolerance is for quality and testing thoroughly, etc. If using a multiplatform framework can get it 70% of the way there, some may be motivated to put in that extra 30% (I’m making numbers up). I don’t want it to be a single-dev effort forever, though. I do eventually want more developers working on it.
Well it depends how much is there to "make things work". 70% of a kind 1 feed is a day-long project. 70% of multiplatform picture-in-picture background video playback controlled by AppleTV/Chromecast at the same time as the AppleWatch and GalaxyWatch with in-device controls to like, zap and report is a multi-month clusterfuck of work.
The key is the size of the app. To me Olas is already too big to be maintainable by a single dev in two platforms.
That’s fair. Alternatives could be to:
1. Continue building native for one platform and focus on speed and quality. Make the product desirable enough that there will be demand for other platforms, and desire from other developers to contribute to (or hire developers to build on) those other platforms.
2. Same as 1 but use a multiplatform framework, which reduces the amount of code that needs to be rewritten.
On 2, the true question is: can you make that product desirable enough faster than on 1? It's all about user adoption.
