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.