r/KotlinMultiplatform

I developed Weather World because I wanted a simpler, more helpful way to stay ahead of the forecast. I truly believe that a weather app should be a tool that makes your life easier, not a source of distraction with ads and confusing menus.

How it helps you: The core of the app is all about visual clarity. I’ve focused on creating intuitive graphs that let you see temperature shifts and precipitation trends at a single glance. Instead of reading through long lists of numbers, you can visualize exactly how your day will unfold. It’s minimalist, lightweight, and built for speed—perfect for anyone who values a clean Android experience.

I’d love your support! Please give it a try and see if it helps your daily routine. If you find it useful, please recommend it to your friends! As a solo developer, your support and word-of-mouth are what help me improve and grow.

In compliance with the community rules, I’ve shared the link via IndieAppCircle. Check it out there and let me know what you think!

Find it here: https://play.google.com/store/apps/details?id=com.danie.pocasisveta

I've been working on offline-first sync for Android apps that use Room.

Pattern: local write immediately → outbox queue → push/pull when online → handle conflicts if the same row changed on server.

Short demo (GIF): offline add → sync → wipe local DB → pull restores data.

Technical bits:

• Room stays the source of truth for entities

• Separate SQLDelight outbox (survives process death)

• KSP generates sync handlers from Entity/DAO

• Gradle plugin wires KSP + serialization

Stack is Kotlin 2.1, minSdk 24. Apache 2.0, sample + mock server in the repo.

Repo (if useful): https://github.com/Arsenoal/syncforge

Genuinely looking for architecture feedback:

1. Would you trust a library-owned outbox next to Room, or keep everything in-app?
2. What's the minimum you'd need before trying this in a non-toy app?

Happy to share Gradle setup in comments if anyone wants to poke at it.

Hi all,

I just released my first app using KMP Compose. I really want to get real people honest review which is to be honest hard to get.

This is gallery clean up app. I will be really really appreciate if you could try and give some feedback about UI/UX and app in general.

I enjoyed the KMP so far and Compose approach, it gives me such speed and basically I had no troubles with Compose UI behave differently for iOS/Android

Apple Store: https://apps.apple.com/app/goby-cleaner/id6773443313
Google Store: https://play.google.com/store/apps/details?id=io.pixel.studio.goby_cleaner

I am coming to KMP from native iOS and Expo. Already did some agent powered work with KMP and managed to release app built with it that has some decent usage for an enterprise customers. KMP is lovely and I want to do more things with it.

There’s a one little thing though. I just can’t stand material design - I find it obnoxious, over-dramatic, and really hard to customize in a way that hides its ugliness (worth to mention that I am also not loving Liquid Glass for the same reasons). I know this is matter of taste, but I really much prefer design systems that are middle ground between the two native takes on UI, as typically they are made for the purpose of blending in with whatever branding you’ve got. A good example of what I am taking about is HeroUI from React Native world - https://heroui.com/en/docs/native/getting-started

Now, what’s the current landscape of “middle-ground” UIs in KMP world? Is using compose/material as a foundation for your own design system the best way to do it?

What’s the latest practice and path forward? I am guessing compose is a still moving target and there might be a lot of things just around the corner?

So many questions! Would love to hear some battle stories rather than talking this through with Claude heheh

Hi,

I built goldr, a server-first Go framework for building templ + HTMX web applications. I created it because I wanted the structure and ergonomics of a modern web framework, but without moving my app into SPA, hydration, or client-state territory. I'm already using Goldr in production, and the main goal is to keep Go web apps easy to see, run, debug, and ship as they grow.

Repo: https://github.com/mobiletoly/goldr

Goldr gives you:

• filesystem routes under app/routes
• route-local pages, HTMX fragments, and POST actions
• nested layouts based on the route tree
• reusable mounted route subtrees, so the same workflow can live in multiple parts of an app without copying route folders
• generated URL helpers, so templates and redirects do not copy path strings
• visible HTMX in .templ files
• live reload with route generation, templ generation, app restart, asset fingerprinting, and browser reload
• fingerprinted and embedded static assets using simple directory conventions
• CLI inspection for routes, layouts, HTMX references, and packaged assets
• a browser visual inspector that can outline which layout, page, fragment, or labeled component produced a page region

The part I like most is that the app still feels like a Go app. Goldr does not own your server, middleware, auth, sessions, database layer, asset compiler, deployment, or client state. It gives structure around the boring repeated parts while leaving application policy explicit.

A route tree looks like this:

app/routes/
  layout.go
  layout.templ
  route.go
  page.templ
  users/
    route.go
    page.templ
    frag_table.templ
    by_id/
      route.go
      page.templ

Goldr turns that into generated net/http dispatch and URL helpers, while the source files stay ordinary Go and templ.

Goldr is still pre-v1, so APIs may change, but it is already useful enough that I'm using it for real production work.

Repo: https://github.com/mobiletoly/goldr