August 05, 2020
Developing mobile apps can be quite confusing. Should you start with just one platform? iOS or Android? Can you develop for both simultaneously? Are you going to need two teams for that? Is it costly? Several questions come to mind.
We are going to give you some answers and help you learn something new about native apps and how they differ from hybrid and cross-platform frameworks.
We have the two most popular operating systems for mobile devices - iOS and Android. The former powers Apple devices and the latter is used in a wide variety of smartphones, smartwatches, microwaves, fridges and whatnot - from Samsung through LG to Xiaomi. It’s safe to say that if something isn’t an Apple device, then it most likely runs on Android.
The most significant distinction between these two systems is the programming language they are written in. iOS uses Swift and Objective C; Android uses Java and Kotlin.
Okay, so what does it mean for an application to be native?
An application can be called native when it’s written in a programming language specific to its platform. What does it mean in practice?
Let’s say we are developing our Instagram-like mobile application. Of course, we want our app to be widely popular and we want everyone to install it - so we have to create an app that’s downloadable from both Google Play (Android) and App Store (iOS).
Since the programming languages differ for both platforms, it means that we are going to need two different applications - one built for iOS and another one for Android.
As you can see, creating native mobile applications means programming them in the platform-specific language. Hence if you decide to go native, you will have two separate teams building your app.
The first one will consist of Java/Kotlin developers that will be working on your Android application, while the second one will have Swift developers working on the iOS app.
Sounds costly? It is. And, like everything, it has its upsides and downsides.
Native development is the most costly approach since you have to support two teams working on your app. However, is it also the most time-consuming?
Not necessarily. In reality, if you already have two teams set and ready to jump into development, it can be quite fast. Looking at a time-to-market perspective, it can sometimes be the quickest option.
Maintaining two independent code bases means that your iOS developers focus solely on iOS features and potential bugs and the same goes for the Android team. Additionally, numerous solutions to the most prevalent problems are widely available and in case one platform has a known bug, it will not affect the other.
Another thing to be wary of is that if you decide to heavily invest in the native look and feel, you should consider the design challenges that come with it. Official guidelines are different for Google and Apple. Both have different opinions about style and components like navigation.
Nevertheless, if you have an unlimited budget for your mobile application, then native development is probably the way to go.
However… What if you could save money by writing an app only once and publish it in both stores?
The distinction between hybrid apps and cross-platform frameworks can be confusing. And some people use these terms interchangeably.
For the sake of simplicity, let’s assume that a hybrid application means an app that is written and deployed exclusively with the use of web technologies. You can think about it as a website elevated to a mobile app. Don’t mistake these with Progressive Web Apps (PWA).
At Blazity, we are not fans of hybrid apps. However, cross-platform frameworks are a whole different thing and they allow programmers to create native-level mobile applications. The idea behind them is to have a single codebase, which is then transformed into two separate app bundles - for iOS and Android. And most importantly, they work exactly like native apps.
In the hybrid space, the most popular framework is Ionic.
Building a hybrid app involves using tools known from web development like HTML tags and CSS styles and then displaying it inside a WebView component. WebView is an embeddable browser that can render web content.
To simplify, using WebView is somewhat comparable to installing a web browser inside your mobile application and then displaying the content in it. So, you basically build a website and then display it inside a web browser, inside your mobile app. A rather indirect approach (once again, don’t mistake these with PWAs).
Cross-platform frameworks, on the other hand, are significantly different. The resulting apps can be almost indistinguishable from the natively written ones.
Of course, some purists say that the only proper way of mobile development is writing native code. Being overly dogmatic is rarely the right approach. The list of companies successfully using React Native speaks for itself.
The two most important frameworks, at the time of writing, are React Native (developed by Facebook) and Flutter (developed by Google).
React Native (not the same thing as React for web development!) is an established, battle-tested technology. Flutter is a new competitor in the mobile landscape and it’s steadily gaining popularity.
It was first announced to the broader public in January 2015 and it’s been continually growing since. Today it’s used by companies like Facebook (obviously), Netflix, Microsoft, Instagram, Uber Eats, Walmart, Bloomberg, Discord, Tesla and, until recently, Airbnb, amongst many others.
Microsoft likes RN so much that most of their Office 365 package has been rewritten to React Native.
Looking at this list, you can certainly see that it’s a widely used technology, incorporated by the biggest players in the industry. And for good reasons.
So, what’s happening when you use a React Native component in your code? This component is actually just a facade for a native component. For example, when you use a core component like
<View />, React Native informs the system that it should render the corresponding native element. Clever, right?
For starters, we believe that React Native is a brilliant piece of technology. It allows you to have a single team working together on an app that can be deployed and installed on both iOS and Android. At Blazity, we leverage that a lot. We can achieve great results with a relatively small team, because of the synergy we have.
Since React Native is indeed sharing its core concepts with React (the web framework), it’s quite easy for a web developer to understand the architecture and make a switch. So, even if someone is currently working on a web application, they can jump in and help with a mobile app written in React Native since all our developers have a deep understanding of both technologies. It feels natural, especially when both mobile and web apps are part of the same product.
And sometimes you can keep your teams really small. A prime example of that is Discord - a voice communication platform that’s popular in the gaming community. It’s used by over 130 million people worldwide, and their React Native iOS app is developed and maintained by a team of two people. Let that sink in.
Some developers argue that only fully native applications can be truly performant. We disagree. React Native is really fast and in the overwhelming majority of cases, it delivers a smooth 60 FPS experience and works with no visible distinction from a native app.
Besides, when needed, it is possible to incorporate native Java or Swift components into a React Native application. Thanks to that, we can fully leverage the features and capabilities of both iOS and Android.
Simply put, developing applications in React Native costs less. You need to maintain a single development team and a popular statistic says that you save around 30% of your budget when you decide to go with RN.
Of course, keep in mind that even though it’s true for most projects, it will not always be the case. For example, Airbnb, one of React Native pioneers, decided to drop it because they had so many custom elements that they ended up having three teams anyway (iOS, Android, RN).
React Native has a brilliant toolkit for prototyping. It’s called Expo and allows you to create applications exceptionally quickly and publish them with ease. It’s meaningful because releasing a mobile app deserves a blog post of its own.
If you are a frequent visitor on our blog, you have definitely heard about our love for open-source. React Native is an open-source, mature technology that has gathered a massive community. We are proud of being a part of it. Having access to the overwhelming support and knowledge-sharing between developers is priceless.
What’s important is that with the ever-changing online world and mobile systems getting constant updates, open-source is ensuring that RN stays ahead of the competition and evolves at a rapid pace.
React Native, like every other technology, has its pain points. It’s essential to understand them before you decide to invest and build your project with it.
As we mentioned before, there are two different style guidelines for the App Store and Google Play. So, if you need your app to 100% comply with native styles, you will need to do a lot of conditional rendering (e.g. rendering one type of navigation for iOS and another type for Android). We wouldn’t say that it’s that big of a deal, since having an entirely consistent design between the two stores can make your product distinguishable from other apps.
Secondly, since React Native uses native modules, you will, more often than not, still need Android/iOS expertise on the team to make specific problems easier to solve.
Discord describes it perfectly: In React Native world, a web developer will take much longer to succeed than a native developer. Most of the time, it has been smooth sailing working on React Native. However, you sometimes come across very specific native technical details or find yourself working on OS-specific features like the share extension on iOS. Web developers will likely take longer to learn and sometimes need help from engineers with a native experience. But once they learn and grow, they can share valuable information across front-end platforms and help keep our teams small and mighty.
And lastly, performance. Again, for the vast majority of use cases, it won’t be a problem. But if there’s very heavy CPU computing going on on the frontend side of your app, then sticking with React Native might not be the best solution. That’s a great example of why it’s imperative to always consult your specific project case before jumping into the development.
Flutter is a novelty in the mobile development landscape. Currently, it’s becoming the most popular cross-platform alternative to React Native. Google develops the framework and it is based on the Dart programming language.
Being a new player in the field, its community is still relatively small. However, we keep hearing that it can provide exceptional performance, so the support will definitely keep growing.
At Blazity, we always investigate up and coming technologies and even though we haven’t started any Flutter projects yet, we think that over time it will become a fully mature competition for React Native. Just like Angular is for React, in the web world.
No one can say that the only proper way of creating mobile apps is going with React Native or full native, using Flutter, or building a WebView with Ionic. As always, it depends on the project.
Do we recommend you try React Native for yours? Most likely yes! But it’s always a good idea to consult with a professional software development team (e.g. Blazity 😎) before starting your journey.
Subscribe for news
Share this article
Tell us more about the project you want to work on