React Native App Maintenance
hint: it’s a pain
If I met you about a year ago, I would have told: “I help non-technical founder design and build their first iOS app”.
From a business perspective, there is an issue with that statement. Most founders want to get both an iOS and an Android version of their app. For good and for bad reasons, but this is not the topic of this post.
So about 8 months ago I embarked on the adventure of learning React Native. I since worked on two React Native apps and a couple of native iOS apps. I now tell people: “I help non-technical founders design and build their first mobile app”.
Now that I have one React Native app in the store and another one on the way, I’m discovering an aspect of React Native I did not know about.
Maintaining a React Native app is harder than maintaining a native app.
Let me unpack this a little bit.
I have a maintenance contract with a company that had first hired me to create their React Native app. I’m lucky enough that I created the app so I know the code base well. Apart from a few: “What was I thinking?” and “Good thing it was my first app”, the code quality is good (if I can say so:-)). I installed Flow from day 1 and es-lint is keeping me honest. But even then because of a configuration issue, a lot of errors were not getting reported.
So why is it hard to maintain that app. Well, I started the maintenance part about 4 months after the original release of the app and in React Native time, this is a fairly long time. There had been two releases of React Native in that time, so I had to upgrade the react native dependencies and make sure to look at the changelog to make sure nothing would break.
Once I was done with that part, I updated all the other dependencies of the project. This specific project has about 30 dependencies and another 27 dev-dependencies (library and tools used during the development process).
So going through all those dependencies took some time just to make sure that on the surface nothing would break.
Then the painful part: actually building the app after the dependencie upgrade. And that is where the first time sink is. Resolving all the build issues (I had problems mostly on Android as I don’t have as much experience on that side) is a major pain.
And then finally, running the app and making sure nothing broke. This takes a full test pass on the app and is the second time sink. Which has to happen every time the app is updated.
So the real question is: “Is that any different than a native app?”. The answer is a resounding yes.
if you have an iOS app, for example, Apple releases a major, potentially breaking release once a year. And most of the time, it won’t break your app. You’ll just be told that the API you used is getting deprecated and you should move to the new one. Then you have about a year or two to figure it out.
On React Native this can happen every month.
Then comes the question of third-party dependencies. Those are on their own schedule too and can introduce bugs fairly easily.
In a native app, I find that projects tend to have fewer dependencies because the OS itself already provides a lot. So, on the native front, the dependency hell is somewhat more limited.
Now if you’re just looking at fixing bugs and not keeping React Native up to date, then the maintenance cost are probably identical. But you’re just accumulating technical debt that will have to be repaid later (unless you scrap the project).
All this is driving me to raise my prices when it comes to maintenance contracts for React Native app. It simply takes more time and I find it to be a lot harder.
Does this impact my view of whether React Native is a good choice for an MVP? As a matter of fact, it does a little bit. Most founders are attracted to React Native because of the promise of cheaper development cost and shorter cycles. While the initial development phase will be a bit cheaper, the maintenance cost is starting to offset this. While a lot of MVP will simply die and not need any maintenance, this is still a point to consider.
Also, one risk to not underestimate is how long you might leave your app without updating it and then want to implement a new feature. In the native world, there won’t be any delay when restarting the project, where with React Native you’ll have to factor in the “upgrade” price before you start implementing anything new. And it will only get higher the longer you leave that app untouched.
For example, back in July, I started taking over an app which had not been touched since January. So the transition cost to a new developer was very high for this project because of all the upgrade required (and also because of some bad coding in some part of the app).
Looking for some more interesting article on building iOS apps, head over to http://www.mobdesignapps.fr/blog for more.
Need help with building your app or feature, head over to http://www.mobdesignapps.fr/