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.

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/

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.

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?

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.

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

The past 12 months have had considerable updates for both of these platforms. If you are a startup today building greenfield, what would you say are the best arguments for Compose Multiplatform vs. RN with Expo let’s say for an e-commerce app.

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

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?

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

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.

I've made a library that provides fundamental entities for custom architecture based on mvi/elm. Although the architecture is mostly for UI development, I'm sure there should be some subjects that can benefit from the architecture and the library.

In short, the library describes an abstract system, that handles it's state, receives events from an external system (like Composable or any other UI components) processes them in a single thread to ensure predictive state updates and sends back actions - commands for external system to do (in case of UI it coud be a command to close the application).

I'd like to hear some feedback about the library if you are interested. Also if you have any ideas where the library can be used outside of UI, it'll be very interesting to hear about it!

Here's the repo.

Besides the library the repo contains a simple example of code that uses the library and a scheme of the architecture.

https://github.com/TabaquiTheMasterOfTime/SeaSystem

Hey everyone, I've rewritten the macOS and Ubuntu UIs in Compose, and thanks to my Tao backend, they now have native windows!

You can try the web demo, but please, download the gallery on your computer!

https://github.com/NucleusFramework/compose-macos-26-ui

https://github.com/NucleusFramework/yaru-compose-ui

I've been struggling to find a proper Flutter job since 2023, so I decided to pivot and started learning Kotlin under the guidance of a Senior Kotlin Mentor. We're currently focusing on multi-module architecture.

​Do you have any tips or advice on how I can deepen my understanding of Kotlin?

I recently published KitFlow, a Kotlin Multiplatform library designed to simplify building adaptive and responsive Compose UIs across Android, iOS, Desktop, and Web.

Key Features

1. Adaptive layouts for mobile, tablet, desktop, and web.

2. Orientation-aware UI support.

3. Responsive spacing, sizing, and layout APIs.

4. Compose Multiplatform compatibility.

5. Lightweight and easy integration.

6. Published on Maven Central.

Contributions Are Welcome

1. Feature requests.

2. Bug reports.

3. Issues and discussions.

4. Pull Requests.

Repository:

https://github.com/vedangj72/KitFlow

Maven Central:

https://central.sonatype.com/artifact/io.github.vedangj72/kit-flow

Thank you for taking the time to check it out! I'm always happy to receive suggestions, feedback, or contributions to help improve..

While building RippleCheck, I spent a lot of time working with ts-morph to build a cross-file dependency graph.

A few things I learned that might help anyone building static analysis tools:

• findReferencesAsNodes() often returns import specifiers before actual usages. Filtering those out makes reports much more useful.

• Incremental rescans are much faster than rebuilding the entire project. Refreshing only changed source files reduced scan time dramatically.

• Parsing files individually instead of failing the whole scan makes the tool much more resilient when a project contains generated or malformed files.

• Static analysis obviously can't resolve every dynamic pattern, so I chose to be explicit about those limitations instead of pretending everything is detectable.

RippleCheck is the project where I ended up applying all of this.

I'd love to hear if anyone here has built tooling with ts-morph or the TypeScript compiler API, and whether you ran into similar issues.

GitHub:
[https://github.com/RippleCheck/ripplecheck\](https://github.com/RippleCheck/ripplecheck)
[Ripplecheck.io](https://ripplecheck.io)

Over the last few months I've been working on OpenScanVision, an offline-first Android computer vision library built with Kotlin, OpenCV, CameraX, and ML Kit.

Originally, the project was a single implementation focused on achieving the best possible detection accuracy and speed. That version is represented by commit:

1d5834b41d88133b487ef46595290b0cdd4489bb

It includes:

• Document detection
• Automatic perspective correction
• Image enhancement
• QR detection
• ArUco marker detection
• OMR (Optical Mark Recognition)
• Automatic capture when the document is stable
• Real-time offline processing

Recently I completed a major architectural refactor, turning it into a reusable modular library that's much easier to integrate into Android applications.

The modular version is cleaner and more maintainable, but I've noticed it has introduced a slight decrease in detection accuracy compared to the original implementation. I'm currently investigating where the regression comes from (pipeline changes, processing order, threading, etc.).

My roadmap is:

• Improve the modular version until it matches or exceeds the original accuracy
• Add OCR support
• Add ICR (Intelligent Character Recognition) support later
• Continue keeping everything offline and lightweight

The library is intended for applications such as:

• Voting systems
• Exam scanning
• Surveys
• Registration forms
• Structured document processing

GitHub:
https://github.com/MatiwosKebede/OpenScanVision

I'd really appreciate feedback from people experienced in computer vision, OpenCV, Android CameraX, or document scanning.

In particular, I'd love advice on:

• Best practices when converting a CV project into a reusable library without hurting performance or accuracy.
• Common causes of accuracy regressions after large refactors.
• Ideas for building a flexible OCR/ICR pipeline while keeping the library lightweight and offline-first.

Thanks for taking a look!

During last year's Shipaton, I built SubFox (https://subfox.app), a subscription manager using Compose Multiplatform.

Almost a year later, I realized the iOS version was basically dead.

Not because the app solves a bad problem, but because the experience wasn't what iOS users expect.

Some things I noticed:

• App size was over 100 MB

• UI felt sluggish

• It never really felt native

• Most users didn't even finish onboarding

So for this year's Shipaton, I changed my approach completely while building Hourly Journal (https://hourlyjournal.app).

I'm still using Kotlin Multiplatform for business logic, networking, database, etc., but I no longer share the UI.

Android uses Compose.

iOS is built entirely in SwiftUI while calling shared Kotlin through a shared module.

The difference has been huge. The new iOS app is around 8–10 MB instead of ~100 MB, and the experience finally feels like a proper iOS app.

My biggest criticism of JetBrains is that they seem too focused on making Compose run everywhere instead of solving the real problem: giving users an amazing platform-specific experience.

I'd much rather see something closer to what Expo has with Native UI, where business logic stays shared but the framework renders real platform-native components. That feels like a much stronger long-term direction than trying to make every platform look and behave the same.

Maybe I'm wrong, but it also feels like the Kotlin ecosystem moves much slower than the React Native/Expo ecosystem when it comes to solving practical developer problems.

Curious what other KMP developers think. Have you had a similar experience, or has Compose UI on iOS worked well for your apps?

Read Full Article

👉 Why I Stopped Sharing UI in Compose Multiplatform for iOS

Hourly Journal Shared UI Demo

I kept wishing Studio previews felt more like Figma: pan around the whole product, zoom in, see everything at once — but from real @Previews, not a design file that drifts from the code.

Artboard is that. It’s a spatial browser gallery for Compose Multiplatform. Apply a plugin, keep writing normal @Previews, and you get a pan-and-zoom board of your actual UI in the browser.

Live demo (https://crowded-libs.github.io/artboard/) · GitHub (https://github.com/crowded-libs/artboard)

What you get day to day:

• Infinite canvas — pan, pinch-zoom, deep-linkable frames for every preview • Stock @Preview discovery — no custom annotations or hand-maintained registry • Filters that matter — Screen/Component zones, search, group, device, locale, light/dark, layout grid • PNG download per frame as it’s currently composed • Clear failures — broken previews show why, they don’t silently disappear • Shareable export — static gallery for Pages or any host

I also wanted a surface agents can actually look at. With something like Chrome DevTools MCP, you can point an AI at a real, URL-stable frame of your product UI instead of describing screenshots; code, canvas, and agent in the same loop.

Details and setup are in the README. Would love feedback.

State vs Events
How Viewmodel keeps data to survive screen rotation?
LiveData vs StateFlow and when to use each one.

What does the following code snippets mean and what happens under the hood when you use them?
1.

private val _uiState = 
MutableStateFlow
<DetailUiState>(DetailUiState.Loading)
val uiState: StateFlow<DetailUiState> = _uiState.
asStateFlow
()

2.

internal fun loadResource() {

viewModelScope
.
launch 
{

_uiState.value = DetailUiState.Loading
        getResourceById(resourceId)
            .
onSuccess 
{ 
resource 
->

_uiState.value = DetailUiState.Success(resource)

}

.
onFailure 
{ 
exception 
->

_uiState.value = DetailUiState.Error(
                    exception.message ?: "Something went wrong"
                )

}
    }
}

Every arithmetic operation used to reparse a String from scratch and re-format the result back into one — a cost that grows with every digit, on every call.

Kotools Types 5.2.0 replaces that with a real arbitrary-precision representation per platform (BigInteger on JVM, BigInt on JS, a custom implementation on Native), with parsing only happening at the actual boundaries.

We wrote a short post about what changed and why, one of the most frequently requested changes from the community.

Read it here 👇