Coinbase decided to greenfield their new apps, Airbnb (attempted) to brownfield it. I've worked with a number of clients that have gone down the same path that Airbnb did, from a business perspective it makes perfect sense, keep what you have and slowly move over, but the technical reality is this will be a complete dumpster fire and you will probably fail.
When you try to convert a native app to React Native everything that makes React Native wonderful to work with just seems to break. Hot reloading either barely works or not at all, load up times increase exponentially, the app just becomes a pain in the ass to work with because nothing seems to work like it should.
Whenever companies propose this I always shoot down the idea and recommended a rebuild in React Native from the ground up. Doing so will take just as much time as browfielding because when you try to do a native -> react-native conversion it always seems to go south somewhere, either slowness, having to write 3x the code, or other problems.
Mixing native and React Native = bad.
Doing pure React Native (for everything but ultra high-performance and apps that interact tightly with hardware) = good.
I feel like all those takes completely misunderstood or ignored Airbnb’s technical constraints and the underlying reasons.
Anyone blamed it on the library. Not the dumpster fire implementation that ultimately killed the venture
There will always be technical challenges with any large project. But getting buy in from the right people can make those problems surmountable.
A similar thing is happening with React Native. It is kind of slow on older phones, and it felt very kludgy when it was first released. But things have gotten better and most important of all: phones have gotten substantially faster.
You still have to learn how to make high performance React Native apps, compared to React in the browser where it’s more forgiving. But this is no different than native. So I think there is reason to believe it has gotten to a point where this could be a long term decision.
Mixing an old native project with RN, doing a so called "slow transition" sounds like a really bad idea. Data communication between the native part and React Native will become an issue, you're effectively going to be running a mini distributed system within your device. There's probably 100 other problems that I can't even start to imagine. Perhaps a super experienced, world class expert in both JS and mobile development + runtimes can pull it off but I wouldn't be comfortable trying to do it (been doing mobile development directly since 2016 and have been close to mobile dev since ~2011). Re-write is a better option.
We had occasional tooling issues like you describe but all fixable. I'd be happy to go through the same process again.
It works like this even on hello world apps.
The only platform where Hot Reload works reliably on mobile is Flutter.
An old version of Java that just got lambdas?
Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym)
Are there adequate networking, database ORM, and image loading libraries for all frameworks?
Last time I interviewed for any mobile development role was 2 years ago and every team (FAANG, Fortune 500, Series B startups) wanted something different and acted like that was the normal skillset to expect
- Flutter: Easy to learn, amazing build tools/ devex, very few jobs (though predictably growing). If you become a flutter developer, you can be confident the company that hired you has thought about the tech stack a little more. React Native is the defacto for quick and dirty apps (MVP), and Flutter is for more of a company thats investing in its technology, I would say.
- Android: Okay to learn, very good build tools/ devex, more jobs
- iOS: hardest to learn, okay build tools/ devex, fewer jobs
Difficulty is measured by how long it would take you to implement a feature you don't know, or just my rough feeling of building apps in all platforms, some of them professionally. Im very unusual to know all 4, and I have not met anyone else like me in my jobs.
I would pick Flutter, because you're not optimising for today, and Flutter will be there in 5 years, regardless of how big https://killedbygoogle.com/ gets E.g. The tech lead for Flutter worked on HTML, CSS, WebSockets.
The alternative is to just not use expo and add libraries as you need them. Then you can do things like add widgets and watchOS functionality to your app on iOS using native code. Or create your own custom native views and plugins that bind to the native sdks, giving you an edge over other bland RN apps. I love RN but only when used correctly.
Both Android (e.g. Jetpack Compose, new privacy centric storage APIs that we are now forced to use) and iOS (SwiftUI) have this. I guess we'd need to list them down and compare.
> iOS SDK is both generally more capable
Yes, Apple provide more higher level functionality, at the expense of flexibility. Android also provides higher level features, but these are provided in external libraries which you can package in your app. When it comes to auxiliary features though (e.g. machine learning), I think Apple does the high level APIs much better. Android's features are quite a bit buggy.
- Where will you learn it? Apple documentation is bad. remember this? "On Apple's Piss-Poor Documentation", 1180 points to date https://news.ycombinator.com/item?id=25046691 Android documentation is great. Yes there are at least 5 ways to do something e.g. schedule background work, load files, but its very clearly deprecated in their docs/ in the code. You can, read the code because it is open source. If you find a bug in Apple's library, what do you do?
- There are more developers, more stack overflow questions/ answers and more resources on the internet in general for Android. So even when Android has edge cases/ backwards compatibility issues, its more likely than iOS that someone has written about it.
- Apple tooling is bad: Xcode is not a good IDE to put it lightly. It gets 3 stars on the App Store. The actual code editing part is just a text editor, e.g. searching for function calls involves using the search function, as opposed to a keyboard shortcut that uses static code analysis. Most warnings for your code won't show up until you try to build it, therefore the feedback loop is extremely slow. Many iOS developers I've known admit they do not like Xcode. To upload your iOS app to the app store, you upload gigabytes of binaries. Code refactoring features do not exist on Xcode. Android Studio is one of the best IDE's I've used, and constantly adds support for more features: WorkManager inspector, deploy/debug multiple devices at once. Also, new features come out for Android Studio all the time, and Xcode seems to have not been updated with features that benefit me for a long time. Jetbrains IDEs generally work straight off the bat, and I'm very happy to see AppCode (Xcode competitor by Jetbrains) available, though it is thoroughly buggy at the moment, I still use it because writing code is nicer in AppCode.
- Basic things in the apple ecosystem are broken/ buggy: e.g. New developers in a team will have issues signing their application with the company team, the trick/ fix is to remove/ add a Xcode/ iOS capability to the project, and remove it immediately. Then signing will work. Signing the app is literally the first thing that needs to be done, why is this not fixed?
- Swift is much nicer than Objective-C to program in, but its not as nice as Kotlin. I don't want to get into programming language comparison (im sure there are connoisseurs here who can), but my opinion of reading Swift code is they are less readable and results in unusual architecture. Swift apps are also slower and bigger than Objective-C apps. Some Apple APIs are also designed in a painfully complicated way. It seems like they do not get much feedback from developers about their APIs, whereas Android is constantly getting feedback and improving. Some developers complain that Swift has changed, breaking older Swift code. I haven't heard this from Kotlin developers.
Sorry that felt like a rant. In the end you've can choose based on
- Comfort: Android is much more ergonomic for the reasons above
- Developer competition: You'll be competing with more Android developers worldwide: Android is more than 85% of the smartphone market
- Money: iOS costs $100 annually (not much but if you're starting out your first app, maybe it is). The upside is if you live in a rich country, many people use iPhones, and they also tend to spend more money on the app store.
- Market trends: iOS has added ATT/ privacy features. They've also got powerful chips but it seems like no one has learnt how to use them yet. They are ahead on hardware (M1, A14), they've got great market share in Western countries, and are poised to take even more with recent developments.
> The actual code editing part is just a text editor, e.g. searching for function calls involves using the search function, as opposed to a keyboard shortcut that uses static code analysis.
Xcode has indexed static analysis, symbol navigation, jump to definition, quick fixes, in-line quick help and a bunch of other features I use every day that lift it out of the ‘just a text editor’ class.
> Most warnings for your code won't show up until you try to build it, therefore the feedback loop is extremely slow.
This hasn’t been my experience - warnings that appear on build generally also appear when saving a file. There’s no need to trigger a build to get feeedback.
> Code refactoring features do not exist on Xcode.
Editor > Refactor reveals 13 refactoring options for me in Xcode 12.5.
I like Xcode, even as someone who switches between it and JetBrains editors (for frontend/backend work) every week. The only thing I really miss is stable vim emulation.
Android has a lot of documentation but there are so many more layers to Android development than iOS. On top of that, the best practices on iOS are very consistent while on android they change like twice a year, it’s exhausting. Finally, I personally dislike working in the Java ecosystem, so android is way less fun for me than web and iOS is
In terms of market, do your research on jobs and skill demand in the area.
I prefer native, but I'm pretty biased, to be fair.
>Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym)
We're doing MVVM these days. Or whatever you would like to call the following description:
>There's an object called the ViewModel which survives activity recreation, from which in your view-layer you subscribe to some state. The ViewModel also facilitates access to the Model-part of your application with state and network access and whatever
>Are there adequate networking, database ORM, and image loading libraries for all frameworks?
I'd say so, yes. The Jetpack-family of libraries by Google are all pretty good.
For networking, you can use Retrofit by Square
For database ORM you can use Room by Google. There's also SqlDelight by Square if you like a lighter approach to database interaction.
For image loading the most recent contender is Coil, but Glide also works pretty well.
>Last time I interviewed for any mobile development role was 2 years ago and every team (FAANG, Fortune 500, Series B startups) wanted something different and acted like that was the normal skillset to expect
I can't promise you that the entire android development scene has aligned on anything entirely yet. This may very well still be the case.
It doesn't get the buzz, and the ecosystem is somewhat old (it's surprisingly common to run into a repo that hasn't been touched in a year) but it's the superior platform to React Native and you get none of the capriciousness of the React ecosystem (if anything the Nativescript community might need a jolt). Nativescript is incredibly productive and you can bring along frameworks that do their best to move the work to compile time (like Svelte).
I think the best options form a spectrum like this:
(PWA)-------(NativeScript/React Native)------(Flutter)------(Kotlin/Alternative iOS environments)--------(Objective-C/Swifth/Java "fully native")
If you choose essentially anything on the right side of flutter, performance will be relatively good out of the gate, and anything to the left (including flutter) and you have to be a little careful.
I think Flutter is actually the worst of both worlds because I'm heavily biased against Dart after using it, but it is obviously backed by a behemoth, and the render-every-pixel model makes it insanely portable. If you want to write-once-run-everywhere (generally a bad idea, but if it works for you who cares), then flutter is the best by a longshot.
I want to pass interviews and do android development for employers
Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on
Definitely learn plain old Android-style Java, with the usual tools (android studio, etc) then. Most shops are going to be that, and if you want to pick up Kotlin for the shops that are a step ahead then do that.
> Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on
React Native in this scenario, unless the company already has at least one (and if it's one they have to be VERY competent) mobile engineers on both major platforms.
Fully native is the best results (there's essentially zero limitation) but is the most specialized work. PWA is the easiest, but paradoxically needs a tiny bit of specialization to get native enough that the business isn't embarrassed. Also, with PWA there's lots of hard limits on what the app can do (notifications are a particular bugbear).
I think most developers would prioritize employability + traction/community/documention. There’s not even a comparison there. React Native is the superior solution.
I would like to point out that NativeScript works -- people mostly don't make buzz about it but it's out there powering apps that are delivering value, I've used it myself for a client and it was fantastic.
React Native is the superior solution only if you prioritize employability/traction/community (I disagree on documentation, NativeScript's documentation is excellent), but if you need to get an application out but are turned off by the React crazy-land and bad performance of React in a mobile context, give NativeScript a try, it's the better platform in a technical sense -- it has things React Native doesn't.
- The type system was essentially like java but perhaps even worse -- in a world with Rust, Haskell, Julia, Kotlin, Scala, and even Golang this seemed egregious.
- No algebraic data types (sum/union),
- class-based inheritance
- nullable values
- using exceptions instead of errors-as-values approach.
I know they worked hard on the language (rewrites are hard, there are some good talks on there about it, link @ end), but it's like they ignored all the progress in PL over the last like decade+. Anyway, continuing on:
- JSON serialization/deserialization was like the worst parts of Go and the worst parts of Java (again this has to
- SQLite driver couldn't be used off device. I found this out while trying to write tests that ran off-device. Now there's sqlite3 so maybe it's no longer an issue
- Dart2 was a played down rewrite of Dart1, with JS interop removed. Typescript is a better language than Dart.
- BloC is overcomplicated and was rolled out poorly at the time (this has more to do with Flutter than Dart). The state management patterns felt like unbaked react (flux pattern) v1.
All this said, Dart will probably be around for a very long time. Fuschia makes a LOT of sense for Google to continue pursuing, which uses Flutter. Dart could be worse, and I think it's good enough for a bunch of usecases. If it were me, I wouldn't even choose it over Nativescript.
The Boring Flutter Development Show was/is fantastic, I watched it religiously when I was learning and trying out Flutter -- having a big backer like google means there are always going to be dedicated resources and smart people behind Flutter which honestly probably matters more in the long run than Dart being a shit language. As Golang has shown us, you can just iterate to having a good language.
Feels like Dart2 has it's base to build from now, and I don't like the places it's started, but it will probably continue to succeed. At the very least you won't see bad PR about it, because most people who are willing to tweet about it are invested in it's success or want jobs at Google someday, and there is dedicated money for "dev rel".
Seeing Sony embrace flutter for embedded things is pretty big as well. Sony has a surprisingly strong track record of making technologically competent products:
- PS Vita (generally regarded as ahead of it's time)
- Sony SmartWatch 1 & 2 (I owned both, they were ahead of their time, and were very good quality, easily hackable)
- Sony XPeria phones & tablets (embraced open source and easy bootloader unlock, I own a tablet that I'm extremely happy with)
[EDIT] - Separate some points about the language, also add a link to the strange loop talk on the rewrite
I do agree that some common patterns are contrived (BLoC, json serialization via codegen, etc), but I'm not sure it's fair to criticize the language itself for this.
Also FWIW sound null safety is now the preferred way to write Dart (given your deps have adapted to it), so that part is hopefully solved.
Well I spend a lot of my time yak shaving so :). Most of the time in the real world, Dart is good-enough (and is definitely better than JS without TS, from a safety/maintainability perspective).
You're absolutely right, Haskell is academic, but what impresses me about other languages was that they took little bits -- Rust took a lot, Golang took a tiny bit (protocols look more like type classes than class-based inheritance).
I'm somewhat surprised that you prefer it to C# though -- C# was supposed to be better Java, and I didn't think that Dart was better than C# outright. Maybe I'm wrong on that, if it feels more fun to use (i.e. easier so much so that it's enjoyable, but you're not frustrated).
> I do agree that some common patterns are contrived (BLoC, json serialization via codegen, etc), but I'm not sure it's fair to criticize the language itself for this.
BLoC isn't fair to criticize (it's more about Flutter), but JSON serialization is fair in my mind because it's the direct result of a too-weak type system. But yeah overall I'm making the typical HN ado about nothing. In the real world people would just pick flutter (for it's good parts) and commit.
> Also FWIW sound null safety is now the preferred way to write Dart (given your deps have adapted to it), so that part is hopefully solved.
First I've heard of this addition, and it's commendable that they're undertaking this herculean effort, but this is so meh. Typescript arguably has this problem (since it has to interop with JS), but the way you solve it is so simple there. Turn on strict mode, and you're done -- because they considered it from very early on (if not the beginning). Language designers should know what the state of the art is and make good decisions around it up front, this is like 10x worse than writing a bad framework, because you can't drop out (of the framework) -- there is nowhere to drop out to (I mean... yeah you could FFI or something ridiculous but...).
But anyway I'm just tilting at windmills -- people that have to get shit done will just get it done with Dart like they have with every other tool that is less-than-perfect. I'll just stay in my ivory molehill.
A lot of it probably comes from the excellent devex, but it strikes a nice balance between dynamic get-shit-done-ness that you find in JS/Python, and the more verbose, safe, structured nature of C#/Java.
Global imports, method cascading, extensive list comprehensions, named arguments, inference being heavily encouraged, flexible constructors. It's been a while since I did any serious large scale coding in C#, but I just remember it being more of a verbose slog.
- Linux on PS3
- Indie DevTooling for PSP
The fact that those things were even allowed to exist is awesome, and the best thing I've seen out of MS on this front is Kinect. Not sure if Nintendo has done things that developer friendly.
Most companies are intent on making full on walled gardens.
The article is from a high level engineering standpoint about productivity and trying to be efficient. The thing the article doesn't mention is the best react native developer also is an expert in native mobile development. It is crazy hard finding these people.
All techno fluff aside, any component mobile developer knows once you have a solid foundation it is super easy to build on core features. Given how frequently aplkenabd google breaks things which makes reactive native upgrades a mega PITA, the only proper use at a technical level is to utilize the code at a framework level. React native is still on its knees to cocoapods, which as of now is virtually nonpreferred for future projects.
Sorry for the rant, I just think A.:) Coinbase made the wrong decision in the long run because they limited themselves on a technologist that's infamously know to not favor solid user experiences
B:) they underestimated the specific qualifications they need to get the people that are grounded enough to know native mobile development and its capabilities, abs the react native component. Even though they are coinbase the article acts like it doesn't matter.
Large teams can afford to have a subset of platform devs and a large body of RN app devs to make this plan work (note: you now have 3 platforms: iOS, Android, and RN itself). Smaller teams will struggle. Most often, small teams will end up putting their weight on the RN side (develop new features!), and slowly slide downhill in performance, responsiveness and overall UX like the proverbial boiling frog.
This has been my experience as well. I work on an app that supports multiple generations of iot products. We were forced to start developing for the next gen product in react native, and let the legacy stuff just use the exiting ios and android codebases. We made it about 9 months before throwing out the react native work and porting it all back to native. Management doesn't realize that moving to react native doesn't mean you now only have to support 1 platform, it means you're now supporting 3.
It's not that bad. All they need is at least 1 iOS expert and 1 Android expert in the team.
> infamously know to not favor solid user experiences
I don't think that's necessarily the case. Discord is doing fine for me. Most of the apps don't need such high performance as video games.
People always rant about React Native and Electron. The reality those techs are just scapegoats because most of the companies chose them because they want to build something cheap. If they use the same budget to build the same set of functionalities using native technologies for each platform, the outcome could mostly be even worse.
* They had a much harder time hiring mobile developers than web developers, and per-person productivity was also lower
* They prototyped an app before committing to a new technology
* Similarly, they tested a change to the existing app before switching
* They specifically invested time to cross-train people, and tested how long it took web developers to get productive on React Native
* They interviewed Airbnb, who had also invested a lot of effort into React Native before dropping it
* At each step, they considered whether to rewrite from scratch or incrementally switch that part of the codebase
This makes a lot of sense. It shows the kind of careful consideration we should apply when seriously considering switching to a new technology.
It's not hard at all to find mobile devs, just offer more money. Mobile devs cost more, that's right.
But I think that's because mobile development is significantly harder (personal first-hand experience).
That's what happens when you pay peanuts.
It's definitely competitive pay.
It's pretty common knowledge that FAANG pays really well. One of the big reasons people work there are for the extremely generous salaries. Everyone else is underpaying if you're comparing them to FAANG. Also by your definition, Apple and Amazon are notoriously cheap too. Really you're only comparing to Google, Facebook and Microsoft (less so).
FAANG salary is the median for good developer salary, yes. After all, why would you work for less if you're good enough?
> Everyone else is underpaying if you're comparing them to FAANG.
You're getting somewhere.
> Also by your definition, Apple and Amazon are notoriously cheap too.
Pretty sure they're paying bigger salary than coinbase does. At least their product is more interesting than crypto dashboard, maybe that's how they compensate for "shitty" pay.
RN is good for fast prototyping and market value fit testing but I'm not sure I'd use it for something like Coinbase.
Here's where green-fielding would have also made sense (and a difference) by using a recent example of a new famous product that is NOT using cross-platform tech like React Native / Flutter, and that's Clubhouse.
Last year, they launched their mobile-only native iOS app and everyone was wondering about where the Android app was. It was finally released this month and it took them a year in total. By that time, the hype was already dead, everyone already moved on and didn't care about their app since their competitors copied them to death (And took the Android users with them.)
Had they used React Native or Flutter to build their app, they would have been able to release both platforms quicker and at the same time and become feature complete rather than releasing the Android app feature incomplete with iOS and the Android users still waiting for a year and leaving for the competitors instead as the hype already died.
Now they are stuck with implementing their features on both platform twice. Discord already cloned them as a feature very quickly (using React Native) and now Clubhouse has to catch up with them to bring their lost users back. Given how fierce competing with social networking / messaging companies are, I do not think using native in 2020 / 2021 for a new product was a good idea in this case and green-fielding a RN or Flutter app would have made sense to iterate quickly.
I'm happy to answer any questions that folks have - just thread here, and I'll either answer or pull in our team to give more detail.
We’re they down sized? Re trained? Etc. and so on. Can you speak about the process around this and so on. I understand you want to give a positive image externally here, but I’m more interested in what struggles occurred and how you resolved it / did not resolve it.
I'm a web developer and a few years ago, I had the opportunity to develop a mobile app. What a nightmare...
Among the new versions of React Native or Gradle breaking everything, all the npm packages suddenly not maintained anymore, the virtual phones not always starting or refreshing, the custom code you add to do in Java and Objective C because RN cannot do everything, and certainly the worst, the deployment on the app store.
Mobile is generally shit, but RN made it bareable.
But, yes, much bigger overhead with all the native stuff. I'd recommend everyone to use web tech whenever possible.
Google + Microsoft should really double-down on PWA apps. I think at one point Microsoft was crawling the web and automatically listing any PWA in their app store. If that became the norm then maybe Apple will make their PWA install UX less deliberately clunky.
I'm chasing the holy grail of "build once, run anywhere". I want to basically use Svelte and Tailwind and spit out web, iOS and Android apps.
But I also want to use normal HTML components. RN, Flutter and NativeScript all have their own unique components which is another thing you need to learn.
Will see how far the PWA approach can go when I find the time.
Expo is nice but the whole DX is just painful. The iOS Simulator will crash often. You need to do a hard 'expo start' relaunch often. What looks great in iOS will often be broken on Android. Trying to get pixel perfect UI and the desired UX is painful. Expo is full of bugs and limitations. RN is old and unmaintained.
Can explain the last commit being 2 days ago and the steady progress they've made on all fronts in the last year?
C'mon iOS devs you can't tell
you enjoy the byzantine layout model of the native iOS apps and working in xCode.
Some parts of React Native are problematic but creating screens is simple and intuitive.
The pace of mobile changes is slowing and will probably slow further. This is the usual case of an initial innovation transitioning to incremental improvements. This means that React will eventually catch up or come close to catching up with mobile developments (if they have enough technical expertise to do so).
Competition has consolidated the market into two platforms. This means that only two platforms need to be supported.
Due to competition between iOS and Android, the two platforms are undergoing convergent evolution. This will also make it easier to support the two platforms since new features will be similar.
Stepping back, I think we are just seeing a battle of commoditizing your complements. For Coinbase and Facebook, Apple is the complement. For Apple, Coinbase and Facebook are the complement.
Better to make it natively than to support an extra platform which is RN.
Seriously haven't we seen how this play-out way too many times already?
There is absolutely no incentive for Apple and Google to make sure ReactNative controlled by Facebook is the way to develop apps for their platforms. Till that is true, its absolutely nuts for any company other than facebook to develop their apps in ReactNative.
He certainly didn't do enough of it, right. They have traded long term prospects for short one.
In the long run you'll have more issues with React Native than upsides.
They cited issues with hiring native mobile devs, well now they've made it even harder for themselves. Since they need to find devs who know both native and React Native. And those guys cost even more than pure native devs.
That's actually a good idea for a career. Learn native, React Native and make big buck from companies that are stuck with React Native.
This is extremely presumptuous to say the least. It assumes they didn't do enough and that you know more.
> I don't know shit when you have no idea who I am and what I do.
Your words not mine. Re-read all of my responses without your blind hatred for what they did. All I am asking for is to give them the benefit of the doubt that they did their research and made a good decision. Of course it's clear you find that incomprehensible.
I think you're right. In their case this was the best course of action, unfortunately. Not every company has capacity to do things right.
React Native does suck big donkey though.
I much prefer the unified approach of Flutter (everything is in Dart and not scattered in 3 different places) and batteries included component library.
Not to mention, if you have a small team, Google Cloud Firestone plus Flutter is a very productive and elegant way to launch an app with a small team ... or even solo.
In your opinion, What is the best React Native App, that is also extremely popular which could be used to show case the tech?
I think if you look at the best and you are already unimpressed that we could wait another few years for others to figure out first rather than jumping on to the hype. Sort of like Facebook demonstrating HTML5 during the start of the iPhone App Store era.
Shameless plug: my opinionated beliefs https://ashishb.net/all/react-native/
First of all Flutter has major performance problems on iOS.
Using native views (MapBox, ArcGIS) inside Flutter app has subpar performance.
Flutter has weird styling compared to anything I have ever worked with.
Styling in Flutter is very unintuitive (ex: Global theme for button width).
You can’t OTA update Flutter code.
Weird scroll behaviour.
I can go on and on but personally I would never use Flutter ever
Most comments under the link:
React Native bad because Flutter good.
React Native bad because native good.
React Native bad because Y is good.
Do people actually use Unity for apps? I am actually building an app for kids, Unity can be really interesting for me.
That said, we've spent a lot of time talking with teams using Flutter and we think it's awesome!
But I wasn't convinced either.
So far I've been fairly satisfied with Flutter, however there are some glaring performance issues (though it sounds like these will be addressed in due course).
I'd warn anyone targeting multiplatform mobile from using Flutter until this is resolved.
The lag is awful (and I say this as someone whose app in built on Flutter). I know it’s only a “first-time” thing, but it’s a horrible first impression.
> the average mobile engineer’s velocity remained stagnant
> this could dramatically reduce our overall staffing requirements...also have to deliver improved quality and performance for our customers
Honestly it sounds like Coinbase is quickly turning into a shitty place to work. Sounds like all the ingredients for a race to bottom in culture. It's so easy to tell that this was cooked up by primarily non-technical management types whose only actual "first-principle" is penny pinching.
Obviously you can get work done faster across multiple platforms on a per-engineer basis if you use a single technology. The cost of that speed is quality to the end user, and being in a perpetual state of "1 step behind" the capabilities of native app development. There will be regular instances of shoehorning in functionality as each underlying platform makes updates to their respective operating system. The unforeseen issues are that their engineering department will eventually turn into a technology echo-chamber...and this close-mindedness in regards to technology will likely lead to losing out on top engineering talent.
Also, expecting ever-increasing velocity for each employee is insane. (not to the penny pinching execs tho) There's a finite amount of time and mental energy a human has each week. It's one thing to say you want to build software that can accommodate massive business growth...but it's another thing entirely to represent that by measuring rate of acceleration of velocity per engineer. That in and of itself isn't scalable.
"But we all have to re-qualify for our jobs every year. The red-queen race of Shopify's historic 40% or better growth is that everyone has to show up at least 40% better every year to qualify for our current jobs. I expect you to hold yourself and your teams to this standard."
For a basic CRUD app with simple data visualizations, this doesn't seem to be a huge issue compared to apps that might need to take advantage of whatever new capabilities arrive on mobile phones, though those have largely plateaued in recent years.
I learnt vue in a weekend and the framework7 generator generated a boilerplate app for me. I used react years ago but this stack seems far easier and faster to develop in.
Optimise for user experience (go native)
Optimise for cost (whatever the cheapest developers, or a cross platform solution, like phonegap/pwa/react native)
Optimise for developer experience (use whatever your developers know, maybe native, maybe react native)
In my personal opinion, always optimise for user experience.
Shared code should be in the backend, not in your mobile app. Your mobile app (ignoring camera filters & games, as they should use an engine; unity etc) should just be a JSON viewer, with a small bit of data entry.
80-90% of your efforts should be on UI and user experience, but obviously architecture requirements scales up with the team size.
Anything else is over-engineering, generally.
The amount of leads I get in for mobile apps, that eventually transpire to the client not knowing the app was built in react native, because they heard “native” and assumed Swift/Kotlin, is increasing by the day.
They can’t find enough good developers that know react native, and they don’t have the funds to rewrite.
Obviously I, as a native developer, only hear the horror stories from these experiences and not the times it works out.
But in the last 2-3 years, it has killed 2 startups that I know of, and cost 3 a lot of money to rewrite (two of them made that decision before they contacted me, one after they spoke to me, and they were shocked to find out that they didn’t have a Swift app).
I am now having to rescue more clients from react native, than from clients that outsourced to the cheapest agency on Fiverr. Wild!
Side note: why has every app got to expand until it adds messaging? Let a calculator be a calculator, it doesn’t need venture capital and network effects to sell.
Using a backend (adding network cost)/ sharing code should be the last on your mind for mobile apps. I've had once, where the logic for feature would take less than a day to implement (which I subsequently did), but inexperienced non-mobile developers decided it would be a good idea (and said exactly what you said) to put everything in the backend to share code between iOS and Android. The interface cost (network code) cost more time in development, and made a much worse user experience. Not to mention, I had to use the code written by the inexperienced person, which had bugs.
You might not understand mobile, but there's a lot more that goes on in a mobile app.
If you have unlimited money, that is. If you don't, a suboptimal UX is better than no UX.
> Shared code should be in the backend, not in your mobile app. Your mobile app (ignoring camera filters & games, as they should use an engine; unity etc) should just be a JSON viewer, with a small bit of data entry. Anything else is over-engineering, generally.
Ideally, yes, but depending on the app the frontend can still be heavy - e.g. with Coinbase, all the graphing and real-time stuff, done 3 times over, are probably a not insignificant effort.
Name at least one change in Android SDK that can come close to revolution that is Compose. And same for iOS/Mac and SwiftUI.
Compose and SwiftUI are doing to mobile what React did to web. It arguably single most important change that happened since the inception of mobile platforms.
> There's been many stories written about companies that live on the bleeding edge. I don't remember any of them ending particularly well.
React certainly stood the test of time.
Maybe you should first read about subject before arguing for the sake of arguing?
That being said, I didn't know the iOS app was react native. I don't use coinbase much but it feels pretty good.
I'm wondering in hindsight if titanium wasn't so bad and I just didn't have a firm enough grasp on js and CSS.
Ratings and some perf metrics(start time) improved, no regressions.
And define "fine" first. If you mean that it works, sure.
But it works slower than truly native application, like Telegram.
It is like the circle of life with native vs semi-native (which react is), and just html apps.
Teams build a fast new version, looks great as it is new code, without much baggage, and over time it gets bloated and people complain that it takes too much to debug/develop on it.
Some people in a internal team write a new demo/prototype in a new tech, some director/vp buys in, and the circle of life continuous, in the new tech, and a new blog post is made again.
At Spotify, we had few interactions of these, back and forth... like clockwork.
Ps. If you are junior engineer reading this, don't pay too much attention of these type of blog posts, as they usually are just PR for internal teams, so someone gets a promotion.
Just work on the tech stack that you like working on, and exites you the most.
Especially for personal projects. Don't do something because everyone else is doing, but do it because you do enjoy it.
Their point about brownfield development was a good one. In my experience the intersection between RN and Native (both code and people) is the biggest impediment.
Linkedin had the exact iteration years ago. They had one of the first NodeJS Apps, driven mobile apps, and made some glossy block posts, praising it. Then quietly went back to native. Facebook went back and forth with HTML 5 sound the same time, etc.. etc..
It is like seeing the same movie over and over, with just some minor plot twists, they tend to play out the same. Since the Java's Applets promise 'write once, run everywhere', this story instead has been always the 'write once, debug everywhere'.
"Sunsetting React Native
Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing."
"If you’ve read Airbnb’s excellent Sunsetting React Native article, these challenges may sound familiar. We spent many hours speaking with engineers from Airbnb and trying to learn from their experiences. We’re grateful to the team for sharing the details of their journey, as the information was invaluable in deciding the best path for Coinbase. One of our key takeaways was that the brownfield approach seemed to be core to many of the challenges they faced. While the idea of incrementally migrating is at first glance appealing — leveraging the benefits of React native for new features without the upfront cost of a full rewrite — it introduces significant technical and cultural migration risk over the long term."
Personally, I suspect the reason that big teams are experimenting (and finding successes despite some failures and trade offs) is because this is a difficult problem that isn’t solved and requires ongoing creativity and experimentation.
If you see my end note, "to more junior engineers", don't use React Native in your project because X company is using it, and it must be trendy.
Use it only if you do enjoy using it. If you are already good/skilled at building native apps, then you might not need it at all.
They dismissed advancements in native development and they'll pay the price the future.
It's literally laughable that they decided to transition to half dead tech when Compose and SwiftUI are ramping up.
Moving such a mature company's codebase to bleeding edge tech is one of the stupidest decisions you can make. Is there some price to be paid to be in the future? I'm sure there will be, as there will be with any non native platform. Whether is will be a deal breaker is to be seen.
Riiiight, and quickly followed by Xamarin and Cordova. Lol.
Of course it is not dead in terms of usage. It is more "dead" for anything complex.
I'm looking from a perspective of a best experience, best performance and best integration. If your only reasoning is "we can't afford proper mobile developers" that's probably not the best pitch for a technical folk.
Even Facebook, creators of React Native don't use it.
> Moving such a mature company's codebase to bleeding edge tech is one of the stupidest decisions you can make. Is there some price to be paid to be in the future? I'm sure there will be, as there will be with any non native platform. Whether is will be a deal breaker is to be seen.
Who says about moving now?
Yes they do. https://www.facebook.com/careers/v2/jobs/710998039655439/
"Work closely with our PM and design teams to define feature specifications and build the next generation of products leveraging frameworks such as React & React Native"
The top contributors are Facebook Engineers: https://github.com/facebook/react-native/graphs/contributors...
I'm confused - is this meant to be a disbelief of the survey? "quickly followed by"? Are we seeing the same thing? Did you see the %s? It is significantly lower. Of course there are Xamarin and Cordova developers still. Especially in Asia.
> Who says about moving now?
So wait years and see how everything plays out? So basically you have no solution. Clearly the issues were pressing enough that they needed a more immediate solution. A solution they thought was worth re attempting despite its previous failures.
Oh, I'm sure there are many of them! Just as there are many Visual Basic developers, or people who do everything in Excel.
> So wait years and see how everything plays out? So basically you have no solution. Clearly the issues were pressing enough that they needed a more immediate solution. A solution they thought was worth re attempting despite its previous failures.
No, my solution to the problem would be to rewrite from scratch in native, without waiting for Compose/SwiftUI.
But for some reason it is so much easier to justify rewrite in X, because if it was written in Y, than of course Y is to blame for our shitty practices and lack of developer culture. They neglected best practices, piled crap upon crap and somehow it is native toolkit that is to blame.
> But for some reason it is so much easier to justify rewrite in X, because if it was written in Y, than of course Y is to blame for our shitty practices and lack of developer culture. They neglected best practices, piled crap upon crap and somehow it is native toolkit that is to blame.
Is it really incomprehensible that there's a valid reason to rewrite in X? Now you claim they have shitty practices and no developer culture? What did coinbase do to you? Have you worked there? Did you see their "crap" code? If you don't have anything to back it up, I'll add it to your bs list.
>You clarified it later saying you meant for complex projects but in another comment you claim that they're just a crypto dashboard.
Do I really need to chew everything for you? Crypto dashboard means that they have boring product, I never said it was simple or complex.
> So which is it? Do they have a complex project (not a dashboard) and need something more than react native or they're a dashboard app and react native is fine? The things you say don't line up.\
> Is it really incomprehensible that there's a valid reason to rewrite in X?
Nope, I can imagine that their use case is valid. But for a wrong reasons.
> Now you claim they have shitty practices and no developer culture?
Easy! If React Native application is more performant than your native application, then something really, really, reaaaaally wrong happened. And technology is the last to blame in this case.
> What did coinbase do to you? Have you worked there? Did you see their "crap" code?
What makes you think that if I criticize their technology choice, I have something against them?
> If you don't have anything to back it up, I'll add it to your bs list.
What is this survey supposed to show?
Might Coinbase be rich enough to support native iOS and Android teams? Probably. I'm not trying to litigate Coinbase's decision.
CEO of Shopify praised React Native in January 2020. I guess he was aiming for that postition of Senior CEO there.
You could've just said that you no longer want to invest in mobile talent.
Just opened Coinbase Android app:
* Overall slow
* Jank in transitions
* When dialog pops up and you close it, there's a dangling shadow in the air
Hot garbage, the time you spent on this could be spent on rewriting to proper native standards.
>You could've just said that you no longer want to invest in mobile talent.
How does this even track? They had to retrain their engineers.
I call complete BS with your app experience. I have a Redmi and the app works flawlessly. They seem to have internal data to prove it. They were under no obligation to make the blog post if they didn't think it was successful. If anything they are going against the grain here so they know there are lots of people watching.
I literally listed my experience with the app. And I didn't even create account yet.
> How does this even track? They had to retrain their engineers.
To leverage Web developers, right.
> I call complete BS with your app experience. I have a Redmi and the app works flawlessly.
Which Redmi? I'm testing on Xiaomi Mi A1. It probably works better on my Samsung S10. But then majority of people have phones closer to my Xiaomi.
> They seem to have internal data to prove it. They were under no obligation to make the blog post if they didn't think it was successful. If anything they are going against the grain here so they know there are lots of people watching.
Because the blogpost makes it seem like there are only upsides to technology and the only downside is that it's not fit for brownfield.
I had very bad experience with RN and give my opinion on tech. What's the problem?
That's not all you did. You implied they pay their employees very little, that they didn't do their research before making the switch and called the whole thing an "atrocity" which is heavy to the say the least. That's not an app review.
>Which Redmi? I'm testing on Xiaomi Mi A1. It probably works better on my Samsung S10. But then majority of people have phones closer to my Xiaomi.
I have a Redmi 8 (2019). Most people in the US have something similar to a low budget phone from 2017? I find that extremely difficult to believe. India, probably. US/UK etc? Highly unlikely.
> Because the blogpost makes it seem like there are only upsides to technology and the only downside is that it's not fit for brownfield.
Yes that is their experience so far. They wrote about it and have data to believe it. You don't have either except random anecdotal data and visions about the future.
> I had very bad experience with RN and give my opinion on tech. What's the problem?
Most of your claims don't have merit other than random anecdotal data which you are using to refuse their anecdotal data which is actually a lot less anecdotal that yours because they have many more developers and users.
No implied. I stated it directly. Pay shit and get shit.
> that they didn't do their research before making the switch and called the whole thing an "atrocity" which is heavy to the say the least. That's not an app review.
I'm not an app reviewer, I'm a techie. And sorry that I didn't sugarcoat it enough for your sensitive ears.
> Most people in the US have something similar to a low budget phone from 2017? I find that extremely difficult to believe. India, probably. US/UK etc? Highly unlikely.
I'm sure Electron devs use the same reasoning when developing their stuff. After all, who has 8GB of RAM now?
> Yes that is their experience so far. They wrote about it and have data to believe it. You don't have either except random anecdotal data and visions about the future.
What data, again? "Internal metrics"? They provided literally zero data. The only thing they provided is improved startup on iOS and no data (sic!) from Android.
>Most of your claims don't have merit other than random anecdotal data which you are using to refuse their anecdotal data which is actually a lot less anecdotal that yours because they have many more developers and users.
I never said that my opinion is objective. If you can't handle critique, maybe you should quit online forums.
What are you talking about? Why all this rage? In your previous reply you claim to innocently just talk about your experience with your app. That was a very clear lie and I pointed it out. And now you claim I have sensitive ears? Jeez...
> I'm sure Electron devs use the same reasoning when developing their stuff. After all, who has 8GB of RAM now?
haha way to move the goal posts after you get caught with some other bs you said! First you claimed most people had something similar to your phone so it should be working well on yours. But when I pointed out that this has incorrect assumptions suddenly the goal post is the app should be able to run really well on a a low budget entry device.
> What data, again? "Internal metrics"? They provided literally zero data. The only thing they provided is improved startup on iOS and no data (sic!) from Android.
That's significantly more than anything you've provided. All you have been doing is pointing at random things and saying "I know better than them".
> I never said that my opinion is objective. If you can't handle critique, maybe you should quit online forums.
I've come this far, doesn't a genius to tell whether or not I can handle critique. Question is can you handle being called out without kicking and screaming about knowing better and moving the goal posts of the topic in discussion? TBD
It's a product of a very special place and time where companies were not able to succeed in growing their own locked-down fiefdoms. Microsoft got hammered by the DOJ, AOL gave way to better competition. It was a good time.
About the time the DOJ stopped caring and members of Congress became invested in tech, a new device category arrived on the scene. It took over general purpose computing, becoming perhaps the only computer and gateway to the Internet for many.
Two companies form a duopoly, and they look nothing like the web of the 90's and 00's. App developers have to write and maintain two separate code bases, go through app approval, and have to hold hands to get their software released. It's an asinine retreat from the freedom we once had.
The web, too, has come under attack. The most popular browser is controlled by an ad giant that created an advantageous monoculture, removed ad blocking, and embrace-extended into things like AMP.
We've taken the wrong path.
The W3C should have written a native app spec, described native widget tool kits, and kept the duopoly at bay.
We were all distracted as to what was really going on.
Think about all of the wasted human productivity writing and maintaining two versions of the same software. Instead of working on actual problems, we have to doubly employ to satisfy the powers that be. It's so incredibly dumb that so many work so hard just so that two parties can soak up all the benefit. It's a fluke of evolution that wouldn't have happened if the regulators hadn't fallen asleep at the wheel (or bought into FAANG stock).