Bill Phillips

Application architecture can either die perfect, or live long enough to be a huge, risky problem to solve. If you’re unlucky, that risky problem might require you to add new data boundaries in memory, persistent storage, and even in downloadable dynamic feature modules. It is possible to do it safely, though, using structured concurrency, dependency injection, and a carefully designed tenancy model. By using modern tools and proven legacy code techniques, even a big migration like this is possible without interrupting engineers with tedious migration work, or customers with forced sign outs.

Dependency Injection remains a cornerstone of scalable Android architecture—but as the platform evolves, so do the tools and patterns we rely on. This panel brings together DI experts to discuss the current and future state of DI in Android, from Google’s Hilt and Kotlin-first Koin to community-driven frameworks like Dagger, Anvil, and Metro. We’ll explore real-world lessons and technical insights across topics such as: What are the key strengths and weaknesses of current DI frameworks, and how should teams choose the right tool for their architecture and scale? What are the tradeoffs of using DI at scale, and where do most frameworks begin to show their limitations? How can teams effectively manage complexity, performance, and maintainability as their DI setup grows? Can Dependency Injection be used for more than just wiring services and repositories? What are some unconventional or creative use cases, and how well do frameworks support them? What are effective strategies for migrating between DI frameworks, especially in large codebases? With Kotlin Multiplatform adoption increasing, how can DI be applied across shared and platform-specific code? What are the challenges of building and maintaining multiplatform DI solutions, and what opportunities does this unlock for cross-platform architecture? What goes into designing and building a DI framework from the ground up? What technical decisions, architectural patterns, and developer experience considerations must be addressed—and where do current solutions still fall short?