After I went React (Native), I couldn’t go back — Part 2
Last week, I decided to start a series of articles comparing the developer experience between iOS and React Native. The first part was comparing the IDE/code editor, where VSCode clearly won against Xcode. This week, I chose to focus on an aspect that not only affects the developer’s experience, but also team members that are more business-oriented: the development cycle!
What do I mean by that? In short, the length of time and effort it takes to get from the start to the end of a feature implementation. When writing software, you need to iterate over and over again to improve and perfect your product. This is basically what developers spend their entire days doing. Naturally, how productive you can be using a particular framework should be an essential criterion in deciding which one to use.
Now that you have an idea of what the development cycle is and why it’s important, let’s get started with round 2!
Round 2: Development cycle
Native iOS
The process of writing iOS applications and features is slow, there is no debating that. Between the eternity it takes to compile a Swift application, the need to recompile after every single change in the code, the fact that most of Foundation is based on outdated APIs written almost 10 years ago in Objective-C, and the fact that iOS development was built first and foremost for Apple engineers, and not for third party application developers, all contribute to what I consider to be an unacceptable iteration length for the modern world we live in.
Apple claims that Swift is the future of iOS development. There is no denying that Swift is one of the most enjoyable languages to write code with nowadays. Compared to Objective C, it’s declarative and easier to read, safer thanks to Optionals, and avoids much of the boilerplate that used to be necessary. However, one of Swift’s nicest features, inferred typing (the option to avoid explicitly declaring types on variable, by letting the compiler infer them) increases compile times exponentially.
At Samsao, one of the legacy apps we work on often takes 5–10 minutes to compile. Let that sink in. Imagine how slow it is implementing new features and screens, or to debug existing ones. We’re not the only ones though, I’ve heard many stories of iOS apps that take their maintainers forever to compile. Combine this with the fact that there is no such thing as hot reloading on iOS (apart from an unstable/hacky third party plugin), leading to the need to recompile the application after every change you want to see reflected in your application, even changes as trivial as updating a string. Not only does this directly impact how productive an iOS developer can be, but it also frequently breaks a developer’s “flow”, leading to even slower development times.
I believe the primary reason behind the slow process of iOS development, is that fact that Apple really does not care much for third party developers, despite the fact that they make a lot of profit from their apps’ In App Purchases, subscriptions and downloads. The main reason Xcode and Foundation was developed was to allow Apple engineers to build iOS applications. Eventually, they released that software out of convenience, not out of generosity. The iOS development ecosystem makes a lot of assumptions on how developers build apps. They are expected to use iCloud and Cloud Kit, which is easy for Apple engineers, because Apple never worries about supporting an application on more than one platform. But most iOS developers work as part of teams that also have Android applications, maybe websites, that all need to share the same backend. This is why the most popular iOS libraries all revolve around networking and JSON parsing. Apple doesn’t need to do that, so why would they spend time and resources writing easier APIs to use for that purpose?
In addition to all of this, the IDE or code editor you work with can drastically affect the speed of your developement cycle. If it crashes while you’re in the middle of writing code, gives you errors when there really aren’t any, prevents you from using modern plugins to re-format your code and run your tests when saving your changes, there is no doubt that it will impact your development speed negatively. You can read all about my thoughts on Xcode in last week’s article.
React Native
In this aspect as well, React Native does things entirely differently, and for the better. Thanks to hot reloading, there is no need to recompile when developing, a simple CMD-S, and your changes are automatically reflected on your device, leaving you at the exact same screen you were on. This does wonders in terms of speeding up iterations. It used to take me an hours to create a simple but nicely designed UI in Swift, it now takes me a few minutes.
One of my favourite tools to use for this purpose is Snack, a React Native playground built by the Expo team. It makes it incredibly easy to build UI components outside of your app’s environment, while being able to see that UI update simultaneously on many different physical devices. Can you imagine how long it would take to achieve the same level of certainty about your UI in iOS? It would require you to recompile on multiple devices, every single time you change anything. Or you could wait until your UI is completed on one device, and then test it on other device sizes, taking the risk that it won’t look nearly as good as you were hoping it would.
With Snack, you can just do this:
How beautiful is that? I wouldn’t have even dreamed of this being possible while developing apps with Xcode and Swift. And the worst part of all this? There is no doubt that Apple has the resources to build these cutting-edge features, that would greatly simplify the lives of iOS developers. But the bottom line is: they don’t seem to care. This does not impact them in any way, so why would they spend time and money to help the iOS developer community?
One aspect of React Native that drastically helps simplify an app’s logic, is the fact that React is API-driven by design. As I mentioned above, in iOS development, parsing JSON and dealing with APIs is far from a boilerplate-free task. Not only that, but writing iOS code, after experiencing React Native feels very old. When trying to update a view’s data after an API call succeeds, you need to write code that feels far from modern:
func doApiCall() {
api.doCall() { (data) in
self.data = data
}
}There are ways around that, such as using RxSwift to bind your views to your data. The issue with that is that it will necessarily complicate your app’s logic, make it harder for new developers unfamiliar with Reactive Programming to onboard on your project, and add a quite substantial library to your dependencies.
With React, everything is made to simplify that process. With the concept of component State, your view is bound to your data by design, making it very easy to rerender entire screens or portions of the UI when new data arrives. If you’re unfamiliar with the concept of State, I highly suggest you check out Artsy’s intro to React Native for an iOS Developer.
As you can guess, React Native takes this one again. With features such as hot reloading, API-driven design, customizability of my code editor, I found that my productivity has greatly increased since I started writing apps in React Native. It used to take me one to two days to implement a simple login screen on iOS, it now takes me less than day to implement the mobile UI with React Native, the web UI in React, the business logic for both, and the backend routes in Node.js. Now that I’ve reached this level of productivity, I feel that I am going backwards whenever I need to touch iOS code.
That’s it for this article! I hope you enjoyed it, and please feel free to ask any questions, or comment on anything you agree/disagree with!
Next week, I will touch upon an important aspect in a developer’s experience: the community.
