31–40 of 91 posts
As an Android developer, KMP is the bigger development. It seems mature enough now that if I want to build an app as a single dev I feel confident that I could get the iOS version out at the same time. They seem to be avoiding the mistakes of Xamarin and Flutter
Other than LLMs the biggest change has been moving to Kotlin Compose from the old Android XML-based layout system.
LLMs are something I use often now and I'm not thrilled about this but it is what it is. I'm one of those people who prefer to hand craft code in a deep flow state so the move to LLMs has made me enjoy my job less, but it is hard to argue against the productivity gains so I try to be grateful that there was a long period where what I enjoyed doing and getting paid for were so well aligned. It isn't like my job is horrible now, it is just not quite as fun.
While I use agentic AI quite a bit, I don't "vibe code". Much of the software I currently write falls under various medical compliance systems (FDA, EMA, etc) and they rightfully expect us to understand and be personally responsible for the quality of the code we produce. Even absent the regulations, I still find it absolutely wild people ship code (associated with their name in any way) without looking at it.
I've been working for the same company for the past 5 years so I have little idea of how the career/interview side of things have changed recently. From anecdotal reports it seems like a giant mess of ghost jobs and competing with massive piles of AI-generated and AI-filtered resumes these days unless you have a strong network from the before times.
A lot of people in this thread seem to be worried about discoverability, I'm sure AI has made that worse but it was already a huge problem to get random apps noticed even before AI. The apps I currently work on professionally support external hardware devices that the apps control via bluetooth, so app store discoverability isn't a big concern (you buy the external device, then the documentation points you to the app store downloads).
I have also done app development as a non-commercial side project, writing a PvP game/stat tracking app for the game Destiny 2, this is a free app that has about a thousand users on iOS and a few hundred on Android, written in Kotlin Multiplatform. That started pre-LLM and I've continued to avoid using LLMs while working on it to make sure I can remember how to code sans LLMs, though the fact that Destiny 2 is stopping new development as of June 9th means I'm unlikely to put much effort into it going forward.
My perspective: I've been supporting and working with Mac and iOS developers since the last century, when Apple moved me from Chicago to be an evangelist at Apple HQ in Cupertino. I know as much as anyone about AI-assisted app development, as the creator/maintainer of the free/open source Axiom ( https://charleswiltgen.github.io/Axiom/ ) for iOS/macOS devs. It's not as dire as you might think. To software developers,…
I don't think i fear so much for competing on quality vs a vibe coder, I think two orders of magnitude is underselling the potential snowball effect of a vibe coder attempting to craft up a semi complex project. The sooner they start to pile on complexity, the quicker it is that the 2x gap widens. The fear for me comes with that initial creation, which is a fear i have across a large amount of things for AI "disrupti…
- 90% of everything is vibe-coded crap
- 90% of what isn't vibe-coded crap is also crap
ergo, the small percentage which is left is not crap.
So a bit different from the other comments. We're a wearable company which of course pairs with an app. We built iOS first because that's what most of our users have, though the team is mostly on Android. We built our logic in Rust, so that compiles cross platform. It's really just the UI layer that is per platform. Though I had initially written our first demo in React-Native, the team wanted to go with native UI. L…
I work on the Android side for a company that develops an external bluetooth device (not a wearable, but similar enough) and the bluetooth library situation has certainly been an issue to be concerned about.
Using the default Android bluetooth SDK "raw" is fraught with potential problems, at the very least you need some sort of added message-queue-like system built on top since it does none of this for you. You also have to contend with a lot of strange device specific issues (of the type "works fine on 99% of Android devices, this one Samsung device has a driver quirk we need to work around", etc).
Things looked pretty good with the Jetpack androidx.bluetooth library as a higher level abstraction, but Google suddenly deprecated it and stopped working on it before it left alpha.
After lots of investigations and iterations I ended up using Nordic Semiconductor's 2.0 Kotlin BLE Library, which is technically also still in alpha release, but is much more stable than that designation suggests.
https://github.com/nordicsemi/Kotlin-BLE-Library
After having messed with all of the options, I highly recommend Nordic's library as a solid basis for using Bluetooth in modern Android/Kotlin, but in your specific situation I'm not sure if bridging it to Rust would be less or more painful than having an LLM generate a Rust wrapper and message queue system over the raw android.bluetooth library.
My perspective: I've been supporting and working with Mac and iOS developers since the last century, when Apple moved me from Chicago to be an evangelist at Apple HQ in Cupertino. I know as much as anyone about AI-assisted app development, as the creator/maintainer of the free/open source Axiom ( https://charleswiltgen.github.io/Axiom/ ) for iOS/macOS devs. It's not as dire as you might think. To software developers,…
It also supports the 'native is better' apprpach. For example, I recently started with Powerflow [0] which I really like except for the size of it, and created a Swift version [1] in an hour of Claude plus manual tweaks. It's been running quietly on my laptop ever since.
The downside is that it brings Apple's iOS restrictions into sharper relief: being able to easily write widgets and apps to suit my needs but then being unable to run then for longer than a week on my own hardware without paying $99 a year is especially frustrating.
[0] https://github.com/lzt1008/powerflow [1] https://github.com/Tom1827/powerflow-swift
I had a go at building both a Mac and iOS dictation app the other day (dictator.robgough.net) thinking that with Claude's input, this probably wouldn't work... but it was a real problem I had, and I wanted to see how far we could get. Best way to learn the tools, right? I'd already spent the day playing with alternative apps that didn't quite do what I wanted. The app itself is fairly straightforward, but it included…