ハクソク

世界を動かす技術を、日本語で。

AndroidにおけるSwift: 完全なネイティブアプリ開発が可能に

103日前原文(docs.swifdroid.com)

概要

  • SwiftでAndroidアプリ開発が可能な新しい環境
  • Droid frameworkによる宣言的UI構築のサポート
  • AndroidXやMaterial Designなどの豊富なコンポーネント提供
  • JNIレイヤーを完全に抽象化した高レベルAPI
  • ドキュメントは随時更新中、404や誤字の可能性あり

SwiftでAndroidアプリ開発を始める最適な場所

  • Swift言語でAndroidアプリ開発が現実となった新環境

  • ConstraintLayoutやVStackなど、SwiftUIライクな宣言的構文でUI構築

  • 例：

    ConstraintLayout {
  VStack {
    TextView("Hello from Swift!")
      .width(.matchParent)
      .height(.wrapContent)
      .textColor(.green)
      .marginBottom(16)
    MaterialButton("Tap Me")
      .onClick { print("Button tapped!") }
  }
  .centerVertical()
  .leftToParent()
  .rightToParent()
}

    直感的なコード記述例

  • SwiftUIのような構文でネイティブなAndroid UIを作成可能

  • ユーザーインターフェースとユーザー体験を両立した設計

Droid frameworkの特徴

  • Droid frameworkはAndroidアプリ開発のための基盤
  • AndroidXやFlexbox、Material Designなどの充実したコンポーネントを提供
  • 宣言的構文でUIやロジックを簡潔に記述
  • JNIレイヤー（Java Native Interface）を完全に隠蔽
    • Swift開発者がAndroid固有の複雑さを意識せずに開発可能
    • 高レベルAPIにより、生産性向上と保守性向上を実現

ドキュメントと今後の展望

  • 公式ドキュメントは現在も積極的に開発中
  • 404エラーや誤字脱字が発生する場合あり
  • 新しいコンテンツが日々追加されている状況
  • ユーザーのフィードバックを歓迎する姿勢
  • 今後のアップデートに期待

Hackerたちの意見

Swift Stream IDE v1.17.0をリリースしたよ！これで、完全にSwiftだけでネイティブなAndroidアプリ開発ができるようになった。XMLやJava、Kotlinに触れずにアプリが作れるんだ。内部では、SwifDroidっていうフレームワークが動いてて、Androidアプリのライフサイクルやアクティビティ、フラグメント、UIウィジェット（Android、AndroidX、Material、Flexbox）を管理しつつ、Gradleの依存関係も自動で管理してくれる。IDEはSwiftをコンパイルして、Android Studio用のフルAndroidプロジェクトを生成するよ。これが初の公開リリースだ。ツールとフレームワークはオープンソースで、MITライセンスだよ。
└
おめでとう！Swiftで集中できるのをずっと探してたから、すごく嬉しい。いい仕事だね！
└
Swiftにとって便利なのは、C/C++ライブラリとのネイティブな相互運用性だね。これらはよくSwiftPMやBazelの依存関係として提示されるけど、SwiftPMの依存関係はどう扱ってるの？
└
面白いね。Java/KotlinのコードをSwiftにバインディングするのはどうやってるの？（私たちはSwiftの代わりにRustで似たようなことをしようとしてるんだ）
└
まずはクロスオーバーの話だね。Swift開発者にはどれくらいのAndroid開発経験が必要で、Android/Kotlin開発者にはどれくらいのSwift経験が必要なの？「XML、Java、Kotlinに触れずに」というのは、Android経験がないSwift開発者でも成功できるってことを暗に示してるの？それなら、KotlinやFlutterのアプリのうち、どれくらいがSwiftで書けると思う？今と来年ではどう？
Android StudioやIntellijに触れなくていいのは、すでに大きな改善だね。素晴らしい仕事だよ！
└
それとGradleは？Gradleをスキップして、あの依存関係管理の悪夢を回避できるの？
└
Xcodeを触るのは、Androidを避けるために濃縮塩酸に触るようなもんだね。
なんかこれについては聞いたことがなかったな。SwiftCrossUIと比べてどうなの？Skipもすごく魅力的だよね（実際にSwiftUIをネイティブに動かして、Composeに変換するから）。なるほど、SwiftCrossUIやSkipと比べると、これはAndroid専用のSwiftUIっぽいね。他の二つはSwiftUIやSwiftUIっぽいものを書けて、AppleのプラットフォームとAndroid（または他の場所）で動かせるんだ。
└
目的が違うアプローチだね。SwifDroidはSwiftでのネイティブAndroid開発についてだよ。クロスプラットフォームのUIを書くんじゃなくて、Android特有のUIをSwiftで書いて、AndroidのビューシステムやAPIを直接使うんだ。目標は、JavaやKotlin、XMLに触れずに、活動やフラグメント、AndroidX、Materialを含む完全なAndroidアプリをSwiftだけで作ること。ほかのは「一度UIを書けばどこでも動く」っていうけど、UXに妥協があることが多いから、SwifDroidはAndroidにネイティブで書いて、Swiftから完全にコントロールできることに焦点を当ててるんだ。
プラットフォーム間で共通の言語を使うのは、SwiftでもKotlinでも表面的には素晴らしいけど、実際には期待される効率は得られないと思うんだ。結局、チームは二つのコードベースを持つことになるだろうし、違いがたくさんあって、結局KotlinやSwiftを使う必要があるなら、楽しんで使った方がいいと思う。二つの言語を知るのはそんなに悪くないよ。ほとんどの開発者はキャリアの中で多くの言語を学んで、気にせずに切り替えてるからね。あくまで私の意見だけど、これは良いプロジェクトだと思うよ。
└
二つ以上の言語を知ってるって、ちょっと解放感があるよね。みんなキラキラしたものが好きだけど、今回は近道はないよ。それに、あんな大企業にもっと依存するなんて考えたくもないし。仮にそれを脇に置いたとしても、Swiftは使うのが辛い言語だし、強制されてない場所でも使わなきゃいけないのは自分を痛めつけるようなもんだよね。
└
うん、これらのクロスプラットフォームフレームワークは、簡単で退屈なものを開発するのを早くするけど、もっとエソテリックなプラットフォーム特有の機能に手を出すときには、逆に邪魔になるよね。全体的な時間の節約は疑問だし、特にAIの時代では、簡単で退屈なことに対しては、より良いドキュメントと豊富なトレーニングコーパスで、もっと速くできるからね。基本的にウェブアプリになるなら別だけど、あまりおすすめしないよ（別のネイティブコードベースに戻った人からの意見）。
└
KotlinとSwiftはすごく似てるよね。でも、似てないところはあんまり抽象化したくないかな。確かにクールだけど、実際に使うかは疑問だな。個人的にはSwiftの方が「良い」言語だと思うけど、KMPみたいなものはもっと前からあって、安定してるしね。
└
それが今やってることだよ。アプリがウェブビューのReactのクソみたいなものじゃなくて、基本的じゃない（あるいは基本的な）機能を使い始めると、結局二つのコードベースが必要になるんだ。例えば、フォアグラウンドサービスを使ったり、ランタイムの権限が必要な場合とかね。実際にギャップを埋めてくれるフレームワークはB4Xだけど、サービスの関係で二つの別々のプロジェクトが必要だし、フレームワークが抽象化してない部分（正直言うと、周辺機器やライブラリの高度な使い方）については#ifブロックも必要になる。二つのOSは根本的に違いすぎるんだよね。
モバイル開発がPCに比べてなんでこんなにクソなの？モバイルデバイスでアセンブリでHello Worldを作れないのはなんで？
└
できるよ。PCでアセンブリでHello Worldを書くのと同じくらい悪いけど、だから誰もやらないんだよね。
しばらくAndroidから離れてたんだけど、誰か詳しく教えてくれない？アプリを作るベストな方法は、前に見たときはiOSがSwiftで、AndroidがJavaだったんだけど、JavaがKotlinに置き換わったってどこかで読んだ。さらに、FlutterっていうAndroidとiOS両方で動くものが追加されたって聞いた。React Nativeや「ウェブブラウザベース」も、最もパフォーマンスが悪い開発方法だと思ってた。これってAndroidのSwiftも同じようなレイヤーなの？最もパフォーマンスがいいのはいつもネイティブだよね？
└
React Nativeはウェブビューに基づいてるわけじゃなくて、基本的にはJSXマークアップをSwiftUIやKotlinのUIコードに変換する翻訳レイヤーなんだ。各デバイスでネイティブに動くよ。個人的にはFlutterが好きで、ハードコアなAndroidネイティブ開発者たちも、FlutterがAndroid開発において行くべき道かもしれないって言ってるよ。[0] [0] https://old.reddit.com/r/androiddev/comments/1np26m4/do_othe...
これってSkip[1]と比べてどうなんだろう？こっちは完全にAndroidに焦点を当ててるみたいで、既存のiOSのSwiftUIコードをAndroidで動かすことじゃないみたい。これがより良いアプリにつながると思うけど、実際の例はあるのかな？ [1] https://skip.tools/
ちょうどいいタイミングだね、Appleが静かに見捨てようとしてる時に。
└
それはまだ聞いたことがないな、詳しく教えて。
└
AppleがAndroidでSwiftを見捨てるの？
└
あなたはObjective-Cと混同してるんじゃないかな。
HTTPコールをして、JSONレスポンスをイディオマティックにパースするにはどうすればいい？
まあ、そうだね。結局、80%のAPIがJava経由でしか公開されてないから、最終的にはJNIを通ることになる。こういう取り組みはいつも祝福されるべきだけど、結局は漏れのある抽象化に終わるんだよね。逆に成功するためにはObjective-Cを理解する必要があるのと同じように、Windowsでは.NET/COMを意識しないといけない。
└
面白いのは、今はAppleのシステムで成功するためにSwiftとObjective-Cの両方を使わなきゃいけないってこと。新しいものに対してはもうobj-cのフレームワークを提供してくれないから、両方を使うか、フレームワークごとに対処しなきゃならない。Unityの背景から話してるけど、obj-cとの相互運用性はC#からCへのマシュリングのおかげで結構スムーズなんだよね。でも、Swiftはもうちょっと手間がかかる。