Just seen it's been published. Still unlisted, but visible.

Hi everyone! 👋

​I'd like to share an open-source side project I've been developing called AnvilAI — a native Android client designed to run Large Language Models (LLMs) completely on-device without relying on cloud APIs or external servers.

​Most mobile AI wrappers require cloud subscriptions or send user data to remote servers. I wanted to build something native, fast, private, and secure for Android devices.

​Key Features:

​Vulkan GPU Acceleration: Built with a C++ NDK engine layer to leverage mobile GPUs for real-time token generation.

​100% Offline & Private: Zero cloud dependency and zero telemetry. Your prompts and outputs never leave your device.

​Encrypted Storage: All local chat history and settings are encrypted at rest using SQLCipher.

​Modern UI: Built 100% in Jetpack Compose (Material 3) with clean architecture (Hilt, Coroutines, Flow).

​Source Code & Download:

The project is 100% open-source! You can check out the source code, inspect the architecture, or download the pre-built APK from the GitHub Releases tab here:

​https://github.com/denizaydogan1902/AnvilAI

​I would love to get your thoughts, UI/UX feedback, or ideas for future updates. Feel free to leave a star ⭐️ on GitHub if you find it useful!

There's really not many non trival ui samples for CMP posted online and I wanted to show you can build relatively fancy samples in cmp just as easily as expo people on x

Targets Android, iOS, and desktop (JVM).

iOS even has a second app with native iOS glass ui components embedded the compose views.

Code: https://github.com/luca992/flighty-cmp

This app was made almost entirely by an agent with little supervision in the background while I worked my actual job.

I don't condone building apps this way. I did not review the code, I take no ownership of it, and you absolutely should not use it.

This is just a proof of concept that you can build native multiplatform apps just as quickly, maybe even quicker, without bundling a JS runtime with expo/react native.

Ps. Tried out kotlin-toolchain for the first time in here too .. it's a bit buggy but I liked it way more than I thought I would. Looking forward to using it more

I run a super minimal artix linux setup with hyprland and have setup the official kotlin lsp (vscode one) with neovim

While building a free geography quiz game, I needed an interactive 3D globe — spinnable, with markers and animated flight arcs between cities. I assumed I'd find a library. I didn't: nothing cross-platform, nothing embeddable, nothing customizable enough. So the globe became its own project.

Once it worked, extracting it was the obvious move: the component knew nothing about my game anyway — it just renders coordinates, markers, and arcs on a sphere. Generalizing it forced better design (a clean config API instead of my hardcoded colors, custom marker styles instead of my three), and publishing it meant the next person searching "Android 3D globe library" finds an answer instead of my dead end.

core-globe is now on Maven Central (io.github.advait8:core-globe, v0.2.1): a Kotlin Multiplatform library rendering an interactive globe with markers, animated great-circle arcs, atmosphere, and camera fly-to. One design decision worth mentioning for this crowd: v0.2.1 deliberately removed country borders. Border data is geopolitically contested — any boundary file takes sides somewhere — and for an open-source library, shipping no borders is cleaner than shipping someone's borders. Cities and coordinates only.

Some things I learned publishing to Maven Central for the first time: the signing/portal setup has more friction than any code I wrote, automate it in CI on day one; a real consumer app (mine) is the best API reviewer; and extracting a library mid-project roughly doubled the polish of the component in the main app too.

The library is free (as in both senses), and the game it came from is free with no ads — the library is arguably the more useful artifact of the whole project.

https://github.com/advait8/core-globe

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.

Hi everyone,

I’ve recently finished building my Android app, but I now realise that I probably should have used Kotlin Multiplatform from the beginning so the app could support both Android and iOS.

The Android app is already complete, and my goal is for the iOS version to have 100% of the same functionality, features, business logic, data, and overall user experience.

I’m now trying to understand the easiest, safest, and most practical way to migrate the existing project without breaking or negatively affecting the current Android version.

From what I understand, I have three possible options:

Use Kotlin Multiplatform for the shared business logic, database, repositories, and state management, while building a separate native iOS interface in SwiftUI.

Use Kotlin Multiplatform together with Compose Multiplatform, allowing both the business logic and most of the user interface to be shared between Android and iOS.

Use a hybrid approach, with Kotlin Multiplatform and Compose Multiplatform for most of the app, while using SwiftUI or native iOS components for areas that require a more native experience or platform-specific functionality.

Which of these approaches would be the easiest for an existing Android app that is already built with Kotlin and Jetpack Compose?

My main priority is avoiding unnecessary rewriting while keeping both versions functionally identical. I would also like future features, fixes, and updates to be easier to maintain across Android and iOS.

Would the hybrid approach be easier and more reliable than trying to share the entire interface with Compose Multiplatform?

For example, could I keep most of my current Compose screens and use native iOS components only where necessary, such as navigation, tab bars, notifications, in-app purchases, biometrics, file handling, sharing, backups, permissions, and background tasks?

Is Compose Multiplatform mature and reliable enough for a production iOS app? Can I reuse most of my existing Jetpack Compose interface, or would a significant amount of it still need to be rewritten?

I’m also planning to use Codex to help with the migration. What prompt or workflow should I give it for a project of this size?

Should I use High, XHigh, Max, or Ultra reasoning? Would using /goal help Codex manage the migration more safely and complete it incrementally?

Has anyone completed a similar migration from an existing Android app?

I would really appreciate advice on which approach is easiest, how the project should be structured, what order the migration should follow, how platform-specific features should be handled, and what common mistakes I should avoid.

Thank you all in advance!

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

[ Removed by Reddit on account of violating the content policy. ]

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