The iPhone 3G was introduced in The Netherlands on the 8th of June 2008. If there’s one thing I loved was the way that he platform dictated how to build an app for it. It was clear. It was solid. Then I got hooked on Cordova. And that was fine too. When I look at frameworks like React Native I see what developers like about it. But I also dislike one thing: Regeneration The iOS and Android folder just is a pain in the *ss….

Cross-Platform development

Developing a cross-platform app has a big advantage that you can develop your business logic and — if the platform allows you to — some interaction logic and screen set up once, and roll it out on both iOS and Android. (Wuh, did you say Windows?.. that’s long gone, sorry…).

Before frameworks like React Native and Xamarin really got some crowd going with them, there were hybrid alternatives going around like Apache Cordova / Phonegap. I hooked up with them around 2011 as well and I loved it.

I ♥️ Cordova Hybrid

Cordova was sweet because it allowed web developers to use HTML, CSS, and JS to implement a mobile application and roll it out on iOS and Android.

Coding out business logic and creating some nice views in JS and with web syntax was all that was needed to get apps going for you.

Web Tech Is Volatile

But what I started to notice after 6 months in, is that web technology was going faster than the mobile space. Frameworks and libraries came and went. While mobile plugins and features wear quite steady.

It took its toll on aspects like project compatibility and deprecation of features from certain libraries because of inconsistencies between Cordova, the web stack, and native features.

Regenerating Platform Builds in Cordova Was Easy

One of the biggest plusses of the approach that Cordova took was the fact that the web layer part of the hybrid project was leading. Meaning: building screens & interaction and the business logic of the mobile app were separated from the iOS and Android project compilations. And If you were to decide that you’d like to regenerate one of the platform’s builds, it was as easy as running the following commands:

$ cordova platform rm android

$ cordova platform add android

This was enough to remove the Android platform related build and add it over again, but now with the latest project structure and conform to the current leading standards.

So What’s Up With React Native?

Well. I love the platform too. It is quick, mean and lean. And it helps that you can build an app component-based. No doubt about it.

But the advantage that Cordova (or the derivative frameworks like Ionic Framework) had, was that they took the cross-platform web-based layer as the “truth” and the platform-specific implementation could always be regenerated from that layer.

React Native had something similar when the React-Native Reject command was still valid: it helped to regenerate any missing platform project structure and (re)built it by using the current platform’s standards.

If your Android project was messed up, you only had to:

delete it

run $react-native eject

and the Android project was regenerated with the current standards.

Easy and sweet, right?

The Easy Days Are Gone

Previously, the command “$ create-react-native-app MyApp” was used to generate a new app, and running a “$react-native eject” would regenerate the platform-specific builds.

But since “$ create-react-native-app MyApp” was deprecated (check out this PR), there was no need for the eject command as well.

If you created a React Native application, and you platform-specific builds is screwed over one way or the other, you only have the following steps to take you back to safety:

create a new react-native project using “$react-native init MyProject” remove the iOS and/or Android from the original project directory copy the new iOS and/or Android directory from the newly init-ed project from step 1 rebuild your project

You can see, that with projects based on hybrid platforms like Cordova, the commonly shared layer was leading. Whereas with React-Native, this isn’t the case and you would need to create a (temporary) new project and copy stuff over to your current project just to get platform-specific builds going for you again.

Conclusion

I’ve been working with React-Native for some time on a project lately, and I see the charms that it brings along. The component-based setup, the large community, and slick interfacing possibilities all speak for it.

But when you’re working on a project that was out for one year, and you need to upgrade it to meet the current standards, It’s kinda lime that you need to update each and every element like the builder (yarn, in my case), the plugins, the node-modules and react-native all at once.

It would have been a great help if I wouldn’t have to fight against getting the platform-specific projects runnable again and could focus on getting the cross-platform layer going for me.

I got it done once again, but it took me about 4 working days to get the project structure up and running again.

Just one more lesson to why platform independency makes a developer’s life way easier.

Code Hard, Ship Harder ✌🏻

This post was originally published on EEKAY.NL