iOS9 SDKでDeprecatedになるもの。
UPDATE(2015/09/26):この文書はDeprecatedという単語の使い方が雑なのでDeprecatedになりました。
こちらの記事を参照した方が得るものがあるかと思います。
新しいAPIの誕生より、APIの滅びの方が好きです。なぜならそこには失敗があり、学びがあるからです。
…とか適当に言ってみましたが、iOS9のAPI Diffは、Swift2.0絡みの変更点(主にNSError
に対応するenumの追加と、後述するビットマスクの扱いの変更)だらけで、本当に変わった場所がどこなのか分かりにくいので、ちゃんと調べてないです。
AudioUnitがOSXに追いついたCoreAudio周りが熱いような…。CFunctionPointer
の魔窟だったCoreMIDIなんかは刷新と言っていいレベルで変わっていますね。でも今のAppStoreでオーディオ系のアプリに対価を出す人がいるのかっていうと、微妙なんですよねぇ。
ところで、APIDiffはFrameworksとModulesに分かれているのですが(両方読む必要があります)、Frameworks側の記述はヘッダーファイルレベルの記載なのでObjective-Cになっていて、Modules側はSwiftで書かれていて、読み辛いことこのうえないです。
なぜこんなことになっているのかというと、フレームワークのヘッダは、SwiftとObj-C向けで共用するために、Obj-Cの形式になっているからですかねー。(Swift用のヘッダは、XCodeが動的に変換を掛けている)
RawOptionSetType
NS_ENUM
マクロで定義されたenumはSwiftでも素直にenumになるけれど、NS_OPTIONS
マクロで定義されている場合にはRawOptionSetType
構造体に変換される、という特殊ルールについてご存知でしょうか。
Swiftのswitch-caseのパターンマッチングの強力さと、enumを組み合わせた安全性は言語仕様の魅力のひとつなのですが、素朴なビットマスクには弱いのです。
しかしご安心下さい。Swift2.0ではOptionSetType
構造体がその座に取って代わります。これはSetAlgebraType
プロトコル(SetAlgebraは集合代数の意味)に準拠しており、ビットマスクを扱いやすくするメソッドが追加されています。また独自のビットマスクを定義することも簡単になるみたいです。
独自のRawOptionSetType
や、RawOptionSetType
のextensionを作っている人は今のうちにこっそり削除しましょう。
AddressBook/AddressBookUI
滅亡します。
これはSwiftから使うのが辛そうな(そもそも可能だったんでしょうか?)APIだったので、順当に死にましたねーって感想。
Contactフレームワークがaddedになっているけれど、実際にはAddressBook内部で使われていたCNContact
が機能拡張されて表に出てきて、AddressBookUIに対応するContactsUIが追加される形になっているような気がします。
新しいAPIはモダンで綺麗で素敵なんだろうなー!!と思ってみてみたら、NSPredicate
を使うのかなこれ…。
stringByAddingPercentEscapesUsingEncoding
誰もが一度はこのメソッドに騙され、URLエンコードに失敗したのではないでしょうか。
:
や/
をエンコードしてくれない存在意義がいまいち良く分からないメソッドでしたが、ようやくiOS9で廃止されます。
今後は、iOS7以降のみ使える、stringByAddingPercentEncodingWithAllowedCharacters
が推奨されます。これも正しく使わないと変換できませんが。
iOS6以前からやっていた人や、互換性を意識していた人はCoreFoundationのCFURLCreateStringByAddingPercentEscapes()
関数を利用していたかと思いますが、これもiOS9で廃止されますので注意が必要です。
結構使われてそうな関数なのでちょっと意外です。ARCの概念を知らない人が使うとメモリリークするから?