- SwiftだけでAndroidネイティブアプリを開発できるフレームワークで、UIからマニフェスト、ライフサイクルまで単一言語で構成
- XML、Java、Kotlinを一切使わず、宣言的UI方式でAndroid UIを構築する仕組みを提供
- Webラッパーやトランスパイラではない純粋なネイティブAndroidフレームワークとして動作
- SwiftUIに似た宣言的な文法でUIを定義でき、複雑なJNIレイヤーを完全に隠蔽
- Android ManifestやGradle設定までSwiftコードで直接定義する統合開発体験を提供
- Swift開発者がAndroidへ拡張するための新しいネイティブな代替手段であり、Swiftベースのクロスプラットフォーム開発に新たな可能性を開く転換点
Droid 概要
- DroidはSwift言語のみを使ってAndroidネイティブアプリケーションを開発できるよう設計されたフレームワーク
- UI、アプリ設定、ライフサイクル、マニフェストを1つの言語とコードベースで管理する構成
- Android開発で必須と見なされてきたXML、Java、Kotlinへの依存を排除
- AndroidX、Flexbox、Material DesignなどAndroidネイティブの構成要素を含む
- SwiftUIに似た宣言的な文法を提供し、UI定義を簡素化
- JNIレイヤーを完全に隠し、高水準APIから利用可能
設計目標と特徴
- Pure Swiftベースで、UI、マニフェスト、アプリ構成全体をSwiftで記述
- 宣言的UIを採用し、可読性と合成しやすさを重視
- XMLを一切使わないNo XML開発方式を維持
- Webベースのアプローチやコード変換ではなく、Native Android実行モデルを採用
- UI、マニフェスト、Gradle依存関係を1か所で定義する統合構造を提供
宣言的UIの構成方式
- Swiftに適したAPIを使ってAndroid UIを宣言的に構成
- ConstraintLayout、VStack、TextView、MaterialButtonなどAndroidウィジェットをSwiftコードで表現
- レイアウト制約、クリックイベント、スタイル設定をコード上で直接定義
Swiftで記述するAndroid Manifest
- Android Manifest自体をSwiftコードで宣言
- アプリアイコン、テーマ、アクティビティ、フラグメント設定をコードレベルで管理
- ライフサイクルイベント処理と設定ロジックを1つのSwiftファイルで統合
ドキュメントと開発環境
- 公式ドキュメントが提供され、継続的に拡充中
- Androidの全機能がすべて文書化されているわけではないが、既存ガイドは整理された形で提供
- Swift Stream IDEを通じてすぐに開発を開始可能
サポート範囲
- Classic Androidウィジェットをサポート
- AndroidXライブラリをサポート
- Material Designコンポーネントをサポート
- Flexboxレイアウトをサポート
プロジェクトの状態
- プロジェクトは活発に開発中で、急速に進化している
- APIは拡張性を見据えて改善中だが、核となるビジョンは維持されている
- フィードバックと参加を積極的に推奨
1件のコメント
Hacker Newsのコメント
Swift Stream IDE v1.17.0 が公開された。これで Swiftだけで完全なAndroidアプリ開発 が可能になった
XML、Java、Kotlin に一切触れなくてもよい。内部では自作の SwifDroid フレームワーク が Android のライフサイクル、Activity、Fragment、UI ウィジェット（Material、Flexbox など）を処理し、Gradle 依存関係も自動管理する
Swift コードをコンパイルして、Android Studio でそのまま実行できるプロジェクトを生成する。ツールとフレームワークはいずれも MIT オープンソースライセンス で公開されている
XML、Java、Kotlin に触れないとのことだが、Android の経験がまったくない Swift 開発者でも問題なくアプリを作れるのか知りたい
また、現時点と来年の時点で、Kotlin や Flutter アプリのうちどの程度の割合を Swift で書けるのかも知りたい
私たちは似たようなことを Swift ではなく Rust で試している
こうした試みは結局 JNI を経由する必要がある ため、API の 80% が Java でしか公開されていないという点で限界がある
こういうプロジェクトはいつも興味深いが、最終的には 漏れる抽象化 (leaky abstraction) の問題に突き当たる
iOS では Objective-C を知る必要があり、Windows では .NET/COM を知る必要があるのと同じだ
Unity での経験からすると、C# から C へのマーシャリングは滑らかだが、Swift はずっと手間がかかる
新しいフレームワークごとに個別対応しなければならないのが現実だ
プラットフォーム間で共通言語（Swift や Kotlin）を使うのは一見よさそうに見えるが、実際には期待するほど効率的ではないと思う
結局 2つのコードベース を維持することになり、差異や回避策も増えるので、それぞれの言語を普通に使うほうがよいと思う
ほとんどの開発者は複数の言語を学びながらキャリアを積むし、切り替えもそれほど難しくない。個人的な意見だが、プロジェクト自体は素晴らしいと思う
私も以前 Java で Android ネイティブアプリを作ろうと数か月勉強したが、楽しくなくてやめた
完全なネイティブ開発 を好むほうで、何十年もクロスプラットフォームフレームワークを使ってきたが、大きな成功を収めたことはない
言語の切り替えには常に コンテキストスイッチのコスト が伴う。Swift と PHP を行き来して開発するたびに、文法ミスをよくしてしまう
言語はすぐ覚えられても、SDK・標準ライブラリ・フレームワークの習熟には 長い時間 がかかる
特に今は AI ツールのおかげで単純作業の速度がすでに上がっており、全体の開発時間短縮効果はそれほど大きくない
アプリが実質的に Web アプリ並みであるならともかく、そうでなければ勧めない
言語としては Swift のほうが優れていると思うが、KMP のほうが歴史が長く安定しているので、実際に使うならそちらだろう
ただ、特定の巨大企業のエコシステムにさらに依存するのは避けたい
しかも Swift は個人的には 扱いにくい言語 なので、わざわざ別のプラットフォームでも使いたいとは思わない
Skip と比べてどうなのか気になる
このプロジェクトは iOS の SwiftUI コードを Android に持っていくのではなく、Android 専用の Swift 開発 に焦点を当てているようだ
それがより高品質なアプリにつながるのか、実例があるのか知りたい
Android Studio や IntelliJ を使わなくてよいという点だけでも 大きな改善 だと思う。素晴らしい
Cookie 同意画面が 欧州の法規制に準拠していない ように見える
なぜモバイル開発は PC よりこんなに 不便なのか わからない
なぜモバイルではアセンブリで Hello World を1つ作るだけでもこんなに難しいのか不思議だ
しばらく Android 開発から離れていたので、最近の状況を整理すると
昔は iOS は Swift、Android は Java だったが
今は Java の代わりに Kotlin があり、さらに Flutter や React Native のようなクロスプラットフォームフレームワークもある
Swift on Android はこれらのような別の 抽象化レイヤー なのか、それともネイティブに近いのか気になる
結局いちばん速いのは ネイティブコード ではないのか?
個人的には Flutter のほうが好みだ。多くの Android ネイティブ開発者も、Flutter が Android 開発の未来 になり得ると言っている
関連する議論は この Reddit スレッド を参照
このプロジェクトは SwiftCrossUI や Skip とは異なるアプローチだ
SwiftCrossUI や Skip は SwiftUI をそのまま複数プラットフォームで動かすが、
SwifDroid は Android 専用 UI を Swift で書く ものだ
Android の View システムと API を直接使いながら、Java/Kotlin/XML なしで完全な Android アプリを Swift で作ることを目指している
つまり、「一度書けばどこでも動く」ではなく、Android ネイティブ体験を Swift で実現する 方向性だ
Swift で HTTP リクエストと JSON パースを慣用的に 処理する方法が気になる