Swiftプログラミングの学習：プライムタイムの準備はできていますか？

公開: 2022-03-11

iOSアプリを作成するための新しいプログラミング言語であるSwiftの今年6月のAppleの立ち上げは、iOS開発者コミュニティ全体に大きな話題と興奮をもたらしました。

発売以来、多くのiOS開発者は、Objective-CからSwiftに移行するかどうか、どのように、いつ移行するかという問題に苦労してきました。もちろん、その質問に対する答えは、チームやプロジェクトごとに異なります。

Swiftの利点の多くをカバーするあなたが読むことができる多くの記事があります。 したがって、これらの同じポイントを再ハッシュする代わりに、この記事では、Swiftを使用したアプリ開発を学ぶ前に、考慮したい懸念事項のいくつかに焦点を当てます。

Swiftを使用したプログラミングは、プライムタイムの準備ができている場合とできない場合があります。Swift言語をもう習得しましたか？

しかし、最初に、時計を少し戻しましょう…

Swiftの前：Objective-Cを使用すると、気に入るはずです…

その年は2010年でした。iPhoneはまだ3年前のものであり、iPhone用のネイティブアプリを作成する機能は約2年しかありませんでした。その年の4月8日、AppleはiPhoneOSのバージョンを発表しました。 iPhone OS（これは、名前がiOSに変更される前のことです）には、マルチタスク、高速アプリ切り替え、バックグラウンドサービスなどの魅力的な新機能が含まれていました。当然のことながら、iPhone開発者は、新しいSDKを手に入れて、これらすべてのエキサイティングな新機能を試してみたいと考えていました。

しかし、iPhone OS4SDKには予期しない爆弾が含まれていました。この爆弾はソフトウェアには含まれていませんでした。使用契約に含まれていました。 iPhone OS 4 SDKでは、開発者契約のセクション3.3.1が更新され、次の問題のある言語が含まれるようになりました。

アプリケーションは元々Objective-C、C、C ++で記述されている必要があり、C、C ++、Objective-Cで記述されたコードのみがコンパイルされ、ドキュメント化されたAPIに直接リンクできます。
– iPhone OS4SDK開発者契約のセクション3.3.1

言うまでもなく、この新しい制限は多くの開発者を驚かせました。 Steve Jobs自身によって提供された変更の公式の理由は、最近発表されたFlashCS5などのクロスプラットフォームツールの使用を防ぐためでした。 Jobsは、「プラットフォームと開発者の間の中間層は、最終的に[原文のまま]標準以下のアプリを作成する」と述べたと伝えられています。しかし、これらの「中間層」と戦うためのAppleのアプローチが、iPhoneアプリの作成に使用できるプログラミング言語を制限することであったという事実は、Appleの考え方についてもっと何かを明らかにしました。Objective-Cは誰にとっても十分であるはずです。

Objective-CがTiobeIndexの「ProgrammingLanguageofthe Year」賞を2年連続で受賞したため、この主張に同意することは許されるかもしれません。しかし現実には、Objective-Cの人気は成長するアプリエコシステムの機能であり、その逆ではありませんでした。 2010年にさえ、多くの人々がすでにObjective-Cに不満を持っていたため、他のプログラミング言語でiPhoneアプリを作成する別の方法がすでに登場していました。

最終的に、開発者コミュニティ全体からの圧力を受けて、Appleはわずか5か月後にSDK開発者契約のセクション3.3.1へのこれらの変更を取り消しました。それでも、メッセージは明確でした。iPhone用のアプリを作成したい場合は、おそらくObjective-Cを使用する必要があります。

… またはそうでないかもしれません。新しいiOS言語Swiftを入力します。

その事件から、Appleが開発者に新しい言語であるSwiftを紹介した2014年6月までの4年間を早送りします。 4年前のメッセージがAppleがObjective-Cに完全に満足しているというものだった場合、Swiftの紹介によって送信されたメッセージは、Appleがついに真実を認める準備ができたというものでした。 Objective-Cは、モバイルアプリを作成するのに必ずしも最適な言語ではない場合があります。

SwiftがObjective-Cよりも「現代的な」言語である方法については多くのことが言われています。 Swiftプログラミング言語の学習方法に興味がある場合は、Objective-CからSwiftに移行するためのガイドを確認することをお勧めします。

ただし、Objective-C言語とSwift言語には2つの重要な違いがあることに注意してください。

SwiftはC言語の厳密なスーパーセットではありません。
Swiftは静的に型付けされており、動的に型付けされていません。

Cの厳密なスーパーセットではないということは、Swiftが他の方法では許可されない構文構造を自由に利用できることを意味します。これにより、たとえば、Swiftでカスタム演算子を実装できます。

静的に型付けされるということは、SwiftがHaskellなどの言語によって開拓された型システムの最近の進歩の多くを利用できることを意味します。

Swiftは、一般に公開される前に4年間開発されてきましたが、まだ若いプログラミング言語であるため、いくつかの注意点があります。

Objective-Cとの互換性

iOSはOSXと共通の遺産を共有しており、OS Xは1989年に最初にリリースされたNeXTSTEPオペレーティングシステムからその歴史を引き継いでいます。NeXTSTEPは元々Objective-Cで作成されており、OSXとiOSのコアライブラリの多くはそのルーツをすべて追跡していますこれらの元の実装に戻る方法。（ちなみに、これはNSStringなどのコアクラスに見られるユビキタスな「NS」プレフィックスの由来です。）Swiftは理論的にはこれらのコアライブラリがなくても存在する可能性がありますが、現実には、近い将来に作成する可能性のあるSwiftプログラムはどれでもObjective-Cとのインターフェースが必要になります。

彼らの名誉のために、Swiftの背後にいる開発者は、既存のObjective-Cライブラリとの対話を可能な限り簡単にする素晴らしい仕事をしました。しかし、それはプロセスが完全に痛みがないということではありません。 Appleは、SwiftからObjective-Cコードを呼び出す方法、およびその逆の方法を説明する役立つガイドを提供していますが、注意すべき重要なインピーダンスの不一致がいくつかあります。

おそらく最も明らかな不一致はヘッダーファイルに関連しています。 Objective-Cは、Cルートであるため、呼び出される前に関数を宣言する必要があります。ライブラリを呼び出す場合、これらの宣言はライブラリのヘッダーファイルにあります。ただし、Swiftはヘッダーファイルを使用しません。したがって、Objective-CからSwiftコードを呼び出す場合は、最初に「ブリッジヘッダー」を作成する必要があります。概念的にはこれはそれほど複雑に見えないかもしれませんが、実際には、それは実際にはかなりの作業になる可能性があります。

SwiftとObjective-Cの間のインターフェースにおける別の一連の問題は、それらの型システムの固有の違いに起因します。 Swiftは、他の現代言語からヒントを得て、 nilの概念を廃止しました。その代わりに、Swiftのオプション型があります。たとえば、ファイルがすでに存在する場合にのみファイルを開くメソッドの戻りタイプはFile? （ Fileだけでなく）Swiftで。タイプがオプションであるすべての場所を追跡することにより、Swiftコンパイラーは恐ろしい「ヌルポインターエラー」に遭遇することを事実上不可能にすることができます。それはもちろん、Objective-Cを呼んでいない限りです。 Objective-Cはnilを返さないことについてそのような保証をしないため、Swiftには、Objective-Cコードを呼び出すときに使用されるImplicitlyUnwrappedOptionalsと呼ばれるタイプの特別なカテゴリがあります。これらのタイプは、存在チェックに必要なすべての付随するオーバーヘッドとともに、Swift言語ではオプションとして扱うことができます。または、オプション以外のタイプと同じように使用できますが、Objective-Cがnilを返すと、ランタイムエラーが発生するため、Swiftのコンパイル時の安全性の保証の一部が失われます。

最後に、SwiftとObjective-Cの間でプログラミングするときに考慮すべきもう少し微妙な不一致は、これら2つの言語でオブジェクトとクラスが内部で作成される方法と関係があります。 Objective-Cは、その動的な性質により、動的ディスパッチを利用してオブジェクトのメソッドを呼び出します（ objc_msgSendを介して）。 Swiftは確かに動的ディスパッチを使用できますが、静的に型指定されているため、 vtableを使用して各メソッドの関数ポインターを格納するオプションもあります。 Swiftがこれら2つのメカニズムのどちらを使用するかは、いくつかの要因によって異なります。 Plane Old Swiftオブジェクトは、クラスまたはクラス内のメソッドが@objc Swift属性を使用して注釈されていない限り、 vtableメカニズムを使用します。 Objective-Cクラスから継承するSwiftクラスは、継承されたメソッドに動的ディスパッチを使用しますが、サブクラスによって導入された新しいメソッドには使用しません（ただし、 @objc属性を使用して動的ディスパッチの使用を強制できます）。とにかく、Swiftコードは常にSwiftクラスで動作できますが、Objective-Cコードは、適切に注釈が付けられたSwiftオブジェクトとメソッドのみを利用できます。

Objective-Cよりも速いですか？

Appleが発売を発表したとき、特に強調されたSwiftの利点の1つは、その速度でした。これは、AppleがObjective-Cから高級言語に切り替えることを躊躇する理由の1つが、本質的にCの拡張であるObjective-Cが、はるかに高速で効率的なプログラムを作成できることであると考えると理解できます。 PythonやRubyのようなものよりも。それでも、Objective-Cは絶対的なパフォーマンスに関してはロケット船ではなく、その多くは動的型付けに起因する可能性があります。したがって、Swiftが静的型システムを採用している場合、Swiftは少なくともObjective-Cと同じか、それよりも高速である必要があります。

もちろん、ことわざにあるように、「嘘には、嘘、大嘘、ベンチマークの3種類があります。」（またはそのようなもの…）確かに、Swift言語がより速く実行される理由はたくさんあります。残念ながら、Swiftがメモリ管理にAppleのARC（自動参照カウント）技術を利用する方法では、特に最適化設定（開発中に使用する可能性があるものなど）が低い場合、Swiftのコンパイラが生成するプログラムが大幅に遅くなることがあります。幸いなことに、Swiftの改善によりこの問題が継続的に解決されているようです。したがって、近い将来、SwiftはObjective-Cと少なくとも同じかそれ以上の速度で実行可能ファイルを生成する可能性があります。

ただし、Swiftの速度には別の注意点があります。 Swiftの要点は、開発者がObjective-Cで記述したのと同じコードを記述しないことです。これはパフォーマンスにとって何を意味しますか？確かに、SwiftとObjective-Cのパフォーマンスの比較は、単純なベンチマークで明らかにできるよりも複雑であることを意味します。また、生成された実行可能ファイルの絶対実行時パフォーマンスを比較しても、話の半分しかわかりません。

誰もが高速なプログラムを望んでいますが、多くの場合、開発速度は、それ以上ではないにしても、重要です。より表現力があり、より少ないコード行でより多くの作業を実行できる言語は、この点で大きなメリットになります。一方、編集-コンパイル-実行-デバッグのサイクルがプログラマーの1日の大半を占めるコンパイル型言語で作業する場合、コンパイラーの速度が遅いと生産性が大幅に低下する可能性があります。証拠は主に逸話的ですが、Swiftコンパイラは現在、特にSwiftの高度な型システムを実行するコードを操作する場合は、煩わしいほど遅いようです。あるグループは、コンパイル速度がObjective-Cへの切り替えを動機付けるのに十分な問題があることさえ発見しました。

コンパイラ

Swiftコンパイラーと言えば、新しいSwift言語への切り替えを検討する際には、それ自体がさらに多くの警告の原因になります。コンパイル速度は別として、SwiftがAppleでSwiftを使用している開発者の小さな幹部から現れ、大衆に解き放たれるにつれて、コンパイラはストレスの下で亀裂を示し始めました。 Swiftコンパイラをクラッシュさせるコードの例を収集するための専用のGitHubリポジトリ全体もあります。

Swiftコンパイラがどのように変わるかという問題もあります。 GitHubの別のプロジェクトは、Swiftにどのような変更が加えられるかについて、コミュニティから推測と分析を収集することです。たとえば、カスタムオペレーターは、パーサーに大きな負担をかける可能性があります。当初、Swiftのカスタム演算子は疑問符（？）文字を使用できませんでした。これは最新のSwiftリリースで修正されていますが、有効なカスタムオペレーターと見なすことができるものの柔軟性をさらに高めるために、成長を続けるSwift開発者のコミュニティからリクエストが引き続きストリーミングされています。

言語のパーサーが流動的であると聞いたときはいつでも、一時停止する必要があります。言語のパーサーは、プログラミング言語の核心です。コードに意味を与えるために言語セマンティクスを適用する前に、最初に有効なコードとそうでないコードを決定するのはパーサーです。したがって、AppleがSwiftのランタイム互換性をある程度確保することを約束したことは心強いことです。ただし、XcodeやiOSの新しいリリースごとに再コンパイルせずに、Swiftコードが実行されることを必ずしも保証するものではありません。また、Swiftの将来のリリースとの互換性を維持するために、Swiftコードの一部を書き直す必要がないことを保証するものでもありません。しかし、繰り返しになりますが、このプロセスを可能な限り無痛にするというAppleの取り組みは、少なくともいくつかの小さな慰めです。

コミュニティ

これまでに作成された最悪のプログラミング言語のいくつか（名前はありません）は、それぞれのコミュニティの力だけで失敗したテクノロジーのゴミ箱に追いやられるべきだと常識が言ってからずっと後のことです。同時に、コミュニティの不足のために定着できなかった本当に素晴らしいプログラミング言語のコレクションは、数えるには多すぎます。強力なコミュニティは、チュートリアルを作成し、Stack Overflowに関する質問に回答し、オンラインまたは会議で直接会って、ストーリー、ヒント、トリックを共有し、有用なライブラリを相互に作成して共有します。プロジェクトに使用する言語を選択するとき、コミュニティは間違いなく考慮すべきものです。

悲しいことに、iOS / Objective-Cコミュニティは、友好的で歓迎的であるという評判が最も高くありません。それは徐々に変化しており、Objective-Cの開発においてオープンソースがますます重要な役割を果たしています。それでも、この初期段階では、Swiftコミュニティが今後どのようになるかを判断するのは困難です。それは主に、公式のApple APIと独自のコードのプライベートコレクションだけで作業する孤立した開発者で構成されますか？それとも、ヒント、コツ、便利なライブラリを共有するグループの活気に満ちたコミュニティになるのでしょうか。

コミュニティの役割のもう1つの側面は、Swiftの開発者自身の役割です。プログラミングの全体的な傾向は、プロプライエタリプログラミング言語とプラットフォームからオープンソースソリューションに移行することです。オープンソース開発は、特にプログラミング言語とランタイムのレベルで、真の利点になる可能性があります。 Swift開発者は、Swift言語とランタイムを完全にオープンソース化することを意図していると何度も述べていますが、それはまだ行われていないため、注意が必要です。

とは言うものの、Swiftの背後にいる開発者は、長期にわたるLLVMプロジェクトの背後にいる同じ開発者の一部です。 LLVMは、イリノイ大学アーバナシャンペーン校のプロジェクトとしてオープンで活動を開始したため、完全なアナロジーではありません。しかし、彼らの名誉のために、コア開発者は、彼らのほとんどがAppleで働くように移行した後も、非常にオープンでコミュニティとの関わりを保っています。 Swift言語が（ほとんど）オープンで開発され続けることを期待することは完全に合理的ですが、コミュニティからのパッチや機能の提案が言語に浸透するかどうかはまだわかりません。

Swiftを学ぶべきですか？

もちろん、ここに「1つのサイズですべてに対応する」という答えはありません。いつものように、仕事に適したツールを選択するには、問題のプロジェクトのすべての詳細についての深い知識が必要です。確かに、現時点では、Objective-CはiOS開発にとって「安全な」選択肢であり続けますが、Swiftは間違いなく検討に値します。

ただし、SwiftがiOS開発にもたらす最も重要な変更は、多くの開発者が初めて、「どの言語を使用すべきか」という質問をすることです。 Apple、Objective-C、およびiOSプラットフォームの歴史を考えると、特に選択がバイナリではないことを考えると、この変更だけでもかなりエキサイティングです。 Appleは彼らの好みを明らかにしているが、iOS開発者コミュニティ全体は何年にもわたって懸命に働いており、すでにこの質問に対してさらに多くの可能な答えを提供している。