なるようになるかも

力は多くの場合、その人の思いを超えない。

iOS9 SDKでDeprecatedになるもの。

UPDATE(2015/09/26):この文書はDeprecatedという単語の使い方が雑なのでDeprecatedになりました。

こちらの記事を参照した方が得るものがあるかと思います。

qiita.com


新しいAPIの誕生より、APIの滅びの方が好きです。なぜならそこには失敗があり、学びがあるからです。

developer.apple.com

…とか適当に言ってみましたが、iOS9のAPI Diffは、Swift2.0絡みの変更点(主にNSErrorに対応するenumの追加と、後述するビットマスクの扱いの変更)だらけで、本当に変わった場所がどこなのか分かりにくいので、ちゃんと調べてないです。

AudioUnitがOSXに追いついたCoreAudio周りが熱いような…。CFunctionPointerの魔窟だったCoreMIDIなんかは刷新と言っていいレベルで変わっていますね。でも今のAppStoreでオーディオ系のアプリに対価を出す人がいるのかっていうと、微妙なんですよねぇ。

ところで、APIDiffはFrameworksModulesに分かれているのですが(両方読む必要があります)、Frameworks側の記述はヘッダーファイルレベルの記載なのでObjective-Cになっていて、Modules側はSwiftで書かれていて、読み辛いことこのうえないです。

なぜこんなことになっているのかというと、フレームワークのヘッダは、SwiftとObj-C向けで共用するために、Obj-Cの形式になっているからですかねー。(Swift用のヘッダは、XCodeが動的に変換を掛けている)

RawOptionSetType

NS_ENUMマクロで定義されたenumSwiftでも素直に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以前からやっていた人や、互換性を意識していた人はCoreFoundationCFURLCreateStringByAddingPercentEscapes()関数を利用していたかと思いますが、これもiOS9で廃止されますので注意が必要です。

結構使われてそうな関数なのでちょっと意外です。ARCの概念を知らない人が使うとメモリリークするから?