iTunes Connect での submit エラー
iOS8 対応の申請が無事完了しました。iTunes Connect の UI も変更され、申請手順も少し変わっています。そこでいくつかエラーに遭遇したのでまとめておきます。
バイナリアップ 〜 レビュー審査のために送信
これまでは iTunes Connect に「Ready to Upload Binary」ボタンがあり、そこをクリックすることで Xcode からバイナリをアップすることができましたが、今後は Xcode からバイナリを上げると以下のプレリリースというところに表示されるようになっています。
はじめは Processing 状態になっていますが、5分から10分程すると バージョン タブの ビルド にてバイナリを選択できる状態になります。
バイナリをセットしたら保存をし、画面右上にある「レビュー審査のために送信」ボタンからこれまで通り設問に答えると晴れて Wating For Review のステータスになります。
レーティング設定によるエラー
しかし、ここで1つめのエラーが起きました。「レビュー審査のために送信」ボタンを押した際に以下のエラーメッセージが出てきました。
You must submit your builds using Xcode 5.1.1 or later, or Application Loader 2.9.1 or later. After you’ve submitted a build, select it in the Builds section below.
自分の場合、レーティングの設定が漏れていたために、ちゃんと答えてねと言われていました。ということで、レーティングを設定し再度送信ボタンを押すと同じエラーが。。。どうやっても解消されませんでした。
おそらくですが、Xcode からバイナリを上げる際にレーティング等の設定情報を読み込みバイナリを作成しているのでは。そのため、バイナリアップ後にいくら設定を変更しても見た目上反映されていても、バイナリ自体にはその設定が読み込まれていないためエラーが起きているような気がしました。
仕方なく再度 Xcode からバイナリを上げることに。
バイナリ再アップ時のエラー
iTunes Connect 側の設定に漏れがないことを確認した上でバイナリを再アップ。ここで再びエラーが発生しました。すでに同じバージョンのバイナリが存在してるよと言われ先に進めず。これまでとは違い、再アップするにはバージョンを上げて行うしかないようですね。
バージョンを上げ再アップし、「レビュー審査のために送信」押すとエラーもなく無事申請完了しました。
こういった仕様なのか、まだ iTunes Connect 自体にも不具合があるのかは分かりませんが、現状同じようなエラーに境遇しましたら参考にしていただければと思います。
shenzhen コマンドで .ipa ファイルを作成する
shenzhen コマンドとは
gem に含まれる iOS プロジェクトのビルド、パッケージング用ライブラリです。TestFlight へのデプロイ機構も持ちます。
読み方は シンセン。
準備
gem に含まれていますので、ruby がインストールされていることが必須です。
rvm のインストール
Ruby のインストール
ruby instal 2.0.0
shenzhen のインストール
sudo gem install shenzhen
ipaファイルの作成
ipa build -c Debag
対象プロジェクトの配下でこれを実行すれば ipa ファイルが作成されます。準備さえ整えばコマンド1つで作成することができます。
.ipa ファイルを自動生成する
.ipa ファイルを作るにはいくつか方法があります。
- Xcode で作成
- xcrun コマンド
- shenzhen コマンド
- TestFlight を利用
など。Xocde6 beta5 で ipa ファイルを作成しようとしたところ、Archive は問題なく通るのですが、その後 Export しようとすると「権限ないよ」と言われ作ることができませんでした。Xcode の不具合か弊社の環境周りに問題があるのか原因は調査中。。。ただ ipa ファイルの作成は他にも方法はあるので、とりあえず別の方法で作成しました。ここでは xcrun コマンドによる方法を紹介します。
xcrun コマンドによる .ipa ファイル作成
対象のプロジェクトのディレクトリ配下で、以下のスクリプトを実行することで ipa ファイルが作成されます。
#!/bin/sh # -----ビルド〜ipaファイル作成----- #SDK SDK="iphoneos8.0" # Debug or Release CONFIGURATION="Debug" # Xcodeのプロジェクト名 PROJ_FILE_PATH="Sample.xcodeproj" # ターゲット名 TARGET_NAME="Sample" # プロダクト名 PRODUCT_NAME="SampleApp" # app出力先 APP_DIR="app" # 出力先ipa IPA_DIR="build" # プロビジョニングプロファイル PROVISIONING_PATH="~/Library/MobileDevice/Provisioning\ Profiles/{プロファイル名}.mobileprovision" # 出力先ディレクトリ作成 rm -rf "${APP_DIR}" rm -rf "${IPA_DIR}" mkdir "${APP_DIR}" mkdir "${IPA_DIR}" # クリーン xcodebuild clean -project "${PROJ_FILE_PATH}" # ビルド xcodebuild -project "${PROJ_FILE_PATH}" -sdk "${SDK}" -configuration "${CONFIGURATION}" -target "${TARGET_NAME}" install DSTROOT="${APP_DIR}" # ipaファイル作成 xcrun -sdk "${SDK}" PackageApplication "${PWD}/${APP_DIR}/Applications/${PRODUCT_NAME}.app" -o "${PWD}/${IPA_DIR}/${PRODUCT_NAME}.ipa" -embed "${PROVISIONING_PATH}"
上記のスクリプトでは build ディレクトリが作成され、そこに SampleApp.ipa が書き出されています。SDK はビルド対象のバージョンを指定してください。ここでは BaseSDK 8.0 でビルドしたかったため 8.0 を指定しています。
※ 追記
shenzhen コマンドでの作成は以下にまとめています。
Xcode6 beta版での Row Height について
storyboard を使って TableView を組んでいた箇所で iOS8 では TableView の Cell がうまく表示されないことが起きました。問題なく表示されているところもあるのですが、ダメなところはいっさいダメな状況でした。表示できるところとできないところの差分を確認し原因を探っていくと、Cell の高さを 44 に設定しているところは一切うまくいっていないことが分かりました。
上記のように Row Height 44 だとなぜか 高さ0 扱いされており、Cell が重なって表示されていました。試しにと思い、Row Height を 43 や 45 にすると問題なく表示されます。。。44 に設定した状態で表示をさせたい場合は、以下のように明示的にコードで返すようにすれば問題は解決できます。
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { return 44; }
先日、Xcode6 beta5 がリリースされたため試してみましたが事象は変わらずでした。おそらくstoryboard の不具合のような気もするのですが、現状はこの方法で回避することができます。
対症的療法と根本的療法
つい最近企画について学ぶ機会がありました。普段はエンジニアとしてサービスの開発をしていて、ごりごりコードを書いているのですが、ユーザにサービスを届ける立場として開発だけではなくそこに +α として”企画”という部分をより知っていこうと今学んでいます。
まず、学んだことというのが「対症的療法」と「根本的療法」です。対症的療法はある課題や問題に対して、素直に解決策を見いだして対応すること。根本的療法は何が原因でその問題が起きているのか根本原因を考えて対応することになります。
たとえば、以下の状況があった場合。
「60代一人くらしの女性が冷蔵庫のものを余らせてしまい賞味期限をすぎてしまうケースが多い。あなたがスーパーの店長だったらどんな対策を打ちますか?」
原因を考える
いきなり対策を考える前になぜそうなってしまうのか原因を考えてみます。
- 献立を考えずに食材を買ってしまう
- 何度も買いに行くのが手間なためまとめ買いをしてしまう
- 冷蔵庫に奥にあるものに気付かず同じものを買ってしまう
- 家族暮らししていた習慣が残り1人前の目安がわからない
など、いくつかこんな原因があるのではないかと推測します。これらの原因から対策を対症的療法と根本的療法に分けて考えてみます。
対策を考える
対症的療法
- 献立単位でパック販売する
- 1人前の目安が分かるように販売する
- 食材にいくつかレシピも添えてあげる
根本的療法
- デリバリーサービス
対症的療法では課題に対し売り方や商品の見せ方を変えて対応しています。スーパーに来店するユーザを落とすことなく対応していることになります。それに対し根本的療法では、お年寄りが頻繁にスーパーに来る大変さを考え、デリバリーサービスをすることで必要なときに必要な分だけ食材を届けることでまとめ買いすることを防止しています。スーパーに来店するユーザはその分減りますが、お店側はユーザに食材を有効に使っていただけるし、ユーザはお店に足を運ぶことなく食材が手に入れることができます。
まとめ
今回のケースで正解はありませんが、ユーザの課題を解決する際にこういった考え方は大切だと感じました。ユーザの真意を考え、状況によって使い分けできることが大事ですね。