Skip to content

Anvil Moves to Maintenance Mode #1149

@JoelWilcox

Description

@JoelWilcox

Hey all! We wanted to share an update on the state and future of Anvil. We previously published a roadmap covering the major work we had planned, including K2 support and making Anvil a standalone tool with component generation, replacing the need for Dagger. While the team worked on adding K2 support in Anvil, we also started evaluating Zac Sweers’s Metro in parallel once it became available. We now have enough confidence in Metro’s future that we have decided to deprecate Anvil and endorse Metro as its replacement.

What does this mean for Anvil? We will no longer be finishing K2 support, nor moving forward with the other plans laid out in the roadmap; instead we’ll continue to focus our efforts on contributing directly to Metro. There are also no plans to add additional features or enhancements to Anvil going forward. However, we will continue to publish critical fixes and Kotlin compatibility updates for releases that support K1 (or languageVersion 1.9).

We understand this is a big shift and we don't take it lightly. We ultimately felt that this would be the most direct path to K2 support for all Anvil users (ourselves included), and that it makes more sense to consolidate efforts on one framework.

The remainder of this post will focus more on the “why”, as well as some details of where we are internally.

In its own words, “Metro is a compile-time dependency injection framework that draws heavy inspiration from Dagger, Anvil, and Kotlin-Inject. It seeks to unify their best features under one, cohesive solution while adding a few new features and implemented as a compiler plugin”.

Metro is closely aligned with Anvil’s long term vision, both in terms of its tech stack and the improvements it makes over existing solutions (Anvil included). To highlight a few items:

  • It is a pure Kotlin compiler plugin, eliminating the requirement of both KAPT and KSP in the build toolchain. This also means that it brings notable performance improvements. We already see a significant improvement in clean build times of two internal development apps at Square, even with KSP still running for our custom code generators.
  • Reasoning about errors is much simpler now that they originate from a single framework – developers do not need to work through whether an issue is occurring in Anvil, Dagger, or even with KAPT. It also means better error messages and reporting since all validation is unified instead of split across tools.
  • The API and generated code can now take advantage of newer Kotlin language features

Zac has also put a lot of thought and effort into improving the API while keeping ease of migration from other frameworks a top priority.

As part of our evaluation we:

  • Migrated two internal Square development apps to Metro, including using KSP processors to replace our existing Anvil code generators
  • Verified that changes we needed to make for Metro could be done in a backwards compatible way that allows us to toggle back and forth between building with Dagger+Anvil or Metro based on a build property
  • Performed a series of both manual and profiled benchmarks to confirm the expected build speed improvements
  • Contributed numerous fixes and interop enhancements (such as support for @ContributesBinding.rank and improved interop for @ContributesBinding.boundType) back to Metro

Square is now gearing up to migrate our production applications to use Metro and expand on what we learned from our evaluation. In concert with us, other units at Block are starting to evaluate Metro as well.

While we're choosing to deprecate Anvil in favor of Metro, we acknowledge that different projects are going to have varying needs when it comes to choosing how they move forward. For example, projects that want to unlock K2 now but require more of a proven track record in production may be interested in Anvil-KSP for now. For those who do plan to move to Metro, we intend to share any scripts and tools that we create internally for our own migration. However Metro is continually getting easier and easier to migrate to with each update and is much closer to a drop-in replacement than when we first started evaluating it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions