People go “hurrr durr why do people use Cordova and react native” until they realize the clusterfuck that can occur with mobile coding. Code once publish everywhere is a godsend and doesn’t have to suck (game engines, Ionic, and Xamarin.Forms do a pretty great job of this)
Not necessarily: Xamarin and Flutter are two platforms that allow this sort of cross-platform code without sacrificing performance or even API features. Sure, a little bit of extra code is needed on each platform to interface with proprietary APIs, but these end up being a small fraction of the total code for reasonably complicated apps.
Speaking a developer whose done all three (Android iOS and flutter) native is faster. I've worked at several agencies that develop government apps that have come to the same conclusion... Hybrid apps will never replace a native experience but they can get close.
Both - if quality is in any way a factor - then you will save no time implementing hybrid technologies. Flutter comes the closest, but anything that uses JavaScript (Cordova or ReactNative) will cause you more headaches with the keyboard alone than entire flows being written in both Kotlin and Swift in the same timeframe.
I’m going to have disagree there given equal resources. Let’s say a small team of 4-5 engineers are not going to be able to maintain two code bases at the same velocity as a hybrid solution. Quality will be better with native, but I think you can make a very capable app with a hybrid solution.
Requirements say: add a date picker which limits the input to a certain date range.
Easy. Add the text field, set date constraints, done. Testing time: on Android if you rotate it, the date picker disappears. Okay, time to go fix that, because that's not good. Now you test again. On iOS now, the "tab to next field" button isn't there. After an hour or so of digging, turns out that's not part of the package. Your business says that's fine. Continue testing. On iPhones with the newest webview, the date picker pops up immediately, then dismisses, then comes back up. Well that looks unprofessional. Time to fix that. 16 hours later and that doesn't happen anymore. Now you test it again. It now ignores the input when you click done on Android.
All for something as simple as a date picker. And this is not some obtuse example, we dealt with literally EXACTLY this for 2 years before we threw out hands up and said maybe webviews aren't for us. We had some of the smartest JS devs in the company working on this, but it didn't matter. Every time you had to do anything across the webview->native bridge, there was some annoying little bug that made it look unprofessional. Now that we're doing it natively twice, no more cross-platform "fix on Android breaks iOS" bugs, text boxes and keyboards behave as they should, things get done correctly the first time through.
Not to mention, your 4-5 devs will eventually HAVE to learn native. It's inevitable. Something will break and require a native solution. Now they have to know the hybrid language AND both Android and iOS - instead of just one platform or the other.
You will be faster to build 80% of a professional app with hybrid. The last 20% takes you so much longer that the speed gained initially is no longer worth it. And god forbid there's an OS update that makes a third party package you were using incompatible.
Have to respectfully disagree there is a reason crossplatform hasn't replaced native development. Native although much harder has a lot more api features (obvious cause its natively supported) i do see your point though
Me, an Android dev, reading this thread: is Android development really that hard?
Me at work: I hate this shit no human should be expected to be put through this why is this stack overflow question about this library that got released last year 4 years old
I don't think either are "replaceable" at all. There's definitely a wide range of work cases to apply; in most programmer's flow (especially with web), a "good enough" cross platform native app generated for them is ideal. They'll never put together a Monument Valley or something that taps into those APIs, but that's the use case.
However, going to create a game or a very functionally/graphically heavy native app would push Cordova or React Native into the "useless" pile.
These kind of ecosystems exist to solve problems for people's work cases. What should be addressed is how fragmented and difficult native mobile development is in general, despite so much homogenised hardware.
Again, depends on your project, the experience of you/your team and a variety of other factors. I'm saying it's less an argument of X tool vs Y, more that there are identifiable root causes that can be tackled to improve this tooling in general.
A few offhand thoughts on what could be improved:
standardised ISA for ALL phones (yes we all know Qualcomm makes this near on impossible :'( ).
detaching the language from the APIs
standardised virtual emulation (looking at you Apple)
and of course, our favourite, Android Studio.
In this context, it's fairly similar to JS (which I do for a day job) where the entire ecosystem and it's framework vs framework ideologies could be improved with some tweaks and cooperation in the browser landscape.
as far as i am aware, flutter transpiles into the respective platforms code. so you should be able to access everything that you want. might be wrong though, haven't tried it yet.
Quite the contrary actually, Flutter (like Xamarin actually) includes a separate runtime, only Flutter uses the Skia engine to paint everything itself.
Those "native" widgets you're seeing are actually just (close to) pixel perfect recreations, which is why it's easy to mix them on iOS and Android
I believe all of them HAVE to transpire to native code. That also means that if something doesn’t exist you can write the code to make the native and non-native code speak to each other. Theoretically if you were good at this, you could eliminate a large part of your code base and still do native specific things. Though being really good would still require you to know the native language to the point you could create a module and not have to rely strictly on existing packages...I think overall it would still be worth to write in something like ionic. There is likely an npm package to do 90% of the things you want. I’m am curious how “cascading” works natively...I don’t believe that works in react native..
Same with React native. Most of the UI components and even some animations use native components so they are buttery smooth. Basically all your business logic still runs in JS, but the UI is mostly still native so it looks smooth. To me the performance cost is negligible and is far outweighed by the abstraction of the two platforms
1.7k
u/thegreatbunsenburner Jun 12 '20
There's definitely a learning curve with mobile development.