私は、言語にあまりこだわりがある方ではなく、使えればなんでもいいやタイプ。
そんな私でさえ、「あー、そうよなー」 と共感してしまった所があった。
WWDCのセッションでは、ほぼSwiftで書かかれているなど、Swift押しなのかなーと思う反面、Swift発表から結構経った今でもなお、上にのっかっているライブラリの位置から抜ききれていないのが悶々とする。
Swiftは、コードの文字量が減るし、GenericsやEnum, Extensionなどのおかげでスッキリと見やすいコードを書きやすい。
見やすいコードは凄く大事。複数の人数で開発していたらさらに。
多少のコンパイル速度や、実行速度を落としてでも、見やすいコードの方が優先順位は高いと思う。（便利なフレームワークを使うとか もその一例デスヨネ）
でも、一人でコードを書いている&修正している場合、ぶっちゃけ動けばOKなのだから、見やすいコード の優先度を下げても問題ない訳で。
受託案件であれば、Swiftバージョンの互換性問題を考えると、委託者の立場からするとObjective−Cで作ってくれた方が有り難いかもしれないし。
「これからのiOSアプリはSwiftで書くべし」 と人に言われたことがあるけど、私はそこまで断定して言えないなぁ。
そうはいいつつ、Flaskのアプリは3年前からSwiftです。Swift発表の直後から使い始めたので、長い方と思う。受託じゃないからできる技ですねw
速度に関しては、そこまでシビアなモノを作っていないし、デバイス性能が上がればカバーできることも多いので、そのためにObjective-Cを選択することは無いのだけど...
アプリにSwiftライブラリを含める必要がある
のが、一番ツライ。
ここでいうSwiftライブラリとは、libswiftCore.dylib など のような、これがないとそもそもSwiftが動かない必須のやつです。
Swiftのバージョンが上がるとどんどんサイズも大きくなっていく代物。
XCodeでビルドした際に作成される ○○.app の中を見ると、このSwiftライブラリ類の合計は、
- iPhoneアプリでは35MB
- Apple Watchアプリでは12MB
ぐらい占める。
が、これで驚く無かれ（？）
App Storeに向けたビルドとして出力すると、
- iPhoneアプリでは100MB
- Apple Watchアプリでは36MB
ぐらいに膨れ上がる。
Apple Watchアプリは50MBのサイズ制限があるのに、半分以上持っていかれるとか、ほんと切実すぎる。
(最近、制限が75MBにアップされたかも？）
これらのサイズは、どうやらコード内のスペースとかも含まれているサイズらしく、実際に配布される時は少なくなるようなのですが、iTCへアップロード時のWatchアプリのLimitのチェックはこれを使っている様子。
これらのサイズは、どうやらコード内のスペースとかも含まれているサイズらしく、実際に配布される時は少なくなるようなのですが、iTCへアップロード時のWatchアプリのLimitのチェックはこれを使っている様子。
どっちの言語でも書くのは問題ないけど、後にObjective-C ←→ Swift に移行するのは、やりたくない。
とすると、これから作成するアプリであっても、ボリュームがありそうなWatch appはObjective-Cで書くのがいいか？ と考えてしまう。
今後、Swiftライブラリをアプリに含めなくても良くなる (= Objective-Cと同等レベルの言語として格上げされる) 予定があるのか？ ないのか？ をホント、知りたい。
公表してくれると嬉しいが、オトナの事情もあるだろうし難しいんだろうな....。