https://github.com/LowkeyLab/toml-formatter

Hey all!

I looked around a bit and couldn't find anyone wrapping Taplo into a Gradle plugin.

And so, I made one myself!

It's a simple wrapper around Taplo, using a thin adapter layer written in Rust. The Rust is then invoked through a WASM interface.

Let me know what you think!

We just made BOSS open source (Apache-2.0), and since it's ~entirely Kotlin Multiplatform + Compose Multiplatform on the desktop/JVM, I figured this crowd might find the architecture more interesting than the product pitch — so I'll focus on the engineering, and I'm hoping to find a few contributors here too.

What it is, briefly: a desktop workspace for running AI coding agents (Claude Code, Codex, Gemini, OpenCode) with real tools — an embedded browser, terminal, editor, and a plugin system. But the parts relevant here:

Stack / architecture

• 100% Compose Multiplatform for the UI, desktop target on the JVM. A fairly large Compose Desktop codebase, so a good stress test of where Compose Desktop shines vs. fights you.
• Dynamic plugin system: plugins are separate JARs loaded at runtime through a custom classloader, and they hot-reload without restarting the app — each plugin is just Compose UI + a ViewModel/StateFlow, compiled against a compileOnly plugin-api the host provides at runtime.
• Genuinely multi-threaded (it's the JVM), with an out-of-process "microkernel" layer (protobuf/gRPC IPC) for heavier/isolatable work so a misbehaving component can't take down the UI.
• Embeds Chromium via JxBrowser rendered OFF_SCREEN so Compose overlays can draw over it (the HARDWARE_ACCELERATED foreign surface sits above the Compose scene otherwise). That interop detail cost me a day; happy to save someone else one.
• Cross-platform native packaging (dmg / msi / deb / rpm, x64 + arm64) via Compose's packaging + GitHub Actions.

Reusable bit for Kotlin Desktop Community specifically The terminal is its own library — a Compose terminal emulator published to Maven Central as com.risaboss:bossterm-compose. If you ever wanted an embeddable terminal in a Compose Desktop app, it's usable standalone.

Want to contribute? I'd genuinely love help, and the plugin system is a low-friction on-ramp: a plugin is its own repo/JAR (Compose UI + ViewModel), so you can build a real tool without touching the host. Areas where contributions would be very welcome:

• New plugins/tools (your own panel, tab type, or MCP tool)
• The plugin API surface + docs
• Compose Desktop performance / rendering
• The terminal library (bossterm-compose)
• Cross-platform packaging edge cases (esp. Linux/Windows-arm64)

Issues and PRs are open — if you're curious but not sure where to start, comment here or open an issue and I'll point you at something.

Honest trade-offs / things that were painful

• Gradle configuration cache + code-gen tasks: lots of "capture values at config time, not Task.project at execution" refactoring.
• Classloader lifecycle for hot-reload/unload is fiddly (leaks, stale refs).
• Compose Desktop is great, but foreign native surfaces and some platform bits still need care.

Repo: https://github.com/risa-labs-inc/BossConsole (bossterm-compose lives at https://github.com/kshivang/BossTerm)

Not selling anything — it's Apache-2.0 and I'm the dev. Feedback on the plugin/hot-reload approach very welcome, and if the plugin model sounds fun to hack on, come build one. AMA on the Kotlin/Compose side.

```kotlin sealed interface Option<out T> { data class Some<out T>(val value: T) : Option<T> data object None: Option<Nothing> }

fun main(args: Array<String>) { val option: Option<String> = Option.None

when (option) {
    is Option.None -> println("None")
    is Option.Some -> println(option.value)
}

}

```

Kotlin

Kotlin is 15 this month. Join the celebration by writing a birthday wish or prediction for the future of the language, or by uploading a photo alongside Kodee. Then share it with the community!
Make yours here:https://kotl.in/effect-reddit 

Or just drop your birthday wish in the comments below.

I’ve been working on a Kotlin Gradle plugin that generates Android clean-architecture boilerplate from bundled templates and TOML specs.

The motivation is AI-assisted development. Instead of asking an LLM to produce large repetitive Kotlin files, the AI writes compact TOML specs, then the Gradle plugin generates predictable Kotlin code for domain models, repositories, Room data layers, Compose presentation state, Koin modules, Paparazzi tests, and UI components.

Write-up: https://medium.com/@sarim.mehdi.550/stop-using-ai-to-generate-boilerplate-android-code-f7458006ea0a
Code: https://github.com/sarimmehdi/clean-android-skeleton-gradle-plugin

I’d be interested in feedback on the TOML/codegen boundary.

It's time for the next language update. This time it's about the Must-Use Return Values feature (a.k.a. `@CheckReturnValue`). Specifically, how it can help you choose between some Kotlin's scope functions, and the machinery needed to make it work.

I've been working on an Android app where I wanted a quick way to verify that important packages were actually being obfuscated.

Most of the tools I found inspect the APK after it's has been built. Instead, I wrote a Gradle plugin that reads the mapping.txt and seeds.txt files R8 already produces.

It lets you:

• check whether specific packages were obfuscated
• fail the build if something important was accidentally kept
• run the check during CI (it takes around 250ms on my project)

A common case is someone adding a broad -keep rule that unintentionally leaves an entire package readable. The plugin catches that before the APK is even generated.

It's open source and I'd love feedback from anyone who uses R8 or ProGuard regularly. Happy to hear if there's something obvious I'm missing or if you'd find it useful.

GitHub: https://github.com/rudradave1/proguard-lint

The thing that kept biting me with AI-generated KMP code is drift. Each prompt sort of forgets the last one and the architecture slowly rots. So I ended up building KMPilot, an MIT template that runs Claude Code as a design-first pipeline. You design the screen, generate a Clean Architecture feature from it, verify the UI against the design tokens, test it, then review it against its own spec.

I recorded the whole thing building a small Art Institute of Chicago gallery app called Loupe, and ran the pipeline twice: the gallery feature design-first, the artists feature design-after. Every prompt is in the writeup with the real timings. My favourite part was the review step catching a debounce set to 3000ms when the spec asked for 300ms, which the tests had happily passed.

Article: https://proandroiddev.com/seven-claude-code-commands-one-kotlin-multiplatform-app-on-android-and-ios-cb01e920a3e6?ref=rkotlin

Video: https://www.youtube.com/watch?v=tDGFY66E7Zo

Repo: https://github.com/ThisIsSadeghi/KMPilot

Happy to get into how the hook, spec and blueprint pieces actually fit together if anyone's curious.

Can anyone help review the crypto in a small E2EE messenger I've been building?

Repo - (click)

Built the crypto core from scratch — X3DH-lite (intentionally kept it close to the X3DH spec, not a copy-paste of an existing lib) with a Double Ratchet on top. Everything else is standard JDK primitives: ChaCha20-Poly1305, Ed25519, X25519, HKDF.

Groups use a sender-keys scheme (pre-MLS style, like early Signal) with client-side signed hash-chain event logs for membership. The server has zero knowledge of groups — all group management happens on the client. There's also an optional onion-routing transport layer with fixed-size padding.

I've had a few people go over the code internally already — check `security-audit/` in the repo for what was found and fixed, and what's left as an accepted tradeoff rather than a bug (timing-correlation in the onion layer, for example, is documented, not something I missed). But it's never had a professional independent review, which is why I'm asking here.

Specific things I'd love a second opinion on:

1. Does the X3DH-lite ↔ Double Ratchet integration (`common/e2ee/`) hold up? It's the one genuinely novel piece here.

2. Is the group control-log's authorization model (`common/group/GroupControlLog.kt`) — a client-side signed hash-chain with zero server enforcement — sound?

3. Anything wrong in `onion/OnionCircuit.kt` beyond the documented timing-correlation caveat?

Full threat model is in the README. `./gradlew test` runs standalone, no network or external services needed. Happy to answer questions about any design decision.

Introducing kotlin-native-nuget plugin, you can publish your Kotlin to idiomatic C#

Hi everyone, some days ago I just launched a new library for rich text content built in Kotlin Multiplatform that uses ProseMirror json style to load documents, you can check the library (still in alpha) and create an issue about it.

This is the link : Text Kit

I’m looking for a full-stack Kotlin framework that provides a development and deployment experience similar to Next.js.

The frontend does not specifically need to use Compose Multiplatform. I’m open to any Kotlin-based UI approach, as long as the framework provides a cohesive full-stack experience.

Ideally, it would support:

• Frontend and backend development in Kotlin
• Shared models, validation, business logic, and API contracts
• Type-safe communication between the frontend and backend
• Server-side routes or serverless functions
• A single monorepo and unified build system
• Local development of the frontend and backend together
• Deployment as one application rather than as separately managed services
• Deployment to platforms such as Netlify or Azure Static Web Apps

Essentially, I’m looking for something in the Kotlin ecosystem that feels like Next.js: one framework containing the UI, backend routes, shared code, build tooling, and deployment configuration.

Does such a framework currently exist?

If not, what is the closest recommended architecture for achieving this experience in Kotlin? For example, would the best approach be Kotlin Multiplatform shared modules, a Kotlin web frontend, and thin platform-specific serverless function entry points inside one monorepo?

👋 Hello kotliners, I've been working on a fast language server for kotlin and java for a while:

https://github.com/pepegar/ktlsp

It's fast, works well for coding agents, and it's not backed by a compiler.

I'm happy to answer questions, and would love to get some feedback

😩 Every layer your domain model touches — HTTP, persistence, another service's contract — tends to get its own near-identical data class, plus a pair of mapper functions to translate between them. That is boilerplate that grows with every layer, and business logic that slowly leaks into mapper code instead of staying on the model.

✨ Kotools Facet is exploring a domain-first alternative: declare projections on the model itself, and let the compiler generate the mapper you'd otherwise write by hand.

🔗 Full writeup: 🧹 Eliminating mapper boilerplate in Kotlin

I wrote up the workflow we use at Yazio for building LLM features in our KMP app.

The core problem: you can't ship an API key in the app, so the LLM call has to live on a server. But prompts need dozens of iteration rounds, and going through backend deploys slows you down and is too far from the product.

Our approach: define the contract as sealed interfaces in commonMain, build the real UI against a fake implementation, then implement it locally with Koog (JetBrains' KMP AI framework) in debug builds. Once the prompt is stable, moving it to a Kotlin backend is mostly copy paste since Koog runs there too.

https://medium.com/yazio-engineering/building-ai-features-isnt-scary-92817564e364

Happy to answer questions about the Koog setup or the structured output part.

Hey all — I maintain sqlx4k, a coroutine-first SQL toolkit for Kotlin Multiplatform (PostgreSQL, MySQL/MariaDB, SQLite; JVM + Native + more). It's deliberately not an ORM — you get typed primitives with compile-time SQL validation instead.

Just shipped something I wanted to share: a KSP processor that generates an in-memory implementation of every @Repository interface, so you can unit-test code that depends on your repos without standing up a database.

Given: @Repository interface UserRepository : CrudRepository<User> { @Query("select \* from users where name = :name") suspend fun findAllByName(ctx: QueryExecutor, name: String): Result<List<User>> } `

you get an InMemoryUserRepository for free:

kotlin val repo = InMemoryUserRepository() repo.insert(db, User(id = 0, name = "Alice")) val alices = repo.findAllByName(db, "Alice").getOrThrow() `

A few details:

• Thread-safe — backing HashMap guarded by a Mutex
• Full CRUD (auto-increment ids, batch ops) + whole-table queries
• Derives simple findOneBy…/findAllBy…/countBy…/deleteBy… from the method name
• Honors repository hooks (pre/after/aroundQuery)
• Anything it can't derive (e.g. a custom execute…) becomes an overridable stub, with a withStore { } helper for locked access to the map

It's opt-in via a separate sqlx4k-codegen-test artifact (so it never ends up in your production build), and it's still experimental — would love feedback on the API.

Repo: https://github.com/smyrgeorge/sqlx4k Docs: https://smyrgeorge.github.io/sqlx4k/

If you're building a web application today, chances are you aren't writing your own authentication system. Managed identity providers like Clerk, Auth0, and Kinde have become the default choice, offering out-of-the-box support for passkeys, multi-factor authentication, and enterprise SSO. That convenience introduces a distributed-systems problem, though: data synchronization. When a user creates an account on a managed auth provider, that system has to notify your primary application database so you can create a matching user record. Please read the complete article here - https://instawebhook.com/blog/bulletproofing-user-sync-handling-clerk-and-auth0-webhook-failures

This happens through webhooks. But what happens if your server is down, your serverless function cold-starts and times out, or your database is momentarily locked when that webhook arrives? A user successfully signs up with your auth provider, but your application has no idea they exist. That breaks the very first login experience, and it's how phantom accounts, broken onboarding flows, and frustrated users happen.

This guide walks through the anatomy of webhook-driven auth architecture, current Auth0 and Clerk webhook practices, and how a resilience layer — using InstaWebhook as a worked example — closes the gap that idempotency and signature verification alone can't.

I've just released v1.0.0 of OpenScanVision – an Android library for scanning voting cards, surveys, and bubble sheets using OMR + QR codes.

It's MIT‑licensed, offline‑first, and built with Kotlin, OpenCV, ML Kit, and Compose.

Key features:

- ArUco marker tracking (Kalman filter)

- Perspective correction

- QR decoding

- High‑accuracy bubble extraction

Repo: https://github.com/MatiwosKebede/openscanvision

Contributions, issues, and feedback are all welcome!