WWDC 2016 iOS開発Tips
永井 佑樹
こんにちは。Airシリーズ開発チームでiOSの開発リードを担当している永井です。
今年、初めて現地に赴いてWWDCに参加してきました。
主なアップデート情報は既に様々な記事で紹介されている通りですが、WWDCでは新機能が紹介されるセッションの他に「こういう時はこうすると良いよ」というような開発Tipsが紹介されるセッションもあります。
本記事では、セッションの中から参考になりそうな開発Tipsをいくつかご紹介いたします。（網羅性はないことご了承ください。）
技術的負債の解消
Improving Existing Apps with Modern Best Practices
このセッションでは、既存コードの技術的負債や改善方法について語られています。開発者以外にも分かりやすく話されていて、チームに共有すれば改善の後押しになるかもしれません。
Deployment Targetの再考
動画：02:34 -
2016年5月時点でiOS8以上のユーザーが95%を占めています。セッション中では、アプリのOS対応バージョンを「最新メジャーバージョンの1つ前 & マイナーバージョンが最新のもの」以上（つまり現在ならiOS8.4以上）にすることが推奨されています。
iOS8で登場したDynamic Frameworkなど、対応OSバージョンの選定によって単に保守範囲が広がるだけでなく開発方法も変わってくる場合があるので、古いバージョンをサポートする場合もデメリットはきちんと議論して決めていきたいですね。
Asset Catalog
動画：10:00 -
AirシリーズではAsset Catalogを活用していますが、未導入のアプリも少なくないようです。
1倍画像だけを入れている場合に、2倍・3倍スケールの端末で画像が荒くなるのは言うまでもありませんが、3倍画像のみを入れている場合もメモリ圧迫してしまいます。今後はAsset Catalog上にベクター（PDF）ファイルを追加していくのが手間が少なくて良いでしょう。
依存性注入（Dependency Injection）
動画：19:05 -
DIを活用しようという内容もありました。これはとても長らく言われてるはずのことなんですが、AppDelegateにいろいろ持たせてAppDelegate経由で呼ぶ処理、未だに見かけますね……。
起動時間短縮
全てはmain()関数の前
起動時間が長い時applicationWillFinishLaunchingも疑ってしまいますが、大抵の場合main()関数までの処理が原因である場合が多いようです。
400msを目標に
動画：22:30 -
OSのアプリ起動アニメーションがだいたい400msなので、アプリの起動時間も400msを目標にしましょう。
計測方法：DYLD_PRINT_STATISTICS
動画：25:48 -
環境変数にDYLD_PRINT_STATISTICSを加えることで、これまでもmain()までの処理時間を確認することができましたが、seed 2からより詳細なデバッグ情報を確認できることになるようです。
Swiftで書こう
動画：36:15 -
起動時間改善のためにも、
Rewrite in Swift
だそうです（笑）。
国際化対応
Internationalization Best Practices
timeStyleを活用しよう
動画：12:30 -
NSDateからStringにフォーマットする際、下記のようにdateFormatで指定する場合も少なくないと思います。
1
2
3
4
5
// スライドより拝借
var formatter = DateFormatter()
formatter.dateFormat = "hh:mm a"
let str = formatter.string(from: date)
しかしこのように指定した場合、英語環境では正しく9:41 AMとなりますが、中国語環境では本来上午9:41であるべき所で9:41 上午と出力されてしまいます。dateFormatの文字列を言語環境に合わせて変更することもできますが、セッションではtimeStyleによって指定する方法を推奨しています。
1
2
3
4
5
// スライドより拝借
var formatter = DateFormatter()
formatter.timeStyle = .shortStyle
let str = formatter.string(from: date)
この方法であればアプリが意識すべき範囲を削減できて良いですね。ただし現在の表記がNSDateFormatterStyleにない場合、仕様変更調整が必要です。
Auto Layoutを使おう
動画：18:10 -
Right-to-Left（RTL）な言語にも対応できるようにAuto Layoutを活用しましょう。UIStackViewやNSStackViewも便利なので使っていこうと紹介されています。iOS9以上のサポートになり次第ぜひAirシリーズでも使っていきたいです。
ただし、翻訳した結果文字の長さが大きく変わる場合には個別で対応していく必要があります……。
UIFont.preferredFont(forTextStyle:)を活用しよう
動画：22:15 -
言語によっては、行間の幅も調整する必要が出てきます。セッション中ではヒンディー語が英語と同じスタイルだと読みにくいという例が紹介されていました。
そんな時は、UIFont.preferredFont(forTextStyle:)を使えばOSがよしなにフォントを設定してくれます。
Size Classesの活用
Making Apps Adaptive, Part 1
Making Apps Adaptive, Part 2
各端末サイズ、端末の向き、マルチタスキングそれぞれのパターンを考えるだけでも、考慮すべきレイアウトパターンは22種類にも及びます。セッション中では、Dynamic TypeやRTL言語対応なども含めて、300以上のパターンになると話されていました。
その膨大なパターンを簡略化するための仕組みがSize Classesです。Size Classesの分類に従えば、縦横それぞれCompact/Regularの4パターンに絞ることができます。実際にはその他の条件も見ながらレイアウト調整必要なこともあるでしょうが、可能な限りこうした仕組みを採用して、アプリ自身が考慮すべき項目を減らしていきたいですね。
値型の活用
Understanding Swift Performance
このセッションは複雑化したアプリケーションコードをProtocol Oriented Programmingで改善していく、最近よくあるようなセッションではありましたが、「値型は簡素なモデルのためだけのものではない」という部分が印象的でした。実際に、セッション中ではこれまでの一般的なstructの利用方法を超えた例が紹介されていました。
AirレジSwift化の際、structを活用しようと掲げたものの、まさに「簡素なモデル」への適用に留まっていたので、再度活用を検討してみたいと思います。
WKWebView
セッションで明言されていた内容ではありませんが、UIWebViewはやっぱり消えていく運命なのでしょうね。ATSの内容の中でもWKWebViewでは回避策があるものの、UIWebViewの話は一切挙がりませんでした（笑）。
AirシリーズではまだWKWebView/SFSafariViewControllerに移行できていないものもあるので、今後移行検討していく予定です。
最後に
iOS開発をする上では、Apple社の開発Tipsはぜひとも参考にして実践していきたいところです。
この他にもCore Location Best PracticesやNSURLSession: New Features and Best Practicesといったセッションもあるので、興味があればぜひ参照してみてください。