[iOS 10] CoreDataの変更内容をまとめてみました。

CoreData

こんにちは！
モバイルアプリサービス部の田中孝明です。

CoreDataといえば、macOS / iOSアプリ開発において、標準的なローカルDBとして利用されてきましたが、比較的レガシーな構造なため、学習コストが高いことでプロジェクトへの組み込みを敬遠されることもありました。
長らくアップデートされることが無かったのですが、iOS 10にて若干の修正がされました。
今回は気になった修正内容を記述していきたいと思います。

モデルの定義の変更

モデルの定義にClass Definitionが追加されました。
Xcode 8.0以前ではCoreDataのエンティティを作成すると、NSManagedObjectを継承したモデルクラスを別途作成することが多かったと思います。（無くても良いが、メンテナンス性に難がある）

Class Definitionを指定することで、以下のようなNSManagedObjectを継承した拡張クラスとして扱えるようになります。

Event+CoreDataClass.swift

import Foundation
import CoreData

@objc(Event)
public class Event: NSManagedObject {

}

このエンティティの定義の変更によって、エンティティの作成と更新の煩雑な作業が解消されました。

Generics

Fetch処理にGenericsでモデルの型を指定するようになりました。

前のバージョンまではNSFetchRequestのentityNameで対象のモデルを文字列で指定していました。

let request = NSFetchRequest(entityName: "Event")

Swift 3.0からはGenericsでモデルの型を指定できるようになりました。

let fetchRequest: NSFetchRequest<Event> = Event.fetchRequest()

NSManagedObjectを継承したモデルクラスであれば、fetchRequestメソッドが備わっていますので、NSFetchRequestを生成することが可能です。

UITableViewControllerやUICollectionViewControllerと親和性の高い、NSFetchedResultsControllerも同様にGenericsでモデルの型を指定できるようになりました。

var fetchedResultsController: NSFetchedResultsController<Event> {
    ...
}

ここで注意すべき点ですが、NSFetchRequestとNSFetchedResultsControllerはSwift 3.0でもNSprefixが付いているので、次回バージョン以降で変更される可能性はあります。

並列書き込み処理の変更

PersistentStoreCoordinatorが別々のManagedObjectContextからDBへの並列書き込みが発生した場合、DBをロックするタイミングが変更されました。
こちらに関しては検証プログラムを用意する必要がありますので、別の機会で検証したいと思います。

まとめ

最近ではRealmを採用するプロジェクトも増え、学習コストが比較的高めのCoreDataは敬遠されがちです。
しかし、開発環境が標準で備えているローカルDBは、学習しておくことで最新のOSなどの対応を迅速に行うことが可能です。
CoreDataの基礎についてはいずれかのタイミングで記事にしたいと思います。

参考文献

What's New in Core Data