[colesantiago]

I'm very curious if there were any reasons or design decisions on why Clubhouse didn't go for React Native from the start?

Would it be fair to say they could have gotten to market quicker had they went with RN?

Would love someone from the team to elaborate on this as Agora also has RN SDK's as well as Firebase.

[taylorhughes]

[I'm on the clubhouse team, but was not involved in this decision]

1) the CH iOS app itself has a long history of powering other prototypes / small communities before CH existed — so I think the early engineers were leveraging what they had already, vs starting out from zero. (I think this is why they were able to find fit with CH - ability to move fast and try different things.)

2) I built an app with RN at a previous company and it was a reasonable experience, but custom UI / transitions / etc was pretty much out the window. I don't think it's an obvious choice by any means to go with RN, especially for a media-heavy app. Also, expanding that particular RN app I had built to Android was no easy task — the UI mostly "just worked" when we built the Android container, but many of our third party libraries didn't work at all on Android, and managing app navigation was a huge hassle between the two platforms. We ended up shelving the android effort altogether and shut the whole project down a bit later. :)

[PragmaticPulp]

I inherited a React Native initiative at a previous job. It was fine for simple things like login screens and settings pages, but as soon as we had to do anything complex (like audio/video) we ended up writing native platform code anyway. Now instead of benefiting from React Native we were writing platform code anyway and paying the React Native tax to integrate it back into the app.

[smackeyacky]

Xamarin is/was very similar. Want to do bluetooth? Out of luck, native library time.

I haven't looked at React Native, but in Xamarin all the easy stuff (basic layouts, logins etc) were no easier than writing native Android code, and the hard stuff was a lot harder due to having to integrate the native code.

[pjmlp]

That is the hard truth of any cross platform toolkit.

Which is why I always advocate for mobile Web (plenty of CRUD apps are doable as such), native views + C++, native + server driven UI/business logic.

Mobile SDKs are already complex on their own, adding an additional development stack on top just makes everything worse, and when things go wrong one needs to be skillful enough to dig deep down anyway.

If those JNI bindings are a pain to write, having to debug the additional layers that React Native, Xamarin, Flutter, whatever put on top isn't much fun either.

[jamil7]

I think the founders were just familiar with iOS development so that's what they built it in. My perspective is that RN is a risk and a tradeoff like any other, there are quite a lot of pain points of RN which make it less attractive than it initially seems upfront. If your product is highly dependent on mobile it's better to go native for maximum flexibility, capability and to remove one extra party that you need to depend on. I also feel like mobile teams tend to naturally divide between platforms at a certain size and if you're already at that point you may as well use the native frameworks.

[kevmo314]

Having dealt with Agora's RN SDK, honestly looking back I think it would've been easier to just write two completely separate native apps.