Out of interest, I notice that android is behind iOS in terms of development/features (and I look forward to android updates ).
But why did you go with native development rather than hybrid, for example react native?
This would have meant feature parity across devices (and later ubuntu phone, windows, samsungâs mobile OS) without much additional coding.
This is just out of interest, the obvious answer is probably something like âwe have iOS development experienceâ which makes sense, but longer term would cross platform make more sense?
Hybrid apps = lazy company. Or one with less resources.
The thing with hybrid coding is that youâre not playing to the strengths of each platform.
Itâs like people who post Facebook posts to Twitter. Not using the platform in the ways itâs intended to be used.
Also, I VERY much doubt youâll ever see Monzo on Ubuntu, Windows Phone, or Tizen. Even large companies like Google, Amazon, BBC etc donât make their apps for these operating systems because they have marginal market share, so the chances of a startup doing it? Slim to none.
I really dislike hybrid apps. Iâve worked on a few myself as well as building some native applications.
I think thereâs a performance hit due to rendering in a web view and itâs downhill from there.
Itâs difficult to design for multiple OSes too, one design for multiple platforms will result in a worse experience for all users.
Completely disagree @caseyrain it doesnât mean lazy at all. 80% (and increasing) code sharing between android and iOS for facebookâs advert manager suggests its just smart thinking. And if anything what youâve said backs my thoughts that hybrid would make more sense for monzo as a startup.
@Throwingspoon completely agree on the webview style hybrid apps (as someone who works with and builds them daily). However Iâm talking about react native (or NativeScript, etc) which are essentially native apps. Additionally hybrid != same, the final views used can be different for each platform, whilst still reaping benefits of huge code reuse under the skin.
Agreed with @Throwingspoon - users in the Android community hate it when an app shows up with an iOS style UI, itâs very jarring and reeks of laziness. I can imagine the reverse is true too.
I think it depends on the type of application. For a straight forward CRUD application, I think unifying the code base across platforms as much as possible is the smart thing to do. It not only, reduces development time, but also allows you to release updates to all platforms simultaneously.
I think itâs also possible to get UI benefits if the app is developed using web techniques (possibly as a progressive Web app) as libraries like D3 could be used to enhance the visualisation of the app.
I commend Monzo for making native apps⌠itâs harder work but makes a much better app in the long run. The glut of barely acceptable iOS ports is really annoying.
Where I work we have a hybrid approach - the core in Xamarin, and each platform gets its own native UI, designed as much as possible to follow the platform guidelines. Itâs a little more work but the results are worth it. We have rather a lot of common code though, so get the benefits of that.
Yep. I like that idea. I have a Windowsphone I love using but have to use Android for banking. A UWP app for Windows 10 would work on PCs and Windowsphone.
Progressive web apps are another choice that makes the app device independent.
Over time I think one progressive web app that works on anything would make a lot of sense too. The device specific app is beginning to get to the end of the shelf life. I has some time yet but down the road being independent of a device makes more sense as connectivity is everywhere.
The Facebook app is almost entirely native nowadays, they just have big enough teams to build all that out for every platform and keep pace between them.
Facebook did try HTML5 and hybrid apps but it didnât work out so well for them. I remember the app being near-unusable without perfect connectivity.
That story is very out of date (predates react). Yes it is native, but
react-native which is mostly/increasingly cross platform, which is what I
queried in the original post.
Apologies for not realising you were the original poster and for not fully rereading all the way up to your original points when replying, looks like Discourse handled the email reply in a weird way that didnât link back to your account and I didnât properly spot the name.
In any case, React Native is pretty good these days. I would struggle to even call it hybrid considering how badly tainted the word is by webviews (this thread serves as evidence of that!). Itâs not something that fits my own work but it would be interesting to hear what the key consideration points for Monzo would be for this.
Iâm personally glad theyâve gone with native apps. As others have mentioned, the UX tends to be poor with hybrids (those based on WebViews and those using technologies such as React Native IMO). Hell, the React Native folks canât get String#startsWith to work consistently (sure, Unicode can be hard but this seems like something that shouldâve been fixed) and Iâve heard horror stories about ListViews choking on lists with over a hundred elements.
From what I understand, the JS is interpreted at runtime too - I honestly canât see how this can be anything but slower than equivalent JVM or native code.
Flutter is slightly different, as far as I can tell. Code is compiled ahead of time and executed using an engine written in C/C++. With that saidm itâs still not ideal because it doesnât use the native widgets users are used to.
Iâm not sure why popularity implies quality or good UX! Lots of companies use Electron because they can reuse code/save time/not have to hire developers familiar with UI frameworks, but youâre going to suffer on performance and usually have to settle for non-native components. Iâm not the only one with this opinion.
Iâm sure you can make good use of React Native but there are going to be inherent limitations you will have to work around. If I recall correctly, animation is done in a JavaScript thread for instance - which is going to be slower than native code no matter how good your JavaScript engine is.
).
