Go to Qiita Advent Calendar 2024 Top
LoginSignup
283
283

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@mono0926(Swift/Flutter 🐶 mono )

秋のiOS 9対応リリースに向けて、iOSアプリ開発者が今からやっておくべきことまとめ

Last updated at Posted at 2015-06-30

一部メンテナンスはしていますが、本記事は2015年7月執筆で後から読むと不自然な記述が混ざっています。それを踏まえて読めば、内容的には間違っていないと思います。

新型iPhone・iOS 9のリリースは9月25日あたりと言われていますが、僕も例年通りこのあたりと見ています。
よほどのことが無ければ、9月下旬からはそうズレないでしょう。
→ 9月18日の噂も出てきました

【確定しました】

  • iOS 9: 2015年9月16日リリース
  • iPhone 6s系: 2015年9月25日リリース

このあたりダウンロードして対応しましょう(　´･‿･｀)

7月になったばかりでちょっと早いと思うかもしれませんが、そろそろそれに向けての対応を少しずつ準備する必要があると思っています。

既存アプリをiOS 9対応するために必要な作業

最小工数コース: Xcode 6でiOS 9対応

現状の開発環境(Xcode 6)で、iOS 9端末上で動かした時のバグを潰す、というのが一番楽です。
8月くらいから、iOS 9 βをインストールしたテスト端末で、アプリをテストしてバグを洗い出して、どんどん潰していくという感じですね。
Xcode 6でiOS 9シミュレーターは実行出来ないはずなので、実機でのみの確認となります。

今までは、規模の大きなアプリ・凝ったUIのアプリでは新iOSリリースの度にけっこう壊れて直すのが大変でしたが、iOS 9に関してはあまりアプリの挙動に影響を及ぼすような変更が少なく、 今年は楽な年 になりそう、と感じています。
(私物iPhoneにiOS 9βをインストールして、自分で開発しているアプリ・ストアのアプリ群を日々弄っている印象から)

メリット

  • 対応工数が抑えられる

デメリット

  • iOS 9の新しい機能が使えない
  • Xcode 7の新しい機能が使えない
  • Swift 2の新しい構文が使えない
  • watchos 2対応出来ない
  • 結局いつかはXcode 7への移行が必要

最後の項目は重要です。
Appleは比較的早く古いXcode・SDKでのアプリ申請・更新の受付をやめます。
去年は以下で、例年このような感じです。

  • Xcode 5での新規アプリを受付廃止: 2015/02/01
  • Xcode 5でのアップデート受付廃止: 2015/06/01

参考: Appleが2015年2月1日から新規アプリ及びアプリのアップデートは64ビットをサポートしiOS8SDKで開発されたアプリのみ申請受付と発表 - Qiita

どういう時にこのコースを選ぶべきか

メリット・デメリットを見れば分かりやすいですが、8-9月にどうしてもXcode 7対応の工数が確保出来ない時にこのコースを選ぶと良いと思います。

先延ばしにすることで、その間に書いたコードで負債が貯まっていきますし。
ただ、少し待ってからアップデート対応すると、ノウハウがネット上などに蓄積してきて、ぐぐった時などに解決がスムーズになる、というメリットもあります。

Xcode 7に移行

というわけで、リソースさえ確保出来れば早いタイミングでXcode 7に移行するのをオススメします。
が、それなりに大変です。

主な作業

  • コンパイルエラーを直す
    • Swiftコードはけっこう変更が必要となるはずですが、まあちゃんとエラー文読み解きながら淡々と作業すれば半日〜1日あれば潰せるのでは無いですかね
      • ただ、外部ライブラリに依存していてそのライブラリがSwift 2に未追従の場合は、ForkしたりPR出したり、さらにキツい作業を強いられます(´・︵・｀)
    • Objective-Cで書いてある場合はほとんどそのまま動くはずです
  • バグったところを直す
    • Xcode 7・iOS 9 SDKでビルドした際、微妙な変更で機能的におかしくなったりする
    • 見た目が崩れたり挙動がおかしくなったところを直す
    • こっちは実際動かしてみないと分からないが工数が膨らむことがありうる。iOS 9はUI上の差分が少なめなので、ここ数年よりは軽微なものに収まりそうとは思いつつ。

ここで注意なのが、Swiftコードは、欲張ってSwift 2の文法を取り入れたベターな書き方に変えすぎないことです。
ただでさえすることが多いので、ぐっと堪えて最小限のコンパイルエラーを潰す作業に徹して、リファクタリングは後回しにしましょう(　´･‿･｀)

メリット・デメリットは「最小工数コース: Xcode 6でiOS 9対応」の逆ですね。
加えて、デメリットとして、Xcode 7対応開始したら、開発リソースが少ない場合他の機能開発はストップせざるを得ないということがあります。
致命的なバグに対する最低限のhotfixのみという感じとなります。
複数人開発だったら、分担してXcode 6上で機能開発、Xcode 7対応、と分けることも出来ますがコンフリクト起こしやすくなりますし、Xcode 7対応注力の方が効率は良いです。

これを乗り越えると、新しいSDKの恩恵が色々得られますのでがんばりましょう(　´･‿･｀)

必要な工数

アプリの規模に依存しますが、1人でやるとして少なくとも1週間〜1ヶ月は見積もった方が良いと思います。
僕の感触では、今年はSwift 2対応以外は、例年に比べて対応が楽な年だと思っています。

今開発中のPlayer!については、1人で2週間くらいかなと思いつつ、リスク含めたり新API使った機能も取り入れたいということで1ヶ月と表明しています(　´･‿･｀)

1ヶ月の場合、スケジュールはこうなります

  • 8月半ばから対応を開始
  • 9月半ばまでに対応が終わり、ちょうどその頃リリースされるXcode 7 GMにてビルドしてリリース
    • もし早めに対応終わっちゃったら他の機能実装するなど
  • Xcode 7対応のアプリは優先的にレビューされるはずなので、晴れてローンチアップデート成功するはず

→【追記】画面数が数十程度のアプリ(今開発中のPlayer!)でも半日程度で移行出来ました。今年は予想以上に楽な年でした。作りが悪いと画面崩れなどあり得るかもしれませんが、Appleの推奨通りのお行儀の良い作りにしてあれば問題無かったです。
余裕が出た分は、Search API使った機能の実装などに充てられました。
GM版の1つ前の版で対応し、GM版リリースされたらそれでビルドかけましたが、特にコンパイルエラー・バグなど無く、そのまま申請予定のビルドを作れました。

CI環境整備

自前のサーバー上でJenkinsなど使っている場合は単純にそのマシンのXcodeのバージョンを上げるなど、ちょちょいと弄れば済みますが、Travis・CircleCIを使っている場合、ここが悩ましいです。

まず、Travis・CircleCIは、Xcode正式版が出てしばらく経たないと対応されないとみなしましょう。(これまでそうなので)

というわけで、選択肢としては以下ですかね。

  • Jenkinsなどに移行
    • Jenkins環境整備・メンテナンスが手間なので、Travis・CircleCI選んだはずなので、微妙な選択肢
  • 開発マシンなどでビルドしてしのぐ
    • Xcodeのアーカイブ機能や手元でコマンド叩くなど
    • 今開発中のPlayer!ではfastlaneを使っているのでそのlaneを実行すればほぼCI環境を再現出来るのでしのぎやすい。 fastlaneオススメです(　´･‿･｀)
    • BUILD_NUMBERのインクリメント管理をどうしようか悩み中
  • Bitrise - iOS Continuous Integration and Deliveryなど最新版のXcode追従が早いものを使う
    • @su_aska さんからのコメントより
    • ただ、Xcode 7 GMが出てからどのくらいで更新してくれるか何とも言えない

【2015/08/27追記】TraavisがXcode 7 beta 6に対応しました:
The Travis CI Blog: Xcode 7.0 Beta Is Now Available

【2015/09/11追記】TravisがXcode 7 GMに対応しました。(fastlaneも標準装備!)
The Travis CI Blog: Xcode 7 GM available for everyone

アプリ配信

iOS 9 betaアプリは配信出来るのか？という心配があります。

iTunes ConnectのTestFlightにはこう明記してあるので安心です。

You can now invite your internal testers to test apps that you’ve built for iOS 9 beta.

Crashlyticsは未調査です。(追記予定)

意思決定

というわけで、以上を踏まえて、開発体制としてどうするかを今くらいのタイミングから展開・相談しておくと良いです。
新しいXcodeへの移行作業の時期・大変さを適切に展開しておかないと、それ抜きで通常通りのリリーススケジュールが組まれてしまいます。

Xcode 7/iOS 9対応したらやりたいこと

「Xcode 7に移行」だけで精一杯かもしれませんが、せっかく対応したので、何か新しいAPIを使った機能を取り入れたいですよね。
Xcode 7対応自体大変なので、今のうちから新しいAPIなどの情報収集やそれを使った機能を練るなどの作業をしておかないとローンチアップデートには間に合わないと思います。

メリット

「新APIでUX上げたい」という単純な動機以外に、 AppStoreでiOS 9対応アプリとしてフィーチャーされる可能性 という大きなチャンスがあります。
1年のうち数少ない機会なので、是非活用していきたいところです(　´･‿･｀)

iOS 9の新API

派手な機能は無いですが、ちょくちょく便利になっている印象です。

個人的には、Search APIに注目してます(　´･‿･｀)
→ 【追記】早速書きました:iOS 9の「Search API Best Practices and FAQs」が公開されたので読み解いてみた - Qiita

あと、iOS9 - iOS 9の新しいWebビュー: SFSafariViewController - Qiitaも手軽に導入出来て良いですね(　´･‿･｀)

watchos 2

僕は今回はこちらに手を付けられる余裕無さそうですが、楽しみですね。

参考資料

ぐぐってもなかなか情報がヒットしない時期なので、一次ソースが一番の情報源です。

その他、Swift - iOSアプリ開発情報の集め方 - Qiitaなど参考に有用な情報をかき集めていきましょう(　´･‿･｀)

その他

iOS 9の挙動を知る

WWDCの発表などでもざっくりiOS 9の機能など分かりますが、やはり触ってみないと分からないことも多いです。
また、iOS 9上でアプリがどんだけバグるかも早めに知れるので、見積もりもしやすくなります。
僕は私物端末にβインストールしちゃって、開発中のアプリに対して気づいたバグなどメモっています。
βゆえにOS自体の一時的なバグで、自然と直ることも多いので着手タイミングまではメモにとどめています。

僕みたいに、私物端末にインストールしちゃうのは是非があると思います。

メリット

  • やはり普段使いして日々触れないと分からないことが多い

デメリット

  • 最悪、メイン利用のアプリや開発中のアプリが全く使えなくなることがある
    • 特に開発中のアプリで全く使えないと、開発端末が1つ減ることになるし、バグ気になっちゃうし
    • 逆に軽微な挙動不審などだったらありがたい情報

無難な選択肢はiOS 9 βをインストールしたテスト端末を用意してちょくちょく弄ることですね。

というわけで、iOSアプリ開発者にとって毎年地味に大変な作業ですが、Xcode 7/iOS 9対応がんばりましょう(　´･‿･｀)

go.png

自作スタンプ(ラヴさん (ラブラドール) - LINE クリエイターズスタンプ)より拝借

283
283
4

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
283
283

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?