Apple系デベロッパーの人たちがSwift普及のいかんともしがたい現状について話していたので考えてみた。
サーバーサイド用途
サーバーサイドSwiftは現状あまり利用したいケースが見当たらず、モバイルアプリ開発組織のマイクロサービス開発の共通化においてはJVMが枯れているのでKotlinの方に傾きがち。
WindowsやVSCodeやIntelliJ系の非Xcode系開発環境のサポートのハードルも越えるぐらいモチベーションが必要である。
ただユーザー規模はそこそこあり、DenoやDartやHaskellが有効な程度にはWeb開発用途には使えると思われる。苦労しそうだけど。
Wasm化
Wasmにしてブラウザサイドでコードを動かそうという向きもある。拡張用途では周辺ツールの多いRustやCのライブラリ資産のポートもありレッドオーシャンであることは変わりないが、Swiftに限らずWasmアプリケーション化はstdlibを動かす部分(ランタイムというんですかね?)を含めたコードサイズとの闘いも上乗せされそう(にもかかわらずJSのが早かったり)。
あるとしたらiOS/macOSアプリケーションのコードをピンポイントでWeb活用して共通化、という使われ方を想像した。
iPhoneがあと20年ぐらい使われる
iPhoneが今後10年ぐらい使われ続けてそのアプリ開発にSwiftが使われ続けるのは想像にやさしいところだけど、2040年となるとSwiftにももうひとまわり大きな変化が起きていそう。そうしたらSwiftはもっと広く使われているのではないか。
新世代デバイス向けのスクリプティングレイヤーに採用される
3Dゲームを作る時に使われるUnity並に普及したXRスタジオな何かを拡張する手段としてLLVMコードが要求され、なぜかSwiftが組込まれて使われていくという世界線が来る。
Xcode for Windows
Appleにもナデラ的なリーダーがあらわれクロスプラットフォームな開発者取り込み戦略を進めてゆく。なぞの魔術WinObjCとかではなく、Apple自身がWindowsネイティブに動くアプリケーション開発環境を開発する。
ただなんやかんやでみんなそれぞれWebViewで実装し、Electronプロセスを立ち上げ続けるのであった。
新ブラウザ発表
突如としてSafariに変わるまったく新しいエンジンを積んだブラウザをAppleがリリースする。それでは期待されたWeb標準APIが充分に完備され、JSでアプリが作成でき、envoyのようなアーキテクチャでSwiftでブラウザ拡張も作れる。そしてSwiftはWASM生成元として地位を確立するのであった(私はRustで書きます)。
サーバーレスSwift
Testflightのような力技でAppleがどこかのmBaaSを買収。Xcodeからワンボタンでデプロイ可能になり、Apple系デベロッパーはもうこれ以上VPSを借りなくていいんだよ・・と御告げが来る。
あんまり使われなさそう。
まとめ
Appleの将来に依存し過ぎている
