I want to build an application that runs on the Web, iOS and Android.
I just followed a tutorial to build an iOS app using React Native. I have the app successfully running on my phone.
My initial understanding was "build once, deploy everywhere". I quickly realized that wouldn't be the case once I was editing an index.ios.js
file.
Additionally, it became clear to me that I could not just copy the source code from index.ios.js
into index.android.js
, because many of the imports and APIs were platform specific. However, I know other than that most of the codebase is platform ambiguous.
What is the appropriate approach to achieve my desired result?
index.ios.js
index.android.js
I've found that a well-designed project can reach a relatively high degree of code-sharing between both iOS and Android - in some instances 85-95% - it depends how complex the app is. The .ios
and .android
extensions simply exist because it's useful to be able to target each platform specifically - when creating modular components sometimes each OS yields a different challenge, so you have to rethink the architecture. An example is the <Picker>
component, which creates a UIPickerView
on iOS, but a modal Picker
and label on Android - both of which work slightly differently. But in general this isn't the case, at least in my experience.
As the index.js
file is the entry-point it therefore serves as the router for many apps, which means you want this to be the same across each platform - so you can actually have just one index.js
for all platforms. Sometimes it might be necessary to have platform-specific initialisations and global assignments which would make the separate approach useful.
Web-wise there currently isn't much cross-over (although hopefully this will change). React Native utilises the power of React, while running on top of the native components designed by the iOS and Android teams, and the differences between mobile and web are fairly broad. That having been said there are some components such as React Swipeable Views which work across web and native which is very promising. But for now the two are fairly separate - one sits on the DOM, the other on native SDKs, although both share pretty much everything else, meaning there's good transfer of skills across platforms.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With