iOS8向けアプリ開発時の注意点
Android, iPhone等のスマートフォン向けアプリ開発などの話題を中心に、時事ネタなどを気の向くままに書いています。 先日、iOS8のGM seedが公開されました。iOS8の正式リリースも間近ですね。 ところで、iOS8対策は済んでいますか？ もし対策が済んでいたとしても、この下にある「UITextView、UITextFieldで編集メニューの表示がおかしい」だけは読んでおく事をお勧めします。 全てのUITextView、UITextFieldを使用したアプリが関係する問題です。 私自身、iOS8はベータ版の時から見ていたので、いくつか不具合が出る箇所を発見していました。 そこで、まだGMの段階ですが、備忘録を兼ねてiOS8対策に関して情報共有したいと思います。 間違いがありましたならばご指摘ください。 今回記載するのは以下の内容です。 他にもiOS8ではDeprecatedに
【iOS】iTunesConnect(2014/9) スクリーンショット作成の注意点 - Qiita
iPhone6 plus向けに作ってiPhone6/5はただのリサイズでほぼ行ける。(2ptくらい引き延ばしなどあるが) iPhone4SとiPadは独自調整必要。iPhone4S作ってからiPad作る方が結果的には楽。 縦960→1024の方が横640→768よりも変化率が少ないのと、 iPadを入れる場合はいずれにせよ横幅を取るので、横に合わせると詰む。 ファイル形式 透明部分にチェックが入っていると弾かれるので注意。 ファイル名 日本語が混ざっているとエラーを返す（サイズがおかしいです、等、意図しないエラーで返される）ので、入れない。 ファイル名に日本語入れるなんて…！って皆様は気にしないで大丈夫です。 動画（Appビデオプレビュー） 500MB以内でCM動画をUPできる（for iPhone6）のだけど iPhone6を使っている所を撮影しないと意味がなさそう…そのうち加筆します
iOS 8 beta5にてポップオーバーをキャンセルするための暗いところを連続でタップすると下にあるモーダルビューも閉じてしまうバグ - 24/7 twenty-four seven
一昨日くらいにiOS 8でテストをしていたら見つけました。 問題となる画面構成を多用するアプリケーションにとっては、修正が間に合わなければけっこう致命的と思われるので共有します。 （Base SDKをiOS 8にしてビルドしない限りは起こりません。リリース済みのアプリケーションをiOS 8で動かすぶんには問題無いです。） ↓ バグレポートした内容は下記の記事で公開しています。 重ねてレポートすると優先順位があがるかもしれません。 Radar: When double-tap the dimming view to dismiss the popover, it will also close modal view under - 24/7 twenty-four seven サンプルコード ↓ バグレポートに添付した問題が再現するサンプルコードです。 Xcode 6でビルドして、iOS 8
iPhone6/iPhone6 Plusの画面対応について - Qiita
iOSにも画面フラグメントの時代がきました。 特にややこしくしているのが、iPhone6 Plusです。ピクセル比が3倍。 iPhone6 plusのiOSシミュレーターで画面のサイズをデバッグしてみると「414 x 736」になり、3倍すると「1242 x 2208」ですが、公称では「1080 x 1920」です。ということはピクセル比は正確には@2.46とかなのかな・・・。この辺りの仕組みがまだつかめてません。 既存プロジェクトの対応方法 iPhone6/6+のiOSシミュレーターで、既存のiOSプロジェクトを特に何もせずにビルド、実行すると「320 x 568」いわゆるiPhone5/5sサイズを拡大したような形で表示されます。（iPadでiPhoneアプリをx2で実行したような感じ。ただiPad⇔iPhoneほどの解像度の差は低いので、そこまで違和感は感じない。） iPhone6/
リニューアル後の iTunes Connect で新規バージョン追加時の注意点と手順 - Qiita
レビュー審査のために送信をすると下記エラーが表示されて送信出来ない You must choose a build. 対応 レビュー審査のために送信の前に Xcode にて Distribute をして、 iTunes Connectでビルドを指定する必要がある Xcode の Organizer にてValidate、Distribute時に下記Warningが表示される。 Undeclared Use of Advertising Identifier [IDFA]. You app contains the Advertising Identifier [IDFA] API but you have not indicated its usage on the Prepare for Submission page in iTunes Connect. Click Submit fo
CrashlyticsでTestFlightよりも簡単にアプリをテスターに配布する - Qiita
みなさんはCrashlyticsというサービスをご存じでしょうか。 Crashlyticsとは、アプリのクラッシュを分析し、それをWeb上から可視化できるようにしたサービスです。 iTunes Connectからもクラッシュレポートは見れますが、それよりもより高機能になっています。 Twitterに買収され、日本ではグノシーをはじめ、さまざまなアプリに組み込まれています。 そんなCrashlyticsになんと Beta Distribution という機能が追加されました！ Crashlytics Beta Distribution Beta by Crashlytics Crashlytics Beta Distributionは簡単にいってしまえばTestFlightやDeploygateと同じようなサービスです。 アプリのベータ版をテスターの方に配り、またその後のアプリの状態をトラッ
AppStoreに動画が載せられるようになったので、その仕様とよくある質問まとめ - Qiita
iOS 8からアプリの動画をスクリーンショットと共に載せられるようになりました！ App Video Preview 仕様 15秒〜30秒 500MB以下 900 x 1200 pixels か 1136 x 640 pixels M4VまたはMP4、MOV形式 H.264（推奨）かApple ProRes videoコーデック 30 fps フレームレート ステレオ 256kbps AAC オーディオフォーマット 画面の向きはportraitかlandscapeどちらでもOK これは必須ですか？ 任意です。 いくつまで載せられますか？ 1つです。 ※ 3.5inchビデオはサポートしていません BGMやナレーション、画面上にグラフィックを重ねてもいいですか？ はい。 動画はローカライズできますか？ いいえ。 一つの動画がすべての言語に対して表示されます。 サムネは設定できますか？ できま
In App Purchaseのレシートをローカルで検証できるようになった話 - Qiita
iOS Advent Calender 2013 iOS second stage 6日目担当の@fm_tonakaiです。 普段はWebの会社でiOSアプリの開発を行っています。 初のQiita投稿で緊張しています。 今日はIn App Purchaseのレシートのローカル検証についてちょっと調べたので書きます！ はじめに iOS7よりSKPaymentTransaction#transactionReceiptがDepricatedになりました。 代わりにNSBundle#appStoreReceiptURLが追加され、 Transactionの処理時にこのAPIを用いてレシート情報を取得することができます。 この情報を用いて今までのようにAppleに問い合わせしなくてもローカル内で レシートの検証が行えるようになりました。 なりましたが、簡単にできるとは言っていない！ レシートの検証
アプリ内課金のレシートは1つのバイナリになる - Qiita
最近気づいたんだけど、iOSで使われるアプリ内課金（In-App Purchase）では複数の課金をしてもそれぞれにレシートのバイナリができるわけではなく、複数まとめて1つのバイナリになっている。 もしかしたら同じような勘違いをしている人もいるかもしれない。そうするとサンプルコードが全然違って見えるよという話です。 Appleの公式リファレンスであるレシート検証プログラミングガイド PDFによるとレシートの構造はこんな感じらしい。 （ちなみにこの図のタイトルはレシートの構造のはずなのに後続と訳されていた） iOS7より前ではtransactionReceiptがNSDataで取得できるので、アイテムごとにレシートが作られているのかと思っていた。コードとしては次のような感じ //このメソッドはオリジナルで - (void)finishTransaction:(SKPaymentTransac
Mac/iOSアプリ内課金(StoreKit)実装とリジェクトの注意点 - リンゴをかじれ
MacOSX/iOSのInAppPurchase（アプリ内課金）の、 Non-Consumable（非消費型）の課金の実装をして沢山リジェクトされたのでメモメモ。 相当癖のあるStoreKitとローカルレシートの扱いで散々な目にあったのでご紹介します。 Non−Consumableは’非消費型’のアプリ内課金モデルで、 機能のアンロック 固定アイテム 等に利用するアプリ内課金システムです。 レシート情報を自前で管理しないで良いので実装がかなり楽出来る！！ 思いきや、レシートの解析でえらいドツボにハマりました・・・。 すいません。凄いナメてました・・・。 1. 前提 2. 大枠の流れ 3. 復元ボタンを実装しておくこと 4. 別スレッド・・・・ 5. 商品名、説明文、値段は必ずローカライズすること。 6. テスト用アカウントの落とし穴 7. ローカルレシートの扱い
TWorksの試行錯誤記録 : iOS 7/In-App Purchase/ローカルレシート検証
これの続きです。 iOS 7 + Auto-renewable + TransactionReceipt これで有効期限が取れたのは取れたのですが（値も正しかった）、これで良いのかわかりません。素直にOpenSSL使って、ローカルレシート確認にする方がいいのかしら… 2013/11/4 追記： このやり方はAppleのドキュメントに書いてないからダメっぽい。 OpenSSL使ってローカルレシート認証にするのが正解だと思われる。 引き続き検証中。 元の話は、iOSのアプリ内課金（In-App Purchase）でレシートの確認を行う場合、SKPaymentTransaction#transactionReceiptが、iOS 7からDeprecatedになっており、さてどうしたらよいのやら…ということでした。そしてこれに対する回答は、Appleのドキュメントに”超”概要が書いてありました。
課金(In-App Purchase)の不正対策例
今回のエンジニアブログを担当する村田です。 前回の「iOSアプリ内課金(In-App Purchase)のはまりどころ」に引き続き、アプリ内課金に関する内容です。 2012年の夏、iOS5.1以前において脱獄不要でアプリ内課金が無料になってしまう脆弱性が見つかるというニュースがありました。iOS6のシェアが8割を超える今日、この脆弱性はどのようになっているのか。 実は、iOS5.1以前の端末では、依然としてこの脆弱性を利用して脱獄することなく無料でアプリ内課金を行うことが出来てしまいます。レシートの確認をAppleのサーバーに問い合わせているから大丈夫！では無いのが現状です。 この状況に対してAppleは放置している訳ではありません。Appleから対応内容が公開されております。 In-App Purchase Receipt Validation on iOS 上記ページ右上「Compan
iOSアプリ内課金(In-App Purchase)のはまりどころ - WonderPlanet DEVELOPER BLOG
今回のエンジニアブログを担当する村田です。Consumable(消費型)アプリ内課金を実装して分かったはまりどころをポイントで説明します。 １．レビュー時におけるStoreレシートの確認先 アプリ内課金では、有効なトランザクションである事を確認するためにレシートデータをAppStoreへ送信します。 Storeレシートの確認先は「In-App Purchaseプログラミングガイド」によると下記のとおりです。 環境 送信先 製品時 本番環境 開発時 サンドボックス環境 では、レビュー時は？ プロダクトモジュールを送付するので...本番URL？ と判断し実装するとはまります。 レビュー時は、サンドボックス環境を利用します。 環境 送信先 開発時 サンドボックス環境 製品時 本番環境 レビュー時 サンドボックス環境 と、なります。 環境に応じて切り替えていると障害を埋め込む原因となります。 では
Apple Push Notification (APN) 使用時の delegate の挙動について、 iOS 7以降 / iOS 6以前の差をまとめた
Apple Push Notification (APN) 使用時の delegate の挙動について、 iOS 7以降 / iOS 6以前の差をまとめた iOS 7以降とiOS 6以前で、俗にいうリモートPush通知の受け取り方と受け取った際の挙動がまるで違っているので、最近リモートPush通知を実装した時につまづいた箇所をまとめてみました。 使用するdelegate methodの違い いかなる種類のPush通知においてもapplication:didReceiveRemoteNotification:fetchCompletionHandler:を使用します。 application:didReceiveRemoteNotification:fetchCompletionHandler:とapplication:didReceiveRemoteNotification:が両方実装され
iOS 8でIn-App Purchaseの状態に追加されるSKPaymentTransactionStateDeferredの影響を考える - 24/7 twenty-four seven
In-App Purchaseでプロダクトの購入を扱うときにはStoreKitのSKPaymentTransactionStateを使います。 例えばPurchasedなら購入完了なのでプロダクトのダウンロードを始める、Failedなら失敗なのでアラートを出すなどとします。 iOS 8からはその状態に新しくSKPaymentTransactionStateDeferredが追加されます。 2014/8/6時点ではまだドキュメントに解説はありません。 API diffとヘッダには記載されています。 WWDCのセッション218, 303ではそれなりに詳しく解説されていますので参考になると思います。 Deferredという状態は「Ask to Buy」というiOS 8のApp Storeの新機能のために導入されました。 「Ask to Buy」はiOS 8で搭載される「ファミリー共有 (Fami
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://study-cocos2d-x.info/game/209/
http://study-cocos2d-x.info/other/309/
Play Games Services | Google for Developers
音系ソフトウェア制作日記
UIWebViewのキャッシュ