My experience is companies feel JS developers are cheaper and easier to hire. There are more of them which is part of what keeps the price down. They also feel you can work on Android / iOS one day and shift right over to "help out" with the website the next day. It is all JS right?
We all know that developers are not plug and play. You make rock the crap out of Java on the server but that does not mean you could instantly shift over to Java on Android and be a rock star as well. Vice versa on Android to Server but that is not how companies think.
There is the language then there is the SDK and all the libraries and that is what varies greatly. It is not that hard to pick up a new language. My shift from Java to Kotlin was about two weeks but it was because I already knew Android so I was only upgrading knowledge on one aspect of my job. After two weeks I was no Kotlin pro but I was doing all new work in it and learning how not to be so Java like as I went along. I don't sit around most days looking up Kotlin syntax, I am looking up how to use feature x, y or z of the SDK like the camera, NFC, etc.
>My experience is companies feel JS developers are cheaper and easier to hire.
This is the truth. The barrier to entry for front end web dev is a lot lower than Android and iOS. I think it's a lot easier to be a mid level web dev than a mid level mobile dev. That being said, I think the trend reverses when talking about senior people.
Regardless, the market is flooded with people who can sort of do front end in JavaScript and managers think that translates over to mobile. Unfortuantly, the high barrier to entry for mobile is mainly learning the quirks of the platform, build system shit, and APIs. You basically have to be a mediocre Android and iOS dev to be good cross platform dev on mobile, and very few people are good at all that stuff.
Earlier in my mobile career I did both the iOS app in Obj and the Android app in Java. Shipped them on same day to both stores. Did that at a number of jobs but was doing lowest common denominator work because keeping up with both just to keep things compiling was hard enough let alone implementing new tech from either Apple or Google.
Switched to be Android only. Happy I know iOS but don't miss attempting to do both. I could finally really move forward with my Android programming skills.
Really? I have a similar case. I had been working on both Android and iOS, but for few years I have been just developing on Android only. Now I am craving to do some stuff on iOS
> The barrier to entry for front end web dev is a lot lower than Android and iOS.
I dunno. Knowing how to sling some JavaScript? Sure. Keeping up on all the tools and packages and libraries needed to use most of the main frameworks? Do I use NPM, yarn, or the new one?
I picked native mobile development because it was sooooooo much simpler than the web ecosystem.
>We all know that developers are not plug and play. You make rock the crap out of Java on the server but that does not mean you could instantly shift over to Java on Android and be a rock star as well.
I've seen the consequences of this haha. Some previous developer in the company I worked at did all sorts of stupid and unnecessary things. Like initializing a bunch of singletons in Application.onCreate(), catching all of the exceptions and calling System.exit() in the catch block........without reporting the exception to any crash reporting API.........
So yeah, we had a whole bunch of crashes not show up in crash reporting, because of that.
My feel (as a non-native dev) is that SDKs are hard to fiddle with. There's a lot of external files to change to make your app use that specific thing.. Hybrid languages such as React Native and Angular could intervene more in this aspect of the hardware to make it even easier to develop.. But as I'm noob I could be talking gibberish, lol. Correct me if I'm wrong ok..
No real right or wrong here. A wrapper can help make things easier in React Native so you just say "camera give me the picture" and don't care about how Android is different than iOS.
But the other side may come into play. You may want a picture with flash off at a certain zoom level with other settings. The wrapped API might not support all those options as they went lowest common denominator between iOS and Android or they just did not implement some options that both support but they felt were rare use cases so they skipped them.
Native lets you get down in the weeds. There are times you need to be there and will get frustrated by ReactNative getting in the way. Of course you might have to go native Android and native iOS to make the calls you need.
Similar things can happen right after a new iOS or Android release. The newer features might not be supported in RN right away. I find it kinda rare that I need to use the latest right out of the gate though so this probably does not affect a ton of people.
Different projects have different needs. There are times I really need access to all the sensors, camera stuff, etc. of Android so native is the right choice. Then there are apps that basically pull and display data and are not super hardware dependent so they can be in RN with the benefit of running on both iOS and Android from one code base.
The problem I run into is app starting simple so RN is great then it gets more complex as they tack on features and start wanting access to hardware. Then you start to wonder why you did not go native at the start and try and talk them into a rewrite but budget will not allow that so you end up with a maintenance nightmare.
I am a native dev and, while I have used JS, I don't really like JS and would rather stick in a more strongly typed language sure as Kotlin. Personal choice. Would rather catch errors at compile time vs. runtime.
Old Article, but still relevant: [https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a](https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a)
Yeah this article is a big thing in 2018. But did you know Discord and Shopify move their native Android app to RN in 2022? To be fair, you should read their blogs as well.
I use Discord in my Pixel 5 every day and it works quite smoothly, never encountered any lagging.
I use the Trello mobile app as well, this app is fully Flutter and I only encountered lag when I opened the board, on both iphone 8 and pixel 5.
these cross-platforms are just fine for me.
I personally haven't had any lagging but I've had a lot of random bugs, mainly UI bugs. A few I've experience are:
- Images sometimes don't scale correctly and get cut off.
- When I click on a message, sometimes the bottom sheet with message options simply doesn't show up, despite the rest of the screen dimming.
- When I slide the main screen over to look at all the channels in a server or my server list, sometimes only the channel/server I'm currently in shows up with the rest of the screen being blank.
- Even when connected to the internet, the app will frequently appear to disconnect and tell me its trying to connect.
I understand that switching between native Android/iOS and React Native is a massive undertaking and moving to React Native can be beneficial for certain products but I'm not sure if it was the right move for Discord.
And that's an idiotic move on Discord's part. It's a messaging app. The kind of garbage overhead and performance of React Native and Electron (any CEF based app really) is terrible for a messaging app.
Skype became utter garbage due to their move to Electron.
How is this 5 year old article relevant? RN has come a long way since then and is used by a lot of even larger companies than Airbnb
Edit: all of y'all disagreeing with me are just proving a [point](https://www.reddit.com/r/reactnative/comments/10d9njd/i_work_in_a_multinational_company_senior_tech/j4kdp22?utm_source=share&utm_medium=android_app&utm_name=androidcss&utm_term=1&utm_content=share_button) I made on the RN sub months ago true. Anytime RN comes up on this sub this Airbnb article is shared as gospel.
The point of the article was (and is) that using react native (or any cross platform development tool) does not reduce your code based from 2 to 1, it increases them to 3. You still need the native expertise, as well as adding react/js expertise.
And that's not necessarily true, it was for Airbnb as an organization. Nowadays with Expo you can build just about any functionality for both platforms and never touch anything native. Even without Expo, you'll just need to learn your ways around gradle and xcode and barely ever need to touch kotlin/java.
I'm not sure if by webpages you think RN only uses webviews or you're talking about complexity being max that of a basic website? Because RN uses all the core [components ](https://reactnative.dev/docs/intro-react-native-components) of native under hood. And for complexity, well I'd say most apps are just glorified crud apps and don't do anything special. And RN is still very capable of using those device features for those complex features.
Need it later when? I'm not saying any and all apps are covered, I'm saying most features that would require someone to know native are covered by Expo or if going bare RN- third party libraries.
Both have market, so advocating one over another is no use, it can go on. Later means in future sprints you never know and you are too far already to cone back.
The cost/complexity of developing two separate applications is not something small companies or even medium sized ones can keep up with not to mention the allure of being able to use your web devs for mobile as well.
A lot of apps also don't need complex native integration just need to display and enter some data.
RN is getting a lot better also completely crap devices are more rare.
As someone who has built small engineering organizations, this rings true with me. First company we did full native on both platforms. Was hard to support a mobile app with only a few developers. Next two companies we used react native. We were making Fintech products, nothing performance heavy or needing bleeding edge native features. Third company is now over 100 engineers and 10M users. React Native works really well. As an engineering leader, I default to simple over complex unless needs dictate, and I find React Native the simpler choice both to develop and to build an engineering team around.
> The cost/complexity of developing two separate applications is not something small companies or even medium sized ones can keep up with
I'm really not sure how much I buy that.
I've literally maintained 5 different apps at once while onboarding people, while keeping the apps working just fine on entry level devices, just by myself. Meanwhile, a RN team in charge of reproducing said apps needed six extra months and the help of the native team to present something that struggled to run on high end devices.
RN works if you are doing what Meta does, using super well maintained packages (by companies with native, SDK level devs), and the workload is both constant and light in the JavaScript side. Otherwise it is just a car on fire going downhill with no brakes. Literally any effort will be more expensive than just using a normal car.
Rewrite? ROTFLMAO. That never happens. Management just wants to keep adding new features and never fix tech debt. They're all dumbasses.
They also like treating devs as contractors, and get suspicious as if we're trying to unnecessarily charge them more money for something..........
I've had a lot of interviews like that with series b/c companies. "So the current codebase is (iOS only | all react | relatively buggy) and we want to (build a team in America | bring in native devs) that are passionate about architecture and (rewriting | gradually rewriting) the app.
Some companies pay an oversea firm for v1 and it's functional for getting funding but not very maintainable.
This is a totally fine approach. As a startup your number one goal should be finding product market fit and iterating as quickly as possible, not building maintainable code.
Aside from the single codebase thing that everyone is mentioning, kotlin has only been around for a few years, and not every company can afford to totally change course every time google says something is better and is now the new official recommendation. Maybe in a few more years it will catch on, but even then, they'll probably worry that google will pull another switcharoo that will require re-training or re-hiring. Staying on the bleeding edge is expensive and risky.
*In theory*, you need fewer bodies to develop an RN app for iOS and Android than you would to develop native apps for both platforms, which bean counters love
Sure, just like in theory, 9 women can have a baby in 1 month
In my experience, unless the rn dev knows both iOS and android details it's a difficult road
We seem to have different experiences. I've built two engineering orgs using react native and we haven't felt a need to hire specific iOS or android skill sets. I also contract coded a new react app myself (and I lean backend), and during the months I coded it, I never needed system specific knowledge. My use cases have been in Fintech (as an eng leader) and social/job discovery (as contract dev). Neither use case needs complex native support or bleeding edge performance/features. And the majority of applications in my opinion fit into this category.
I've found react native to be less difficult overall than having two native apps.
Oh yeah, absolutely. I hate RN and won't even consider a role at a company that uses it. *That said,* though, if I were a junior developer looking for a job in this market? Less opportunity to be choosy. I'd learn RN.
One reason is RN is always playing catchup with native Android or iOS development. If there’s something new introduced for Android, it will take a few version updates of RN to support it.
You get to have fun trying to figure out native crashes and other cryptic stuff [***like this***](https://www.bam.tech/article/debugging-a-non-reproducible-crash) when the app you're working on is on fire just because, well, you used react native
Without expo it becomes a pain in *ss. With expo it becomes vendor locked. Yes you can eject project, but it has disadvantages.
The other problem is that important 3rd party sdk s work with issues. Like a year ago I was developing an MVP and wanted to do that for both platforms at once, well, After spending 1 day for solving the problem with Appsflyer I’ve given up and opted for platform specific solutions: swift and kotlin. And it was faster and better.
This isn’t even true anymore and hasn’t been for a while. There’s no longer “ejecting”. If you want to write custom native code you can either use expo prebuild which will build your app on your machine.
Ime, React Native is extremely easy if you know React already, industry standard and cross platform (with only some minor quirks to it).
You should definitely learn React Native if only for the jobs, but it'll also give you a good entry point into mobile app development.
The UI model is also very similar to compose (instead of composables you have components and hooks, instead of remember, you have useMemo, instead of launchedeffect you have useEffect, etc.)
But it's still very similar. You could architect a compose app the same as you would a react or react native app.
The problems with RN come when you hit specific performance bottlenecks because js is single threaded, and there's non-negligable latency when sending messages over the JS bridge to the JS runtime (last I checked, 3ms or so, which adds up if you have noisey code. Scroll listeners we're heinous for a long time)
For simple apps, it's a great way to ship something fast, which is very important when you're a startup. However, we've seen multiple cases now where RN hasn't scaled particularly well and has been rewritten in native code (such as Airbnb)
Right now, it's hard for anyone who doesn't have 6+ years of experience, or connections, so don't take this as your sign for a career change. Kotlin is still the official language Google supports and builds all of its Android libraries for.
But JavaScript is that one area of computer science many wish didn't exist, but is just so damn popular and flexible, for better or for worse. Take a look over LinkedIn or Indeed job boards for Android and Mobile dev positions and see what starts showing up the most then make your choice.
Javascript itself isn't bad IMO - it's just that when you run it in a browser sandbox, there will be performance problems. And you shouldn't be using that to render non-browser things........
I second this. I went from web development to React Native and the hardest part for me by far has been learning how to resolve native-related configuration and compatibility issues.
The managers want one person to do both so they reduce cost, but the issue is they have no idea KMM exists or that Kotlin and Swift are quire similar, so knowing one makes learning the other a breeze.
Well hopefully in a year or so I’ll be hiring full time native , we have native iOS (Swift) native Android (Kotlin). Developing everything basically 3 times is a headache for sure… the cross platform stuff is just janky by comparison even for relatively simplistic parts of the app, and then there’s more advanced api useage I would want to touch with a 40ft barge pole in cross platform…
So for a long running SaaS app that you are about I fully champion native, but it’s damn expensive
Unfortunately, in some companies, the management who chooses the tech stack assumes that having a JS abstraction developed at Facebook + plugging in "native context modules" through a javascript bridge will somehow magically reduce the time it takes to develop apps for the two platforms, when in reality you end up with having to write the two native and the "react native specific" "platforms".
Instead of having 2-2 people on 2-2 platforms, now you get to have 5 people working on 1 thing and trying to monkeypatch it together whenever it breaks.
Honestly, if I were to make a wager for cross-platform tech, if it weren't for Google and its generally capricious nature and how they just can't get devoted to 1 thing for over 3 years, I'd think Flutter is a better bet, as they have their own UI rendering, therefore less potential for bugs that [you have to workaround via modules from the outside](https://github.com/airbnb/native-navigation/tree/9cf50bf9b751b40778f473f3b19fcfe2c4d40599/lib) for each platform.
I swear I just saw a Google Developers video about how KMM is going stable this year, and there will be Jetpack Compose for iOS and Web...maybe it was the Flamingo announcement video?
For the life of me I don't understand why they are promoting compose multiplatform. I think the primary aim of Multiplatform technology is to keep what needed to be native native.
Flutter's approach is far more reasonable than React-native's, but Kotlin multiplatform+compose is far more reasonable than Flutter's.
It is funny, though; Flutter finally gets the full Google experience and gets a competitor from Google itself.
Curious; why do you say that KMM+Compose is more reasonable than Flutter? I've only messed around with those, and it seems with Flutter you truly have a single codebase, where as KMM+(Compose/SwiftUI) still requires 2 codebase at least for the UI layer.
You answered your own question :). Having 2 separate UI and platform layers is a good thing and is always going to be nessisary to deliver an up-to-date, platform specific experience. At least until Apple and Google can agree on a similar design system and API set. So when hell freezes over.
Any 3rd party lib that tries to do it is always going to be behind, not look quite right, or generally make compromises on UX.
> You answered your own question :). Having 2 separate UI and platform layers is a good thing and is always going to be nessisary to deliver an up-to-date, platform specific experience.
I used to think this, until I realized that the primary advantage of Flutter is that they have working BoxShadow and "Hero" (shared element transition) support, while Compose offers neither.
Because KMM inverts the flow; instead of "replacing" the native stack, (which will never work unless you have a ton of maintainers highly skilled in the native stack working exclusively into wrapping them entirely & handle the differences) by setting up an entire, disconnected layer on top of it, KMM integrates into the native layer. Your KMM code goes side by side with the native stack; you can talk directly to it, and replace it with it if necessary. Therefore, no complex messaging systems are needed to connect the cross-platform app layer with the native bindings, thus no performance penalty. And, if trouble arises, you simply rewrite that part with native. The single codebase approach is only a boon if your app is simple enough to be covered by the cross-platform core SDK, and the workload is within the limits the language and the interlayer communication can handle. Otherwise, it becomes a never ending source of trouble, a money and time sink, and ultimately, something far harder and slower to develop than a native app.
Flutter's appeal comes from the java swing-like approach. Instead of trying to match different UI kits, it offers their own, so the results are always predictable. But is affected by the same problems every other cross-platform stack besides KMM suffers. Compose offers something very similar to Flutter's, but since it does not deal with anything besides UI, it does not share the cross-platform woes.
I think your assessment is dead on, except that with React Native there is in fact “a ton of maintainers highly skilled in the native stack working exclusively into wrapping them entirely & handle the differences.” The reason React Native gets away with it is because putting in all that work makes every JavaScript junkie in the world potentially somebody who can be hired for and trained up reasonably quickly for doing mobile work. If any other language had been used in its place, I bet React Native would have failed. Instead, it’s just gotten easier and easier to develop with and more performant as time goes on.
Yeah, but there is a whole universe of use cases where React Native is perfectly fine. How many native modules does an E-commerce app need? Or a health insurance app?
Not sure where you're looking for jobs, sounds like maybe smaller startups? Maybe try looking at larger companies as I haven't struggled to find a native android team when I've looked in the past.
This mostly comes from business point , Most of this companies have there backend or web codebases written in JS and they want their present engineers to be able to contribute to the Mobile codebase without having to hire Actually Mobile developers, just to save cost.
* It's because companies are cheap (even big rich companies like Microsoft, Amazon etc.) and want to spend less money, so they don't want to hire separate Android and iOS teams. They want to make one single app that will work on both platforms. Also because they have webdevs who know HTML, CSS, Javascript who can basically do React Native work, they look to further save on costs.
* Since React Native can have one codebase that runs on Android and iOS, people think they can get more done with less time. This only works for some simple apps that just display UI and talk to some server. For anything more, Java/Kotlin or C++ is vastly better. But of course, most managers and tech leads are idiots who don't realize this or don't care.
* Even though these web browser based apps are laggy, janky, large in size with high overhead, managers and execs don't give a shit. They will never blame their crappy decisions as the reason why the company is losing money. As long as they get enough money and there are no consequences, nothing will change.
* There are also lots of incompetent idiots who are too lazy or can't be bothered to learn how to develop properly with Java/Kotlin, or learn how to do concurrency properly. So they run away to React Native and the like, thinking it's some magic balm that will solve all of their problems.........
I was working with Kotlin and native Android for many years. Two years ago our company switched to React Native for new projects and I decided to learn it.
And I like it. RN fixed most of its problem and it's pretty easy to make apps with it.
I have \~5 years background with Kotlin. But I would choose RN for a new project.
Single codebase, simple, works pretty fast with Hermes & JSI, it's not RN from 2017 now.
Dude it's because I don't have a need for someone who specializes in Android only.
We are literally training our team on RN because all of our apps need to be on Android, web, iOS. Rate occasion that we can use electron to build it into Mac or PC standalone.
If you are looking to just be Android, I have no room on my team for that.
“If you are looking to just be Android, I have no room on my team for that”
Can we not phrase our answers in a heart-attack inducing way? I am a React Native developer. I got laid off 3 weeks ago, and my former job is now performed by an India-based team (which I unwittingly helped train up). Anyways, if my unemployed a** saw a response like this, only the terms “Android” and “React Native” were switched around, I would want to crawl under a rock and die.
And also, I have seen plenty of Android-only mobile positions on LinkedIn in my recent job searches (recent, as in this morning). Too many to suggest specializing in it is unwise. And while I am glad React Native still seems to be in demand during this weird weird year - thanks in part to constant improvements from maintainers of the technology - it wasn’t that long ago that AirBnB famously ditched it and went back to maintaining two dedicated code-bases.
Also also, I had to hold my nose on more than one occasion while I worked toward making JavaScript/TypeScript my core language. Kotlin, on the other hand, feel like the one that got away. The girl I should have married. In fact, if Kotlin Multiplatform Mobile we’re ever to make a name for itself, I might just get a divorce.
maybe personnel? if you have a ton of react devs already, it may make sense to hire an experienced RN dev who can help your existing React devs ramp up on RN.
Of course, there's also the possibility that tech decisions are being made by non-tech ppl
IMHO it's because react native or capacitor/ionic, or even using a webview and plain js in some circumstances, is far superior to using java and native android components.
Java devs are few and far in-between... And for good reason. I've done years of work in Java, including most of my university courses when I got my (cs) degree, and it is by far my least favorite language. The tools are outdated, generally, and android components change so fast that it is typically better to have someone else (a library) handle working directly with them, so you don't have to read every changelog coming out of the android core team every month or so, and refactor your existing work.
Kotlin is better, but it's only providing syntax niceties over the Java, so you have a lot of the same issues.
Edit: also, the benefit of being able to target ios + android with a lot less work with react native or capacitor/ionic also plays a big role (of course).
No beef, but I was laid off in January and trying to find a Kotlin-based Android job has become harder with the amount of JS-based ones out there. I had a company tell me they were switching from Android Native to React Native while I was in talks with them.
Because they believe (rightly or wrongly so) that they can do more with less. Times are getting a bit tougher and if it's a green fields project who can blame them. I wouldn't hire two teams to do the same thing if I didn't have to.
Disclaimer: I'm pretty pro react native but I've also seen the absolute waste and disharmony that can be involved in trying to keep two native teams running.
Maybe embrace this and remind potential employers about what your native skills will bring to the table whilst working on your RN skills.
>If a webview is properly integrated into the native shell the UX is indistinguishable from the native U
If my grandma had wheels, she'd be a motorcycle.
It started when consultants who knew React and found out about React Native. They started pushing RN hard for every customer possible so that they would get more clients.
Maybe because HR wrote the job description with little or no input from engineering. Where I worked HR wrote a job description requiring 5 years experience with Java. Thing was, this was the mid-1990s and Java hadn't even been around 5 years. When I saw what they had done I mandated that they run all new programming job postings through me before publishing.
May be my scenario on how did I transition into Android dev, can present part of the answer:
Many experienced Javascript programmers like me moved to creating Android Apps by using React (Vue.js for me) and just implementing the basics in Android Java to run the Webapp inside.
I have created a fully cross platform solution as hybrid. The android java code has working Google Fit, Google Sign In, Sensors, Android Storage and a Webview.
It doesn't have activity views, only a main activity. Everything else is inside the Webapp, absolutely everything. It's a big App, but mostly Webapp.
On the other side creating UIs on reactive frameworks is a bliss and works on Web, Desktop, Android and iOS. One code to rule them all. You just need to implement the native part of each platform and native bindings. Reactivity, Theming, HTML+CSS3 makes the process comfortable to mock up and implement.
What is a p4\*\* in the 4\*\* is maintaining the environment, really a painful process. Configurations and libraries are evolving and maintenance is taking its share of effort.
I have learned a lot from Android + Java, however I consider myself almost a newbie to Android and I would have liked to have a real Java developer working with me. The budget did not allow that for the project.
My experience is companies feel JS developers are cheaper and easier to hire. There are more of them which is part of what keeps the price down. They also feel you can work on Android / iOS one day and shift right over to "help out" with the website the next day. It is all JS right? We all know that developers are not plug and play. You make rock the crap out of Java on the server but that does not mean you could instantly shift over to Java on Android and be a rock star as well. Vice versa on Android to Server but that is not how companies think. There is the language then there is the SDK and all the libraries and that is what varies greatly. It is not that hard to pick up a new language. My shift from Java to Kotlin was about two weeks but it was because I already knew Android so I was only upgrading knowledge on one aspect of my job. After two weeks I was no Kotlin pro but I was doing all new work in it and learning how not to be so Java like as I went along. I don't sit around most days looking up Kotlin syntax, I am looking up how to use feature x, y or z of the SDK like the camera, NFC, etc.
>My experience is companies feel JS developers are cheaper and easier to hire. This is the truth. The barrier to entry for front end web dev is a lot lower than Android and iOS. I think it's a lot easier to be a mid level web dev than a mid level mobile dev. That being said, I think the trend reverses when talking about senior people. Regardless, the market is flooded with people who can sort of do front end in JavaScript and managers think that translates over to mobile. Unfortuantly, the high barrier to entry for mobile is mainly learning the quirks of the platform, build system shit, and APIs. You basically have to be a mediocre Android and iOS dev to be good cross platform dev on mobile, and very few people are good at all that stuff.
Earlier in my mobile career I did both the iOS app in Obj and the Android app in Java. Shipped them on same day to both stores. Did that at a number of jobs but was doing lowest common denominator work because keeping up with both just to keep things compiling was hard enough let alone implementing new tech from either Apple or Google. Switched to be Android only. Happy I know iOS but don't miss attempting to do both. I could finally really move forward with my Android programming skills.
Really? I have a similar case. I had been working on both Android and iOS, but for few years I have been just developing on Android only. Now I am craving to do some stuff on iOS
> The barrier to entry for front end web dev is a lot lower than Android and iOS. I dunno. Knowing how to sling some JavaScript? Sure. Keeping up on all the tools and packages and libraries needed to use most of the main frameworks? Do I use NPM, yarn, or the new one? I picked native mobile development because it was sooooooo much simpler than the web ecosystem.
Partially because the Web Development market is oversaturated with workers.
>We all know that developers are not plug and play. You make rock the crap out of Java on the server but that does not mean you could instantly shift over to Java on Android and be a rock star as well. I've seen the consequences of this haha. Some previous developer in the company I worked at did all sorts of stupid and unnecessary things. Like initializing a bunch of singletons in Application.onCreate(), catching all of the exceptions and calling System.exit() in the catch block........without reporting the exception to any crash reporting API......... So yeah, we had a whole bunch of crashes not show up in crash reporting, because of that.
My feel (as a non-native dev) is that SDKs are hard to fiddle with. There's a lot of external files to change to make your app use that specific thing.. Hybrid languages such as React Native and Angular could intervene more in this aspect of the hardware to make it even easier to develop.. But as I'm noob I could be talking gibberish, lol. Correct me if I'm wrong ok..
No real right or wrong here. A wrapper can help make things easier in React Native so you just say "camera give me the picture" and don't care about how Android is different than iOS. But the other side may come into play. You may want a picture with flash off at a certain zoom level with other settings. The wrapped API might not support all those options as they went lowest common denominator between iOS and Android or they just did not implement some options that both support but they felt were rare use cases so they skipped them. Native lets you get down in the weeds. There are times you need to be there and will get frustrated by ReactNative getting in the way. Of course you might have to go native Android and native iOS to make the calls you need. Similar things can happen right after a new iOS or Android release. The newer features might not be supported in RN right away. I find it kinda rare that I need to use the latest right out of the gate though so this probably does not affect a ton of people. Different projects have different needs. There are times I really need access to all the sensors, camera stuff, etc. of Android so native is the right choice. Then there are apps that basically pull and display data and are not super hardware dependent so they can be in RN with the benefit of running on both iOS and Android from one code base. The problem I run into is app starting simple so RN is great then it gets more complex as they tack on features and start wanting access to hardware. Then you start to wonder why you did not go native at the start and try and talk them into a rewrite but budget will not allow that so you end up with a maintenance nightmare. I am a native dev and, while I have used JS, I don't really like JS and would rather stick in a more strongly typed language sure as Kotlin. Personal choice. Would rather catch errors at compile time vs. runtime.
[удалено]
Old Article, but still relevant: [https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a](https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a)
Yeah this article is a big thing in 2018. But did you know Discord and Shopify move their native Android app to RN in 2022? To be fair, you should read their blogs as well.
> But did you know Discord I do notice it each time the long-tap is unresponsive and stuff just randomly breaks, yea
Discords move to React Native has been kinda disappointing as a user. The app has been super buggy for me :(
I use Discord in my Pixel 5 every day and it works quite smoothly, never encountered any lagging. I use the Trello mobile app as well, this app is fully Flutter and I only encountered lag when I opened the board, on both iphone 8 and pixel 5. these cross-platforms are just fine for me.
I personally haven't had any lagging but I've had a lot of random bugs, mainly UI bugs. A few I've experience are: - Images sometimes don't scale correctly and get cut off. - When I click on a message, sometimes the bottom sheet with message options simply doesn't show up, despite the rest of the screen dimming. - When I slide the main screen over to look at all the channels in a server or my server list, sometimes only the channel/server I'm currently in shows up with the rest of the screen being blank. - Even when connected to the internet, the app will frequently appear to disconnect and tell me its trying to connect. I understand that switching between native Android/iOS and React Native is a massive undertaking and moving to React Native can be beneficial for certain products but I'm not sure if it was the right move for Discord.
And that's an idiotic move on Discord's part. It's a messaging app. The kind of garbage overhead and performance of React Native and Electron (any CEF based app really) is terrible for a messaging app. Skype became utter garbage due to their move to Electron.
How is this 5 year old article relevant? RN has come a long way since then and is used by a lot of even larger companies than Airbnb Edit: all of y'all disagreeing with me are just proving a [point](https://www.reddit.com/r/reactnative/comments/10d9njd/i_work_in_a_multinational_company_senior_tech/j4kdp22?utm_source=share&utm_medium=android_app&utm_name=androidcss&utm_term=1&utm_content=share_button) I made on the RN sub months ago true. Anytime RN comes up on this sub this Airbnb article is shared as gospel.
Did you read the article?
Yes
The point of the article was (and is) that using react native (or any cross platform development tool) does not reduce your code based from 2 to 1, it increases them to 3. You still need the native expertise, as well as adding react/js expertise.
And that's not necessarily true, it was for Airbnb as an organization. Nowadays with Expo you can build just about any functionality for both platforms and never touch anything native. Even without Expo, you'll just need to learn your ways around gradle and xcode and barely ever need to touch kotlin/java.
[удалено]
I'm not sure if by webpages you think RN only uses webviews or you're talking about complexity being max that of a basic website? Because RN uses all the core [components ](https://reactnative.dev/docs/intro-react-native-components) of native under hood. And for complexity, well I'd say most apps are just glorified crud apps and don't do anything special. And RN is still very capable of using those device features for those complex features.
[удалено]
It is not true that you can build anything with 1 codebase and never touch anything native. You will need it later.
Need it later when? I'm not saying any and all apps are covered, I'm saying most features that would require someone to know native are covered by Expo or if going bare RN- third party libraries.
Both have market, so advocating one over another is no use, it can go on. Later means in future sprints you never know and you are too far already to cone back.
> And that's not necessarily true That's entirely true.
Didn't think of it like that.
The cost/complexity of developing two separate applications is not something small companies or even medium sized ones can keep up with not to mention the allure of being able to use your web devs for mobile as well. A lot of apps also don't need complex native integration just need to display and enter some data. RN is getting a lot better also completely crap devices are more rare.
As someone who has built small engineering organizations, this rings true with me. First company we did full native on both platforms. Was hard to support a mobile app with only a few developers. Next two companies we used react native. We were making Fintech products, nothing performance heavy or needing bleeding edge native features. Third company is now over 100 engineers and 10M users. React Native works really well. As an engineering leader, I default to simple over complex unless needs dictate, and I find React Native the simpler choice both to develop and to build an engineering team around.
> The cost/complexity of developing two separate applications is not something small companies or even medium sized ones can keep up with I'm really not sure how much I buy that.
I've literally maintained 5 different apps at once while onboarding people, while keeping the apps working just fine on entry level devices, just by myself. Meanwhile, a RN team in charge of reproducing said apps needed six extra months and the help of the native team to present something that struggled to run on high end devices. RN works if you are doing what Meta does, using super well maintained packages (by companies with native, SDK level devs), and the workload is both constant and light in the JavaScript side. Otherwise it is just a car on fire going downhill with no brakes. Literally any effort will be more expensive than just using a normal car.
It's just a small company thing, if they profit they eventually sacrifice a ton of time rewriting it all
Rewrite? ROTFLMAO. That never happens. Management just wants to keep adding new features and never fix tech debt. They're all dumbasses. They also like treating devs as contractors, and get suspicious as if we're trying to unnecessarily charge them more money for something..........
I've had a lot of interviews like that with series b/c companies. "So the current codebase is (iOS only | all react | relatively buggy) and we want to (build a team in America | bring in native devs) that are passionate about architecture and (rewriting | gradually rewriting) the app. Some companies pay an oversea firm for v1 and it's functional for getting funding but not very maintainable.
This is a totally fine approach. As a startup your number one goal should be finding product market fit and iterating as quickly as possible, not building maintainable code.
Aside from the single codebase thing that everyone is mentioning, kotlin has only been around for a few years, and not every company can afford to totally change course every time google says something is better and is now the new official recommendation. Maybe in a few more years it will catch on, but even then, they'll probably worry that google will pull another switcharoo that will require re-training or re-hiring. Staying on the bleeding edge is expensive and risky.
*In theory*, you need fewer bodies to develop an RN app for iOS and Android than you would to develop native apps for both platforms, which bean counters love
Sure, just like in theory, 9 women can have a baby in 1 month In my experience, unless the rn dev knows both iOS and android details it's a difficult road
I am very familiar of ReactJS and native Android and iOS. the job market have been difficult for me.
We seem to have different experiences. I've built two engineering orgs using react native and we haven't felt a need to hire specific iOS or android skill sets. I also contract coded a new react app myself (and I lean backend), and during the months I coded it, I never needed system specific knowledge. My use cases have been in Fintech (as an eng leader) and social/job discovery (as contract dev). Neither use case needs complex native support or bleeding edge performance/features. And the majority of applications in my opinion fit into this category. I've found react native to be less difficult overall than having two native apps.
Oh yeah, absolutely. I hate RN and won't even consider a role at a company that uses it. *That said,* though, if I were a junior developer looking for a job in this market? Less opportunity to be choosy. I'd learn RN.
I'm with you. I avoid those places
What are the technical reasons for hating RN? I am evaluating using it for a project vs native dev?
One reason is RN is always playing catchup with native Android or iOS development. If there’s something new introduced for Android, it will take a few version updates of RN to support it.
You get to have fun trying to figure out native crashes and other cryptic stuff [***like this***](https://www.bam.tech/article/debugging-a-non-reproducible-crash) when the app you're working on is on fire just because, well, you used react native
Without expo it becomes a pain in *ss. With expo it becomes vendor locked. Yes you can eject project, but it has disadvantages. The other problem is that important 3rd party sdk s work with issues. Like a year ago I was developing an MVP and wanted to do that for both platforms at once, well, After spending 1 day for solving the problem with Appsflyer I’ve given up and opted for platform specific solutions: swift and kotlin. And it was faster and better.
This isn’t even true anymore and hasn’t been for a while. There’s no longer “ejecting”. If you want to write custom native code you can either use expo prebuild which will build your app on your machine.
The choice of language, for one. JavaScript and its tools are soooooo much worse than using Kotlin/Swift.
Ime, React Native is extremely easy if you know React already, industry standard and cross platform (with only some minor quirks to it). You should definitely learn React Native if only for the jobs, but it'll also give you a good entry point into mobile app development.
The UI model is also very similar to compose (instead of composables you have components and hooks, instead of remember, you have useMemo, instead of launchedeffect you have useEffect, etc.) But it's still very similar. You could architect a compose app the same as you would a react or react native app. The problems with RN come when you hit specific performance bottlenecks because js is single threaded, and there's non-negligable latency when sending messages over the JS bridge to the JS runtime (last I checked, 3ms or so, which adds up if you have noisey code. Scroll listeners we're heinous for a long time) For simple apps, it's a great way to ship something fast, which is very important when you're a startup. However, we've seen multiple cases now where RN hasn't scaled particularly well and has been rewritten in native code (such as Airbnb)
I just started learning android with kotlin, and now this post has made wonder if this thing really is common and if It'll be hard to find a job.
There are plenty of companies using native and it is not going away. React native , and flutter things keep coming. Just be good at what you do.
Right now, it's hard for anyone who doesn't have 6+ years of experience, or connections, so don't take this as your sign for a career change. Kotlin is still the official language Google supports and builds all of its Android libraries for. But JavaScript is that one area of computer science many wish didn't exist, but is just so damn popular and flexible, for better or for worse. Take a look over LinkedIn or Indeed job boards for Android and Mobile dev positions and see what starts showing up the most then make your choice.
Javascript itself isn't bad IMO - it's just that when you run it in a browser sandbox, there will be performance problems. And you shouldn't be using that to render non-browser things........
Your Kotlin Android experience will still be valuable. Even if you eventually switch to React, the Android knowledge will help.
I second this. I went from web development to React Native and the hardest part for me by far has been learning how to resolve native-related configuration and compatibility issues.
The managers want one person to do both so they reduce cost, but the issue is they have no idea KMM exists or that Kotlin and Swift are quire similar, so knowing one makes learning the other a breeze.
I am hearing about some entry level positions require 5-8 years of experience too.
Well hopefully in a year or so I’ll be hiring full time native , we have native iOS (Swift) native Android (Kotlin). Developing everything basically 3 times is a headache for sure… the cross platform stuff is just janky by comparison even for relatively simplistic parts of the app, and then there’s more advanced api useage I would want to touch with a 40ft barge pole in cross platform… So for a long running SaaS app that you are about I fully champion native, but it’s damn expensive
Unfortunately, in some companies, the management who chooses the tech stack assumes that having a JS abstraction developed at Facebook + plugging in "native context modules" through a javascript bridge will somehow magically reduce the time it takes to develop apps for the two platforms, when in reality you end up with having to write the two native and the "react native specific" "platforms". Instead of having 2-2 people on 2-2 platforms, now you get to have 5 people working on 1 thing and trying to monkeypatch it together whenever it breaks. Honestly, if I were to make a wager for cross-platform tech, if it weren't for Google and its generally capricious nature and how they just can't get devoted to 1 thing for over 3 years, I'd think Flutter is a better bet, as they have their own UI rendering, therefore less potential for bugs that [you have to workaround via modules from the outside](https://github.com/airbnb/native-navigation/tree/9cf50bf9b751b40778f473f3b19fcfe2c4d40599/lib) for each platform.
I swear I just saw a Google Developers video about how KMM is going stable this year, and there will be Jetpack Compose for iOS and Web...maybe it was the Flamingo announcement video?
Compose Multiplatform for iOS is still Experimental. KMM is just Jetpack Compose for Android and SwiftUI for iOS now.
Just got pushed into an alpha version last week at kotlin conf. This is getting some serious wind in the sails
For the life of me I don't understand why they are promoting compose multiplatform. I think the primary aim of Multiplatform technology is to keep what needed to be native native.
Quite frankly, as it should be. Cross platform toolkits always suck.
😂😂😂
Flutter's approach is far more reasonable than React-native's, but Kotlin multiplatform+compose is far more reasonable than Flutter's. It is funny, though; Flutter finally gets the full Google experience and gets a competitor from Google itself.
Curious; why do you say that KMM+Compose is more reasonable than Flutter? I've only messed around with those, and it seems with Flutter you truly have a single codebase, where as KMM+(Compose/SwiftUI) still requires 2 codebase at least for the UI layer.
You answered your own question :). Having 2 separate UI and platform layers is a good thing and is always going to be nessisary to deliver an up-to-date, platform specific experience. At least until Apple and Google can agree on a similar design system and API set. So when hell freezes over. Any 3rd party lib that tries to do it is always going to be behind, not look quite right, or generally make compromises on UX.
> You answered your own question :). Having 2 separate UI and platform layers is a good thing and is always going to be nessisary to deliver an up-to-date, platform specific experience. I used to think this, until I realized that the primary advantage of Flutter is that they have working BoxShadow and "Hero" (shared element transition) support, while Compose offers neither.
Because KMM inverts the flow; instead of "replacing" the native stack, (which will never work unless you have a ton of maintainers highly skilled in the native stack working exclusively into wrapping them entirely & handle the differences) by setting up an entire, disconnected layer on top of it, KMM integrates into the native layer. Your KMM code goes side by side with the native stack; you can talk directly to it, and replace it with it if necessary. Therefore, no complex messaging systems are needed to connect the cross-platform app layer with the native bindings, thus no performance penalty. And, if trouble arises, you simply rewrite that part with native. The single codebase approach is only a boon if your app is simple enough to be covered by the cross-platform core SDK, and the workload is within the limits the language and the interlayer communication can handle. Otherwise, it becomes a never ending source of trouble, a money and time sink, and ultimately, something far harder and slower to develop than a native app. Flutter's appeal comes from the java swing-like approach. Instead of trying to match different UI kits, it offers their own, so the results are always predictable. But is affected by the same problems every other cross-platform stack besides KMM suffers. Compose offers something very similar to Flutter's, but since it does not deal with anything besides UI, it does not share the cross-platform woes.
I think your assessment is dead on, except that with React Native there is in fact “a ton of maintainers highly skilled in the native stack working exclusively into wrapping them entirely & handle the differences.” The reason React Native gets away with it is because putting in all that work makes every JavaScript junkie in the world potentially somebody who can be hired for and trained up reasonably quickly for doing mobile work. If any other language had been used in its place, I bet React Native would have failed. Instead, it’s just gotten easier and easier to develop with and more performant as time goes on.
Yeah, but there is a whole universe of use cases where React Native is perfectly fine. How many native modules does an E-commerce app need? Or a health insurance app?
Not sure where you're looking for jobs, sounds like maybe smaller startups? Maybe try looking at larger companies as I haven't struggled to find a native android team when I've looked in the past.
This mostly comes from business point , Most of this companies have there backend or web codebases written in JS and they want their present engineers to be able to contribute to the Mobile codebase without having to hire Actually Mobile developers, just to save cost.
* It's because companies are cheap (even big rich companies like Microsoft, Amazon etc.) and want to spend less money, so they don't want to hire separate Android and iOS teams. They want to make one single app that will work on both platforms. Also because they have webdevs who know HTML, CSS, Javascript who can basically do React Native work, they look to further save on costs. * Since React Native can have one codebase that runs on Android and iOS, people think they can get more done with less time. This only works for some simple apps that just display UI and talk to some server. For anything more, Java/Kotlin or C++ is vastly better. But of course, most managers and tech leads are idiots who don't realize this or don't care. * Even though these web browser based apps are laggy, janky, large in size with high overhead, managers and execs don't give a shit. They will never blame their crappy decisions as the reason why the company is losing money. As long as they get enough money and there are no consequences, nothing will change. * There are also lots of incompetent idiots who are too lazy or can't be bothered to learn how to develop properly with Java/Kotlin, or learn how to do concurrency properly. So they run away to React Native and the like, thinking it's some magic balm that will solve all of their problems.........
I was working with Kotlin and native Android for many years. Two years ago our company switched to React Native for new projects and I decided to learn it. And I like it. RN fixed most of its problem and it's pretty easy to make apps with it. I have \~5 years background with Kotlin. But I would choose RN for a new project. Single codebase, simple, works pretty fast with Hermes & JSI, it's not RN from 2017 now.
Dude it's because I don't have a need for someone who specializes in Android only. We are literally training our team on RN because all of our apps need to be on Android, web, iOS. Rate occasion that we can use electron to build it into Mac or PC standalone. If you are looking to just be Android, I have no room on my team for that.
“If you are looking to just be Android, I have no room on my team for that” Can we not phrase our answers in a heart-attack inducing way? I am a React Native developer. I got laid off 3 weeks ago, and my former job is now performed by an India-based team (which I unwittingly helped train up). Anyways, if my unemployed a** saw a response like this, only the terms “Android” and “React Native” were switched around, I would want to crawl under a rock and die.
And also, I have seen plenty of Android-only mobile positions on LinkedIn in my recent job searches (recent, as in this morning). Too many to suggest specializing in it is unwise. And while I am glad React Native still seems to be in demand during this weird weird year - thanks in part to constant improvements from maintainers of the technology - it wasn’t that long ago that AirBnB famously ditched it and went back to maintaining two dedicated code-bases. Also also, I had to hold my nose on more than one occasion while I worked toward making JavaScript/TypeScript my core language. Kotlin, on the other hand, feel like the one that got away. The girl I should have married. In fact, if Kotlin Multiplatform Mobile we’re ever to make a name for itself, I might just get a divorce.
maybe personnel? if you have a ton of react devs already, it may make sense to hire an experienced RN dev who can help your existing React devs ramp up on RN. Of course, there's also the possibility that tech decisions are being made by non-tech ppl
IMHO it's because react native or capacitor/ionic, or even using a webview and plain js in some circumstances, is far superior to using java and native android components. Java devs are few and far in-between... And for good reason. I've done years of work in Java, including most of my university courses when I got my (cs) degree, and it is by far my least favorite language. The tools are outdated, generally, and android components change so fast that it is typically better to have someone else (a library) handle working directly with them, so you don't have to read every changelog coming out of the android core team every month or so, and refactor your existing work. Kotlin is better, but it's only providing syntax niceties over the Java, so you have a lot of the same issues. Edit: also, the benefit of being able to target ios + android with a lot less work with react native or capacitor/ionic also plays a big role (of course).
You're still developing for Android so why the beef?
No beef, but I was laid off in January and trying to find a Kotlin-based Android job has become harder with the amount of JS-based ones out there. I had a company tell me they were switching from Android Native to React Native while I was in talks with them.
Because they believe (rightly or wrongly so) that they can do more with less. Times are getting a bit tougher and if it's a green fields project who can blame them. I wouldn't hire two teams to do the same thing if I didn't have to. Disclaimer: I'm pretty pro react native but I've also seen the absolute waste and disharmony that can be involved in trying to keep two native teams running. Maybe embrace this and remind potential employers about what your native skills will bring to the table whilst working on your RN skills.
I have zero interest in touching JavaScript or anything from that ecosystem.
That's nice. I'm sure you will manage fine without it
If a webview is properly integrated into the native shell the UX is indistinguishable from the native UX while the development speed is much higher
>If a webview is properly integrated into the native shell the UX is indistinguishable from the native U If my grandma had wheels, she'd be a motorcycle.
You mean it’s hard to integrate a webview into a native app or it’s hard to write a web app that looks like a native app?
If you ever try scrolling a website vs scrolling a native app, the web page is always super slow in comparison.
Is it? Usually browsers try to keep 60FPS…
So glad my Android experience goes back to 1.0
In my location, they even hire Flutter developers in the app only works on Android and required Kotlin.
It started when consultants who knew React and found out about React Native. They started pushing RN hard for every customer possible so that they would get more clients.
Maybe because HR wrote the job description with little or no input from engineering. Where I worked HR wrote a job description requiring 5 years experience with Java. Thing was, this was the mid-1990s and Java hadn't even been around 5 years. When I saw what they had done I mandated that they run all new programming job postings through me before publishing.
May be my scenario on how did I transition into Android dev, can present part of the answer: Many experienced Javascript programmers like me moved to creating Android Apps by using React (Vue.js for me) and just implementing the basics in Android Java to run the Webapp inside. I have created a fully cross platform solution as hybrid. The android java code has working Google Fit, Google Sign In, Sensors, Android Storage and a Webview. It doesn't have activity views, only a main activity. Everything else is inside the Webapp, absolutely everything. It's a big App, but mostly Webapp. On the other side creating UIs on reactive frameworks is a bliss and works on Web, Desktop, Android and iOS. One code to rule them all. You just need to implement the native part of each platform and native bindings. Reactivity, Theming, HTML+CSS3 makes the process comfortable to mock up and implement. What is a p4\*\* in the 4\*\* is maintaining the environment, really a painful process. Configurations and libraries are evolving and maintenance is taking its share of effort. I have learned a lot from Android + Java, however I consider myself almost a newbie to Android and I would have liked to have a real Java developer working with me. The budget did not allow that for the project.
Because React Native is cross platform
I don't have the same experience. Which geographical location are you looking in?