iPhone 6 および Plus の画面まわりについて、やや開発寄りに

　いよいよ、iPhone 6が発表されましたね。

　今回は、かなり事前から「iPhone 6 のディスプレイは 4.7 インチと 5.5 インチの２パターンになる」というリークがあった訳ですが、「また大画面厨がなんか言ってるわ。いい加減、諦めればいいのに。iPhone は、手のひらにすっぽり収まる 4 インチだからこそいいんじゃないか」みたいにガセであると確信していた私は、まるで相手にしていませんでした。

　ま、まさか、ホントに 4.7 インチと 5.5 インチになるとは......

　普通はさ、これまでの手のひらサイズ厨にも配慮して、4 インチと 4.7 インチの２パターンとかにしませんか。なんでいきなり、小さい方でも 4.7 インチになっちゃってんの......

　iPhone 6 の小さい方とか言って、どっちもでっかいよ！

　大画面厨、大勝利！

　おめでとうございます！

　畜生め！

　はぁ......同時に発表された Apple Watch も、なんだか購買意欲をそそりませんし、iPhone は新しい画面サイズが一気に２つも増えて開発が面倒臭くなっただけだし、今回の発表は個人的に全くワクワクしませんでした。

　なーんかなー、やっぱり Apple はギーク寄りに変わってきてる気がするなぁ（彼らが喜びそうな変更ばっかり的な意味で）。以前の Apple だったら、iPhone の画面サイズはこうならなかった気がするんだけどなぁ。いや、ひたすら個人的な見解に過ぎませんけど、いままで持っていた Apple ならではの強みを、業界標準を追いかけることで徐々に削ぎ落としているような。

　まぁ、愚痴ばっかり言ってても仕方ありません。画面サイズが２パターン増えたということは、サイズ別に用意するアイコン等の画像がまた増えるということなので、マジいい加減にして欲しいと思いつつ、さっき Xcode 6 を落としたら、なんか知らんけど beta が取れててシミュレータで iPhone 6 と 6 Plus が選択できたので、そちらも軽く確認しつつ、新しい iPhone の主に画面まわりについて見ていきたいと思います。

　正直なところ、新しい iPhone は、画面まわり以外は気圧センサーと脈拍センサー*1と NFC がついたくらいで、その他は当たり前の進歩しかしてないので、特にみるべきところはありません（断言していいのか）。

　どころか、私の見かけた情報だとメモリ 1GB って書いてあったんですけど、いや、画面とかよりそっちを 2GB にしておきなよ...... iOS 7 以降はシステムがメモリワーニングをすげー気軽に発行するクセにさー。なんかチグハグですよねー。
（2014/10/21追記：実機確認の為に仕方なく入手した iPhone 6 Plus で sysctl の hw.memsize の値を取ってみました。よろしければ、そちらもどうぞ）

読み込み中です。少々お待ち下さい

まずは、画面の比較表から

　そいでは、まずは解像度の辺りから。

　情報は、基本的にこれらを参考にしました（画面サイズのみ、実際にシミュレータで取得した値です）。

• Apple - iPhone - モデルを比較する
• Apple - iPhone 6 - ディスプレイ
• iPhone 6と歴代iPhoneのスペックをまるっと比べてみました

※スマホ等で表が画面に収まりきっていない場合は、表だけ左右にスライドできます

　この表を踏まえて、気になる点について、以下で個別に見て行きましょう。

アスペクト比と起動画面

　こうして見ると、iPhone 6 はディスプレイを物理的に大きくしつつも ppi はそのままに保った、これまでの iPhone 5(s) の正統後継機であることが分かります。

　まぁ、だからこんな中途半端な画素数なんですが。
　ていうか、iPhone 5(c,s)とも、微妙にアス比違うけどね。

　うぅん、この微妙さはどうなんだろう。iPhone 6 Plus は、ようやくアスペクト比が一般的な 16:9（1920x1080 のフル HD）に落ち着きましたけど、元々 iPhone 5(c,s) はアス比がほぼ 16:9 というだけで、正確には 71:40、iPhone 6 に至ってはさらにそれとも違って、正確には 667:375 なんですよ。
（ここで述べているのは、ソフト的な話です。iPhone のピクセルアスペクト比は 1:1 だと思うので、ハード的にもそうだと思いますが）

　より比べやすいように書くならば、iPhone 5(c,s) のアス比は約 16:9.014、iPhone 6 は約 16:8.9955 です。多分。

　まぁ、iPhone 6 の方は 16:9 と言い切ってしまっても大丈夫かなーと思うレベルの微差ですが、iPhone 5(c,s) の方は 16:9 換算で縦（長辺）に合わせると、横（短辺）が実際に 1 ピクセル足りなくなるんですよね（1136x639）。

　じゃあ、横に合わせれば良いかというと、そうすると今度は iPhone 6 で縦に 1333.33... になってしまって（16:9 換算で横に合わせた場合）、iOS が内部的にどう処理するんだか分かりませんが、余分を調整する為に無駄な拡縮が発生してしまう気がするんですが、どうなんでしょうか。

　ここで述べた点について、最も直接的かつ単純に関係するのは起動画面（画像）なのですが、Xcode 6 からは Launch Screen にストーリーボードを指定できるようになったみたいなので（Launch Screen File。xib でおっけーです）、自分で好きなように対処すれば済みそうだから、どうでもいいっちゃどうでもいいのかも知れません。

　ただ、iPhone 6 Plus を基準にして 16:9 で全部合わせちゃうと、5 やら 6 やらで画像の無駄な拡縮が発生するんじゃないかなーということを憂慮している訳です。

　画質に超こだわる場合は、少し大きめに作って切り捨てるのが一番綺麗なのかな。

　ちなみに私は、超こだわってはいないです。というか、画面サイズ別の起動画像を全部いちいち用意するとかいう前時代的な手間をかけずに、全てのサイズに対してプログラム側で適当に対応させられるので、ジツは待ち望んでいました、この機能。

　それにしても、いまさらフル HD にするくらいなら、5 の時からアス比 16:9 にしとけばよかったのにと思わずにいられません。

　でもまぁ、現在生きている端末はほぼ Retina の筈なので（非 Retina で iOS 8 が正式サポートされるのは、無印 iPad mini と iPad 2 のみ）、基本 4 倍密以上で表示してるから、別に 1 ピクセルくらい無視してもいっか！

（「コイツ、さっきから何言ってんの？」と思った方は、今後の起動画像は最低でも 1920 x 1080 以上で作ろうかなとほざいているのだとご理解ください。
　いや、待てよ。後でもう少し触れますが、iPhone 6 Plus 用には 1242x2208 と 2208x1242 の縦横を用意した方がいいのかも？）

iPhone での横向きについて

　それから、問題は困ったちゃんの iPhone 6 Plus です。どうやら、デフォルトで横向きがサポートされるらしいですよ。

　いや、今までも iPhone での横向きは、アプリ側で頑張れば対応できたんですが、対応することにほぼ意味が無かった為、実際は縦向きしか考えられていないアプリがほとんどだったりするのです（ゲームと動画系を除く）。

　なので、これまではアプリで横向きをサポートしていても、「お、やるじゃん」みたいに感じるだけだったのですが、OS がデフォルトでサポートしてしまうということは、今後は iPhone アプリも iPad アプリのように、基本的に横向きも考慮して実装しなきゃいけないでしょうねぇ。

　とはいえ、アスペクト比が 4:3 の iPad とは訳が違って、16:9 の縦横とかレイアウトが全然変わっちゃうから、オブジェクトを適切に配置しなおさなきゃならないのでしんどいんですけど。

　まぁ、ライブラリ側である程度吸収してくれるとは思いますが、凝ったレイアウトにする場合は大変そうですね。

拡大表示だと！？

　あと、拡大表示ってなんだコレ。

　どうやらアイコンやコンテンツを大きく表示する機能のようですが、コレはまたしても、ほぼ OS 周りと Apple 製のアプリだけが対応する的な機能と考えていいんでしょうか。

　いやあの、いままでも設定アプリから「文字サイズを変更」することってできたじゃないですか？（Dynamic Font）
　でも、アレって、ジツは OS 周りと Apple 謹製のアプリくらいしか対応してなかったんですよ。いや、もちろん中には対応しているサードパーティー製アプリもありますが、私は普段ほとんど見かけません。

　それと同じ程度な感じだったらいいんですけど、まぁ、これは OS が勝手に制御してくれて、アプリ側では考慮しなくていい機能ってコトでよろしいでしょうか、Apple様？

アイコンに x3 が登場

　Xcode 6 の Asset Catalog のアイコンサイズに、とうとう @3x が登場してしまいました。

　これはおそらく、iPhone 6 Plus 対応でしょう。そんで、リソースも「@3x」を用意すると、そっちを読んでくれるんじゃないかなーと予想。

　ということで、実際に試してみたトコロ、「test.png (100x100)」、「test@2x.png (200x200)」、「test@3x.png (300x300)」という画像を用意して UIImageView に読み込ませてみたところ、やっぱり iPhone 6 Plus では「@3x」が読み込まれました。

　iPhone 6 は「@2x」みたいです。まぁ、iPhone 5(c,s) と大してサイズ変わらないですもんね。

　つまるところ、これからは全ての画像に @3x を用意してあげた方が良いのでしょう。はー、めんどくさ......。

　いちいち手で作ると面倒臭いので、以前作った iOS 用アイコン画像拡縮プログラムに、いちおう対応させました。あと、オリジナルのイメージから @1x、@2x、@3x をいちいち切り出すのも面倒臭かったので、PNG をドロップすると切り分けてくれる機能もおまけで追加しました。

最大の問題、画面サイズ

　そしていよいよ、最大の問題である画面（スクリーン）のサイズについて見ていきましょう。

　上であげた表の「画面サイズ」とは、コードで扱う際のサイズのことでして、具体的に言えば「[[UIScreen mainScreen] bound]」で取った値です。

　う～...... iPhone 6 は 2x のままでスクリーンサイズが広がり、iPhone 6 Plus は 3x で且つスクリーンサイズが広がってますねぇ......

　つまり、適当なアプリを組んで iOS シミュレータで動かすと、こんな感じになります。

　同一アプリを動かして、全て同じフォントを同じサイズで表示しているのですが、スクリーンサイズが異なるので表示可能な文字数が異なっているのが分かると思います。つまり、単純に縦横に広がったと考えてよいでしょう。

　てゆうか、iPhone 6 Plus の 414 x 3 って、実際の画素数である 1080 じゃなくて 1242 になっちゃうんですけど（縦は 2208）......414って、どこから来たんだ。1080 / 3 の 360 でいいじゃないか。さらに言えば、3 って割り切れない場合が多いから、止めて欲しかったな～......あ、あれかな、iPhone 5(c,s) と 6 と 6 Plus で、同じサイズの文字や画像は、実際に目で見た時に同じくらいの大きさに見えるように調整したとか？

　てゆうかコレ、座標固定で view を配置してるアプリとか、位置がズレちゃうんじゃないの？

　と思って、何も手を加えずに手持ちの自作アプリをそのまま iOS シミュレータの iPhone 6 と iPhone 6 Plus で動してみたんですが、不思議なことに何もしなくても 568 x 320 で動いてくれるんですよねぇ。

　それは何故かということについては、次の見出しに譲るとして、iPhone 6 と Plus の新しい画面サイズに対応するために、今後は iPhone 用のネイティブアプリであっても、レスポンシブなデザインを心掛ける必要があるでしょう。

画面サイズの切り替えについて

　以下、記事を書いたその日（2014/09/10）に追記した内容を元に、情報を整理しました。

　さて、iOS がどうやってスクリーンサイズを切り替えているのかという話ですが、どうやら縦にサイズが伸びた iPhone 4s → 5 の時と同じように、Launch Image (Screen) の有無で画面サイズを決定しているみたいですね。

　iPhone 4s 以前 → 5 の時も、新しい 568x320@2x の起動画像が存在しない場合は、iPhone 5 では上下に黒い帯（余白）が表示されて、アプリ自体は以前の 480x320 で動作してたじゃないですか？

　それと同じように、今回新たに追加された Launch Screen File、および旧来の Launch Image セットに追加された iPhone 6 と Plus 用の起動画像（Retina HD）が設定されていない場合は、iPhone 5 以上であれば 6 も含めて全て 568x320、iPhone 4s 以下なら 480x320 で動作するようです。

　より正確には、568h すら設定されていない、もしくは起動画面に何も設定されていない場合は、4s 以前 → 5 の時と同じように、iPhone 5 以上では上下に黒い帯が表示される 480x320 モードで動作するみたいです（このパターンはアプリの審査に通らないので、意味はありませんが）。

　整理すると、こんな感じでしょうか。

1. 320x480、320x480@2x の Launch Image しか設定されていない。または、何も設定されていない。
2. Launch Screen File および Retina HD 用の Launch Image は設定されていないが、Retina 4 インチ用の Launch Image（568h）は設定されている。
3. Launch Screen File または Retina HD 用の Launch Image が設定されている

　つまり、iPhone 6 では 667x375、iPhone 6 Plus では 736x414 の新しい画面サイズに対応したい場合は、これまでの起動イメージのセットではなく、Launch Screen File、もしくは Retina HD 用の Launch Image を設定すれば良いようです。

　逆に言うと、いままでのアプリを単純にそのまま iPhone 6 以上で動かしたい場合は、Launch Screen File、および Retina HD 用の Launch Image は設定せずに、これまで通りの起動イメージのセットを Launch Images Source に設定すれば良いということになります。

　Xcode 5 以前の環境に Launch Screen File や Retina HD 用の Launch Image は含まれていませんから、手を加えずにそのままビルドし直せば、上述したように iPhone 6 (Plus) で 568x320 のまま動くっていうことですね。ただし、この場合 iPhone 6 (Plus) では 568x320 に引き伸ばされて表示されることになるので、多少ボケます。

　まぁ、遠からず Apple 様に「iPhone 6 と Plus の新しい画面サイズに対応しないと、審査通さねぇ」って言われちゃうと思いますけど（笑）

新しい Launch Image について

　上でも触れましたが、Xcode 6 から新たに Launch Screen File が追加されただけでなく、旧来の Launch Image セットにも Retina HD 用の設定が追加されました。

　これにより、Xcode 5 までのように起動画面に PNG を設定することでも、新しい画面サイズに対応可能です。

　設定している筈なのに新しい画面サイズが有効にならない場合は、PNG のサイズが正しいか確認してみてください。iPhone 6 は @2x なので 1334x750、iPhone 6 Plus は @3x なので 2208x1242 です。間違っている場合は、新しい画面サイズが有効になりません。

　ていうか、iPhone 6 Plus には、iPad ライクな Landscape の起動イメージが、やっぱり必要なのね。iPhone なのに、縦横用意しなきゃなのかー（うんざり）

Launch Screen File について

　Launch Screen File について少し弄っていたのですが、派手にカスタムしようとしても may not have connections だそうなので、基本的にビルダーでぺとぺと貼り付けてぽちぽち設定するくらいしかできないかも知れません。

　まぁ、重い処理できちゃったら、起動画面の意味がないですもんね。Custom View も "error: Illegal Configuration: Launch screens may not use instances of CustomeView." ってコンパイラに怒られちゃうし。せめて drawRect したいだけなんですけどー。

　こんなトコをハックするのもなんですし、Apple 的にはコードを書かずに Size Classes と Auto Layout を駆使しつつビルダーでなんとかしなさいというお達しなんでしょうねぇ。

ベクターは PDF が使える？

　以下、2014/09/20 〜 21 の追記を切り出して、内容を追加修正しました。

　それならベクターイメージはどうよ？と思って簡単に調べてみたところ、なにやら SVG や EPS は扱えないけど、PDF はサイズ情報があるから扱えるんじゃね？的な書き込みを見かけました（違和感を覚える方が多いと思いますが、とりあえず読み進めてください）。

• Xcode 6 allows VECTOR image assets... any idea how to use them?
• How vectors work in Xcode6 for designers and developers

　ホンマかいなと思って試してみたら、確かに SVG や EPS は Image Set に登録できないけど、PDF は登録できますね。UIImageView の Image としても指定可能です。

　ただ、[UIImage imageNamed:@"vector.pdf"]; のように、PDF を直接指定して取得することはできないっぽいです（null が返される）。どうやら PDF は Asset Catalog 経由じゃないとダメみたいですね。つまり、[UIImage imageNamed:@"Image Set名"]; とすれば取得できます（後述しますが、理由はビルド時にラスタライズする必要があるからですね）。

　それから、アイコンと起動イメージに関しては、いまのところ PDF は指定できないようです。少なくとも、2014/09 時点で私が試した範囲では、App Icon や Launch Image に PDF を登録したらビルドエラーになってしまいました。

　ですので、以下の記述は App Icon や Launch Image ではなく、Image Set のことだと思って読んでください。

　ちなみに、PDF を扱えるのは iOS 7 以降になります。Target に iOS 6 を指定すると、「Asset Catalog Compiler Error」が発生してビルドが通りません。

PDF の登録方法

　Xcode 6 におけるベクターイメージの扱いは、かなり特殊です。

　というか、一説によれば、ビルド時に PDF からラスタイメージ（PNG）を生成して、実際はそれを利用しているそうなので、ベクター本来のように自由自在にサイズを変えるような使い方は出来ないと思った方が良いでしょう（上で触れたように、iOS 6 以前だと「Asset Catalog Compiler Error」が発生することから、どうやらビルド時にラスタ化してるのは確定っぽいですね）。

　果たしてこれは、ベクターイメージに対応したと言っていいのか微妙ですが、ともあれ上手く使えば、画像を用意する手間くらいは若干減らしてくれるかも知れません。

　何故なら、Image Set に PDF を登録するだけで、自動的に @1x、@2x、@3x を生成してくれるからです。

　Image Set に PDF を登録する場合は、Types で「Vectors」を選択します。

　ただし、ここで「Vectors」が選択できたからといって、コード上で通常のベクターのようにスケールできる訳ではありません。

　上でも触れましたが、ビルド時にラスタライズされてしまいますので、「Vectors」を選択して PDF を登録しても、ラスタ化以降はラスタイメージとしてスケールされます。

　前置きが長くなりましたが、Image Set へは以下のように PDF を登録します。

　以上です。

　このように PDF を登録するだけで、自動的に @1x、@2x、@3x のラスタイメージを生成してくれますので、全サイズの PNG を自力でぽちぽち切り出して登録するよりは、少しだけ楽になるのではないでしょうか。

PDF は @1x のサイズで作ろう

　Xcode 6 + iOS 8 でのベクターの扱いは、PDF 自体のサイズ情報に必要以上に依存しています。

　例えば、PDF のサイズ情報に 64x32（横x縦）のような非常に小さいサイズを指定した場合、ベクターイメージであるにも関わらず、以下のようなボケボケの表示になってしまいます。

　これは、まず先にビルド時に 64x32 という PDF のサイズ情報を元にしてベクターイメージがラスタライズされてしまい、それがスケール表示されている為です。

　この例では、実際の描画先である UIImageView のコード上のサイズは、iPhone 6 Plus が縦向きの場合の画面幅 × 高さはその半分なので 414x207 になります。ですので、単純化して言えば 64x32 → 414x207 にラスタイメージとしてスケールされていることになるので（iPhone 6 Plus は @3x なので、実際は 192x96 → 1242x621）、こんなにジャギジャギになってしまう訳ですね。

　PDF のサイズ情報を小さく設定しすぎたせいでボケてしまったのなら、大きくすればいいだけでしょ？と言わんばかりに、ヤケクソ気味に 2048x1024 とかまで大きくして PDF を作れば、ちゃんと綺麗に表示されることは確認しました。

　ですが、Image Set に PDF を登録した場合、そのサイズ情報を元にして @1x、@2x、@3x のラスタイメージが自動的に生成されるのだとしたら、PDF のサイズ情報は @1x と同じであるべきです（あくまで、Xcode 6 と iOS 7,8 用には、という話です）。それで、充分綺麗に描画される筈です。

　iPhone 6 Plus を使用したこの例で言えば、PDF のサイズ設定が 414x207 であれば、実際はその @3x が採用されますので、上の 2048x1024 と遜色なく綺麗に描画される道理です（余計な拡縮が発生しない分、こっちの方が綺麗まである）。

　同じくらい綺麗に描画できるのであれば、コード上での大きさ（@1x）と PDF のサイズ情報を一致させた方が良いのは、メモリの使用量から見ても明らかです。

　上で私がやったように、安全を考えて「こんくらい大きければ、どんな環境でも大丈夫だろ」みたいにサイズ情報を無駄に大きく設定してしまったり、それとも 100x100 のイメージは、iPhone 6 Plus のことを考えると 300x300 で作りたくなったりするものですが、そこはぐっと堪えて 100x100 は 100x100 で作った方が良いでしょう。

　何故なら、それらのように実際に必要とされるサイズよりも大きく設定された PDF を登録すると、無駄にメモリを消費してしまう可能性があるからです。

　StoryBoard に 414x207 の UIImageView を貼り付けて、その Image に PDF を指定しただけの単純なアプリケーションを、実際に実行した時のメモリ使用量を見てみましょう。
　シミュレータよりも実機の方が望ましいと思いましたので、実行環境には iPhone 5 を使用しました。ですので、@3x ではなく @2x の状態です。

　以下のように、414x207 の UIImageView に、コード上と等しいサイズの PDF（414x207）を設定した場合は 3MB 前後、PDF のサイズ情報だけ 2048x1024 に変えた場合のメモリの使用量は 34MB 前後、という結果になりました（繰り返しになりますが、この行の数字が @1x です。iPhone 5 なので、その @2x。アルファ込みなので、まぁこのメモリ使用量になりますよね）。

　このメモリ使用量の差は、繰り返しになりますが PDF のサイズ情報を元にしてベクターデータがラスタライズされるからでしょう（単純に、でっかい PNG を読み込んでるようなものですからね。@3x の 6 Plus だと、さらに差が広がります）。

　もっとまともにベクターが扱えれば、こんな差は出ない筈ですが、iOS が対応するまでは必要以上に大きなサイズ情報を PDF に設定しないように気をつけた方が良さそうです。

　ちなみに、戯れに同じ環境で 4096x2048 と 8192x4096 のサイズ設定でも試してみたら、4096 の方はメモリ使用量が案の定 100MB を超えてしまい、8192 の方はメモリワーニングを吐きつつ 300MB を突破し、その後一瞬 500MB を超えたと思ったら iPhone 5 が強制再起動されました。怖い。
　ということで、ベタな 32bit ビットマップ分は普通にメモリを消費しますので、お気を付けください。まぁ、こんな大きな値を設定する人はいないと思いますが、いちおう情報として。

　例えば、比較的小さいサイズのイメージを、微妙に異なる大きさでいくつか使い回したいだとか、何か明確な理由があるのでない限りは、必要とされる適切なサイズ（つまり @1x）に設定するのが良いと思います。

サイズの融通を利かせたい

　現状の iOS 8 で扱えるのは、なんちゃってベクターなので、ベクター本来のようなスケールはできない（ラスタ的にスケールされる）と書きましたが、そうは言っても、サイズを変えたいケースだってありますよね。

　例えば、上で繰り返していた 414x207 というサイズ情報は、iPhone 6 Plus の横幅を前提とした上のサンプルに限った話であり、「動作しているデバイスの横幅」のように、プログラム内における値が環境によって一定でない場合は、さらにもう一工夫必要でしょう。

　おそらく、そう遠くない将来に SVG 等も対応フォーマットとして追加されて、サイズの融通も利くようになるんじゃないかと期待しているのですが、動作端末や利用シーンによってベクターイメージをどうしても今すぐ任意にスケールさせたい場合は、PDF ではなくコードで描画してしまうのが一番確実だと思われます。

　もしくは、Image Set の設定で「Device Specific」が選択できますので、それで対応できるケースも、もしかしたらあるかも知れません（かなり限定的に思われますが）。

　これは、iPhone と iPad で大きさを変えたい時に使えそうな気もしますね。iPhone サイズのままだと iPad でボタン等は小さく表示されてしまうので、その切り分けをするには意外と便利かも知れません。

　それから、Devices の下にある Width、Height と Size Classes の組み合わせでも色々対応できると思いますが、まだ個人的にイマイチ便利に使えそうな気がしないので、いまのところは下手に触れないでおきます。触れるとしても、さすがに別記事ですね。

実験結果と自己弁護

（以前の追記を元に、内容を追加修正しました）

　画面幅一杯のような大きなサイズではなく、32x32 や 64x64 のような小さいサイズでも、@1x のサイズで作った PDF を Image Set に登録して、それを UIImageView の Image として読み込ませるだけで、iPhone 6 Plus でもボケずに綺麗に描画されました。
　32x32@3x（つまり、96x96px）の PNG と遜色無いのが確認できると思います。

　これ以上は PDF の話になってしまってキリがないので、ここではあんまり触れたくないのですが、例えばコード上で 100x100 なら PDF のサイズ情報も 100x100 にして裁ち落としを 0 にすると、感覚的にも分かり易く作れるんじゃないかと思います（それから、カラーは CMYK だと色味が変わってしまうと思うので、RGB の方が良いと思います）。

　ともあれ、それなりに綺麗に表示できるみたいですし、試しに使ってみてもいいんじゃないでしょうか。でも、あちこちクセやアクが強そうなので、あえて使わないという判断も、もしかしたら賢明かも知れません。
　あ、ちなみに、PDF にビットマップ画像を埋め込むのはダメですよ。それだと、ただでさえ多くない Xcode 6 でベクターを扱う意味が、全く無くなりますので。

　というか、なんだか PDF のハナシ全体を通して、ベクターイメージについて書いている気がしないのですが。なんなの、この強烈なサイズ設定依存は。ベクターの意味ないじゃん。これじゃ、PNG と大して変わらないじゃないですかー。まぁ、確かに画像切り出しの１手間２手間は省けるかも知れませんけど！

iPhone 6 時代の最適化とは

　レイアウトを含めて、スクリーンサイズが増えた環境での画面周りって、実際のところどうするのが良いんでしょうね。

　本来であれば、画像はベクターで、レイアウトはレイアウトマネージャーに任せて自動的にレスポンシブに、みたいのが、一番効率良さそうですが。

　まぁ、ほっといても、その内ベストプラクティス厨がベストプラクティスを提案してくれる筈ですので、ぐーたら人間としては他のアレコレを片付けつつ、のんびりと待ってます（ヒドすぎる）。

おわりに

　ひとえに個人的な感想を言うならば、今回の新型は全く心の琴線に触れませんでした。

　なんだかなー。私、iPhone は 4インチが良いんですけど。個人としては、ホントに開発がめんどくさくなっただけだなぁ......

　これ、動作確認を考えたら、iPhone 6 Plus を買った方がいいんでしょうねぇ。いや、ホントは両方持ってなきゃいけないんでしょうけど、大して欲しくもないのに、さすがに個人で両方買ってらんない訳ですよ。

　で、どっちか買わなきゃいけないとしたら、いままでと比べてより特殊な iPhone 6 Plus にするしかないかな、と。

　高くてデカくて重い方か......iPad mini Retina で間に合ってるので、要らないんだけどなぁ。

　普段使いだったら、せめて iPhone 6 にしたいところですが、やっぱり両方は買えないなー。うーんうーん。

　正直なところ、Apple Watch もそれほど欲しいと思えなかったし、今回の発表は個人的には非常に微妙な感じに終始しました。

• 速報：Apple Watch発表、349ドルで2015年初頭発売予定。リューズ状のダイアルDigital CrownとRetinaディスプレイ搭載
• Apple Watchは3コレクションでそれぞれ2サイズ、ストラップもあわせると計34モデルも！

　Apple Watch に専用の OS を用意したのは素晴らしいとは思いますけどね。でも、アプリ開発に手を出さない限り、買わないだろうなぁ。

　まぁ、分かんないけどね！

　２週間後には、「iPhone 6 Plus サイコー！」「Apple Watch 素晴らしい」って高らかに褒め称えているかも知れませんけど！

　私、そういう人なので！！（笑）

　この記事、おそらく追記しまくることになると思うので、よろしくお願いします（2014/10/22追記：案の定、追記しまくりの整理しまくりで疲れました......）。