So you want to write an “app” (2025)

I did something similar. I’m not a developer, but I use programming as a problem solving tool, and have written little apps for limited uses such as controlling a fixture in the factory — stuff that the devs won’t touch. My first language was BASIC on a mainframe, before I had access to a microcomputer.

I was getting sick of Visual Basic and Excel, and besides, my VB license was more than a decade old. So I went “language shopping” by trying out the same two tasks in a whole bunch of languages. And I also let myself be influenced by online discussions, blogs, etc. Between computers at work and at home, I tried out each language on both Windows and Linux. One of the tasks was computational and graphical, the other was controlling a widget connected to USB.

I ended up with Python, and have been loyal to it for 13+ years. Did I make the best choice? I can drum up a list of pro’s and con’s, but it would be based on hindsight.

When I need desktop app for my personal needs, I'm still writing them in Lazarus (text editor, git client, music player, spreadsheet, image cropper, various oddball one off desktop apps). It works on Linux and windows. If it really doesn't need to be desktop (typically visual apps that works on different files in different local dirs, or opening it in browser would be awkward) then I make browser app or extension in vanilla js. If it can be both desktop or browser, I chose browser most of the time, Lazarus is not exactly pinnacle of bug free apps.

Probably not what most on HN would think of, but for writing a simple app with a GUI, I'd suggest that Tcl/Tk is hard to beat. Of course the simple approach wouldn't suffice if the program had to be compiled to a native binary. Though Tcl/Tk has an excellent C API, so a binary version of the app could be built if considerably more work to accomplish.

I think Jetpack Compose is not actually as bad as you think. I think it's really great and I wish more people caught on actually.

I can't comment on the learning materials as I was following it since the project started and I was already accustomed to the Android Developers website.

Kotlin has a few reactiveness concepts that make reactivity easier but might scare off developers from other languages. The most important ones are Flows and Coroutines.

Say you want to have a UI that shows the current list of connected devices that should always show up to date info. The function to get the list would be something like this:

  val devices = manager.getDevices()

But you need it to be declarative instead of imperative, so you use a Flow:

  val devices = flow {
      while(true) {
          emit(manager.getDevices())
          delay(1000)
      }
  }

Devices is now a cold flow. It does nothing unless it's being collected. When you start collecting it, e.g. by using collect:

  devices.collect { list -> ... }

Now it starts running the while loop and you get the up to date devices list in your lambda every second. You can also make the lambda run only when the list has changed, or debounce it, or run only for the latest value, and more with trivial function chaining. But this function is suspending, which is Kotlin's way of async functions, and suspend functions take turns running on the threads that are managed by the coroutine scope they are in, so you need to provide it a coroutine scope by wrapping your collection in scope.launch { ... } .

And your viewmodel can now collect the flow in a way that's going to be accessible without suspending (async) functions by turning it into a StateFlow:

  val devicesStateFlow: StateFlow<List<Device>> = devicesFlow.stateIn(scope, some more arguments...)
  // Now synchronous code can call like this:
  print(devicesStateFlow.value)

  // And Compose (reactive ui) code can do this in Composable functions:
  val devicesState by vm.devicesStateFlow.collectAsState() 

I think that was the source of confusion you had when you were trying to use datastore. It's designed for reactive applications so you were supposed to use it in a viewmodel, turn it into a stateflow and collect it as state in your ui.

Lazarus[0] would probably have scored well in this exercise.

[0] https://www.lazarus-ide.org/

> it's simply not clear why a new developer would or should bother to invest in Microsoft's ecosystem

Well, depends on the context.

In my domain (professional, non-software engineering) Linux users don't matter as Linux users generally don't like to pay for products, and Mac users don't matter because they do not exist in this context. Zero incentive to bother with anything that is NOT Microsoft ecosystem.

I wish you had tried C# with WinForms which is still has the best GUI development tooling in Visual Studio.

Increasingly, there just aren't enough incentives to write native apps.

This isn't a criticism of the article, but rather a tangential observation about why so many people turn to the web instead of using native toolkits to build apps, and why so many of native toolkits feel uninspired and lacking any real innovation.

If I choose to build an app using web tech, I get:

- Universal distribution

- No download and install process

- No "please wait while we update this"

- Users can easily share my app

- Users can link to individual pages within my app

- Users get autofill for forms and passwords and credit cards

- Users can block ads

- Users can scale and zoom my content

- Users can find text on any page in my app

- No "SmartScan couldn't verify if this app is safe" because it wasn't signed with a cert.

- A clearer security model: web apps prompt the user for access to e.g. microphone, camera, or secure disk locations. Native apps can kinda do whatever they want.

Why would I give up all those things to write a native app? A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.

Another common answer is app store distribution, but web apps can now be published to the major app stores without Electron or other frameworks. Google Play and Microsoft Store both support PWAs, and iOS App Store supports web apps via web view.

There are some scenarios where a native app is warranted. For example, hooking into some native component or OS API; e.g. HealthKit on iOS. But for many apps, the web is good enough.

They should've tried Flutter, which is what I primarily use for building apps, and it's hard to find a competitor that's as "write once, run everywhere," as Flutter. Only Dioxus with their native renderer might come close, but that's years away from being at a Flutter-level production capacity.

I keep coming back to the web for small projects for exactly those reasons.

The distribution alone is hard to beat — if someone can open a link and try the app instantly, it removes a huge amount of friction.

I think most people starting on linux or *bsd (and macos power users) will learn about POSIX long before they start programming. Usually because a shell script they want to run breaks

If you type 'shell' into arch wiki the first line talks about POSIX On my system typing 'man sh' brings up a posix programming manual. On systems with dash the man page refers to POSIX. On Wikipedia linux mentions it all over the place, on unix's page the offical site link is a link to opengroups. Even 'man man' (man-db) mentions POSIX. Oh, and the coreutils info page mentions it right at the start (and 234 times in total) which based on my admittedly poor count is the second most used nonstandard word behind env beating out coreutils/cp/du/cksum/printf/uniq/.

Until we hit the YOTLD users will continue to be exposed to standards.

I'm a semi-retarded product manager that was interested in what it was like building linux desktop apps. With a hand from Claude, I was surprised to get a simple Gnome/gtk widget that was functional and understandable. I was also able to iterate on it without any headaches.

Use Flutter.

How about React native? Is it still a thing in 2025/26?

Good that someone is calling out Compose. Android team and Google and JetBrains should be ashamed of the state of documentation around it. It’s all over the place, outdated the moment it is posted and generally feels like written by ADHD students. “Hello world” format virtue signaling they’ve posted on YouTube is an embarrassment and we’re clearly made as ones promo checklist.

Hire a proper tech writer, not a student for a bowl of rice, who will fix this shit.

Now, make a web app and compare the effort and tooling.

[dead]

> I wanted to get a personal "feel" for what the "new developer experience" is actually like across all of the current platforms...

I don't really understand what this means. Without explaining that, the rest of this blog post is just rambling notes about developer ergonomics. Of all the things to focus on, that's going to be by far the lowest priority in app dev.

Maybe I'm just too young to have ever experienced the kind of stability expected here. My opinions of tools are based on what they are capable of doing and how well it lines up with what I expect them to do. That's my definition of "feel" as an app dev. I don't care if the interface is stable. I want the capabilities to be stable. To make an analogy, when I buy a new work truck I care more about the specs and not the stuff on the dashboard.

> ... if you don't resort to web tech such as Electron

And that's precisely why everything is now a web app for over a decade, and why W3C standards and big tech bureaucracy won out.