非専業プログラマにとってSwiftDataという福音であった
非専業プログラマーにとってはiOSのデータ永続化は難しかった
iOSやiPadOSなどでデータを永続的に保管したい場合、それまでCoreDataを使っていたらしい。しかしこのCoreDataだが、非専業の初心者にとっては非常に学習のハードルが高い。
- CoreDataの概念が非常に複雑
- 低層レベルまでコードを書き込む必要があり、iOSプログラマとしての経験が必要
- 日本語での資料が不足しており、独学で学ぶ場合英語が必須
- 英語で独特な概念を理解しなければならず、コードを書くまでにかなり時間がかかる
- Objective-C時代の名残をかなり残している。
企業のノウハウにあずかることができない非専業日本人プログラマーにとっては非常にハードルが高いものであった。
Swiftの歴史をおさらい。
SwiftDataは2023年に開催されたAppleのソフトウェア技術の発表会であるWWDC23で初めて披露されたライブラリである。
Appleは2015年に主力の開発言語としてSwiftを発表していらい、それまで使われていたObjective-Cをモダンな言語に置き換えることに注力してきた。
2019年には従来のGUIフレームワークであるStoryBoardの代替えとして、SwiftUIを発表。コードのみでUIデザインを完結させる方向へ舵を切った。これもモダン化の一つである。
しかし残るObjective-C時代のレガシーたち
とはいえ、Objective-CはAppleのテクノロジーの根幹であって、そう簡単に全てのコードがSwiftになったわけではない。2015年から9年経ったいまでもそうである。Appleは膨大なObjective-Cをすべて一気に書き換えることはせず、SwiftとObjective-Cの互換性を確保して、徐々にSwiftに移行させている。
NSと頭文字につくオブジェクトはObjective-Cで実装されているオブジェクトと見て間違いない。なぜならば、NSというのはNeXTSTEPの略であり、これはスティーブ・ジョブズ氏がAppleを退社後に作った会社NeXTが作ったオペレーティングシステムの名称なのである。
AppleはNeXTを買収し、現在のMacOSになるOSX作った。OSXの基盤はNeXTSTEPであった。さらにOSXはiOSを作るための土台となった。
こういう歴史的経緯でiPhoneアプリ開発にもNSオブジェクトが登場することになった。もちろんObjective-Cが開発言語に使われることになった。
30年以上の歴史が積み重なっているのだから、Objective-Cのコードが全てSwiftに置き換わるのはまだ時間がかかるだろう。
UIKitというつまづきの石
さらに初心者の頭を悩ませるのはUIKitの存在である。SwitUIが発表されるまでiOS開発はUIKitがAppleが推奨する唯一のGUI開発のライブラリであった。そしてUIKitはStoryBordというシステムによってグラフィカルにGUIを作ることができた。
しかしその反面、コードではなくXcodeに組み込まれたシステムによって制御される挙動が数多くあり、コードを学ぶというよりXcodeの扱い方やAppleの組み込んだシステムを学ぶ時間を長くとらねばならなかった。
Webシステムを勉強してHTMLやJavaを学んだ人間にとってこれはつまづきになりうる。Appleが組んで設定したシステムを学ばなくてはボタンひとつ挙動させるのが難しいのだ。
さらに同一画面であっても、タブやリンクを追加するごとにStoryBordが肥大化していき、開発画面に何十ものボードが並んでいく。これを制御する人間はもはや職人である。
SwiftUIが登場！でも顔をだすUIKit
Appleもモダンなアプリ開発がStoryBordのようないわゆる命令的UIではなく宣言的UIになりつつあることを察して、SwiftUIを発表した。これによりStoryBordが肥大化しつづけることはなくなり、開発画面も学習コストもシンプルになった。
しかし、前述の通りAppleは膨大なレガシーから独立したわけではなかった。とくにUI以外のAppleデバイスの機能を実装しようとした場合UIKit時代のコードを書く必要があった。CoreDataやCloudkitはその代表格である。
おそらく私のような非専業プログラマで「SwiftUI」で簡単にアプリが作れる！と考えていた人間はデータを永続化しようとして面食らったのではないか。
いきなり下のような単語が続出して頭が混乱してくるのだ。
- NSManagedObjectModel
- NSPersistentStore
- NSPersistentCoordinator
- NSManagedObjectContext
- @FetchRequest
- NSSortDescriptor
SwiftUIで少ないコードでアプリ構築をして自分でもアプリが作れるぞ！となった矢先にこれである。
データ永続化をしようとしたやさきにUIKit時代に先祖帰りしてしまうのである。
コードがObjective-Cのように複雑になり、文字量も増え疲れる。Swiftで書いてるようで、Objective-Cを書かされているような感覚になる。
詳しい情報を調べようにも日本語では詳しい資料が不足しているのである。特にCloudkitは不足している。多分、個人や非専業の利用のシーンが少ないのだろう。APIサーバを建ててRDB使うなり、Firebase使えば企業ならば簡単に代替えは可能だ。
だが、私のような非専業としてはiCloudの無料枠1PBは安心感がある。なんとかして使いたいのである。
CoreDataで求められてしまうシステムプログラミング
CoreDataを使うためにはCoreData Stackの仕組みを理論的に理解する必要があった。
CoreData Stackは以下の５つの要素からなる
- アプリケーション本体
- Context・・・Persistent Storeにデータを読み書きさせるように命令をだす
- Model・・・Pesistent Storeとコードの仲介をする
- Persistent Store・・・データの形を加工してファイルに書き込む
- ファイル・・・書き込まれる場所
自分で書いていてもよくわからない。が、内部構造はこうらしく特にContext、Model、Persistent Stroeを制御するオブジェクトが多数存在する。
SwiftUIですいすいコーディングできてたのに、ここでいきなりシステムプログラミングみたいな抽象度が増してきてハシゴをはずされたようであった。
詳しく勉強すればいいかもしれないが、やはりモノができないとやる気が出ない。データを永続化しないと業務で使うアプリにはならない。
ネットに転がっているサンプルもほとんどUIKitメインであり、解説もUIKitをやってきた歴戦の猛者たち向けなのだ。これでずっと悩む日々であった。
2023年SwiftData現る
2023年、Swift登場から8年、SwiftUI登場から4年。ついに、Objective-Cライクなデータ永続化ライブラリから脱却できるSwiftDataが発表された。SwiftUIのコードとマッチする宣言型のライブラリであった。
細かい制御などを気にしなければコード量と前提とされた知識はは劇的に減ったのである。正直、非専業であればこれで十分に見える。自分の職場で使うぶんには銀行のトランザクションを処理するわけでもないのだから、精密な制御は出番がない。
SwiftDataのなにがすごいかといえば、さきほどのCoreData Stackの仕組みを知る必要がないということである。WebアプリのフレームワークのようにCRUDもCoreData専用の知識がなくてもできるのである。
以下の記事を見てもらいたい。Cloudkitを使っているのに複雑なNSオブジェクトは一切登場していない。
モダンな他の開発環境と同じく、データベースプログラマーがシステムを直接叩くようなことを要求されなくなったのである。
これからはSwiftDataを試していきたい。
Discussion