I’m going to raise a discussion about a Status’ taboo subject – a choice between React-Native and native iOS/Android app development. It’s always been in the Top-3 list of discussed topics in private conversations with other devs, and too many people outside of status-react team (and some from inside) were unhappy with this choice.
To make sure everyone on the same page, it’s a classic choice for anyone willing to build a mobile app:
Write native mobile apps for iOS and Android with their native stacks (Swift/iOS and Java/Kotlin)
Both approaches have a number of cons and pros, in more than one dimension and it often boils down to the personal decision of a CTO. In the very early days of Status, @jarrad put bets on React-Native, but with more layer on top, which is Clojure-Script.
I guess it made perfect sense back then – initial product, development speed vs performance and maintainability, cross-platform support out of the box – all that was making React-Native a really promising candidate.
As the company grew more and more developers joined, the first problem of our React-Native stack become evident: it’s extremely hard to build, so let’s talk about it.
I wrote about this problem number of times before, but the building experience in status-react is the worst I have ever seen. In Bangkok 4 core members working on status-react daily were sitting at my laptop for 2 hours straight trying to achieve a simple goal – just build it. We succeeded only partially back then (iOS build never worked).
I have a litmus test for the processes inside the company – will you be proud to share this experience in the conference or meetup? I doubt anyone can be proud with build pipeline of status-react.
But it’s not just about complexity in the puritanic software engineering sense. It was a huge hindrance to:
- test out ideas. We often wanted to change something in status-go and test it on the real app – after months of fighting build system, I just dropped this idea completely.
- contribute to the status-react. Again, I had multiple ideas I wanted to implement, and extremely negative experience with the build was a stopper.
- create bounties for status-react during hackathon – due to incredibly buggy and complex build process, we just could not afford ask hackers on hackathon to build it and be able to assist them if something fails during the build.
- it virtually excluded iOS builds from being actively tested and considered as important – there were other reasons too, of course, but building for iOS has always been broken and nobody in the team for over the year could fix this.
It created an unexpectedly high entry barrier for developers, while the original goal of React-Native seems to be the opposite.
Now, this topic has been a second taboo among Status developers, probably because many Clojure developers have been hired and discussing it may piss them off.
The first problem with choosing Clojure Script is that it’s one more layer on top of an already complicated multi-layered stack of status-react. The current status-react stack consists of human- and code-generated code written in:
Each of those layers has its own building step in the pipeline, its own tooling, its own dependency management, and its own set of problems and bugs. Managing this mess is an extremely hard task, and I don’t remember anyone at Status who understands all those layers good enough to solve practical problems.
The second problem is that Clojure(and ClojureScript) is still a relatively exotic and unknown language, making it hard to find developers. Even more, it’s not the easiest language, making it another high entry barrier to the contributions even from within the core team.
The third problem is that most Clojure folks come from backend development field. It’s easy to understand that backend engineers aren’t usually good in UI/UX, design and nuances of mobile app development. I think it’s shaped quite some choices in status-react design, especially at the beginning.
Tabooing the subject
I raised those concerns in many private conversations and always felt that people are afraid of talking about it. So I went straight to @jarrad and asked him about it (it was around a year ago). The response was a rather harsh and cold message in public Slack channel, and later in private conversation, stating that:
- React-Native is absolutely the right choice, many cool companies build their apps with React-Native, proving it’s great and anyone who thinks otherwise should think twice
- Clojure is a great choice because it attracts smart people with the right mindset and a lot of experience in computer science.
I never pushed further these discussions in public, because it’s usually hard to make changes with such a response from the top. Plus, hiring people for the specific stack is almost automatically shifts the balance of opinions and discussing the technology may be seen as a threat for the job position for some people. I think those two factors contributed most to the tabooing the subject.
But let me respond to both of those claims.
React-Native success stories
The apps were mentioned as React-Native success stories include Airbnb, Facebook (obviously), Instagram, Uber and others. While clearly suffering from the survivorship bias, when you look closer, you might see that the picture is not that bright.
Instagram app is native as well, but they integrated React-Native code into various parts of the app like “Push Notification Settings” or “List of saved items” screens.
Facebook is a clear outsider here because the app is awful and they are creators of React-Native, which means they have enormous resources just to work on React-Native itself.
Airbnb app is beautiful, and it could be a good success story, but this summer they shared a series of blog posts describing their experience with React-Native and saying that they’re moving back to native mobile app development.
Clojure as a language of extremely skilled CS people
I don’t have anything against Clojure per-se, but I’ve been programming since the age of 6, and I just can’t buy this argument. Clojure is definitely a modern language with its aura of coolness around, but it doesn’t automatically make people smart or experienced or right.
From my experience, people often choose Clojure not because it reflects their decades-long aspirations about best programming approaches, but because of coolness and social perception of this choice. PHP is not cool, Clojure is, that’s it. This bias is actually known, and here is an article that comes to mind: https://daiyi.co/blog/2016/11/30/Signaling-in-tech-is-some-fucked-up-shit/ A quote of the author, who switched from being a web developer to a Clojure developer:
People started telling me I was really cool. I noticed people making all these wildly positive assumptions about my programming ability despite not having read a single line of code I’ve written ever. I instantly get elevated to a respect-worthy status for free and maybe for people who are used to being treated well that’s not a big deal, but coming from being treated like trash after telling people I am a web person the contrast was super intense and really obvious.
So the argument “Clojure attracts really skilled people”, no matter how true it is, simply can’t be used in reverse (“If someone have chosen Clojure, they’re automatically skilled”).
I always liked working on UI apps and been writing apps in Qt, Delphi, QML, QuickScript, PyQT, TCL, Objective-C/Swift and I’m always happy to learn some new technology to work on, but the Status choice of technological stack literally excluded me from being able to contribute to the UI part (and not only UI, unfortunately) of the app for more than a year.
Now I’m practising with Swift 4, and it’s hard to even compare those experiences – you have just one stack – Swift lang and compiler, and the tooling is perfectly suited for this stack. I bet the similar experience with Android native app development.
Status hired and fired tons of people recently, and I think it’s worth rethinking if React-Native is a truly great choice if it excludes people from contribution, excludes codebase from being a good choice on hackathons and uses a bloated multi-layered stack of technologies.
As a final note, Status Desktop comes to mind, but having heard about the pain developers deal with and the need to write own half-finished bindings by Canonical raises more than an eyebrow in question if the native desktop app development with QT wouldn’t be much faster and productive.
I’m going to work in my spare time on the native Swift Status UI, meanwhile, and I don’t really care anymore if top management of Status is agreeing. I’ve heard many developers begging for switching to native app development.
Hopefully this post will start some productive discussion.