> What is going on in the world of pure IOS/Android app development?
I'll speak only for Android.
I am tired of Google breaking source compatibility with every AndroidX release and remaining on outdated IntelliJ Platform versions in Android Studio.
not too long ago, Google released AGP 9.0, which was a SHOCKWAVE for many Android projects. many compiler plugins' compatibility, including Google's own Protobuf Gradle plugin, took very long to adapt. also, Kotlin Multiplatform received so much damage that a month after release, JetBrains themselves released an AGP 9.0 migration video on YouTube.
and then we have MDC-Android (Views) v. Compose tension. MDC-Android got Material 3 and M3 Expressive components much faster than Compose, and for many you still have to be on alpha Compose Material3 releases... which are more stable than "Stable," somehow. Compose is nice, but I'd swap Material for something else ASAP or use Compose Foundation directly.
> How is AI/LLMs affecting app development?
you have more useless buttons in Android Studio. or, if you are a paying IntelliJ IDEA Ultimate user, you can have Android support in IDEA, which enables ACP agents without sacrificing proper Android support. IDEA Android plugin lags behind AGP upgrades a little, though, but it's fine.
oh, and, you can vibecode Android apps in Google AI Studio with streaming from a Google-hosted device, all without Android Studio.
> what has changed in App Development in the past 2-5 years?
2 years? a lot. 5 years? the world turned upside down! Compose got Stable release 4 years ago.
> What does a career in only app development look like nowadays?
very discouraging. everyone just prefers React "Native". I couldn't find an Android job in two years because it's nowhere to apply to in Ukraine and just recently switched to .NET. guess what? less than a few weeks passed after I updated my Djinni and now I have a few interviews on the next week.
I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to create. once someone creates a Zig-native immediate-mode or reactive UI framework, that is.
I am still a little salty about `@cImport` removal, though! without it, I can't confidently call it "Kotlin of C" anymore.
> that will let me iterate at the speed of JS or Python with performance of C or Rust.
Didn't Go already do that?
> I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement
Yes, and it will still only be useful in the same niche that C is because the entire philosophy of Zig is to essentially be like C. You're never going to interate at JS/Python speeds with Zig because you'll always be wrangling with memory lifecycles, object lifecycles, etc...
> no. GC pauses turn any serious systems work into hell.
did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter
> this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui
Sure, but if you're philosophically okay with hidden allocations and control flow, why not just choose a language that doesn't compromise itself for those ideals in the first place?
that was me comparing, please kindly read usernames next time :)
> why not just choose a language that doesn't compromise itself for those ideals in the first place?
I might want to wrap a timing-sensitive machinery into some nice UI. Rust has Tauri for that, sure, but now we are bringing npm and have zero chances of having GPU-accelerated UI without a crap-ton of fuckery which would be easier in Zig. another path for resolving that same issue is Compose Desktop + Project Panama, but then you are dealing with data marshalling, FFI boundary, and manual resource management in an environment that does not expect this.
so, here is a genius idea: why not have everything in one language? C++ already does that, much like C, but Zig does that so much better, and incremental compilation time is one of the more practical and immediate developer UX benefits it provides. Rust? good luck having shared mutable state there.
That sounds good on paper. But as a guy who tried to learn Kotlin and only it. It comes with baggage to learn Java to use its libraries because... You know... they interact seamlessly and stuff. In the end, for a new learner, it might actually make things harder.
Nothing about Zig and C here, just a bit salty from my experience with Kotlin.
Kotlin is a terrible language for learning, as it has a lot syntactic shortcuts that are easy to mistake for magic. I think it's actually easier to learn some Java first, as it's simpler and teaches you the semantics both languages (mostly) share.
Kotlin also has its own features that differ from the way the JVM or Java has decided to develop them. For example: coroutines vs virtual threads or Kotlin “value” classes and Java value classes. The semantics don’t match and Kotlin stops becoming simply a “better Java”.
Kotlin <-> Java interop is a totally optional topic you could have skipped over, telling you as a Kotlin developer (who recently had to switch to .NET because Ukrainian job market is fucked up). besides, Java itself isn't that hard if it's Java 17 or newer, and it's rather good if it's Java 25 or newer
> Kotlin <-> Java interop is a totally optional topic you could have skipped over
This is the same place F# has been stuck in. It’s a great language on its own, but you can’t just use F#. Every F# must also do C# interop. It’s too 100% optional in theory, but never in practice. The best CLR/JVM libraries for anything are Java/C# ones. You need to interop with them to develop practical Kotlin/F# applications. You can limit yourself to the Kotlin/F# ones, but then you’re artificially limiting yourself to experimental libraries at best. You will find yourself needing a charting library, a DNS library, an SMTP library, an AWS SDK or a rabbitmq SDK. The best ones are gonna be Java/C#. Yes, you can always find a random GitHub repo for a “Kotlin-native X”, but the Java X library is a thousand times more mature, stable, performant, feature rich, etc. Same problem with F#. And the “glue” code is so “straight forward”, why would any one bother?
It's already sort of possible. https://codeberg.org/fellowtraveler/flux here is my Zig DAW. It has been amazing for the audio engine, but the ui is currently using imgui.
`@import` that you have to configure in the build system first.
this makes porting projects gradually, file by file, rather cumbersome. now I have to rewrite quite a lot of Chocolate Doom because my port was halfway there and then @cImport got gutted... or keep going with Zig 0.16.2 until it's either 100% Zig or has little enough files that upgrading won't make my build.zig file implode in lines of code
> Zig, Rust, and the likes are only viable in niches where C is viable
Pretty much correct, yes.
> Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust.
Fundamentally impossible. C/Zig/Rust have 100% performance as a top goal, which has to be traded off with something else and that's always realistically going to be programmer work/effort/time.
You can't have a house built 100% fast but also 100% cheap and with 100% quality. At best you could cleverly abuse the law of diminishing returns and aim for ~80% in all three areas. That's basically what Go's trying to do.
> once this linker and incremental compilation on other targets land,
In any case, why would a better linker and faster compile times of all things achieve this supposed goal?
Beyond being low level, Zig is still pretty memory unsafe and has you make choices about each allocation, making it unappealing as an applications language. Zig and Python are completely different worlds.
> At best you could cleverly abuse the law of diminishing returns and aim for ~80% in all three areas. That's basically what Go's trying to do.
then how does Zig achieve ~90%?
> In any case, why would a better linker and faster compile times of all things achieve this supposed goal?
sub-100ms rebuild is actually more important as the project grows. when you iterate, you think differently. picking different colors or fonts or whatnot becomes much cheaper, so you are more willing to try
No? The conventional engineering wisdom has always been: pick two out of fast, cheap, or good.
And technological improvements don't remove these tradeoffs. You still have to balance tradeoffs. The best thing you could do is have a mix of technologies that choose different tradeoffs. A single technology (zig) won't do.
one concrete thing I can name is "widening" your view on writing. force different styles upon yourself, different constraints. the results will keep being shit for a while, but at least it will be very fun to tonally cosplay Shakespear before the mirror! you won't notice how time will pass :)
listening to narrations of vast variety of poetry and narrating something yourself will help you develop your specific voice and read with more intent.
you may not even need the "science of writing" this article describes. let yourself just... be with text.
dunno, I have electricity problems (especially on winters when Russia strikes the hardest on infra) but I usually have this time as a downtime for lightweight C coding in Termux and retro gaming, all on Galaxy Note 8 (Android 9!!) + power bank.
I guess it feels less like a problem when you have that problem regularly and are forced to adapt. and I guess I'll just HAVE to switch to Pixel 10 when Pixel 11 comes out - the integrated Linux terminal right there is awesome. or maybe just get a MacBook like most around me did
UGH! imagine a BCI chip serving advertisements into your brain directly and recording everything from how you breathe to how you fuck to "personalize" said ads.
no, I love technology, but I will never bind a piece of tech directly into my brain. we failed with mobile phones and we WILL definitely fail with BCI chips, ON THE EXACT SAME SPOTS. they will be impressive, sure, but they will also hold us captive past user acquisition period
I said an interface, not a full blown computer. The idea would be to have a standard protocol so you can control the computer of your choice (which could run adless open source software) without having to touch a keyboard, look at a screen or use headphones/speakers.
Obviously we'd have to legislate so that the kind of ad ridden stuff you mention is not allowed but that is a separate problem.
I think it is interesting in a way that it could allow deaf, mute and blind people to communicate more easily to other non disabled people and vice-versa but I fear we might lose progressively more senses (we have already lost many compared to the wildlife surrounding us) and we would progressively all become deaf and mute and reliant on technology.
But I don't see how we can avoid this kind of technology to take over at some point.
does it matter? the moment my brain becomes a computer's peripheral (input and output alike), said computer can read from my brain and infer things I don't want it to infer.
> The idea would be to have a standard protocol so you can control the computer of your choice
good luck doing that without a regulatory push that's tenfold stronger than DMA. we are lucky to not have vendor-locked keyboards and mice.
> I think it is interesting in a way that it could allow deaf, mute and blind people to communicate more easily
...with the same research that has a HUGE potential for law enforcement/employer/adtech corp/Palantir/whoever to forcefully crack my brain open for them? no thanks I'd rather put `contentDescription` and `alt` properties of UI components as well as test the deaf/mute/blind experience rigorously than face BCI
> But I don't see how we can avoid this kind of technology to take over at some point.
so let's delay it for as long as we physically can!
well, GenAI is an ultimate prototyping machine. I keep repeating that so often that autocomplete on my phone already learned it. look at Clair Obscur - this game did use GenAI internally for textures and forgot to clean up in ONE place. they were sorry for that and thanked the community for pointing out. naturally, Twitter and Bluesky went equally mad at Sandfall just for the mere fact of usage, but that didn't disqualify them from The Game Awards, as you can tell from how many awards they got.
Expedition 33 nailed music, aesthetics, and narrative, and I am glad that they took a diffusion model for what it is, not for what marketing wants you to believe. although the game itself would benefit from one or two months dedicated exclusively to optimization, it is THE reference of how generative technology can be used - purely internally, to ideate and iterate at the pace of your taste and a bunch of H200s. we are aware of that process detail purely because they slipped in one place and got briefly "owned" by Twitter.
CLion in particular is abysmal, yeah. so is RustRover. `rustacean.vim` gave me much better Rust UX than RustRover. although, for Android and serious Kotlin work, IntelliJ IDEA is the IDE and you can do nothing about it. yes, there is Kotlin LSP made by JetBrains themselves, but there are so many little things that are done faster in IDEA than Neovim unless you configure the hell out of it. Docker integration is one of hundreds of examples. meanwhile, assuming that you have set up your CMake properly, `clangd` just works and CLion has nothing to offer on top for anything but Unreal Engine. (didn't try Unreal support, so can't vouch for quality.)
same story with Rider and .NET: ReSharper, tied to Visual Studio, VS C*de, or Rider is just so much better than Roslyn-based analysis. and although you totally can put up some contraptions to prevent roslyn-ls from `ENOSPC`'ing your drive with leaked file watches in Neovim and benefit from even higher speeds, Rider is just faster than Visual Studio and that's enough.
> Most of the people pushing [...] are Luciferians and transhumanists.
transhumanists - yes. Luciferians - this definition is a lot more broad, branched, and complex. one transhumanist is hell-bent on Christianity (or at least seems to be; also pun intended) and most others have an atheistic position.
> Lucifer thought he could do better than God, and many of these crazy people working on, and pushing AI so hard believe they can do the same.
that's as far as similarities go, the rest is the usual atheist scientific-method-believing behavior HEAVILY smeared with a bias to their own interests.
> transhumanists - yes. Luciferians - this definition is a lot more broad, branched, and complex. one transhumanist is hell-bent on Christianity (or at least seems to be; also pun intended) and most others have an atheistic position.
Which transhumanist is hell-bent on Christianity? If you're approaching this seriously then provide names please. There have been plenty of Luciferians that have posed as atheists throughout time and space. Also, there is atheistic Luciferianism, just like there is atheistic Satanism.
There are many people who claim to be Christian but are not in order to subvert the religion. Pretty much the same with all Abrahamic religions. Peter Thiel definitely doesn't display Christian values. Joel Osteen is a great example - claims to be a Christian but doesn't at all behave like one. Same with Thiel.
Freemasonry is Luciferian, yet many of its members claim to be Christian. [1]
> What is going on in the world of pure IOS/Android app development?
I'll speak only for Android.
I am tired of Google breaking source compatibility with every AndroidX release and remaining on outdated IntelliJ Platform versions in Android Studio.
not too long ago, Google released AGP 9.0, which was a SHOCKWAVE for many Android projects. many compiler plugins' compatibility, including Google's own Protobuf Gradle plugin, took very long to adapt. also, Kotlin Multiplatform received so much damage that a month after release, JetBrains themselves released an AGP 9.0 migration video on YouTube.
and then we have MDC-Android (Views) v. Compose tension. MDC-Android got Material 3 and M3 Expressive components much faster than Compose, and for many you still have to be on alpha Compose Material3 releases... which are more stable than "Stable," somehow. Compose is nice, but I'd swap Material for something else ASAP or use Compose Foundation directly.
> How is AI/LLMs affecting app development?
you have more useless buttons in Android Studio. or, if you are a paying IntelliJ IDEA Ultimate user, you can have Android support in IDEA, which enables ACP agents without sacrificing proper Android support. IDEA Android plugin lags behind AGP upgrades a little, though, but it's fine.
oh, and, you can vibecode Android apps in Google AI Studio with streaming from a Google-hosted device, all without Android Studio.
> what has changed in App Development in the past 2-5 years?
2 years? a lot. 5 years? the world turned upside down! Compose got Stable release 4 years ago.
> What does a career in only app development look like nowadays?
very discouraging. everyone just prefers React "Native". I couldn't find an Android job in two years because it's nowhere to apply to in Ukraine and just recently switched to .NET. guess what? less than a few weeks passed after I updated my Djinni and now I have a few interviews on the next week.
reply