What I Learned While Building my Noisli Clone Musicly in React Native and Expo
Initially, when I heard the news that Facebook released a cross platform framework, as most of us know, I also presumed that it was yet another Hybrid framework. I ignored the news altogether even when it said that it’s equivalent to a Native app since that’s the way most of the Hybrid frameworks promote themselves. But after a few days I looked into their official docs, and I saw that they really had a Native app working behind the scenes by having Javascript as the interfacing language. This triggered me to keep it on my bucket list.
Last weekend, I finally got that precious time and decided that instead of simply walking through the docs and trying out the already given sample, I’d actually build something to try it out.
Recently, I’ve been using the Noisli chrome extension frequently to concentrate/focus while working and I’ve seen a constant productivity increase from filtering out the external noise. It’s also useful while meditating and while driving (I have tried listening to it in the car. It was fabulous. It gave me a serene/ambient/divine feelling).
So, I decided that I’d built my own version of ‘Noisli’ in React Native. I call it ‘Musicly.’
Before talking about my experience with it, lets describe RN a bit for those new comers ;)
Enter React Native
React Native is a cross platform framework (I won’t call it a hybrid framework, since I give this name to those frameworks that loads UI into webviews) for building apps on iOS and Android, and it inherits principles and syntax from ReactJS.
Pros of React Native:
Multiple Platforms
It covers the major platforms (iOS & Android) which is sufficient for most businesses. Most of the code can also be reused across the platforms.
Faster Development
This is the selling point of React Native. It provides a handful of ready made components that can be plugged and played, which eases the development process. For RAD, it is a BOON.
Hot Reloading
Developers don’t have to reload for changes to reflect, thus less build time and faster development. Think about making small UI changes by maintaining the app states. Its definitely BLISS.
Uses Javascript language
Javascript has been the most preferred front-end language FOR YEARS.
Native controls/components
Since it doesn’t use HTML/CSS to generate components, instead only creating a bridge to connect with native components, the USER EXPERIENCE is almost equal to a native app. Thus the next pro below.
Small team or Less labor cost:
Javascript is used across platforms, but still might need help from a native team, which can be very minor, usually for custom UI components and creating other unavailable modules.
Cons of React Native:
Still depending on Native developers
Since javascript is only the interfacing language, its still very dependent on native code, and thus on developers with skill sets of ObjectiveC/Swift for iOS & Java/Kotlin for Android.
Novelty
Since RN is new, it’s still maturing and the open source community is still developing, and there aren’t many open-source components/modules when compared to native.
Delayed SDK Updates
Since React Native API’s needs to be updated each time the iOS or Android SDK gets an update, it takes a little bit more time for them to be upgraded, and not all the API’s gets updated at once.
Facebook Rules
You’re still under the control of Facebook’s license (BDD).
High-Level/Major difference between React JS & React Native: (For web devs)
- React JS uses virtual Dom to render UI components in browsers/webviews, whereas React Native uses native API’s as a bridge to render components on mobile. For example: It uses UIKit components/API’s for iOS through Objective-C or Swift and for Android, it uses the equivalent UI components via Java.
- React Native uses <Text>, <View> whereas React JS uses <p>, <div>
Enter Me — My Experience with React Native
Jumping back to my experience with React Native.
There are 3 ways to build RN apps:
1.) CRNA (Short for create-react-native-app) or Expo based app
2.) Expo ejected app
3.) React Native (‘react-native’ way)
1.) ‘CRNA (Short for create-react-native-app)’ or the ‘Expo based app’ method
Expo is a framework/tool that acts as an interface for React Native & that simplifies the development process. It basically provides an XDE from which you can literally control the packager and run your app on a Simulator/Emulator. And most of all, the Getting Started guide on the home page of RN suggests using Expo, hence its kinda becoming official as well.
So, I started off with the default suggested way.
Pros of Expo:
Provides an XDE to control the packager and launch the simulator/emulator.
Provides an Expo Client app for iOS & Android, which can be used to run your app on a real device.
Faster development. You just have to start the packager and you see your app live on the simulator and a device at the same time, across platforms.
Works well for most of the apps that just displays data from the service.
All the pros of RN.
Cons of Expo:
Most 3rd party components/modules cannot be used.
No easy support to debug your app on device as an independent app.
Not all device specific capabilities can be tested.
In my case, I wanted to have an Audio module, which is not yet provided by RN, but there are 3rd party modules available from the open source community. But since I can’t integrate external libraries into Expo based project, that option was ruled out. Therefore I looked into the Expo API’s and fortunately, expo provides it. I integrated it into my app, after some struggle, but the main feature of the app is to play audio in background mode, which is not yet supported by the Expo module.
Lessons learned from ‘Expo based app’ method
Developing an app with native device capability enabled is tough. After a while I was feeling like I was wasting a lot of time just checking the possibilities of integrating the external modules/components into my Expo based app.
So, I jumped onto the next option/method.
2.) ‘Expo ejected app’ method
There is a process called ‘Eject’, which is like taking your app out of the Expo XDE configuration. It will still use something called ExpoKit to continue supporting Expo modules (hence the Audio API’s I used will still work).
I ejected my app from Expo, after which it uses ExpoKit for when my Audio API’s are called/triggered.
Pros of Expo Ejected app:
Integrate 3rd party components/modules.
You can continue to use Expo APIs.
You can still run your app on the Expo client app.
All the pros of RN
Cons of Expo Ejected app:
No easy support to debug your app on device as an independent app.
Not all device specific capabilities can be tested.
Lessons learned from Expo ejected app method
But, I was again limited to test my app as an independent one on the device.
Hence, the Expo Ejected app method will not work perfectly for all apps with native capabilities, as it can make testing difficult.
So I tried out the last method, which was previously the recommended method from the RN team, but for some reason they moved on to Expo using CRNA (short for Create React Native App). This can be a bit confusing. I recommend this for an explanation.
3.) ‘React Native (‘react-native’ way)’ method
Finally, I was ready to try out the last method.
Now that Expo was out of my way, I got the freedom to use the vast options provided by the open source community. Despite it being immature, there are quite a good number of options available.
Since Expo is not available via this method I couldn’t use any of the ExpoKit APIs, so I made the decision to change my Audio module to ‘react-native-sound’, which has more features than Expo. And since I had my code neatly written in a separate component, it was easier for me simply remove the Expo APIs and integrate the ‘react-native-sound’ APIs.
When I installed the app on the device and closed the app to the background, I heard it playing in the background. I let out a sigh of relief.
Pros of React Native app:
Integrate 3rd party components/modules.
All pros of RN.
Cons of React Native app:
Can’t use Expo Client app. I miss it. :(
I needed both Xcode and Android Studio to run the separate/native project to install and debug on my device.
Then I tweaked the app a little bit to match my UI taste. Here’s the final app:
Here is the open-source code, each in their respective branches in the same repo:
CRNA (create-react-native-app) or Expo based app
Expo Ejected app
React Native (‘react-native’)
Conclusion
The Expo team has done a fabulous job, no doubt about it. And they’re still adding more capabilities, which is fantastic.
Expo will still work for the majority of apps, specifically for Rapid Application Development iterations. It is not quite ready for the main stream in my opinion, and needs rapid enhancements for all of the major players to start using it.
I found the third method the easiest one, since I was not restricted by anything. It really comes down to the developers attitude, and I do prefer to work in a more boundary-less, flexible environment. When I get the flexibility to add or modify anything I wish, it just feels good. And most of all, the project is very close to native projects, which puts power in the developer’s hands, and which made this the best option for my Musicly app.
That’s all I had to say. If you’ve found this useful, then please don’t hesitate to clap, so that it reaches others who might find it useful.
Expo fans, please thrash me in the comments!
