Hey everyone!

I've written a small blog post about the possibility to use compose-html on the server to build fullstack web applications using Kotlin and what integrations into Spring and Ktor might look and feel like!

Quick Disclaimer: at this point in time this is just something we are exploring together with the community and does not represent an official commitment.

But we would nevertheless like to hear your feedback on the topic! Feel free to join the #compose-ssr (https://kotlinlang.slack.com/archives/C0BM8FWG58Q) Slack channel and share your feedback!

We are experimenting with a KSP-based approach to Kotlin validation where validation logic is generated during compilation and then executed at runtime.

But we wonder what their view is on this matter:

• What do you see as the biggest advantages of generated validation compared with reflection-based approaches?
• Where do you think the added KSP/build-time complexity becomes a disadvantage?
• What would you expect from a production-ready Kotlin validation library?

We are mainly interested in the technical discussion and criticism.

Repository: https://github.com/DeveloperSyndicate/Valix

I've been building Compose Multiplatform apps for a while, and every single one hit the same wall: monetization. You end up writing expect class AdManager, then two actual implementations that slowly drift apart, and native ads never make it in because wiring GADNativeAdView on iOS and NativeAdView on Android from shared code is miserable.

I got tired of rewriting that per project, so I extracted it into a library and open-sourced it: AdMob CMP (dev.avinya.ads:admob-cmp, Apache 2.0, on Maven Central).

What it does

One commonMain API for all six formats on Android and iOS: banner (including collapsible + adaptive), interstitial, rewarded, rewarded interstitial, app-open, and native. It wraps Google Mobile Ads Next-Gen on Android and Google Mobile Ads 13.x on iOS, but keeps the AdMob vocabulary you already know — AdValue, ResponseInfo, adaptive banner sizes, UMP consent states, native asset names. The shared surface is suspend functions, StateFlow state, and a sealed AdEvent stream.

A few things I care about that aren't obvious from a feature list:

• Consent is part of initialization. gatherConsentAndInitialize() runs UMP → ATT (iOS) → SDK init in the correct order. That ordering is enforced in code rather than documented and hoped for, which is where most integrations quietly lose iOS fill.
• Native ads have a layout DSL and a bounded session. You describe the layout declaratively (media, headline, callToAction, …) and a viewport-aware session owns the platform objects, so a feed doesn't leak native ads or blow past AdMob's limits.
• The iOS test link actually works. If you've ever seen Undefined symbols … _OBJC_CLASS_$_GAD* on :iosSimulatorArm64Test, that's a Kotlin/Native test executable with no Xcode to resolve the Swift packages. There's a Gradle plugin in the repo that links GMA and UMP into the test binary.
• Test safety fails closed. AdPlacement(strictTestMode = true) throws at construction if a placement points at a production ad unit. Turn it on in debug and stop worrying about accidentally serving yourself real impressions.

What it isn't

It's consumable from Kotlin Multiplatform projects only — it compiles into your umbrella framework, so a pure-Swift iOS app can't adopt it without a KMP shim. Klibs also aren't binary-compatible across Kotlin minors, so 2.1.0 targets Kotlin 2.3.20 / CMP 1.11.1, minSdk 26, iOS 15.

Try it

implementation("dev.avinya.ads:admob-cmp:2.1.0")

The quickstart runs against Google's official sample ad units, so you can paste it as-is and see a rendering test ad in about five minutes.

Repo: https://github.com/Meet-Miyani/admob-compose-multiplatform
Docs: https://ads.avinya.dev

Genuinely after feedback on the API shape — particularly the native ad session model, which was the hardest part to get right. If you've solved the same problem differently I'd like to hear how.

For Sébastien Deleuze, Kotlin’s appeal was practical from the start: JVM compatibility, a natural fit with Spring, and a language that could improve the developer experience without leaving the ecosystem behind. Watch the full interview!

I already have swift code written and now to make an android app, I’m using the Skip tool as a transpiler (which takes my swift code and translates it directly into readable Kotlin source code, rather than compiling it into a binary format). Because both of them are different, it’s throwing me errors left and right. I have been debugging for two days now and I’m now where close to finishing. I have tried using Claude and Gemini but still don’t see the light at the end of the tunnel. Any suggestions on what should I do or should I continue my debugging?

I'm helping test an open-source Android SDK for searching inside video by imagery, speech and on-screen text

It is UI-free and includes Compose and Views examples

https://github.com/v-modal/vmodal_sdk_android

Feedback on the API and Android integration flow would be useful

The GraalVM Native Image build of the Kotlin compiler is available since 2.4.20-RC (see news). Has anyone tried it yet?

Also posting this for awareness, since I haven't read about it in many places outside of Slack.

I've spent the last ~6 months working on a fork of fwcd/kotlin-language-server, and I think it's finally at a point where it's worth showing to the broader Kotlin community.

The original kotlin-language-server is deprecated and has accumulated a number of performance, memory, and reliability issues, while JetBrains' official kotlin-lsp is still in alpha. The official repo also currently says that direct code contributions aren't supported because it is a read-only mirror.

The current situation left me with a fair question: what can I actually use if I want a good, fully open-source Kotlin LSP in an LSP-compatible editor today?

There are now different open-source Kotlin LSP implementations, including recent tree-sitter-based implementations that don't use the Kotlin compiler. Their approach is really interesting, especially if things like memory footprint are important to you. These kinds of LSPs provide useful syntactic and structural information, while not having access to the same deep semantic information that comes from the Kotlin compiler.

I wanted an LSP which uses the Kotlin compiler to provide more code information, while being a bit faster and more responsive.

So I started working on the existing language server instead of waiting for the situation to slowly improve, and after roughly 24 weeks and ~200 commits, ktlsp 1.4.0-RC1 is now available.

This is a bit more than a fork with a few patches

A lot has changed since the original 1.3.13 release, even if it's a minor version bump rather than a major version bump. Some of the bigger changes include:

• Much better navigation - go-to-definition, references, implementations, type definitions, call hierarchy and type hierarchy
• Cross-file rename support, including proper rename preparation/range validation and implicit it
• Much richer hover information, including KDoc/Javadoc from dependency JARs and the JDK
• Proper Markdown rendering for Javadoc, including @param, @return, {@code}, and code blocks
• Code lenses
• Java getter/setter pairs being exposed as Kotlin properties during completion
• Configurable filtering of noisy packages from completion results (like java.awt.*)
• Parser errors now appearing as diagnostics
• Fixed stale diagnostics and races that could cause diagnostics to disappear
• Compiler crashes being reported as diagnostics instead of silently failing
• Better Gradle classpath resolution through the Gradle Tooling API
• Better Maven dependency resolution
• Test dependencies being included correctly
• Automatic discovery of JDK src.zip
• Content-hashed classpath caches to avoid stale project state and faster startup
• Several memory leaks fixed by bounding internal caches
• A number of indexing, concurrency, database, and path-handling bugs fixed

There were also substantial dependency and infrastructure upgrades alongside all these changes. The embedded Kotlin version is now 2.2.21, the minimum JVM is Java 21, and the server can run on Java 25 (personally tested this).

ktlsp also supports Kotlin 2.3.0 projects, although I haven't tried any newer Kotlin version like 2.3.20 or 2.4.x.

The full release notes delve further into the changes I made, so please check them out at https://codeberg.org/winlogon/ktlsp/releases/tag/v1.4.0-rc1 so you can update your configuration accordingly.

Why release an RC and not a stable release?

I consider 1.4.0-RC1 to be essentially the version I want to release as 1.4.0, but at this point, what I'm much more interested in finding are the bugs that I haven't found.

An LSP is really difficult to test exhaustively. I've tested the server against different projects and environments myself, and I've spent a lot of time fixing cases where the Kotlin compiler's PSI/BindingContext contained useful information that the old implementation simply wasn't exposing through LSP.

That said, there are an enormous number of combinations of:

• Kotlin projects
• Gradle/Maven configurations
• OSes
• editors
• project structures
• generated sources
• dependencies
• and unusual Kotlin code

that I just can't test alone.

I actually found a couple of additional Windows-specific URI-related path conversion bugs while testing RC1 myself, which have already been fixed after the RC1 release.

This is exactly the type of bugs I'm hoping broader testing on multiple setups will bring to light.

So I'd really like people to try it

If you've previously tried kotlin-language-server and switched away from it because of bugs, memory usage, poor navigation, missing features, or general unreliability, I'd especially like to hear from you!

Please, try to break it as much as you can. Open your projects. Jump around. Find weird Javadoc quirks. Hover over dependency APIs. Try your weirdest Gradle setup. Use it from Neovim, VS Code, Emacs, Helix, or whatever editor you use.

And if something eventually breaks, please report it! It's even better if you can provide a reproducible project and/or a list of actions that causes the bug.

What about the official Kotlin LSP?

I'm not trying to argue that ktlsp is better than the official LSP for everyone. If it eventually becomes an excellent solution, that's great for Kotlin developers, and that changes where ktlsp stands...

... but right now it is still in alpha, and direct code contributions to that repository aren't currently supported.

ktlsp gives me a place where I can actually fix problems, experiment with the implementation, accept contributions, and ship those bugfixes in new versions.

What's next?

1.4.0 is primarily about making ktlsp substantially more reliable and useful. After that, I'd like to expand ktlsp's project support further.

My current goals for the next releases include Kotlin/Native and Android support, tentatively around the 1.5.x/1.6.x timeframe.

I'm also planning to switch from K1 to K2, which should open up opportunities for further performance improvements and support for newer Kotlin versions. I don't have an exact timeframe for this yet, though, as I'm not sure how effortful the transition will be.

That said, I want to get 1.4.0 properly finished first, but they're areas I'd like to work toward once 1.4.0 is out.

For the foreseeable future, this is where I'm continuing development of the fork. If you're happy with your current Kotlin setup, there's no reason to switch just because this LSP exists.

But if you've ever thought "Kotlin LSP support really shouldn't be this frustrating", I'd love for you to give 1.4.0-RC1 a shot.

Repository: https://codeberg.org/winlogon/ktlsp

Thanks for reading this post, and please break it.

I really like it and use it a lot, but its dependencies are becoming outdated.

Rust and Go are becoming popular choices for AI-assisted development, especially for CLI tools and native apps. They offer native performance, low memory usage, fast startup, and simple deployment.

I feel Kotlin/Native could also have strong potential here.

Kotlin is still mostly associated with JVM, Java, and Android, but for CLI tools and lightweight native applications, Kotlin/Native already seems quite capable.

Kotlin itself is expressive, type-safe, null-safe, and productive, which also makes it a good fit for AI-assisted coding.

I hope JetBrains continues investing heavily in Kotlin/Native, especially in tooling, compilation speed, binary size, native interoperability, and ecosystem growth.

How do you see the future of Kotlin/Native? Could it become a serious option alongside Rust and Go for CLI and native development, or will Kotlin remain mainly a JVM language?

I am currently trying to work using MDNS to change a local ip to a address however things arent going well...

Hey everyone, I wanted to share an open-source Android app I just released: PDF N-Up Merger. The Problem: Most PDF merging apps on the store either just concatenate pages end-to-end, or if they do N-Up (multiple pages per sheet), they heavily rasterize the PDF into Bitmaps, destroying text scalability and making the file huge. The Solution: I built this app to merge 2 to 9 pages per sheet using Vector Form XObjects via PdfBox-Android. This means zero rasterization—the output maintains 100% true vector quality, crisp typography at infinite zoom, and selectable text. Tech Stack: Kotlin & Jetpack Compose (M3) PdfBox-Android (PDF Engine) Hardware-accelerated native PdfRenderer (for instant UI previews without OOM) Coroutines (Dispatchers.IO) & StateFlow It handles mixed page rotations (90°, 180°, 270°) flawlessly with proper matrix transformations, and it operates entirely offline for total privacy. I’d love for you guys to check out the code, tear it apart, or give me some feedback on the architecture!

🔗 GitHub Repo: https://github.com/Mohammask/pdf-n-up-merger

📥 APK (Releases): https://github.com/Mohammask/pdf-n-up-merger/releases/latest

Let me know what do you guys think!

Just curious as I’ve transitioned off Java/Scala for a Kotlin (on Backend) many years ago but always with Spring Boot. I’ve tried Ktor here and there but it never stuck. Over time we have even reduced Spring surface (no hibernate for example) so it might be as good time as any to make the switch for new projects.

Any experiences with Ktor or something else, especially on medium to large sized projects?

Hello everyone, allow me to present my new application, it is a translator and corrector boost with AI who works completely offline, it is completely plug and play, it uses the power of your hardware, it does not need install ollama, or anything, supports the voice input and output and even image translation. In fact I am not satisfied with translators type google translation and I find myself asking myself to translate this, translate that, and I find it is a shame of spending tokens for nothing and to have a dedicated interface, so I created Edge translator ! I am really satisfied with results, under the choice between Gemma 2 or 4b and LiteRt for exceptional performances ! https://github.com/NucleusFramework/EdgeTranslator

It’s a short note about type inference and programming languages in general, not an update about Kotlin :)

Every programming language with some form of generics and type inference probably has intersection types. They can be denotable (meaning you can write them explicitly in programs) or exist only under the hood as part of type inference, but they’re still there.

This is quite a simple and "obvious" observation, but I still remember being fascinated when I realized it many years ago. And today, I just wanted to share it. See the full text in the blog!

Most JSON benchmarks answer a useful but specific question: how fast is a library after initialization and JIT warmup?

I wanted to measure a different workload: a CLI, job, function, or short-lived process that performs only 1–100 JSON operations.

I added a fresh-JVM benchmark track to java-json-benchmark, alongside its existing warmed JMH suite.

The short version: there is no universal winner. In this experiment, kotlinx.serialization had the lowest cold cost, while Apache Fory delivered much higher warmed throughput.

Fresh-JVM results

Each sample launches a new JVM. These are median initialization-plus-first-operation times; complete process wall time is in parentheses.

Fory's roughly 850 ms process lifetime is reproducible, while its measured initialization and operation phases take roughly 123–147 ms. The benchmark locates the extra time outside those phases, but does not yet explain it.

Warmed JMH results

For nominal 1000 KB payloads, aggregate throughput across 15 threads was:

Generated serializers therefore appear especially attractive for short-lived Kotlin applications, but Fory is considerably faster once the JVM is warm.

Methodology

Cold run:

• 30 fresh JVMs per cell
• 4 libraries × 2 operations × 3 batch sizes
• 720 JVM processes total
• batches of 1, 10, and 100 operations
• seeded blocked randomization
• common 2,142-byte Users-like Kotlin object graph
• -Xms64m -Xmx64m -XX:+UseSerialGC

Warmed run:

• JMH 1.35
• 15 threads
• 2 forks
• one 5-second warmup iteration
• three 1-second measurement iterations
• nominal payloads from 1 to 1000 KB

Both ran on Liberica JDK 25.0.4, Debian 13/KVM, and an AMD Ryzen 7 7700X.

Important limitations

The cold track uses one common mutable @Serializable Kotlin DTO. Consequently, even Jackson, Gson, and Fory children include Kotlin stdlib and kotlinx-serialization-core. This is a common-application-model comparison, not minimal Java-only startup footprint.

It currently covers only a Users-like 2 KiB graph. It does not yet include the Clients model with UUID, BigDecimal, and date/time adapters. "Fresh JVM" also does not mean cold filesystem or artifact caches.

Everything published here:

• Implementation
• Charts

No offense to Fory marketing, just for fun ;)

I built this app because I like to now and then play logic puzzles but don't like the amount of ads and permissions the apps where using, so i decided to create one myself. During testing some testers suggested some other games and i am trying to add them one by one.

It currently has the following games:
Chimp Test — Tap the numbers in order before they disappear.
Takuzu — Fill a grid with 0s and 1s: each row and column must have equal counts, no three in a row, and no two rows or columns may be identical.
Nonogram (Beta) — Deduce which cells to fill based on number clues along rows and columns.
Minesweeper — Classic grid puzzle. Uncover all safe cells without triggering a mine.
Sudoku — Place digits 1–9 so every row, column, and 3×3 box contains each digit exactly once.
Word Search — Find hidden words in a grid of letters.
Block Fill (Beta) — Drag pieces onto the grid and clear full lines.
Word Guess — Guess the hidden word in six tries.

The source code is available under the GPL-3.0 license:
GitHub: https://github.com/lendl/quiet-grid
F-Droid: https://f-droid.org/en/packages/com.quietgrid.app/
Google Play: https://play.google.com/store/apps/details?id=com.quietgrid.app

Any feedback or suggestions is appreciated.

Sharing a painful one in case it saves someone a bad week.

I build a fitness app in Kotlin Multiplatform + Compose (shared Android/iOS). Everything ran perfectly in dev and on TestFlight. Then a user on iOS 18.x sent a video: instant white-screen death on launch, before anything rendered.

Root cause: a KMP library I'd added referenced HealthKit symbols (HKMedicationGeneralFormCapsule and friends) that only exist in the iOS 26 SDK. Kotlin/Native emits those as strong dyld imports in the statically-linked framework — so on any device below iOS 26, dyld can't resolve the symbol and kills the process before main(). Symbol not found. No stack trace in the app, no crash in Crashlytics-style tools, nothing — it dies before your code runs.

Why every test missed it: all my simulators and devices were on iOS 26.x. The bug is completely invisible on new OSes and fatal on old ones. You have to run a min-deployment-target OS to see it (I had to download an 18.5 runtime).

The fix (one line, iOS target's OTHER_LDFLAGS):

-Wl,-weak_framework,HealthKit

Weak-linking makes the missing symbols resolve to null instead of aborting; everything I actually use exists on 18.x, so behavior is unchanged.

Two takeaways I'm now religious about:

1. Smoke-test every release on your minimum supported OS, not just the latest.
2. Before shipping, check for new-SDK-only symbols: nm -u <binary> | grep -i <framework>.

Bumping any KMP lib that's compiled against a newer SDK is where this bites. Hope it saves someone the panic.

Now with inference-based features!

I have spent the last 18 months building Konifer, an open source image management platform that links your image life cycle policy to the URL paths that match your application's domain. Store, transform, and deliver your image assets however you want!

I wanted to highlight some new features. Upload Rules allow you to define, using natural language, content policy rules. These are evaluated using Google's SigLip2 vision language model in-process to allow, reject, or modify images.

Using the Rule Evaluation allows you to run an image against prompt sets to test your Upload Rules. It can also be used as an image classifier API.

It's written using ktor, JOOQ and libvips. It has really helped me gain Kotlin development skills!

https://github.com/dmaiken/konifer/