はじめに
Jetpack ComposeはAndroidアプリ開発におけるUI実装の中心的な選択肢としてかなり定着してきました。
一方でCompose自体の進化も早く、BOMや各ライブラリの更新内容を毎回細かく追い続けるのはなかなか大変です。
2026年4月に、Jetpack Compose April 26 Releaseが安定版として公開されました。
今回のリリースでは、Compose core modules 1.11、共有要素まわりのデバッグツール、トラックパッドイベント対応などが含まれています。
今回は、その中でもAndroidアプリ開発者目線で気になった変更点をざっくり整理してみます。
Jetpack Compose April 26 Releaseとは
Jetpack Compose April 26 Releaseは、2026年4月22日に公開されたComposeの安定版リリースです。
今回のリリースを利用するには、Compose BOMを以下のように更新します。
implementation(platform("androidx.compose:compose-bom:2026.04.01"))
Compose BOMを利用している場合、各Composeライブラリのバージョンを個別に指定する必要がなく、BOMのバージョンを更新することで対応する安定版の組み合わせに揃えることができます。
dependencies {
implementation(platform("androidx.compose:compose-bom:2026.04.01"))
implementation("androidx.compose.ui:ui")
implementation("androidx.compose.material3:material3")
implementation("androidx.compose.ui:ui-tooling-preview")
debugImplementation("androidx.compose.ui:ui-tooling")
}
Composeを複数モジュールで利用しているプロジェクトでは、個別にバージョンを管理するよりもBOMで揃えた方が、依存関係のズレを抑えやすくなります。
気になった変更点
今回のリリースで個人的に気になったのは、主に以下の3つです。
- Compose core modules 1.11
- 共有要素アニメーションのデバッグツール
- トラックパッドイベント対応
それぞれ見ていきます。
Compose core modules 1.11
今回のリリースには、Compose core modulesのバージョン1.11が含まれています。
Composeは、UI、Foundation、Material、Animation、Runtimeなど複数のMaven Groupで構成されており、それぞれのライブラリにリリースノートが用意されています。
そのため、Compose全体を更新する場合は単にBOMのバージョンだけを見るのではなく、自分たちのプロジェクトで使っている領域に影響がありそうかを確認する必要があります。
例えば、以下のような観点です。
- compose-ui
- compose-foundation
- compose-material3
- compose-animation
- compose-runtime
- compose-ui-test
特に実務ではComposeの更新によってUIの見た目が大きく変わるというより、テストやアニメーション、入力イベント、内部挙動の変更がじわっと効いてくることがあります。
そのため、BOM更新時には最低限以下は確認しておきたいところです。
- 主要画面の表示崩れがないか
- Compose UI Testが落ちていないか
- スクロールやジェスチャーの挙動に違和感がないか
- Material3コンポーネントの見た目や余白に変化がないか
- 独自Modifierやアニメーションまわりに影響がないか
Composeは宣言的UIなので、View時代よりもUI実装の見通しは良くなりました。
ただし、依存ライブラリの更新による影響がゼロになるわけではありません。
BOMでバージョン管理が楽になる分、更新時の確認観点はチーム内である程度パターン化しておくとよさそうです。
共有要素アニメーションのデバッグツール
今回のリリースで特に面白いと感じたのが、共有要素アニメーションまわりのデバッグツールです。
公式ブログでは、SharedTransitionLayoutをLookaheadAnimationVisualDebuggingで囲むことで、ターゲット境界、アニメーションの軌跡、マッチ数などを確認できると紹介されています。
イメージとしては、以下のような形です。
LookaheadAnimationVisualDebugging {
SharedTransitionLayout {
// Shared Element Transitionを利用したUI
}
}
共有要素アニメーションは、うまく動いている時はかなり気持ちの良い表現になります。
一方で、期待通りに動かない時は原因の切り分けが難しくなりがちです。
- どの要素同士が対応しているのか
- 遷移先のboundsがどう解釈されているのか
- アニメーションの軌跡が意図通りか
- sharedContentStateのkeyが正しく一致しているか
このあたりは、コードだけを見てもすぐに分からないケースがあります。
特に一覧画面から詳細画面へ遷移するようなUIでは、要素の対応関係が崩れると「なんとなく変な動き」になりやすいです。
今回のような視覚的なデバッグツールが入ることで、共有要素アニメーションの調整はかなりやりやすくなりそうです。
個人的にはComposeのアニメーションまわりは今後さらに実務投入しやすくなっていくのではないかと感じました。
トラックパッドイベント対応
もう一つ気になったのが、トラックパッドイベントへの対応です。
公式ブログでは、今回のリリースにトラックパッドイベントが含まれていることが紹介されています。
スマートフォンだけを対象にしたアプリでは、トラックパッドイベントを意識する機会は少ないかもしれません。
ただ、Androidアプリが動作する環境は以前より広がっています。
- タブレット
- Chromebook
- 折りたたみ端末
- デスクトップライクな利用環境
こうした環境ではタッチ操作だけでなく、マウスやトラックパッドでの操作感も重要になります。
特にComposeでスクロール、ドラッグ、ピンチ操作などを扱っている場合、入力デバイスごとの挙動差は見落としやすいポイントです。
今後は、Androidアプリであっても指で触る前提だけではなく、より広い入力手段を意識する場面が増えていきそうです。
個人的にはComposeがこうした入力デバイス対応を強化していくことで、Androidアプリの対応範囲がより広がっていく印象を受けました。
実務で更新する時に確認したいこと
今回のCompose BOM更新を実務プロジェクトへ取り込む場合、いきなり全体へ反映するよりもまずは影響範囲を確認しながら進めるのがよさそうです。
確認観点としては、以下のようなものが考えられます。
- Compose BOMを更新してビルドが通るか
- Compose Compiler / Kotlin / AGPとの組み合わせに問題がないか
- UIテストが落ちていないか
- 主要画面のスクリーンショット差分が大きくないか
- スクロール、クリック、ドラッグなどの操作に違和感がないか
- アニメーションや画面遷移の挙動が変わっていないか
特にComposeは見た目の実装だけでなく、状態管理やテストにも関係してくるため、画面単位で軽く触って終わりではなくテストコードや操作系の確認も含めて見ておきたいところです。
また、複数人で開発しているプロジェクトではBOM更新のPRに以下のような情報を添えておくとレビューしやすくなります。
- 更新前後のCompose BOMバージョン
- 公式リリースノートへのリンク
- 影響がありそうな機能
- 確認した画面
- 確認したテスト
- 既知の懸念点
ライブラリ更新は地味ですが、後から原因不明の表示崩れやテスト失敗につながることもあります。
そのためBOM更新自体を小さな変更として扱いつつも、確認観点は明確にしておくと安全です。
まとめ
Jetpack Compose April 26 Releaseでは、Compose core modules 1.11、共有要素アニメーションのデバッグツール、トラックパッドイベント対応などが含まれています。
個人的には特に共有要素アニメーションのデバッグツールが気になりました。
ComposeはUIを作るための仕組みとしてかなり成熟してきていますが、今回のように「作れる」だけでなく「調整しやすい」「デバッグしやすい」方向に進化しているのは実務でもありがたいポイントです。
また、トラックパッドイベント対応のように、スマートフォン以外の利用環境を意識した更新も今後さらに重要になっていきそうです。
Composeの更新はどうしてもBOMのバージョンだけを見て終わりがちですが、こうした変更点を追っておくと、今後のUI実装や設計の選択肢も少しずつ広がっていくのではないかと思います。
さいごに
5月でこの気温、夏本番はいったいどうなってしまうのでしょう…