Looking back at the past three years, React Native has proven to be extremely successful at Discord and helped drive our iOS user adoption from zero to millions!
More specifically, React Native has allowed us to reap the benefits of quickly leveraging reusable code across platforms, as well as develop a small and mighty team.
Meanwhile, we’ve learned to adapt to its inevitable pain points without sacrificing overall productivity.
We all complain a lot about these non-native, cross-platform frameworks, but it’s only fair to also highlight the other side of the coin – in this case, the view from the developers of an incredibly popular application who need to easily support multiple platforms.
Whilst it’s easy to complain about non-native apps, it’s like trying to stop a glacier. What we should be learning from this is that demand for cross-platform applications is becoming a non-negotiable requirement and Microsoft / Google / Apple can’t stop this.
Don’t see Electron apps and the like as a bad thing, see them as a vanishing mediator; a less-than-perfect way to break dependency on a one-OS view. Something better will come along in time, something that Microsoft / Google and Apple can’t stop from happening.
Microsoft and Google have a whole bunch of apps that are cross platform or simply run on the web. They also both have cross-platform toolkits (Xamarin and Flutter) and they are starting to work on Progressive Web Apps. These companies are pulling the cross platform car nowadays, not trying to stop it.
You are basically right about Apple though which basically only has iTunes available on another platforms. If I am generous I could include Apple Music and iCloud, but then I should also mention Metal replacing OpenGL for all things Apple-only. Even their “completely open” Swift language is basically Apple only, just like compiling for iOS.
Some companies are better prepared for cross-platform apps than others. Apple, meanwhile, would gladly remove the web browser from iOS if they could get away with it.
You’re right about Apple Music. However, the Android client gets lots and lots of negative reviews so while it’s technically cross-platform, it doesn’t seem like it’s a *quality* cross-platform app/service.
All of these exploits boil down to this:
1. I want to read something in memory.
2. Write code that says, if it’s this value, do something that takes a long time (or a very short time), otherwise do something that takes a short time (or a very long time).
3. You now know more than you used to. Repeat over and over until you know everything you want to know.
Architecturally, this is very hard to mitigate.
Post it there : http://www.osnews.com/comments/30611
oops….
React Native, Electron, Xamarin, QT, Flutter, ionic, Cordova… there’s no shortage to choose from. Can anyone share there experiences of which they’d recommend, or good articles that cover the differences between them from a development perspective?
Generally speaking, sadly, nowadays the question is more which of them sucks the least.
Xamarin works okayish, but occasionally Apple breaks deployment. The general rule for Xamarin is that if you don’t build your app for 6 months then you shouldn’t expect it to work next time you try. YMMV, but their native binding code has been in a bit of a flux (the official way you do it has changed a few times, the thing sometimes just crashes after an update and you have to figure out why), the original mono framework used as a base was rather incomplete and buggy. They also seem to have adopted that “oh, you are using the OLD framework from 6 months ago” mentality that is prevalent in .net land of late. Documentation is generally poor (but that goes for most newer dev stuff).
On the plus side, Xamarin does have a very nice editor on Mac (MonoDevelop aka Xamarin Studio aka Visual Studio for Mac). If you like coding in C# it isn’t a bad choice overall. Despite its shortcomings the client was happy with the solution I built in it for iOS.
Qt has been my pick historically, but then they created Qt Quick. I’m not sure exactly what their long-term plans are for the Qt Widgets framework and therefore I’d be somewhat wary of basing new apps on it. If someone knows their official stance on Qt Widgets I’d love to hear it. Qt is generally a huge beast, though, and I had to write my own custom tools to get around the limitations of the moc tool and how you integrate it into a Visual Studio project in a nice way.
All the Chrome wrapper solutions I can’t really comment on – haven’t managed to create anything with them yet. On the plus side, once set up you can hire the cheaper web developers to do the grunt work. On the negative side, it is based on web technologies and the horror that brings. Is this the future on the desktop? Maybe – we’ll see.
Qt isn’t really meant to be developed in VS at all without the paid integration tools. Use Qt Creator or Emacs/Vim/whatever or pay up.
We are a paying customer where I use Qt. Historically their integration tools have been rather poor and barely maintained. Their first integration with that toolbar was pure trash. I haven’t kept up with how their latest integration works, though.
You didn’t mention react native or flutter in there.
Is that just an oversight, or are you under the impression they are a web-wrapper?
React native and flutter are more like the JVM apps you used to see; they ship their own middleware and run in that.
Personally, react native has been a nightmare because of the way react seems to love breaking things; they stay at 0.x in semver for this very reason.
Flutter has been pretty great and shows a lot of promise. Dart is a sensible enough language, and it’s been a fairly stable target as it heads towards leaving beta.
I have personally really enjoyed using nativescript, because we use vue for PWAs, and nativescript binds in a way that seems like magic. It means you can call pretty much anything from the native side in JS, and it feels like you’re just calling another JS function; no frustrating bindings like cordova, as your JS is running through a live transpiler that makes it into native code.
Apart from flutter they all seem like hacks though. IMHO the native app is not so long for this world. Wasm is progressing rapidly so PWAs for everything is probably the future.
You can actually write your *entire* frontend in rust now, using a rust framework that looks like react and a rust tool that looks like webpack.
Wasm and web components are going to be the final pieces needed to make the web into a highly performant cross-platform VM that’s preinstalled everywhere^aEUR| like JVM mk. 2
Edited 2018-07-27 23:14 UTC
Yes, oops. I thought they were. In any case, haven’t used them so can’t comment on them.
Thanks for the insight and for sharing your experiences. I’ve used QT so the comparison with that is helpful. Context is everything of course, but I get the impression Flutter is the framework developers are most positive about generally (not just here but also elsewhere).
The whole selling point of React Native (as well as NativeScript and Xamarin) is that they render native widgets. So even though the programming language is “non-native” the user interface is native and thus the app should be indistinguishable from a “truly” native app.