Forem: Vikas Soni

I Audited Google’s “Now in Android” Build Architecture (Here is what I found)

Vikas Soni — Mon, 11 May 2026 20:02:33 +0000

The Black Box of Gradle Builds As Android applications grow, they inevitably turn into deeply nested, multi-module mazes. You start with a clean architecture, but fast forward 6 months, and you are staring at a 5-minute build time, wondering where it all went wrong.

Is it a circular dependency? Is a rogue module breaking the Configuration Cache? Are we still running KAPT when we don’t need to?

For a long time, answering these questions required digging through Gradle build scans and manually tracking build.gradle files. Web developers have had "Google Lighthouse" for years to instantly audit their site’s health. I realized Android developers needed the exact same thing for their build systems.

So, I built Gradle Lighthouse — an open-source, zero-configuration build intelligence plugin.

To test if it was truly enterprise-ready, I decided to point it at the gold standard of modern Android architecture: Google’s Now in Android (NIA) repository.

The Experiment: Auditing “Now in Android”
The Now in Android app is Google’s official showcase for modern Android development. It uses Jetpack Compose, a highly modularized architecture, and Kotlin Multiplatform. It is the perfect stress test.

I added the Gradle Lighthouse plugin to NIA’s root build.gradle.kts (it only takes one line) and ran ./gradlew lighthouseAudit.

The engine ran 20+ architectural checks across the entire module graph. I expected a perfect score. I was wrong.

The Results: NIA Scored a 50/100 (“At Risk”)

The NIA project received an overall Architecture Score of 50/100, placing it in the “At Risk” rank.

Wait, how is the official Google showcase app at risk? Lighthouse runs an incredibly strict set of rules. Here are the most fascinating flaws it uncovered in NIA’s build scripts:

Configuration Cache Blockers (allprojects anti-pattern) Lighthouse immediately flagged a critical error: the root build.gradle.kts uses allprojects{} or subprojects{} blocks.

The Impact: This forces Gradle to eagerly configure every single module, even if you are only building one. It actively blocks migration to the Configuration Cache and the upcoming Isolated Projects feature in Gradle 9.x.
The Fix: Replacing this with convention plugins reduces configuration time by 50–90%.

The “Dark Module” Test Lighthouse scans for “Dark Modules” — modules that exist in the graph but have absolutely zero test files. The root nowinandroid module was flagged as a completely untested risk vector. In large enterprise projects, these dark modules accumulate over time and make safe refactoring impossible.

Subscribe to the Medium newsletter

Version Catalog Clutter & Bundle Opportunities NIA uses a modern libs.versions.toml file, but Lighthouse found two major areas for hygiene improvement:

Unused Entries: The catalog defines 103 library entries, but Lighthouse warned that several appear to be unused across the graph, creating unnecessary noise during dependency upgrades.
Missed Bundles: Lighthouse found 9 bundle opportunities. For instance, NIA declares 50 different androidx libraries and 3 coil libraries individually across modules, instead of grouping them into [bundles] for cleaner, safer dependency management.

Security and Reproducibility Blindspots Finally, Lighthouse flagged two easily fixable security and stability issues:

No Dependency Locking: NIA doesn’t use dependencyLocking. This means a transitive dependency could be silently upgraded to a compromised version between builds.
No JDK Toolchain: The build scripts lack a pinned JVM Toolchain (kotlin { jvmToolchain(17) }), which can lead to inconsistent bytecode across different developers' machines.
The Takeaway for Your App
Google’s Now in Android is a fantastic repository, but it proves a crucial point: As a project scales, build hygiene degrades silently.

The difference between a legacy app and a highly scalable one is often just 50ms of build time compounded over 100 modules. But you can’t fix what you can’t measure.

Get Your Lighthouse Score
I built Gradle Lighthouse to be completely free, open-source, and plug-and-play. If you want to see your project’s score and find out exactly why your builds are slow, it takes exactly one line of code.

Add this to your build.gradle.kts:

plugins {
  id("io.github.dev-vikas-soni.lighthouse") version "2.1.1"
}

And run:

./gradlew lighthouseAudit

Check out the repository here, and let me know what score your project gets!

🔗 GitHub: Gradle Lighthouse

(⭐️ If this tool helps you clean up your build graph and save time, I’d deeply appreciate a star on GitHub to help the open-source project grow!)

# Building a Production-Ready Kotlin Multiplatform SDK (Android + iOS)

Vikas Soni — Tue, 05 May 2026 18:42:53 +0000

Kotlin Multiplatform is no longer “experimental curiosity” — it’s a serious choice for production apps.

Companies like Netflix, Cash App, and McDonald's are already using it to share business logic across platforms while keeping native UI experiences intact (LevnTech).

In this post, I’ll walk through how I built a production-ready Kotlin Multiplatform SDK that works seamlessly across Android and iOS — along with the real challenges, trade-offs, and lessons learned.

🤔 Why Kotlin Multiplatform?

Unlike Flutter or React Native, Kotlin Multiplatform doesn’t try to replace native development.

Instead, it lets you:

Share business logic (networking, caching, models)
Keep native UI (Jetpack Compose / SwiftUI)
Avoid code duplication
Maintain near-native performance

This approach is powerful because you’re not forced into an “all-or-nothing” architecture — you can adopt it gradually (InfoQ).

🧱 Project Architecture

A typical KMP setup looks like this:

Android App → Uses shared module
iOS App → Consumes Kotlin framework
Shared Module → Business logic

Kotlin compiles your shared code into:

A native framework for iOS
A standard module for Android

This means no bridges, no JavaScript layer — just native performance (DEV Community).

🚀 What I Built

The goal was simple:

👉 Create a production-grade SDK that:

Can be reused across apps
Is easy to integrate
Handles real-world concerns (networking, error handling, scalability)

⚙️ Key Challenges (and How I Solved Them)

1. API Design for Two Worlds

Designing an SDK that feels “native” on both Android and iOS is harder than it sounds.

Solution:

Keep APIs minimal and platform-agnostic
Use expect/actual wisely
Avoid leaking platform-specific abstractions

2. Dependency Management

Not all libraries are multiplatform-ready.

Solution:

Prefer KMP-compatible libraries (e.g., Ktor)
Abstract dependencies behind interfaces

3. iOS Interoperability

Swift + Kotlin interop can get tricky.

Solution:

Design Swift-friendly APIs
Avoid overly complex generics
Test from Xcode early, not later

4. Build & CI Complexity

KMP builds can become slow and complex.

Solution:

Optimize Gradle configuration
Separate concerns into modules
Cache aggressively in CI

🧪 Production Learnings

After taking this setup closer to production, a few things stood out:

You can realistically share 70–80% of business logic
Debugging is manageable with standard tools
The biggest gains come from team alignment, not just code reuse

📦 When Should You Use KMP?

Kotlin Multiplatform is a great fit if:

✅ You have both Android and iOS apps
✅ Your business logic is complex and shared
✅ You want native UI but shared architecture

Avoid it if:
❌ Your app is UI-heavy with little shared logic
❌ Your team lacks Kotlin experience

💡 Final Thoughts

Kotlin Multiplatform hits a sweet spot:

Not a full abstraction layer
Not fully separate codebases

It gives you shared logic where it matters, without sacrificing native quality.

If you're building something meant to scale across platforms, it’s absolutely worth considering.

🔗 Full Article

If you want the complete deep dive with implementation details, check it out here:

👉 https://medium.com/proandroiddev/building-a-production-ready-kotlin-multiplatform-sdk-for-android-ios-0044cd5d1baf

🙌 Feedback

If you're working with Kotlin Multiplatform or planning to, I’d love to hear your experience.

What’s been your biggest challenge so far?