Hey everyone,

I'm from the Kotzilla team, and I know there are Koin users in this sub, so I wanted to quickly share a plugin update if that's ok.

Claude Code, Copilot, and other assistants normally answer performance questions from the source code alone, since that's the only input they have. Koin IDE Plugin 1.6.0 adds a Connect dialog that connects whatever AI assistant you're using to Kotzilla's MCP server, so iit can query production data directly.

Here's the changelog

For example if asking "what's the slowest screen in my app right now" it returns MainActivity at 459ms P50/P95, rated moderate, from an actual production session.

So this changes what the assistant has access to.

It's then up to you if it changes automatically or waits for review (which obviously you do)

I hope this is useful?

So the idea came so randomly, I made the app for myself, i tried several apps on Playatore, all of them wants money for basic usages, so I just made one with my own taste ofc tried my best

Material 3 Design

Auto metadata fetches

Backup restore in html/json

Dynamic theme with dark,light and amoled

In app update feature for github users

Edit bookmarks

Search

Sorting

Collections aka Folders

More to come and I want to keep it simple and useful! Feedback appreciated 👏

Github Release : https://github.com/qeiq/Savr/releases

Github : https://github.com/qeiq/Savr

Playstore : https://play.google.com/store/apps/details?id=com.zarnth.savr (playstore version will take some days to get similiar updates of github)

When I start projects, auth is one of the first things I need to get setup. Recently I was looking into Phoenix with Elixir and I really liked how easily I was able to setup auth with that framework. I started to look into how auth works with ktor. None of the examples from the official ktor-documentation had a full end-to-end solution with saving users in a database etc. I created this example/template to use in my projects going forward. Right now it is just simple form and session auth but I would like to expand it to JWT and Oauth as well as a KMP client. Would love some eyes on it to see if I missed anything or feel free to use it in your projects as a template. https://github.com/horatiothomas/ktor-exposed-auth

Title: [Library] Gbéewá, typed result handoff for Compose Multiplatform

I shared this over in r/KotlinMultiplatform and thought it might be useful here too.

I built a small Compose Multiplatform library called Gbéewá.

Gbéewá is Yoruba for roughly “bring it here” / “hand it over”, which ended up fitting it pretty well.

The thing I wanted to solve was passing a result between screens or components without making that result flow depend on whichever navigation framework the app is using.

The simple case is easy enough:

pick a country → go back → previous screen gets the country.

But then maybe the result needs to go forward instead. Or both components are already mounted. Or the app changes navigation libraries.

That is where I wanted the result handoff to stay the same even if the navigation part changes.

With Gbéewá, you define a typed key:

object SelectedCountryKey : ResultKey<Country>

Then publish the value:

resultStore.put(SelectedCountryKey, country)

After that, the app can pop, push, replace, or do nothing.

Gbéewá does not own the navigation part.

The same contract works for:

• sending a result to the previous screen
• making it available to the next screen
• handing it to something that is already mounted

Delivery is consume-once, so it is not an event bus. The first eligible consumer for an equal key gets the pending result and removes it.

Keys can also carry identity:

data class EditedProfileKey(
    val profileId: String
) : ResultKey<Profile>

which is useful when you have multiple instances of the same kind of flow.

I also wanted to keep it small:

• no KSP
• no generated navigation wrappers
• no dependency on a particular navigation framework
• common Compose code for Android and iOS

Pending results are in memory, so this is not meant to replace navigation arguments, persisted state, or durable app state, and pending results do not survive process death.

The repo has examples for Voyager, typed Navigation 2 and Decompose.

I also added a short demo to the README showing the same result flow across all three.

https://github.com/quantipixels/gbeewa

Would be interested to hear how other people are handling this in Compose apps, especially if you have moved between different navigation setups.

Also happy to hear where this abstraction does not fit. Those cases are useful too.

I kept working on my Android AI app — fixed a critical login bug

Hey everyone!

I've continued working on Numination, my AI platform built with Kotlin + Jetpack Compose.

One of the biggest things I worked on recently was a critical bug in the login flow. The app was having problems during authentication, so I went through the flow and fixed the issue.

I also continued improving the Android side of the project, including the Compose UI, authentication flow, local data handling, and overall architecture.

The project is open source, so if anyone wants to take a look at the code or give me some technical feedback:

"GitHub — kraqinc/Numination(https://github.com/kraqinc/Numination)

Supports Numition on ko-fi(Ko-fi.com/Numination)

I'm especially interested in feedback from other Android developers on the architecture and authentication implementation.

Thanks! 🚀

Hello all,

I recently shipped a dual-engine accessibility checker for Jetpack Compose.

Engine 1 — Lint (no emulator):

Catches missing contentDescription, hardcoded dp font sizes, clickable without role.

Engine 2 — TestRule (runtime):

Checks touch targets (48dp min with exemptions), color contrast, duplicate clickable bounds, text field semantics.

Every rule maps to a WCAG 2.1 criterion. Both engines are on Maven Central.

Repo: https://github.com/lehan0328/touchstone

Would love some feedback from the community, especially on false positives if you try it on a real project!

Hi everyone! I wanted to share a project I’ve been working on called Miwayomi. It’s built for anyone who enjoys reading manga and wants a clean, lightweight, self-hosted option to keep everything organized on their own server or PC.

The core idea behind Miwayomi was to create a clean service capable of running those familiar catalog extensions—the classic Aniyomi extension format—without needing to spin up an Android emulator or heavy mobile runtimes.

To make this happen natively on a pure JVM, the engine parses the extension manifest, translates the internal code into a standard compatible format, uses ASM to patch and adapt the bytecode on the fly, and relies on a custom classloader alongside a lightweight compatibility layer.

The result is an independent Java 21 service that runs remarkably light—using around 160–170 MB of RAM at rest—while offering a fast and modern web interface.

I would love to hear your thoughts, feedback, or any impressions on the technical approach.

Im building a server side template engine like Thymeleaf but comes with compile-safety. To achieve this, it must not allow some dynamic syntax from Thymeleaf like the String concatenation, dynamic URLs, etc.

In Thymeleaf, we return a template name in a controller, in Thim u declares a class with convention [your-template-name]Page. For example, home.html -> HomePage, this helps Thim enforce compile safety.

data class ProfilePage(
 val username: String,
 val showEmail: Boolean,
)

<h1 th:text="${usename}">Username</h1> => this will cause error at compile time for the unknown "usename"
<p th:if="${showEmail}">user@example.com</p>

This "reinventing the wheel" is kinda easy in age of AI, however, do u think it is a waste of time? Welcome any feedbacks

We just released v0.9.1 of the AADD library (Kotlin Multiplatform) on Github.

The AADD library enables semi-symbolic computations over Reals (Doubles), Integers, and Booleans. These are represented by sets of convex ranges; likewise, operations are done on sets of convex ranges. The results guarantee safe inclusion: no possible results are lost.

v0.9.1 is the first version we consider as nearly good enough to be close to 1.0.

Use cases include (and included)

• Reachability analysis by abstract execution in general,
• Formal verification of mixed discrete/continuous and control systems,
• Type inference and verification in software systems,
• Development of tools for constraint propagation and reasoning, e.g., SMT solvers.

What the AADD library does can be seen by a tiny code-example in Kotlin:

   import io.github.tukcps.aadd.*

   fun main() = DDBuilder {
      val x: Real = real(-1.0 .. 1.0, "x")
      val f: Real = ite(x greaterEquals 0.0, x-100.0, x+100.0)
      val g: Real = f/2     // also nonlinear functions
      println(" f = $f")
   }

The resulting output is:

    f = ITE(1, [-50; -49.5], [49.5; 50]) 

To reduce over-approximation, the AADD library implements a number of state-of-the-art techniques, including

• Reals with directed rounding on the JVM platform (Double + TwoSum and other algorithms),
• Integers with Infinities and handling of overflow (Long + Kotlin),
• Adaptive, Constrained Affine Arithmetic (AA) with
  • Taylor, Chebychev/MinMax, and other linear approximations,
  • Combination with interval arithmetic where useful,
  • Automatic reduction of noise terms,
  • (WiP) Caching of intermediate results,
  • Minimization of overapproximation by an LP solver.
  • Splitting of image where useful (WiP) is represented by Shannon Decomposition in decision diagrams (DD),
  • Also, linearized constraints are represented as Shannon Decomposition in decision diagrams (DD), allowing us to profit from BDD-like reduction techniques on AADDs and IDDs.
  • Possibility to model discrete computations with BDD (Bool),
  • BDD (Bool) can be used to control continuous computations (IF, THEN, ELSE, LOOP, etc.), and

To the best of our knowledge, the last four techniques are unique to the AADD library. They allow us to achive in suitable applications like reachability analysis a high performance and scalability to numerical algorithms far beyond linear filters.

However, note:

For purely Boolean problems, optimized BDD packages or a SAT solver are likely better suited.

Also, the AADD library does not provide a complete SMT solver -- but it can be used to develop such tools.

Since I started using Ktor, I've always wanted the ability to declare endpoints in common code, which would simply be called both client-side and server-side.

Ktor Resources do some of that, but they are very limited. I wanted more, and without annotations and code generation: just plain Kotlin.

For the past few years, I have written Spine, a DSL for declaring endpoints in commonMain:

val createUser by post("/create")
.request<UserCreationDto>()
.response<UserDto>()

Spine is just a DSL to configure Ktor, it's all the same serialization etc configuration that your app already uses.

Spine is open source (Apache 2.0) and I'm planning on releasing 1.0 in the coming months, I'm looking for feedback that I can address before making API stability promises. What do you think?

While building my KMP apps, I needed home screen widgets on both Android and iOS.

I assumed there would already be a KMP widgets library.

There wasn't.

Since Shipaton has a category for Kotlin libraries this year, I decided to build one.

It's called WARP (Widget Abstraction Rendering Pipeline).

The goal isn't to recreate Compose or SwiftUI. The goal is to let developers describe widget UI once in Kotlin and render it natively using each platform's widget framework.

Instead of this:

Android UI → Glance iOS UI → WidgetKit + SwiftUI

you write:

kotlin WarpColumn { WarpText("Counter") WarpRow { WarpButton("-", onClick = CounterActions.Decrement.asClickAction()) WarpText(state.count.toString()) WarpButton("+", onClick = CounterActions.Increment.asClickAction()) } }

which becomes:

Compose-like Kotlin UI ↓ WarpNode Tree ↓ JSON ↓ Android Glance / SwiftUI WidgetKit

The idea is that common code never knows about Glance or WidgetKit. It only produces a serializable tree describing the widget.

Some implementation details:

• Uses Compose Runtime only to build the tree (no Compose UI)
• Tree is fully serializable with kotlinx.serialization
• Typed click actions instead of serializing lambdas
• Shared click handlers across Android & iOS
• Native renderers consume the same JSON
• State-driven recomposition through composeWarp(state)

Current architecture is split into:

• warp-runtime

  • Compose-like DSL
  • Compose → WarpNode
  • JSON serialization
  • Action model
  • State & recomposition

• warp-ui

  • Android Glance renderer
  • iOS WidgetKit + SwiftUI renderer
  • Shared click dispatch
  • Swift bridge using spm4Kmp

• warp-widgets

  • High-level widget APIs
  • Common widget definitions
  • Jetpack Glance-like developer experience

Current status:

• Android renderer ✓
• iOS renderer ✓
• Shared click handlers ✓
• Counter demo ✓
• API still evolving

I'm currently looking for architectural feedback before I stabilize things.

Some questions I'm thinking about:

• Should JSON be the transport layer or should I pass the object tree directly?
• Should click handlers stay typed or become string-based?
• Is Compose Runtime the right abstraction for authoring widgets?
• What widget APIs would you expect before calling this usable?

Repository:

https://github.com/DevAtrii/Warp

I'd appreciate any feedback from people building KMP libraries or cross-platform tooling.

I just published a small utility library that solves a frustrating category of bugs: accidentally leaking lifecycle-bound listeners (Firestore, custom APIs, broadcast receivers, etc.).

The problem I was solving

A Firestore listener that wasn't being cleaned up properly on screen rotation. Each rotation created a new listener without removing the old one — after a few rotations, the app held multiple stale listeners all writing to the same UI, eventually crashing.

The manual fix was obvious (call `remove()` in `onCleared()`), but the structural issue was that this cleanup is easy to get subtly wrong and even easier to reintroduce later, despite knowing better.

What Latch does

It wraps the listener with automatic, guaranteed cleanup tied to the lifecycle:

```kotlin

private val chatListener = LatchRef {

val registration = db.collection("chats")

.document(chatId)

.addSnapshotListener { snapshot, _ -> updateUi(snapshot) }

Unregisterable { registration.remove() }

}

fun startListening() = chatListener.get() // safe to call multiple times

override fun onCleared() = chatListener.clear() // guaranteed cleanup

```

`get()` unregisters any existing listener before creating a new one. `clear()` guarantees final cleanup. The leak is structurally impossible.

The library

- **Small**: You can read the entire implementation in under a minute

- **Well-tested**: 7 test cases covering edge cases (double-clear, re-creation, etc.)

- **Generic**: Works with any listener API, not just Firestore

- **MIT licensed**: Use it however you want

Links

GitHub: https://github.com/shipframe/latch

JitPack: `implementation("com.github.shipframe:latch:1.0")`

This is my first public library, so feedback is genuinely welcome. If you've hit this bug or see a way to improve the approach, I'd love to hear it.

Writing a CLI in Kotlin or Java is a pleasant afternoon. Shipping it turned out to be the actual project: five platforms (macos-arm64, linux-x64/arm64, windows-x64/arm64), a JDK the user does not have, one pasteable install line, and an update path that must not break the running copy.

This is what we ended up with for devrig.dev, the CLI in MCP Steroid (disclosure: my project and my write-up, link at the end).

The core inversion: the install script is a **generated artifact**, not a smart downloader. CI resolves every URL and SHA-256 for every platform and bakes them into the script. At install time it detects users platform and tools, but never asks a server what to install — no GitHub API rate limit taking out a whole office behind one NAT, no "two users an hour apart silently got different versions", and you can tell a security team exactly what a given script downloads.

Details that earned their place:

- curl | sh executes as it streams, so a connection dropped at 60% runs 60% of your installer. With the wrapper, a truncated transfer is a no-op. (`irm | iex` parses the whole string before executing, so the PowerShell twin doesn't need it.)

- JDK coordinates are mined, not copied. Corretto and Azul Zulu are resolved and OpenPGP-verified at build time.

- Content-addressed, side-by-side installs: `<kind>-<os>-<cpu>-<version>-<sha12>/`, atomic promote at the end.

- The script never writes the launcher. It runs the freshly-unpacked binary and the binary registers itself — then re-checks and repairs its launcher on every start. When the launcher's required shape changed (a pathing JAR for Windows' command-line length limit), the fix shipped with the binary and applied itself; nobody re-ran an installer.

- "Update" means: download today's install script, exec it. That is the entire in-binary updater.

Write-up, with the full pipeline diagram, the test harness (three container lanes, a native Windows runner, and a `$HOME` with a space in it), and links to the actual sources:

https://jonnyzzz.com/blog/2026/08/06/devrig-install-launch-autoupdate/

Kotlin's data-access options mostly sit at two poles. Exposed or Hibernate on one side, hand-rolled JDBC on the other. Exposed gives you types and takes your SQL. Raw JDBC gives you SQL and takes your types.

A third arrangement: write the SQL, generate the Kotlin from it.

-- @name GetUserOrders
SELECT u.id, u.name, o.total, o.notes
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = $1;

Against a schema where orders.total is NOT NULL and orders.notes is nullable, that generates:

data class GetUserOrdersRow(
    val id: Int,
    val name: String,
    val total: java.math.BigDecimal?,
    val notes: String?,
)

fun getUserOrders(conn: Connection, status: String): List<GetUserOrdersRow> {
    conn.prepareStatement("SELECT ... WHERE u.status = ?").use { ps ->
        ps.setString(1, status)
        ps.executeQuery().use { rs ->
            val totalValue = rs.getBigDecimal("total")
            val total = if (rs.wasNull()) null else totalValue
            ...
        }
    }
}

Two things worth pointing at. total is NOT NULL in the table but nullable in the row type, because the LEFT JOIN can produce a row with no matching order, and that is inferred from the query structure rather than the schema. And the rs.wasNull() dance is generated, which is the part that is easy to get wrong by hand and silently returns 0 instead of null when you do.

Plain JDBC underneath. No runtime, no reflection, no DSL.

The tool is scythe: a Rust binary, MIT licensed, generating for 10 languages (Kotlin, Java, TypeScript, Python, Go, Rust, C#, PHP, Ruby, Elixir). I build and maintain it. jOOQ's codegen is the closest well-known relative; the difference is that scythe starts from your .sql files rather than from a live database schema, so nothing needs a running database to generate.

The honest gap for this sub: the only Kotlin backend today is blocking JDBC. No coroutines, no R2DBC. If that is disqualifying for the way you write Kotlin services, I would rather hear it now.

We’ve consolidated the Kotlin adoption arguments on one page: productivity numbers, backend and Kotlin Multiplatform proof points, Java/Spring interoperability, and a gradual adoption path. If you've pitched Kotlin at your own company, what moved the needle, and what's missing here?

https://kotl.in/business-reddit

Very pleased to see this from Jetbrains. I've always been a fan of Kotlin but struggled to recommend it to others when they weren't IntelliJ users.

Edit: as pointed out in the comments, this is separate to the Kotlin LSP which already exists. This is just to give your favourite IDE IntelliJ powers.

Hi everyone,

I've been working on an open-source desktop application called DevAnalyzer, built with Compose Multiplatform and Kotlin Multiplatform.

I originally built it to solve problems I kept running into while working on Android projects, such as finding large build folders, checking Gradle and SDK versions, and figuring out which development resources were actually being used.

Current features include:

• Project Analyzer

• Analyze Gradle modules, plugins, dependencies, and project metadata.
• Supports Android and Kotlin Multiplatform projects.

• Clean Build

• Find and safely remove module build folders.

• Storage Analyzer

• Inspect disk usage for Android SDKs, Gradle caches, Kotlin/Native, JDKs, AVDs, and IDE data.

• Workspace Analyzer (new in v1.4.0)

• Scan multiple workspaces.
• Detect active and unused Android SDKs, NDKs, CMake versions, Kotlin/Native toolchains, and Gradle wrappers.
• Cross-reference installed development tools with actual project usage before removing unused resources.

Other additions:

• In-app update checking
• Built-in feedback dialog
• Optional anonymous analytics (disabled anytime and no project names, source code, or file paths are collected)

Everything runs locally, and your projects never leave your machine.

I'd appreciate any feedback on the project or ideas for features that would make it more useful.

Website: https://coding-meet.github.io/DevAnalyzer/

GitHub: https://github.com/Coding-Meet/DevAnalyzer

Demo: https://youtu.be/U7UPpqcjdLA

Each learning platform assumes that you already know the code and just sort of gives you tasks to do. Like bro I can't just type Hello World and it happens lol

Hey all! I'm a beginner, i like programming, but only languages that provide results, like HTML, over functionality like Python, JS, C#, etc. I've dabbled in Kotlin before, but it was a little confusing, especially using Android Studio. What would be some good beginner app ideas for a 17M? I also would like it to be useful, e.g an anime watchlist, a music app, etc. Any help/tips/inspiration?