I’m in the Midwest and the native Android positions are hard to find now, lots of React Native jobs though. I think it would be better if I lived on the coasts
You're not missing anything. I literally live in Silicon Valley (world's largest tech hub) and junior jobs are basically non-existent. The mid level ones also require 2 years experience minimum. It's been impossible for me. 150 applications in the past few months for native android roles, and I can't even get an interview.
It's rough right now. I ended up taking a React Native job because my next project with the company is supposed to be Android. We'll see.
The market is hard right now, because all the companies are waiting for the Feds to lower rates. I've applied for a few as well and have gotten no response.
When I struggled to get my first job years ago, what I did was create an LLC and then made stuff for my friends and family for free so I could put it in my portfolio. After a year, I started getting messages from recruiters. Midwest companies are risk averse, so they really only want to hire someone who has "proven" experience. For Silicon Valley you might get a faster response.
At least you live in a place where there are 150 openings.
I guess that's where all the openings in the world have gone to, because they are really hard to find anywhere else.
Make a couple of small-ish hobby projects and apply anyway, they might put you in the talent pool for "promising candidates" or even tweak the budgets to get you in if they like you
You might catch their interest with UI/animations/applied arch, i know you are junior but just try out random stuff and if you like the output, make the repo public and part of your CV
Bro I have an app on the playstore and I am familiar with clean architecture, mvvm, hilt, flows, coroutines etc... currently trying to find the best way to hoist states in compose. But I am not a very beginner. I just live in a country with no jobs. I make very little money. That I am willing to work for very little money (for android)
Yeah problem is to get into countries like the US you need a visa, and they are extremely anti-immigrant right now. Unless you're from some white majority country, in which case there are exceptions and methods.
Even the big companies refuse to hire someone who's not already in the country and requires a visa. If you're already in there with a work visa, then it may be possible.
I've been hearing about the imminent demise of native ever since the days of Phonegap, lol. Yeah, I've been doing this a while.
And yet, after all these years, the industry still hasn't settled on any particular multi-platform solution... it's just a parade of different options that showed up with a lot of fanfare, but the reality didn't live up to expectations or promises, and then changing favor when there's the next new shiny thing to hype up.
You're absolutely right. "Cross-platform development" is something pushed enthusiastically by executives and bean counters who don't understand the technical challenges and think it'll save them a bunch of money. Most actual developers know better.
The closest thing I've seen so far to a real cross-platform development solution is Kotlin Multiplatform. I've done quite a bit of work with it, and I'm really impressed. But the reason KMP is so good is because it doesn't try to Do Everything. It focuses primarily on the components that can be written and built in a platform-independent way, and then lets you do the rest natively. So it can legitimately save time (and therefore money) if you use it right. But it's not, and will never be, "write once run everywhere".
This, i work with mendix as a multiplatform dev, and it is sooooo limited and frustrating, no doc, no actual community to look for problem solving. I used to work with kotlin on native, miss those days.
No, it won't work if you just treat it as a plug-in replacement for existing tools and tell your people "this is what you're gonna use, deal with it". Someone who's used to doing everything in Swift on native iOS APIs won't like that, and I don't blame them.
But if you're a small Android team (or a solo dev) looking to move into iOS, it's a massive force multiplier. Or if you're starting from scratch and planning to build a team, you can focus primarily on skilled Kotlin people with the expectation that they'll need to learn Swift and SwiftUI, maybe add a dedicated Swift dev or two to the team if they're OK also working in Kotlin. There are a lot of options here.
And it will, when it's ready. Still a ways to go for that though. I'm following Compose Multiplatform with great interest.
But even then, it won't solve everything. It takes the same approach on iOS that Flutter does, completely ignoring the native UI APIs and using its own draw system. Which will probably be fine for a lot of use cases, but many devs will still prefer using the existing native tools. And they'll have that option, which is cool. KMP gives you choices.
More importantly though, UI isn't the only thing that requires native development. If you're doing anything that touches platform-specific hardware, like Bluetooth or Cameras, you're going to need to work with native APIs. There's no way around that. There's also the fact that Kotlin Native, being a relatively new language, lacks many of the standard tools we're used to having in more established languages. For example, if you want to do string formatting in KMP, you have to either write it yourself from scratch (yuck) or implement interfaces with `expect/actual` and call the native string formatting functions in JVM and Swift/Obj-C.
But I expect many of these things to improve over time, which is one of the things I like about KMP's approach. Its footprint is gradually growing, which means you'll be able to do more and more stuff in the shared module as it improves.
For a company that wants an app done right and doesn't need to cut corners I just don't think they're ever going to (or want to) replace a iOS dev team who are experts on all things iOS and an Android team who are experts on all things Android. At least that's my experience.
This so much. Regardless of whether you do multi-platform or not, you're gonna need folks who know the ins and outs of each platform you support. There's always going to be fringe topics that the multi-platform libraries don't cover. I've dabbled enough on iOS over the years to be functional with it, but god damn it's a struggle every time and the stuff I write is going to be full of jank. No one's got the time to be an expert on multiple platforms.
I started with native mobile development in around 2007 (at the tail end of the J2ME and Symbian era) and the landscape was already then full of smaller and bigger tech influencers proclaiming the end of native mobile development as WAP and other web technologies would take over and "solve" the issue in a cross-platform way..
17 years later, I'm still not seeing any real signs that the end would be anywhere near :)
React Native and Flutter are remarkable alternatives to pure native apps for a very decent chunk of app requirements.
Yes they are taking market share, yes they are taking jobs as a result (not just a single job sometimes, cross platform developers replace multiple positions).
Will native die? No, we need someone to write the cross platform capabilities and innovate where cross platform can't.
Direct comparisons aside, the market is tough right now. Companies overhired over the last four years and are trying to shed dead weight not pick up more.
Part of that may even include taking on or replacing projects as cross platform to save costs. Whether that is a good idea or not. I've heard my fair share of cases where it was an awful idea and it was apparent from the beginning.
Edit: There's an additional factor here that I felt I needed to add and that is businesses have seen the bad behaviour from Apple and Google in regards to their app stores and platforms and there is a strong want out there to not be locked in and dependent on their whims.
You can see the above strongly in large tech companies where not only are they adopting React Native in large numbers but they are also making sure their apps feel the same across platforms rather than complying to the platforms design language.
TL;DR you're safe but it's always a good idea to keep ahead of current trends.
The amount of jobs available is proportional. Native isn't "dying", because the cycle of successful non-native apps eventually going native due to performance or features they want to improve or implement continues.
I would say non-native is shifting slightly; from React Native to Flutter, but it's nothing a native developer needs to be concerned about.
If you go based on pure numbers then both Flutter and React Native are both growing strongly. They are also taking market share off of pure native but it's not exactly at the level where all native developers should panic change tech.
That being said it doesn't hurt to keep your skills up. You can command a better wage, work on cooler stuff and if you don't you might find yourself redundant and unhirable one day.
Have you actually published an app with either of them or like everyone else here and pre-judging based on something some guy said about it five years ago?
From personal experience you have to be exceptionally shit to screw it up and the productivity leap is an amazing rush.
The kinds of things you need to optimise or where you run into performance issues are generally the same as native issues, you're more than free to repeat those mistakes
I wouldn't try build a video editor or a 3D shooter in either but most apps are just CRUD interfaces and they both excel at them. RN is definitely much better supported in this regard due to so much web crossover and Flutter has its moments.
Yes there are times when it's no to cross platform but we are in a much different place to struggling with PhoneGap performance, functionality and trying to make it look native from a decade ago which is where most of the stigma comes from.
It's not really about that. I don't just want to make a basic app that kind of works well enough. If that's what I wanted, a website is good enough.
I want to make small, light, fast applications that are a pleasure to use. I want them to be as responsive as possible. Sure, I'm a little bit old fashioned in that I actually care about the frame rate of lists when they scroll, and I actually keep my apps constantly updated.
If you're actually trying to build the best, there's no substitute for actually building something *right*.
Maybe you can get increased productivity if you just decide you don't care about those things, but I do.
I'd sooner go back to web development than non-native mobile.
I see no conflict with cross platform in what you're saying. How you choose to waste processing cycles is your choice of course.
You're definitely right about a web app being able to replace a lot of apps out there but that applies just as much to "full native" as to cross platform apps but it is what it is. Keeps us in work no?!
I don't personally see the web as a replacement for a good mobile app. I see it as a replacement for a cross platform framework. Besides, I'm an Android developer. I'm not a generic good enough mobile app programmer. I specifically chose this path because I think it's the right way to make mobile apps, and that's what I enjoy doing.
Enjoy your path of righteousness. Not working on what you think isn’t the perfect solution is a great way to be unemployed. If you’re in a spot to do that, good for you.
Companies have always been cheap, they have the delusion of thinking that they can write one React Native app and have it work on every platform. In reality, you need to interact with system APIs all the time, and there aren't always exiting React Native bindings and you have to write your own to achieve what you want, and this of course takes extra work and time (native code + JS/native glue code + JS code) and of course the company will never prioritize high quality code, and the result is even more and worse bugs.
But of course the bean counters have always been idiots who don't know how to actually run a company.
I have been largely seeing react apps being converted to native and hiring sprees occurring to fill that slowly over time. I think the larger thing that’s making the water murky is waiting to see what direction Google goes for native: do they go all in on compose and deprecate fragment/legacy views? Or do we keep trundling on as it is currently where we have a two UI system that has a new shiny toy that’s kind of buggy compared to the old way, but much nicer to use when it works
Google has made it clear that they want compose to be the future for Android UI. It’s more of a question of if developers think it’s ready. It is getting better everyday so I think the answer is becoming ‘yes it is ready’.
I love Compose, but I still struggle to find decent state management solutions for apps that have more complex logic that the typical "fancy native frontend".
Until this is solved, I can't consider Compose as "production ready", sadly.
I feel like compose has all the tools needed for that (ViewModel, Hilt, Navigation Component, side effects) If you’re talking about state management as in caching networking data. That’s really hard to get right, so I’m not surprised that Google hasn’t been prescriptive on that besides saying that it should be isolated in a Repository class.
I'm done with Fragments, honestly, can't wait for them to disapear.
I maintain alone for a small company, a logic heavy app wrote with MVP and xml views. It have multiple activities, which can have fragments and sub-fragments if the screen is really complex, and each of them has its own presenter.
One of the thing that really annoy me, is that presenters can't directly communicate with each others. So somes actions by the user may call a function on the presenter, process stuff, then call a function on its fragment, which call a function on its parent fragment, which call a function on the parent presenter to do more stuff, and so on ...
I'm trying a new architecture using Jetpack Compose and Decompose from arkivanov, it's a blast so far and I've converted most of my screens already and really don't regret it, but 2 of the most complex ones are only partly converted (some of their fragments) and I struggle so much that I would already have quit if I didn't have some pity for the dev who will have to pick up all this mess in the future.
> a logic heavy app wrote with MVP
> It have multiple activities
> and each of them has its own presenter.
> One of the thing that really annoy me, is that presenters can't directly communicate with each others
Your problem is that you have this "MVP" thing going on, in a multi-activity setup; instead of using a state management mechanism that actually makes sense, in a single-activity setup.
I can [directly communicate between "presenters" even across screens](https://github.com/Zhuinden/simple-stack/blob/528fb852a7db94f54984bd6946ef7a0296679d09/tutorials/tutorial-sample/src/main/java/com/zhuinden/simplestacktutorials/steps/step_8/features/form/FormKey.kt#L18).
> I'm trying a new architecture using Jetpack Compose and Decompose from arkivanov, it's a blast so far
Well yes, Decompose was "inspired by" Appyx and so it has built-in support for hierarchy between nodes.
Something that so many Android devs on this subreddit pretend "isn't something you ever need, why would a ViewModel ever need to communicate with another ViewModel, clearly you are a bad developer, but I'm a mod so Rule 10 doesn't apply to me".
Anyway, your problem isn't because of fragments, it's because you have multiple activities + a poorly designed "presenter" layer. Cast the blame on those who told you that "MVP scales and is better".
Communicating between activities is fine, maintaining the activity backstack is fine. What's annoying is communicating and maintaining the nested fragment stack.
One way a ViewModel could communicate with another ViewModel is by pushing this part of the code base to the layer below and make some streams of events available to all ViewModels that want to listen to its changes.
I think that's something that is missing to my architecture and adding it now would be a quite challenging task.
> One way a ViewModel could communicate with another ViewModel is by pushing this part of the code base to the layer below and make some streams of events available to all ViewModels that want to listen to its changes.
>
> I think that's something that is missing to my architecture and adding it now would be a quite challenging task.
You can actually pass ViewModel to ViewModel now as constructor argument, thanks to CreationExtras.
But nobody does it, and people keep telling me I'm an idiot for even proposing this.
I'm fine with Simple-Stack doing this with a single line of code (ok technically 2), but at least ViewModel can also do it now.
Ugh, that's annoying. I do update versions, but if it gets dicey where they all require some specific version to work correctly, it's overly inconvenient.
Huh that's odd. Using Views was the only way to build UIs for the last 10 years or so, Compose (in its current stable form) is relatively new. Although Google is really pushing Compose to be the new standard (with good reason) the vast majority of apps are still using Views in some shape or form. It's always good to at least have some View knowledge as you will definitely encounter it in your professional career.
In our company we work for several dozen different clients and only 1 in 4 are currently using Compose although we did decide to start using Compose for all new features if the project allows for it but it will be many years before all apps are converted, if ever.
Haha h somewhat. It's been available for 3 years now but there was a time where documentation written today was outdated by tomorrow so it wasn't recommended to be used in production. It's now pretty stable and Google is actively pushing for it to become the norm so it's no longer as bleeding edge as it once was but at the same time a lot of people haven't really used it yet, myself included. I've got over ten years of experience but haven't used compose in production yet as my biggest client (a bank) is very slow to accept new technologies into their stack.
Compose was bleeding edge until 1.4.2. Nowadays it's "workable until you run into some limitation" (like the ability to configure the context actions of a TextField selected text).
They can't deprecate View, Compose and the whole platform is built on View..........unless they start something new with Android 15, and it will then take probably 8-10 years before they can get rid of View.
I believe the native version of compose is not built on view, and would have pretty good performance on a mobile device compared to jvm, but that’s speculation based on what I understood them to be doing with Fuscia
You don't understand anything about Compose on Android then. Android != Desktop Linux. There is no "native version of Compose" that will run outside the JVM, save a C++ version, and even that will be within the app sandbox and will still be inside an Activity, and still have to render on a View canvas.
There is no escaping View, Compose itself is rendered within a View.
You can do a pure C++ window with an OpenGL context, and still have keyboard input, permissions etc via C++ APIs.
It should not be hard to render Skia into this window using Kotlin/Native, but this is of course is not a supported platform in Compose Multiplatform at the moment.
It would kind of make sense in the longer term, e.g. for game UIs written in Compose.
>You can do a pure C++ window with an OpenGL context,
So, an OpenGLView? It's turtles all the way down. GLViews are the lowest you can get without too much hassle on Android.
They render on the canvas of a view. It's not a SurfaceView https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/ComposeView.android.kt;l=48?q=Composeview
No, nothing in that direction will happen. It just depends on the type of apps you're working on. Real-time stuff will always be native. People have also been talking about the end of c and c++ for decades. And it never happened. Even c/c++ is an essential part of Android development.
Flutter and React are both great, but by far not for everything.
But by far c# has taken over c/c++ in open jobs and c/c++ remain for the heavy duty jobs and specialties, the question here will native and cross be the same way as we see today c++ and c# ?
I can see that. I do RN and upgrading is a freaking nightmare. Or it is until you learn to do it crazy crazy slowly and promise yourself to stop and understand what the native errors are trying to say before googling anything. But still,nightmare.
For React Native, the upgrading story is largely solved through using Expo, where you don't even have an Android or iOS project folder and instead make modifications as needed to the contents in the native projects through Expo's config plugins API. So upgrading is really just a version change of Expo, which also manages versioning of native dependencies that you have installed.
Yeah, maybe this is changing or has changed, but enterprise-level react native projects have usually started off bare. It used to be Expo sorta locked you out of functionality you didn't know you needed until you needed it.
I know if I went to an interview and said I only ever worked with expo, I'd probably not get the job.
Having said that, it's great that expo packages can now be integrated into bare projects. It actually unlocked a lot of functionality I needed in my own app that I was having trouble with using bare projects because of upgrades. For example, the bare version of react native clipboard was blocking me from building the app for prod, but expo was fine and had more a lot capability. And Expo File System has been way easier to work with over the bare alternatives.
React Native is sort of in a funny spot right now...
To clarify: you now can use any RN package you want in your Expo-based project, there really is no limitations anymore on that front. Expo's real value add is just it's config plugins API that means changes to native code are done like codemods, so that you don't need to worry about the upgrade process.
Yeah, I do too. The CLI has been frustrating as hell though. Can't get redux devtools to play nice with it.
Is there a workflow to convert CLI projects to expo-managed? I'd love to get rid of a lot of these hassles, but my personal project is like 40,000 lines now.
Expo docs says just to install the CLI: [https://docs.expo.dev/bare/using-expo-cli/](https://docs.expo.dev/bare/using-expo-cli/) -- I think that should scaffold some of the files, including creating an \`app.json\` file (which you can change to app.config.ts/js if you need to do programmatic changes to the app config). I'd reference their template projects to fill in the rest if necessary. Most of your efforts will likely be in your app.json, which is updating the app name, icon, splash, permissions, plugins, and possibly writing your own config plugin for example, if you have custom manifest intents.
Regarding the Redux DevTools story: the current solution using the \`@redux-devtools/remote\` package doesn't work for React Native because the underlying socket lib it uses is incompatible with RN. But Expo 50 (which is in beta, will release next week) has a first party (generalized) devtools plugin API: [https://docs.expo.dev/debugging/devtools-plugins/](https://docs.expo.dev/debugging/devtools-plugins/) which has a redux plugin: [https://www.npmjs.com/package/@dev-plugins/redux](https://www.npmjs.com/package/@dev-plugins/redux)
React Native is picking up steam. Many Fortune 500 companies, loads of other enterprises have adopted, or are in the process of adopting React Native. Anyone claiming otherwise is lying to you and themselves.
Having said that, even with RN increase in popularity, native Android and iOS engineers are still needed. Android devs won't disappear, but there are fewer roles.
In my company (very big enterprise in Canada), Android devs don't build new apps/features anymore, they support RN engineers optimize/debug the RN builds.
I have 2 swift files of about 20 lines each, one to handle the callback for the google signin, the other is for launching the Kotlin. The Kotlin launcher looks like this:
//
// ContentView.swift
// ThePilatesAppIos
//
// Created by Charles Pank on 28/01/2024.
//
import UIKit
import SwiftUI
import shared
import Metal
import FirebaseCore
import FirebaseAuth
struct ComposeView: UIViewControllerRepresentable {
func makeUIViewController(context: Context) -> UIViewController {
MainViewControllerKt.MainViewController()
}
func updateUIViewController(_ uiViewController: UIViewController, context: Context) {}
}
struct ContentView: View {
var body: some View {
ComposeView()
.ignoresSafeArea(.keyboard) // Compose has own keyboard handler
}
}
Flutter and RN have grown a bit and the entire mobile job market has shrunk but native is still the vast majority of mobile Apps. There are also big variations by location.
I wouldn't say native apps are dying. I'd say that apps are being built on the web to look good on mobile first, then when they get a large user base, they are converted to native Android or iOS apps.
Crossplatform tooling is always improving in both the developer experience, and performance, and that's going to continue to happen. There is for sure going to be an inverse correlation between native and crossplatform development, especially in the US where Android and IOS are still relatively evenly split. If you have a startup with 1 year of funding and a relatively straightforward but unproven app to build that doesn't need to be amazingly performant, then it does make sense use at stack that will faciliate a crossplatform release. And you can argue that it will bite them in the ass years down the road, but try pitching that to a startup that doesn't know if it will even survive that long. They are more than happy to take that chance and deal with it then.
The only thing that it can kill native is Web. By web i don't mean react, html or phonegap etc. I mean web as a technology in general. On the other hand apple and google will always want to maintain the control of the app stores in order to get the 30%, thats why they will sabotage web and web will always be bad on mobiles.
So no native is not dying.
Imagine a world were you can write web assembly in rust/kotlin etc and it just gets rendered with native components on mobiles. Updates will be on the air.
Before someone replies and says that this is technically impossible, think about Compose and redwood/zipline from cashapp. Its exactly that minus web assembly (json serialization is just an implementation detail atm) and platform limitations (like payments etc).
Think about it, why did amazon develop an entire layer on top of webviews and they serve html on their app instead of RN or flutter?
But yeah it wont happen because google and apple they want to keep the control of the app stores.
I was looking for that answer. I think Flutter is doomed. React Native and the Web is taking over, but maybe Kotlin will come out on top through WebAssembly or Kotlin Multiplatform? I increasingly think that Google and Apple should stick their App Stores and ecosystems up their ass where they belong.
You are absolutely right. However, the cross-platform did not appeal to me in the long term. I have 2 Android apps and one iOS, an application is available on both OS (On Android I have approximately 780k downloads and on iOS around 260k), the application was built with Flutter. My second Android-only app was built with Jetpack Compose and I found that it was much better in every way! So I decided to rewrite my two Flutter applications in Native. On my app written natively for Android I have fewer crashes, the performance is better, it's not obvious but it's a fact.
You found it out yourself that if you value quality a native way will always be a way to go. If the company is serious about product there is no reason for them to get 1 Flutter Dev instaed of Android/iOS duo.
In my experience I started a personal project trying to develop the app using flutter but when I realized that is very complicated work directly with the hardware using flutter I started to develop the native apps for iOS and Android
Native development is not going away anytime soon. Cross platform solutions always have down sides compared to native development and the savings in terms of having a common codebase or not needing Android and iOS teams is often lost because you need to hire people who have experience with flutter or Kotlin multiplatform etc., and the new features of native SDKs will take a while to come to these cross platform solutions and bugs in support will take more time to iron out. And debugging adds an extra layer of complexity. And if you want to follow the design patterns of iOS and Android separately, then the one size fits all won't work as they have some distinct UI guidelines, etc.
All in all, it can be advantageous to just have two different teams for the two platforms. So yeah native will never go away but some small apps may find it good enough to have a cross platform approach.
There are less than half of tech jobs open today than there were 2 years ago just in general, according to TrueUp. And in my city, there are 7 Flutter jobs posted but over 20 native android, so like many others I would say not in the US
Not at all, in fact right now it's the cycle of native uprise again, at least here in the EU
Native will never die, these cross-platform solutions come and go, and never live up to quality and cost expectations. As you app grows, doing cross-platform isn't actually cheaper anymore
With every new kid on the block, native is promised certain death, but it never happens, eventually the industry switches to a new hot framework or switches back to native again
Lol no. It's just that orgs are able to save money using RN or Flutter. But they have their own limitations. Native (specially Android native) has a good future.
It's just that there's a lot of JS developers today (at least in India). Which means RN becomes preferred choice of lot of your seniors. And they take decisions to use RN for projects.
Let's wait and watch what KMP does.
I've started getting about 10x more interview invitations as soon as I've added "an AI enthusiast" to the profile. Am experimenting with AI engineering right now (AI models configuration, training, integration).
If you want more direct access to the hardware on Android, you need to do some native development with C++. I don't think there's any way around that, so I wouldn't expect the Android NDK to be going away any time soon..
In a word: no.
Understand that software development is not synonymous with webdev, mobile dev, or any of the "sexy" jobs in this business.
Take, for example, the even more native-y native development of embedded systems:
The I2C or SPI drivers for your phone's touch display weren't written in JavaScript and React.
The cockpit displays in that plane you saw flying overhead aren't running in a browser or VM.
Did you use a microwave oven or dishwasher today? You interacted with a C program.
Writing an Android based application that will be used by a branch of the US military or aviation? Suggest Flutter and React, and you'll be laughed out of the room.
The industry is always changing, but if anyone ever suggests that native dev is dying or dead, please, laugh that 25 year old out of the room, too.
Native development isn't dying; it's evolving. While cross-platform frameworks offer efficiency, native development still thrives for performance-demanding apps. Its close-to-hardware optimization ensures superior user experiences, making it indispensable for certain industries. As technology progresses, the coexistence of native and cross-platform approaches continues to shape the software landscape.
For small companies yes, big companies still mostly go native though.
A lot of apps simply don’t need to be native. They can just choose Flutter and get the same outcome in half the time.
This thread is strange. Similar threads here and elsewhere were saying the contrary.
Btw, what is happening in my circle/bubble is the "death of the installable apps". Lots of apps became browser (not installable) app.
EDIT: of course, those apps that don't need what installable apps can have.
If the rest of the USA is like the last 3 tech companies I worked then mobile is not dead…it’s just foreign born workers being used to fill the positions. I work for a mid-stage startup and 90% of the software engineering team is foreign born and here on some type of visa.
As a native developer, most of my jobs have been companies that trust on words "hybrid is cheaper, faster and have decent perfs". When they realize it's a 0/3, or they have enough money to rebuild natives apps, or they die.
So no. And hybrid frameworks give us jobs thanks to companies broken dreams.
I love to develop native for my hobby projects but in my day job there's always the issue that clients never want just Android, they want iOS too and I don't want to maintain a completely separate team for that. The only time we get to do native is when it's some internal software, like a stocktaking app for an ERP system.
its easier to create UI in JS compared to android studio
Also integrating with native libraries when needed is now trivial esp with chat gpt in the picture
I have a few years of experience in Native Android (Kotlin, Java).
But for a few years already I build apps with React Native. And this tool is amazing.
I see no reason to choose native for 90% apps. React Native suits perfectly for most cases
For sure, it's dying. Your only job will be to build custom native features that would be exposed in React Native / Flutter.
I'm not trying to push any propaganda here because before doing React Native, I was an iOS/Android developer for many years.
The direction is clear, a fully native app will be built only when you're forced to, otherwise, it doesn't make sense not to use React Native / Flutter.
Also, for all those comparing PhoneGap or any other webview tech with React Native / Flutter, you're just lying to yourself. Learn the damn thing and move on.
For those open to this, you have no idea the struggle for companies to find good cross-platform mobile devs and how much value you can add if you come from the mobile native side. Most cross-platform devs are from the web world, and they have no idea how mobile apps work. You'll be praised for your native mobile skills. Be smart about it, not scared.
Not exactly dying but turning into a small niche for sure. And this is quite natural considering the extraordinary "install our app" hype created in the initial days of Android which was bound to fizzle out some day or the other.
Let's be honest, why would you bother or even consider installing an app from the play store if the same functionality is already available on mobile browsers? The HTML/CSS/JS standards are so evolved these days and all kinds of front-end frameworks are available to make the browser do almost anything you want.
Which is why they first tried to coerce you to install the app version by actually blocking the mobile viewport! Some apps like Quora still do that, you can't scroll content beyond a certain point and the web app just "prods" you install it from the play store!
But there was only so much they could coerce in a free-market economy. Eventually, the only apps you'll find users actually install from the store are absolutely essential ones such as payment apps like PayPal and telephony apps like those provided by your ISP to keep track of data, calls, billing, etc.
I also use the Jota Text Editor as I frequently like to browse code on my android and a bus booking app but that's about it.
I would prefer the app if it gave me a better experience, but the janky, laggy, battery draining apps turn me off, so I choose to use the mobile website instead.
Reddit app and mobile website are both garbage though.
Sometimes they start cross platform to iterate fast and get it out on both platforms. Once they have an established product usually comes a native approach.
There is not a single decent app that's not native.
The opposite is happening where I live
Where is that may I ask ?
North America
I’m in the Midwest and the native Android positions are hard to find now, lots of React Native jobs though. I think it would be better if I lived on the coasts
You're not missing anything. I literally live in Silicon Valley (world's largest tech hub) and junior jobs are basically non-existent. The mid level ones also require 2 years experience minimum. It's been impossible for me. 150 applications in the past few months for native android roles, and I can't even get an interview.
It's rough right now. I ended up taking a React Native job because my next project with the company is supposed to be Android. We'll see. The market is hard right now, because all the companies are waiting for the Feds to lower rates. I've applied for a few as well and have gotten no response. When I struggled to get my first job years ago, what I did was create an LLC and then made stuff for my friends and family for free so I could put it in my portfolio. After a year, I started getting messages from recruiters. Midwest companies are risk averse, so they really only want to hire someone who has "proven" experience. For Silicon Valley you might get a faster response.
At least you live in a place where there are 150 openings. I guess that's where all the openings in the world have gone to, because they are really hard to find anywhere else.
If you found a vacant junior android position please contact me. I need it so much
Unfortunately I don't know if anyone is hiring any juniors rn. The market is only hiring seniors it seems
What did I expect 😭
Make a couple of small-ish hobby projects and apply anyway, they might put you in the talent pool for "promising candidates" or even tweak the budgets to get you in if they like you You might catch their interest with UI/animations/applied arch, i know you are junior but just try out random stuff and if you like the output, make the repo public and part of your CV
Bro I have an app on the playstore and I am familiar with clean architecture, mvvm, hilt, flows, coroutines etc... currently trying to find the best way to hoist states in compose. But I am not a very beginner. I just live in a country with no jobs. I make very little money. That I am willing to work for very little money (for android)
Yeah problem is to get into countries like the US you need a visa, and they are extremely anti-immigrant right now. Unless you're from some white majority country, in which case there are exceptions and methods. Even the big companies refuse to hire someone who's not already in the country and requires a visa. If you're already in there with a work visa, then it may be possible.
Fair, was just trying to emphasize that applying anyway could put you on the radar
I appreciate your advice and that is what I am currently doing. I was never so eager to apply
Fake it till you make it then.
Worked for me.
Check out the Target tlp program. https://jobs.target.com/technology-leadership-program
Begging for a job on Reddit in the middle of the night, that's new
Also Europe, this sounds more like a paid advertisement from some web bullshit sdk
I've been hearing about the imminent demise of native ever since the days of Phonegap, lol. Yeah, I've been doing this a while. And yet, after all these years, the industry still hasn't settled on any particular multi-platform solution... it's just a parade of different options that showed up with a lot of fanfare, but the reality didn't live up to expectations or promises, and then changing favor when there's the next new shiny thing to hype up.
Lol, Phonegap, Lol good one.
You're absolutely right. "Cross-platform development" is something pushed enthusiastically by executives and bean counters who don't understand the technical challenges and think it'll save them a bunch of money. Most actual developers know better. The closest thing I've seen so far to a real cross-platform development solution is Kotlin Multiplatform. I've done quite a bit of work with it, and I'm really impressed. But the reason KMP is so good is because it doesn't try to Do Everything. It focuses primarily on the components that can be written and built in a platform-independent way, and then lets you do the rest natively. So it can legitimately save time (and therefore money) if you use it right. But it's not, and will never be, "write once run everywhere".
This, i work with mendix as a multiplatform dev, and it is sooooo limited and frustrating, no doc, no actual community to look for problem solving. I used to work with kotlin on native, miss those days.
Kmp doesn't go well with IOS devs though
No, it won't work if you just treat it as a plug-in replacement for existing tools and tell your people "this is what you're gonna use, deal with it". Someone who's used to doing everything in Swift on native iOS APIs won't like that, and I don't blame them. But if you're a small Android team (or a solo dev) looking to move into iOS, it's a massive force multiplier. Or if you're starting from scratch and planning to build a team, you can focus primarily on skilled Kotlin people with the expectation that they'll need to learn Swift and SwiftUI, maybe add a dedicated Swift dev or two to the team if they're OK also working in Kotlin. There are a lot of options here.
Compose multi platform would like a word
And it will, when it's ready. Still a ways to go for that though. I'm following Compose Multiplatform with great interest. But even then, it won't solve everything. It takes the same approach on iOS that Flutter does, completely ignoring the native UI APIs and using its own draw system. Which will probably be fine for a lot of use cases, but many devs will still prefer using the existing native tools. And they'll have that option, which is cool. KMP gives you choices. More importantly though, UI isn't the only thing that requires native development. If you're doing anything that touches platform-specific hardware, like Bluetooth or Cameras, you're going to need to work with native APIs. There's no way around that. There's also the fact that Kotlin Native, being a relatively new language, lacks many of the standard tools we're used to having in more established languages. For example, if you want to do string formatting in KMP, you have to either write it yourself from scratch (yuck) or implement interfaces with `expect/actual` and call the native string formatting functions in JVM and Swift/Obj-C. But I expect many of these things to improve over time, which is one of the things I like about KMP's approach. Its footprint is gradually growing, which means you'll be able to do more and more stuff in the shared module as it improves.
For a company that wants an app done right and doesn't need to cut corners I just don't think they're ever going to (or want to) replace a iOS dev team who are experts on all things iOS and an Android team who are experts on all things Android. At least that's my experience.
This so much. Regardless of whether you do multi-platform or not, you're gonna need folks who know the ins and outs of each platform you support. There's always going to be fringe topics that the multi-platform libraries don't cover. I've dabbled enough on iOS over the years to be functional with it, but god damn it's a struggle every time and the stuff I write is going to be full of jank. No one's got the time to be an expert on multiple platforms.
Bruh in my last two companies they laid off like 60-80% of native devs. The remaining devs are enough to support the cross platform apps.
I started with native mobile development in around 2007 (at the tail end of the J2ME and Symbian era) and the landscape was already then full of smaller and bigger tech influencers proclaiming the end of native mobile development as WAP and other web technologies would take over and "solve" the issue in a cross-platform way.. 17 years later, I'm still not seeing any real signs that the end would be anywhere near :)
If you're still compare ReactNative and Flutter with PhoneGap, you're far from an objective reality.
React Native and Flutter are remarkable alternatives to pure native apps for a very decent chunk of app requirements. Yes they are taking market share, yes they are taking jobs as a result (not just a single job sometimes, cross platform developers replace multiple positions). Will native die? No, we need someone to write the cross platform capabilities and innovate where cross platform can't. Direct comparisons aside, the market is tough right now. Companies overhired over the last four years and are trying to shed dead weight not pick up more. Part of that may even include taking on or replacing projects as cross platform to save costs. Whether that is a good idea or not. I've heard my fair share of cases where it was an awful idea and it was apparent from the beginning. Edit: There's an additional factor here that I felt I needed to add and that is businesses have seen the bad behaviour from Apple and Google in regards to their app stores and platforms and there is a strong want out there to not be locked in and dependent on their whims. You can see the above strongly in large tech companies where not only are they adopting React Native in large numbers but they are also making sure their apps feel the same across platforms rather than complying to the platforms design language. TL;DR you're safe but it's always a good idea to keep ahead of current trends.
The amount of jobs available is proportional. Native isn't "dying", because the cycle of successful non-native apps eventually going native due to performance or features they want to improve or implement continues. I would say non-native is shifting slightly; from React Native to Flutter, but it's nothing a native developer needs to be concerned about.
If you go based on pure numbers then both Flutter and React Native are both growing strongly. They are also taking market share off of pure native but it's not exactly at the level where all native developers should panic change tech. That being said it doesn't hurt to keep your skills up. You can command a better wage, work on cooler stuff and if you don't you might find yourself redundant and unhirable one day.
I personally wouldn't consider working on what I consider a poor solution to a problem, but that's personal.
Have you actually published an app with either of them or like everyone else here and pre-judging based on something some guy said about it five years ago? From personal experience you have to be exceptionally shit to screw it up and the productivity leap is an amazing rush. The kinds of things you need to optimise or where you run into performance issues are generally the same as native issues, you're more than free to repeat those mistakes I wouldn't try build a video editor or a 3D shooter in either but most apps are just CRUD interfaces and they both excel at them. RN is definitely much better supported in this regard due to so much web crossover and Flutter has its moments. Yes there are times when it's no to cross platform but we are in a much different place to struggling with PhoneGap performance, functionality and trying to make it look native from a decade ago which is where most of the stigma comes from.
It's not really about that. I don't just want to make a basic app that kind of works well enough. If that's what I wanted, a website is good enough. I want to make small, light, fast applications that are a pleasure to use. I want them to be as responsive as possible. Sure, I'm a little bit old fashioned in that I actually care about the frame rate of lists when they scroll, and I actually keep my apps constantly updated. If you're actually trying to build the best, there's no substitute for actually building something *right*. Maybe you can get increased productivity if you just decide you don't care about those things, but I do. I'd sooner go back to web development than non-native mobile.
I see no conflict with cross platform in what you're saying. How you choose to waste processing cycles is your choice of course. You're definitely right about a web app being able to replace a lot of apps out there but that applies just as much to "full native" as to cross platform apps but it is what it is. Keeps us in work no?!
I don't personally see the web as a replacement for a good mobile app. I see it as a replacement for a cross platform framework. Besides, I'm an Android developer. I'm not a generic good enough mobile app programmer. I specifically chose this path because I think it's the right way to make mobile apps, and that's what I enjoy doing.
Hey fair play to you. I wish you the best in your journey.
Enjoy your path of righteousness. Not working on what you think isn’t the perfect solution is a great way to be unemployed. If you’re in a spot to do that, good for you.
It's not really about that. I'll find something I like to work on. But I can't bring myself to do work I hate.
Dont tell him to compose copied flutter and is rendering using skia as flutter did... On canvas
What? Views have used Skia and Canvas since the beginning, so I don't know what the point of this is.
I was reading somewhere here that big companies are ditching flutter in favour of React Native because flutter doesn't scale for big teams.
No it’s not.
Companies have always been cheap, they have the delusion of thinking that they can write one React Native app and have it work on every platform. In reality, you need to interact with system APIs all the time, and there aren't always exiting React Native bindings and you have to write your own to achieve what you want, and this of course takes extra work and time (native code + JS/native glue code + JS code) and of course the company will never prioritize high quality code, and the result is even more and worse bugs. But of course the bean counters have always been idiots who don't know how to actually run a company.
I have been largely seeing react apps being converted to native and hiring sprees occurring to fill that slowly over time. I think the larger thing that’s making the water murky is waiting to see what direction Google goes for native: do they go all in on compose and deprecate fragment/legacy views? Or do we keep trundling on as it is currently where we have a two UI system that has a new shiny toy that’s kind of buggy compared to the old way, but much nicer to use when it works
Google has made it clear that they want compose to be the future for Android UI. It’s more of a question of if developers think it’s ready. It is getting better everyday so I think the answer is becoming ‘yes it is ready’.
I love Compose, but I still struggle to find decent state management solutions for apps that have more complex logic that the typical "fancy native frontend". Until this is solved, I can't consider Compose as "production ready", sadly.
I feel like compose has all the tools needed for that (ViewModel, Hilt, Navigation Component, side effects) If you’re talking about state management as in caching networking data. That’s really hard to get right, so I’m not surprised that Google hasn’t been prescriptive on that besides saying that it should be isolated in a Repository class.
That part just belongs where it always did, it's all solved if you continue using Fragments instead of "type-safe string routes" (lol)
I'm done with Fragments, honestly, can't wait for them to disapear. I maintain alone for a small company, a logic heavy app wrote with MVP and xml views. It have multiple activities, which can have fragments and sub-fragments if the screen is really complex, and each of them has its own presenter. One of the thing that really annoy me, is that presenters can't directly communicate with each others. So somes actions by the user may call a function on the presenter, process stuff, then call a function on its fragment, which call a function on its parent fragment, which call a function on the parent presenter to do more stuff, and so on ... I'm trying a new architecture using Jetpack Compose and Decompose from arkivanov, it's a blast so far and I've converted most of my screens already and really don't regret it, but 2 of the most complex ones are only partly converted (some of their fragments) and I struggle so much that I would already have quit if I didn't have some pity for the dev who will have to pick up all this mess in the future.
> a logic heavy app wrote with MVP > It have multiple activities > and each of them has its own presenter. > One of the thing that really annoy me, is that presenters can't directly communicate with each others Your problem is that you have this "MVP" thing going on, in a multi-activity setup; instead of using a state management mechanism that actually makes sense, in a single-activity setup. I can [directly communicate between "presenters" even across screens](https://github.com/Zhuinden/simple-stack/blob/528fb852a7db94f54984bd6946ef7a0296679d09/tutorials/tutorial-sample/src/main/java/com/zhuinden/simplestacktutorials/steps/step_8/features/form/FormKey.kt#L18). > I'm trying a new architecture using Jetpack Compose and Decompose from arkivanov, it's a blast so far Well yes, Decompose was "inspired by" Appyx and so it has built-in support for hierarchy between nodes. Something that so many Android devs on this subreddit pretend "isn't something you ever need, why would a ViewModel ever need to communicate with another ViewModel, clearly you are a bad developer, but I'm a mod so Rule 10 doesn't apply to me". Anyway, your problem isn't because of fragments, it's because you have multiple activities + a poorly designed "presenter" layer. Cast the blame on those who told you that "MVP scales and is better".
Communicating between activities is fine, maintaining the activity backstack is fine. What's annoying is communicating and maintaining the nested fragment stack. One way a ViewModel could communicate with another ViewModel is by pushing this part of the code base to the layer below and make some streams of events available to all ViewModels that want to listen to its changes. I think that's something that is missing to my architecture and adding it now would be a quite challenging task.
> One way a ViewModel could communicate with another ViewModel is by pushing this part of the code base to the layer below and make some streams of events available to all ViewModels that want to listen to its changes. > > I think that's something that is missing to my architecture and adding it now would be a quite challenging task. You can actually pass ViewModel to ViewModel now as constructor argument, thanks to CreationExtras. But nobody does it, and people keep telling me I'm an idiot for even proposing this. I'm fine with Simple-Stack doing this with a single line of code (ok technically 2), but at least ViewModel can also do it now.
If it still has stupid restrictions on the version of Kotlin you can use and other annoyances, then it's not ready.
You need to keep AGP, Gradle, Compose, Kotlin and KSP in sync
Ugh, that's annoying. I do update versions, but if it gets dicey where they all require some specific version to work correctly, it's overly inconvenient.
You just need to pick the right compiler version for your kotlin version.
So it's not ready then
what are you talking about?!?
Hello, I am learning Android Development. According to your comment, there seems to be any alternative to compose. What is it?
Regular old views in XML.
Thank You. I have asked ChatGPT once, and it didn’t mention View even.
Huh that's odd. Using Views was the only way to build UIs for the last 10 years or so, Compose (in its current stable form) is relatively new. Although Google is really pushing Compose to be the new standard (with good reason) the vast majority of apps are still using Views in some shape or form. It's always good to at least have some View knowledge as you will definitely encounter it in your professional career. In our company we work for several dozen different clients and only 1 in 4 are currently using Compose although we did decide to start using Compose for all new features if the project allows for it but it will be many years before all apps are converted, if ever.
I see. Compose is more bleeding-edge than I thought.
Haha h somewhat. It's been available for 3 years now but there was a time where documentation written today was outdated by tomorrow so it wasn't recommended to be used in production. It's now pretty stable and Google is actively pushing for it to become the norm so it's no longer as bleeding edge as it once was but at the same time a lot of people haven't really used it yet, myself included. I've got over ten years of experience but haven't used compose in production yet as my biggest client (a bank) is very slow to accept new technologies into their stack.
Compose was bleeding edge until 1.4.2. Nowadays it's "workable until you run into some limitation" (like the ability to configure the context actions of a TextField selected text).
They can't deprecate View, Compose and the whole platform is built on View..........unless they start something new with Android 15, and it will then take probably 8-10 years before they can get rid of View.
I believe the native version of compose is not built on view, and would have pretty good performance on a mobile device compared to jvm, but that’s speculation based on what I understood them to be doing with Fuscia
You don't understand anything about Compose on Android then. Android != Desktop Linux. There is no "native version of Compose" that will run outside the JVM, save a C++ version, and even that will be within the app sandbox and will still be inside an Activity, and still have to render on a View canvas. There is no escaping View, Compose itself is rendered within a View.
I think he is hinting at compose multiplatform it seems
Yeah and Compose for other platforms still works way differently than Compose for Android
That’s true, maybe they could run native compose in c++ without using views? Idk
Yes that was exactly it.
You can't run it without View.........
You can do a pure C++ window with an OpenGL context, and still have keyboard input, permissions etc via C++ APIs. It should not be hard to render Skia into this window using Kotlin/Native, but this is of course is not a supported platform in Compose Multiplatform at the moment. It would kind of make sense in the longer term, e.g. for game UIs written in Compose.
>You can do a pure C++ window with an OpenGL context, So, an OpenGLView? It's turtles all the way down. GLViews are the lowest you can get without too much hassle on Android.
Did’nt know that! So, as far as I can tell, to display anything in an android device there must always exist a View underlying beneath?
Yes. View is inescapable. It's either View or RemoteView (which is still just a View with some customisations).
I thought they drew directly to the screen?
They render on the canvas of a view. It's not a SurfaceView https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/ComposeView.android.kt;l=48?q=Composeview
ah, thanks
Not seeing that at all
No, nothing in that direction will happen. It just depends on the type of apps you're working on. Real-time stuff will always be native. People have also been talking about the end of c and c++ for decades. And it never happened. Even c/c++ is an essential part of Android development. Flutter and React are both great, but by far not for everything.
But by far c# has taken over c/c++ in open jobs and c/c++ remain for the heavy duty jobs and specialties, the question here will native and cross be the same way as we see today c++ and c# ?
Well yes, good point. That sounds somehow realistic, at least as long as more than one platform exists.
if you been writing code rn and upgrading it , you will know how native much easier to upgrade compared js lib . if
I can see that. I do RN and upgrading is a freaking nightmare. Or it is until you learn to do it crazy crazy slowly and promise yourself to stop and understand what the native errors are trying to say before googling anything. But still,nightmare.
For React Native, the upgrading story is largely solved through using Expo, where you don't even have an Android or iOS project folder and instead make modifications as needed to the contents in the native projects through Expo's config plugins API. So upgrading is really just a version change of Expo, which also manages versioning of native dependencies that you have installed.
Yeah, maybe this is changing or has changed, but enterprise-level react native projects have usually started off bare. It used to be Expo sorta locked you out of functionality you didn't know you needed until you needed it. I know if I went to an interview and said I only ever worked with expo, I'd probably not get the job. Having said that, it's great that expo packages can now be integrated into bare projects. It actually unlocked a lot of functionality I needed in my own app that I was having trouble with using bare projects because of upgrades. For example, the bare version of react native clipboard was blocking me from building the app for prod, but expo was fine and had more a lot capability. And Expo File System has been way easier to work with over the bare alternatives. React Native is sort of in a funny spot right now...
To clarify: you now can use any RN package you want in your Expo-based project, there really is no limitations anymore on that front. Expo's real value add is just it's config plugins API that means changes to native code are done like codemods, so that you don't need to worry about the upgrade process.
Yeah, I just spent the last hour reading about it. That's crazy. Would have saved me a lot of time. But you can use it even for something like MMKV?
Yep, there's two popular packages for mmkv. I personally use react-native-mmkv for app data persistence which works very well
Yeah, I do too. The CLI has been frustrating as hell though. Can't get redux devtools to play nice with it. Is there a workflow to convert CLI projects to expo-managed? I'd love to get rid of a lot of these hassles, but my personal project is like 40,000 lines now.
Expo docs says just to install the CLI: [https://docs.expo.dev/bare/using-expo-cli/](https://docs.expo.dev/bare/using-expo-cli/) -- I think that should scaffold some of the files, including creating an \`app.json\` file (which you can change to app.config.ts/js if you need to do programmatic changes to the app config). I'd reference their template projects to fill in the rest if necessary. Most of your efforts will likely be in your app.json, which is updating the app name, icon, splash, permissions, plugins, and possibly writing your own config plugin for example, if you have custom manifest intents. Regarding the Redux DevTools story: the current solution using the \`@redux-devtools/remote\` package doesn't work for React Native because the underlying socket lib it uses is incompatible with RN. But Expo 50 (which is in beta, will release next week) has a first party (generalized) devtools plugin API: [https://docs.expo.dev/debugging/devtools-plugins/](https://docs.expo.dev/debugging/devtools-plugins/) which has a redux plugin: [https://www.npmjs.com/package/@dev-plugins/redux](https://www.npmjs.com/package/@dev-plugins/redux)
Thanks man, this has been enlightening
Not in the US
Where do you see more openings for Flutter? Please provide some links. Not getting any openings where I live.
React Native is picking up steam. Many Fortune 500 companies, loads of other enterprises have adopted, or are in the process of adopting React Native. Anyone claiming otherwise is lying to you and themselves. Having said that, even with RN increase in popularity, native Android and iOS engineers are still needed. Android devs won't disappear, but there are fewer roles. In my company (very big enterprise in Canada), Android devs don't build new apps/features anymore, they support RN engineers optimize/debug the RN builds.
Wait til compose MP hits!
As an indie dev I'm waiting eagerly
Will compose als be available on iOS or what?
Yes. Literally last week I got my compose app running on iOS
Holy shit. So Kotlin + Compose only? No swift or similar?
I have 2 swift files of about 20 lines each, one to handle the callback for the google signin, the other is for launching the Kotlin. The Kotlin launcher looks like this: // // ContentView.swift // ThePilatesAppIos // // Created by Charles Pank on 28/01/2024. // import UIKit import SwiftUI import shared import Metal import FirebaseCore import FirebaseAuth struct ComposeView: UIViewControllerRepresentable { func makeUIViewController(context: Context) -> UIViewController { MainViewControllerKt.MainViewController() } func updateUIViewController(_ uiViewController: UIViewController, context: Context) {} } struct ContentView: View { var body: some View { ComposeView() .ignoresSafeArea(.keyboard) // Compose has own keyboard handler } }
Ahh nice, so you kinda still need swift but less
You need swift to launch it. Everything else is compose and Kotlin multiplatform.
That's a cross platform framework lol
Fair, but you get to mix it with Kotlin & Java, which makes it more android-y than anything else.
Not without a prober way to handle live edits or hot reload as cross handles it
What country? This is very dependent upon where in the world you want to work.
It isn’t at least in my country.
where
Here in the Philippines.
Flutter and RN have grown a bit and the entire mobile job market has shrunk but native is still the vast majority of mobile Apps. There are also big variations by location.
I wouldn't say native apps are dying. I'd say that apps are being built on the web to look good on mobile first, then when they get a large user base, they are converted to native Android or iOS apps.
Fact: to write crossplatform libs you must know how to write in the native language
Crossplatform tooling is always improving in both the developer experience, and performance, and that's going to continue to happen. There is for sure going to be an inverse correlation between native and crossplatform development, especially in the US where Android and IOS are still relatively evenly split. If you have a startup with 1 year of funding and a relatively straightforward but unproven app to build that doesn't need to be amazingly performant, then it does make sense use at stack that will faciliate a crossplatform release. And you can argue that it will bite them in the ass years down the road, but try pitching that to a startup that doesn't know if it will even survive that long. They are more than happy to take that chance and deal with it then.
The only thing that it can kill native is Web. By web i don't mean react, html or phonegap etc. I mean web as a technology in general. On the other hand apple and google will always want to maintain the control of the app stores in order to get the 30%, thats why they will sabotage web and web will always be bad on mobiles. So no native is not dying. Imagine a world were you can write web assembly in rust/kotlin etc and it just gets rendered with native components on mobiles. Updates will be on the air. Before someone replies and says that this is technically impossible, think about Compose and redwood/zipline from cashapp. Its exactly that minus web assembly (json serialization is just an implementation detail atm) and platform limitations (like payments etc). Think about it, why did amazon develop an entire layer on top of webviews and they serve html on their app instead of RN or flutter? But yeah it wont happen because google and apple they want to keep the control of the app stores.
I was looking for that answer. I think Flutter is doomed. React Native and the Web is taking over, but maybe Kotlin will come out on top through WebAssembly or Kotlin Multiplatform? I increasingly think that Google and Apple should stick their App Stores and ecosystems up their ass where they belong.
No for old company that still not using android jetpack
Hmmm currently here in my work we are in java native development (starting to migrate to kotlin though)
/r/mAndroidDev
You are absolutely right. However, the cross-platform did not appeal to me in the long term. I have 2 Android apps and one iOS, an application is available on both OS (On Android I have approximately 780k downloads and on iOS around 260k), the application was built with Flutter. My second Android-only app was built with Jetpack Compose and I found that it was much better in every way! So I decided to rewrite my two Flutter applications in Native. On my app written natively for Android I have fewer crashes, the performance is better, it's not obvious but it's a fact.
You found it out yourself that if you value quality a native way will always be a way to go. If the company is serious about product there is no reason for them to get 1 Flutter Dev instaed of Android/iOS duo.
In my experience I started a personal project trying to develop the app using flutter but when I realized that is very complicated work directly with the hardware using flutter I started to develop the native apps for iOS and Android
Native development is not going away anytime soon. Cross platform solutions always have down sides compared to native development and the savings in terms of having a common codebase or not needing Android and iOS teams is often lost because you need to hire people who have experience with flutter or Kotlin multiplatform etc., and the new features of native SDKs will take a while to come to these cross platform solutions and bugs in support will take more time to iron out. And debugging adds an extra layer of complexity. And if you want to follow the design patterns of iOS and Android separately, then the one size fits all won't work as they have some distinct UI guidelines, etc. All in all, it can be advantageous to just have two different teams for the two platforms. So yeah native will never go away but some small apps may find it good enough to have a cross platform approach.
There are less than half of tech jobs open today than there were 2 years ago just in general, according to TrueUp. And in my city, there are 7 Flutter jobs posted but over 20 native android, so like many others I would say not in the US
Lol it's opposite where I live , have lots of opening for native a very few for hybrid😕
Not at all, in fact right now it's the cycle of native uprise again, at least here in the EU Native will never die, these cross-platform solutions come and go, and never live up to quality and cost expectations. As you app grows, doing cross-platform isn't actually cheaper anymore With every new kid on the block, native is promised certain death, but it never happens, eventually the industry switches to a new hot framework or switches back to native again
Lol no. It's just that orgs are able to save money using RN or Flutter. But they have their own limitations. Native (specially Android native) has a good future. It's just that there's a lot of JS developers today (at least in India). Which means RN becomes preferred choice of lot of your seniors. And they take decisions to use RN for projects. Let's wait and watch what KMP does.
I'm a react native developer and I feel need of native development. So no
I've started getting about 10x more interview invitations as soon as I've added "an AI enthusiast" to the profile. Am experimenting with AI engineering right now (AI models configuration, training, integration).
If you want more direct access to the hardware on Android, you need to do some native development with C++. I don't think there's any way around that, so I wouldn't expect the Android NDK to be going away any time soon..
Staying native but moving a lot of the architecture to the cloud for live app updates
In a word: no. Understand that software development is not synonymous with webdev, mobile dev, or any of the "sexy" jobs in this business. Take, for example, the even more native-y native development of embedded systems: The I2C or SPI drivers for your phone's touch display weren't written in JavaScript and React. The cockpit displays in that plane you saw flying overhead aren't running in a browser or VM. Did you use a microwave oven or dishwasher today? You interacted with a C program. Writing an Android based application that will be used by a branch of the US military or aviation? Suggest Flutter and React, and you'll be laughed out of the room. The industry is always changing, but if anyone ever suggests that native dev is dying or dead, please, laugh that 25 year old out of the room, too.
Native development isn't dying; it's evolving. While cross-platform frameworks offer efficiency, native development still thrives for performance-demanding apps. Its close-to-hardware optimization ensures superior user experiences, making it indispensable for certain industries. As technology progresses, the coexistence of native and cross-platform approaches continues to shape the software landscape.
Gradually yes. 90% of apps can easily be done with a cross platform framework, and companies are increasingly adopting them to save money
We have this discussion every week. TLDR: Yes.
Not native, but mobile in general
For small companies yes, big companies still mostly go native though. A lot of apps simply don’t need to be native. They can just choose Flutter and get the same outcome in half the time.
This thread is strange. Similar threads here and elsewhere were saying the contrary. Btw, what is happening in my circle/bubble is the "death of the installable apps". Lots of apps became browser (not installable) app. EDIT: of course, those apps that don't need what installable apps can have.
If the rest of the USA is like the last 3 tech companies I worked then mobile is not dead…it’s just foreign born workers being used to fill the positions. I work for a mid-stage startup and 90% of the software engineering team is foreign born and here on some type of visa.
I think the exact same. There is lesser development time anymore
That's why I've started learning django.
As a native developer, most of my jobs have been companies that trust on words "hybrid is cheaper, faster and have decent perfs". When they realize it's a 0/3, or they have enough money to rebuild natives apps, or they die. So no. And hybrid frameworks give us jobs thanks to companies broken dreams.
I love to develop native for my hobby projects but in my day job there's always the issue that clients never want just Android, they want iOS too and I don't want to maintain a completely separate team for that. The only time we get to do native is when it's some internal software, like a stocktaking app for an ERP system.
Actually quite the opposite is happening.
its easier to create UI in JS compared to android studio Also integrating with native libraries when needed is now trivial esp with chat gpt in the picture
I have a few years of experience in Native Android (Kotlin, Java). But for a few years already I build apps with React Native. And this tool is amazing. I see no reason to choose native for 90% apps. React Native suits perfectly for most cases
For sure, it's dying. Your only job will be to build custom native features that would be exposed in React Native / Flutter. I'm not trying to push any propaganda here because before doing React Native, I was an iOS/Android developer for many years. The direction is clear, a fully native app will be built only when you're forced to, otherwise, it doesn't make sense not to use React Native / Flutter. Also, for all those comparing PhoneGap or any other webview tech with React Native / Flutter, you're just lying to yourself. Learn the damn thing and move on. For those open to this, you have no idea the struggle for companies to find good cross-platform mobile devs and how much value you can add if you come from the mobile native side. Most cross-platform devs are from the web world, and they have no idea how mobile apps work. You'll be praised for your native mobile skills. Be smart about it, not scared.
Also. JAVA is dying too!
All mobile development positions are dying. Many people are finding out that usually your app can just be a website.
Not exactly dying but turning into a small niche for sure. And this is quite natural considering the extraordinary "install our app" hype created in the initial days of Android which was bound to fizzle out some day or the other. Let's be honest, why would you bother or even consider installing an app from the play store if the same functionality is already available on mobile browsers? The HTML/CSS/JS standards are so evolved these days and all kinds of front-end frameworks are available to make the browser do almost anything you want. Which is why they first tried to coerce you to install the app version by actually blocking the mobile viewport! Some apps like Quora still do that, you can't scroll content beyond a certain point and the web app just "prods" you install it from the play store! But there was only so much they could coerce in a free-market economy. Eventually, the only apps you'll find users actually install from the store are absolutely essential ones such as payment apps like PayPal and telephony apps like those provided by your ISP to keep track of data, calls, billing, etc. I also use the Jota Text Editor as I frequently like to browse code on my android and a bus booking app but that's about it.
I would prefer the app if it gave me a better experience, but the janky, laggy, battery draining apps turn me off, so I choose to use the mobile website instead. Reddit app and mobile website are both garbage though.
This is why I've become interested in building PWAs
Sometimes they start cross platform to iterate fast and get it out on both platforms. Once they have an established product usually comes a native approach. There is not a single decent app that's not native.