Swift開発環境はまだ弱い〜Objective-C環境と比較して気づいた問題や不満〜

Swiftの登場からもう１年以上経っていますが、相変わらず実用レベルには至っていません。

これは2015年12月4日現在リリースされている最新のXcode・Swift開発環境（Xcode 7.1, Swift 2.1）の不満点と問題点です。

現段階においてもObjective-Cを捨てるほど価値のある言語環境とは言えないでしょう。言語仕様は素敵ですが開発環境はまだ弱いです。

Xcode 7.1で再検証しました（2015/12/4）
Xcode 7.3.1で再検証しました（2016/05/29）

オーバライド時の補完機能が弱い

メソッド補完は良く出来ていますが、プロパティーの補完が効かないのがいまいち納得できません。

デバッグコンソールが弱い

poコマンドのレスポンスと入力補完がまだ弱いです。そもそも補完は全く効きません。（Xcode 7.3.1で入力補完が行えることを確認しました）

またデバッグ情報はObjC時代よりも抽象的で、色々と手間が多い印象です。

// Swift
(lldb) po self.attributes
▿ Optional<Dictionary<String, AnyObject>>
  ▿ Some : 2 elements
    ▿ [0] : 2 elements
      - .0 : "NSFont"
    ▿ [1] : 2 elements
      - .0 : "NSColor"

// Objective-C
(lldb) po self.attributes
{
    NSColor = "NSCustomColorSpace sRGB IEC61966-2.1 colorspace 0 0 0 1";
    NSFont = "\"Helvetica 13.00 pt. P [] (0x6180000498a0) fobj=0x100d7ea00, spc=5.00\"";
}

リファクタリングが効かない

メソッド名やプロパティー名の一括変更は出来ません。

メソッド名 > 右クリック > Refactor > Rename...を行うと怒られます。

Xcode can only refactor C and Objective-C code.

Xcode 9からリファクタリング機能に対応しました。

コンパイルが相変わらず遅い

Swift1.2リリース時からインクリメンタルビルドに対応したため、ビルド時のストレスはだいぶ減りました。しかし遅いことには変わりありません。ファイルを一つ変更するだけでもiOSでは「Copying Swift source files」OSXでは「Copying Swift standard libraries」という作業が発生し、1.2秒ほどのタイムロスが発生します。5年前のIDEならまだしも現代でこのスピードは少し遅すぎる気がします。

Objective-C使いなら分かると思うのですが、Xcode+Clang上でのビルドスピードは本来かなり速いものです。Objective-C開発環境だと１ファイルを変更する程度なら0.25秒程でビルドが完了します（ステップ数の多いプロジェクトであってもこのスピードはほとんど変わらない）。ショートカットキーを押した指がキーから離れるよりも先にビルドが終わっているという感覚です。それが当たり前と思っている世代にとってはSwitは少しストレスになるかも知れません。

そもそも1.2秒というのはXcode標準のテンプレートプロジェクトでのスピードであり、実開発時にコードや依存クラスが増えればもっと遅くなります。

Xcode 7で再度検証しました。Swiftのコンパイルスピード自体はC++並になりました。ただし、リリース・ビルド時には以前と同様、小さなランタイムを生成する際のタイムロスが発生します。

Swift用の互換ライブラリが大きすぎる

Swiftで作成したアプリケーションパッケージでは、バンドル内のFrameworkディレクトリにSwift関連のライブラリが書き出されます。「libswiftFoundation.dylib」や「libswiftCore.dylib」等といった動的ライブラリで、これは俗に「小さなランタイム (Small Swift Runtime Library)」と呼ばれています。iOSアプリではこれが約11.8MB分書き出されます。OSXアプリでは6MB。ちなみにOSX開発環境ではこの書き出しが、ソースコード修正後のビルド度に発生します（Xcode 7ではコード署名時にのみ行われるようになりました）。

ただし、App Store上では圧縮されたアプリが配信されるため、気にするほどの問題にはならないでしょう

Swift製のスタティックライブラリが作れない

静的ライブラリの作成はサポートされていません。そもそもSwiftが吐き出すネイティブコードは、先ほど紹介した「libswiftCore.dylib」などの動的ライブラリ／小さなランタイムに依存しています。おそらくここらでビルトインライブラリの提供や型変換、システムライブラリとの橋渡し的なことまでしているのでしょう。

いずれいくつかのライブラリはOS側の標準ライブラリとしてバンドルされるようにはなるはずですが、当面はSwiftの仕様変更を憂慮し、アプリ毎に小さなランタイムを内包させる方法が続くと思われます。スタティックライブラリの作成が可能になるのはOS側に共通のランタイムがバンドルされるようになる頃と考えてよいでしょう。それまではお預けです。

なお、Swiftでライブラリを作成する場合は動的ライブラリ（Cocoa Framework / Cocoa Touch Framework）として作成することになります。しかしそのライブラリを利用するプロジェクト側では当然、小さなランタイムを内包する必要が出てきます。

となると、Objective-CメインのプロジェクトではSwift製ライブラリの利用はばかれるかもしれません。Objective-C製のライブラリで統一したほうがアプリサイズは小さくなり、ビルドスピードも速くなるわけですから。

ちなみに、Swift製外部ライブラリのバージョンと、Swiftコンパイラのバージョンを合わせる手間を考えると、やはり仕様や記法が安定したObjective-Cを使い続けたほうが保守作業に掛かるコストも少なくなると思います。

まだ未成熟

以上のことから、Swift開発の環境はまだまだ発展段階であることがわかります。Appleはもっとじっくり地盤（言語仕様やOS標準ライブラリの整備）を整えてからSwiftをリリースしたほうが良かったのではないでしょうか。今のSwift環境は業務利用という観点で見ると少し痛々しい感が有ります。

Swiftは既存開発者のための言語というよりはむしろ新規開発者を開拓するための言語なのでしょう。Objective-Cで十分満足している開発者なら今の段階ではまだ移行する必要はないでしょう。Swift周りの地盤の弱さを見るに、Objective-Cの廃止も当面考えられません。

Objective-Cユーザにとって、Swift移行は満足感よりも消耗のほうが大きいと思われます。言語仕様や開発基盤（開発支援、外部ツール、ABI安定化、プリプロセッサの代替機能等）がしっかりと固まった頃に移行するのも手です。

Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

posted with カエレバ

石川洋資,西山勇世技術評論社 2017-02-07

Amazon

楽天市場

7net