By I’ve had an increasing number of conversations over the past few weeks about both React Native and Firebase — mostly with non-technical founders who have been advised by those they trust that, before they embark on their app development, they should choose one (or both) of these technologies at the core of their stack.
I want to very briefly give my take on both of these, as a developer who has used both, and advised both for and against both.
First, let me begin by saying that my opinions here are based on 20 years of experience in software development, but more specifically, on my 12 years experience as a contract/freelance mobile developer and not ONLY on these specific technologies. I bring a somewhat rare perspective to the table in that I have been developing for these platforms for so long that I’ve seen multiple cross-platform frameworks and backend frameworks and BaaS platforms come and go. I still bear the scars from a few of them! That also means I bring a bit of bias into the discussion that may or may not be fair to the technologies mentioned here.
My opinions are really based more on the types of technologies we can safely use and trust, why we use them, when we use them, what the compromises we have to make are, what the upsides are, and so on, rather than any specific, personal opinion about the specific tools themselves.
So lets take these one by one:
Firebase
Let’s start with the backend. And let’s start by saying Firebase is perfectly fine as a backend platform for your app. I have used it in the past, and I’ve even used it in conjunction with Parse (more on that later). It’s a neat system, works great, and it’s backed by Google.
However, I tend to recommend either open source Parse or a custom built Node.js/Express/MongoDB based backend if at all possible.
The biggest reason is a lesson I learned by going all in on Parse in the early days of that platform. This is going to sound strange, as I currently enthusiastically recommend Parse, but Parse caused me one of the biggest nightmares of my career at one point!
Parse used to be owned and managed by Facebook. Like Firebase, it was backed by a big company, came with a generous free tier, and worked amazing. I built about a dozen apps on top of Parse before tragedy struck: Facebook abandoned Parse suddenly.
In short, Facebook decided they didn’t want to host Parse apps anymore or pay for its continued development, so they open sourced it. Parse developers were given plenty of time to migrate. But the migration meant that suddenly a lot of management that was handled by Hosted Parse was now managed by me! That not only meant a lot of extra work, but a lot of extra knowledge, as I had to quickly get up to expert level on several AWS technologies and MongoDB in order to take control of my data.
When it was all over, Parse became better than before. And the biggest upside is that we now fully, 100% control our data, and the SDKs and backend framework that run our apps is 100% open source and modifiable by us.
It wasn’t until it all hit the fan that I realized how important it was for me to be in total control of the platform, the data, and essentially the destiny of the app.
So, should you not use Firebase? Not necessarily. As I said, its a fine system, it does what it does really well, and now that the Firebase brand has been expanded to include much of what used to be Fabric, I use several Firebase offerings still in everything I build today — even the Parse based projects. There is a lot to take from Firebase — I just don’t recommend it as a database at the current moment for most projects.
React Native
Now on to the big one that comes up all the time. Should you build your app with React Native?
First, let me give a bit of history.
In the early days of iOS development, things were relatively insane compared to today. Apple launched an SDK which got just about everyone excited to start developing for the platform, but they insisted that we all use XCode, build our apps in Objective-C, and learn the Cocoa API for building our UI.
These were strange decisions at the time, because up until the release of the iOS SDK, there were very few Apple developers compared to Windows developers, web developers or even linux/unix developers. The Cocoa API was a little strange too, and a lot of it felt unintuitive to developers who may have come from a Windows UI background.
But most interesting was the insistence on developing in Objective-C — a relatively obscure language that was a carryover from a bygone era. Don’t get me wrong — Objective-C is a great language with a lot to recommend. Its just that no one I knew had ever built anything with it. C++ was the dominant object oriented C based language, and there were a massive amount of C and C++ programmers out in the wild. So iOS came with a significant learning curve.
Also in the beginning, there was no concept of memory management or garbage collection in iOS development. If you had an iPhone back in the late 2010s you may remember apps crashing constantly — and this is why.
This was at a time when almost every modern language came with some sort of memory management and memory cleanup system. C and C++ were still the wild west, but C#, Java and others were much easier to deal with because you didn’t have to keep track of every bit of memory you allocated or else suffer horrendous crashes and late nights squashing bugs.
Android, in comparison to iOS, had a Java based SDK. There were a lot more Java developers in the world, and Java development came with a lot of luxuries like better memory management.
But these problems aside, you needed to typically find two developers to build your mobile apps, AND a web developer to handle your backend!
This was not only potentially 3 times as expensive, it was 3 times as hard to find the right talent! I can tell you from experience it’s hard to find a good developer — finding three is damn near impossible! So naturally when people started putting these new cross-platform frameworks together, they made some logical choices:
- Choose a language and coding style that includes the largest number of available developers — then, as now, that means javascript — there are just many, many more javascript developers out there than Java of Kotlin developers, and definitely more than Objective-C or Swift
- Abstract the underlying SDK by building a new SDK on top of it, that can be compiled down to native code
- Maximize the amount of common code between every platform by focusing on the commonalities between the platforms and build the framework around those commonalities.
Those last two bits are where these cross platform technologies lose me.
First, I have been involved in far too many projects to feel confident being abstracted away to any degree from the underlying hardware and operating system. Just about every project that continues to evolve past a certain point will start to require custom UI and much more creative and aggressive use of the underlying hardware and OS. In my experience, the more a product comes into it’s own, the more it becomes tightly bound to the underlying system. As the platform becomes more mature and new features are added, so too will you likely want to take advantage of those features — even as your product is maturing and adding features specific to your app.
I can regale you with examples of borderline insane ways I’ve had to bend the iOS SDK to my will in order to bring a new feature online. But suffice to say, in very very many of those cases I was only able to do so because I was working so close to the metal. If a javascript framework was in my way, I would have simply had to tell the client sorry, but we can’t do this without starting over and building native. And you never, ever want to start over if you can avoid it!
Second, by focusing on the commonalities between the platforms, you risk building bland technology. I can confidently say that over the years, I’ve learned to appreciate exactly how different iOS and Android actually are when you get down to things that really matter to the user. The difference in UI/UX and user interaction in general is just, or at least can be just far too huge for me to feel comfortable reusing too much code on both platforms.
Granted, React Native really isn’t a “build once deploy everywhere” framework — especially when it comes to UI. But I stand by my point. These are different platforms, with different expectations from users. And if you really care about your product — if the apps are really the core of your business — then I don’t think its a good idea to take short cuts.
So, should you never use React Native? Not at all! I think React and other cross platform technologies are and can be great for certain projects. I tend to be ok with going this route for intra-organizational apps, utility apps, prototypes intended to be rebuilt after funding and the like.
But for public facing apps intended for use by the general public, I still strongly recommend building native and taking advantage of everything the native SDKs offer.
Another caveat is that Apple has from time to time unilaterally decided to drop support or flat out deny apps that use some technology they don’t like. So keep in mind that if you aren’t doing things the way Apple officially wants you to, its possible they will end your run if you build your technology on a platform that suddenly rubs them wrong. It has happened before, and I don’t currently see any reason it couldn’t happen again. In fact, there seems to be something happening that may threaten the future of cross-platform frameworks, at least on iOS — but I can’t yet confirm that it is happening as of yet. That will have to be another post on another day.
As always, I’m happy to discuss these point in more detail, so contact me if you have any questions!
Last modified: February 28, 2020
No comments yet.