A History Lesson:
It's 2007 Apple a publicly traded company for 30 years released the iPhone. The programming language that ran that iPhone was Objective C. A superset of language C that was developed in 1972. A year later, Google a publicly traded company with market value of 20B at the time, released their first Android phone which was programmed in Java. Java was a programming language made by Oracle systems in the 90s that was made with no intent on being on mobile phones.
So why did 2 publicly traded companies, with all the money in the world, have to borrow programming languages from other places in order to get their products off the ground. Well there’s a few reasons.
There’s only about 3000 people on the planet who can write their own programming language from scratch. More then half of them live on a beach and are no longer interested in working.
It’s really a hard and long process to make a language that makes logical sense to the developer mind but can communicate with the device.
Making a perfect programming language is a bit of an art form. Syntax, computation and performance is no easy thing to achieve.
So when Apple finally released Swift for iOS and Google released Kotlin for Android, these weren’t just upgrades to pre existing languages. They were languages specifically made for these phones. They’re beautifully made and a giant leap forward compared to anything else on the market.
Then came along lazy people. Why do we need two separate people when we should have one code base to control two very different phones (with two very different types of user experiences.)
Which is where hybrid programming languages are formed. React Native or flutter are languages built on top of native, which you should never use, for the following reasons:
Performance is Everything
If you build the same exact app, the same buttons, same features, with the best programming skills, a native app will ALWAYS be faster then a hybrid one. Why build something slower from the start.
The User Experience Factor
Native apps follow the design and behavior guidelines of their respective platforms. This means a more intuitive, seamless experience for users. Hybrid apps is a build one for both scenario. Well iOS it’s common for the hamburger menu to be on the left of screens. For android, it’s normal for it to be on the right.
Full Access to Device Features
With native development, you get full access to the device’s features—camera, GPS, push notifications, bluetooth, cell reception levels, etc. If your app has any type of bluetooth connection, needs to have offline functionality, your only option is to make them in native.
Long-term Viability
So another fun story. In late 2016 we took a project under our wing that was written in React Native. We didn’t build it, the core engineering team was a bit older and they planned to move away from mobile development. The owner was looking for a development team to build on top of what they had, project was cool, code was written well, so I decided, oh sure why not.
Then in 2017, Apple released the iPhone X and boy… did all hell break loose. The notch in the new designed iPhone required a wrapper (a way for software to detect it). If you didn’t adapt this wrapper your apps would look all distorted.
The wrapper was available in native a week before the phone was released… it took React Native developers 2 MONTHS to release an update for React Native apps to adapt the notch. No one was happy and there was nothing we can do.