0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【第7回】サンプルPDFと公開用素材を整え、使い始めやすくする

0
Last updated at Posted at 2026-10-24

シリーズ:iOS版『見開きPDFビューア』開発記録

この記事は、ChatGPTと壁打ちしながら作成しました。また、Gitの変更履歴・ソースコードの調査と、筆者が提供したApp Store Connectの履歴をもとにしています。

第6回では、Codexによるコード評価をきっかけに、Viewの分割、描画処理、ドキュメント更新、CIを整えた経緯を紹介しました。今回は、利用者が自分のPDFを用意しなくてもアプリを試せる仕組みと、公開ページに掲載するスクリーンショットや動画の準備を振り返ります。

サンプルPDFの制作から、アプリ内でのダウンロード、差し替え時の不整合への対応、紹介素材の撮影までを取り上げます。アプリ本体の対応言語と販売地域、紹介素材の言語は分け、国内での公開を先行する方針で進めていました。

図1

図1 公開用に用意したサンプルPDF「ためし部」の表紙。上段が第1話、下段が第2話で、左から日本語・英語・韓国語の第2版を並べています。実際のPDFの表紙を使用しています。

自分のPDFを用意しなくても試せるようにする

動作確認用のPDFから、公開できるサンプルへ

最初の動作確認には、自分で自炊したPDFを使っていました。しかし、第3回でも紹介したように、そのデータは一般に公開できません。アプリの開発と並行して、ChatGPTを使い、公開できるサンプルPDFも作り始めました。

App Store Connectへの登録準備では、スクリーンショットも必要になります。動作確認用の簡単なPDFだけでは、公開ページを見た方にアプリの使い方や魅力が伝わりにくいと思いました。そこで、最初はChatGPTでライトノベル風の表紙や本文の画像を作り、自分でPDFへ変換しました。そのPDFを開いた画面を撮影し、App Store Connectへ登録しました。

ただし、画像だけをまとめたPDFには検索用の文字情報がなく、検索機能を紹介する画面には使えませんでした。今回、初期のTestLightNovel.pdfを確認しても、文字は抽出できませんでした。

その後、公開ページ向けの英文をCodexに考えてもらった際、「マンガの表示に便利」という説明が出てきたことが気になりました。しばらく考え、サンプルもマンガ形式にした方が、見開きや右綴じの使い方を伝えやすいのではないかと思いました。そこで、ChatGPTを使って、4コママンガ風の全8ページの作品を作りました。サンプル制作の詳しい経緯は、別の記事で紹介する予定です。

第3回のL2R・R2L、検索用、負荷テスト用PDFは、特定の条件で動作を確認するためのデータです。一方、配布用サンプルは、利用者が閲覧を試すために用意したものです。同じPDFでも役割が違います。

アプリ内からダウンロードして開けるようにする

アプリ内でサンプルPDFをダウンロードできるようにしたきっかけは、Android版のクローズドテストでの反省でした。テスト開始時には、テスターへPDFを提供していませんでした。後からテスト用PDFをダウンロードできるURLを用意して連絡しましたが、外部のURLからファイルを入手してアプリで開くまでには手間がかかります。そのため、実際には試した方がいなかったのではないかと想像しました。

この手間は、アプリを使い始めた人にも同じように生じます。自分のPDFを用意しなくても試せるよう、アプリ内からサンプルPDFをダウンロードして開く機能を追加しました。第4回冒頭の画面例に使ったtameshibu_episode1_2_ja.pdfも、そのサンプルです。

サンプルの存在に起動直後から気づけるよう、入口も見直しました。次の依頼では、ボタンの移動とダウンロードエラーの確認をまとめて伝えています。引用のプロンプトは全文、回答は抜粋です。

筆者のプロンプト(全文)

設定画面からサンプルPDFを開くボタンを削除してください。
ファイル選択画面に、サンプルPDFを開くボタンを追加してください。
アプリ起動後にファイル選択画面をスキップしてFilePickerに進む機能を無効にしてください。
Simulator iPhone 18 ProでサンプルPDFをダウンロードすると、エラーになります。"サーバからサンプルPDFをダウンロードできませんでした。"

Codexの回答(抜粋)

  • 設定画面からサンプルPDFボタンを削除
  • 起動時のファイル選択画面にサンプルPDFボタンを追加
  • 起動直後の自動FilePicker表示を無効化

初期画面に入口を置くことで、自分のPDFを用意していない利用者も試し始めやすくすることを意図しました。併せて見つかったURLの問題は、次のカタログの節で取り上げます。

10月8日にはサンプルのダウンロードに関する変更がGitに残っています。10月20日時点のSamplePDFListViewでは、ダウンロード済みのPDFを開き、不要になったサンプルを削除できます。ライセンスと作者の表示、モバイルデータ通信を使う場合の確認も用意しています。

言語を選ぶ手間も減らすため、初期表示を指定しました。

筆者のプロンプト(全文)

サンプルPDFのダウンロード画面にフィルター機能を追加してください。フィルターは言語別で、全部または各言語を選択します。デフォルトは、端末のデフォルトの言語(なければEnglish)です。

Codexの回答(抜粋)

  • 「すべて」または各言語を選択できるPickerを追加
  • 端末の最優先言語を初期選択
  • 対応言語がなければEnglishを選択
  • 言語・地域コード(例:ja-JP)にも対応

本稿の対象コードでも、優先言語に合うサンプルを初期表示し、対応するものがなければ英語を選びます。メニューで別の言語や「すべて」に切り替えることもできます。

図2

図2 外部URLからPDFを入手する流れと、アプリ内でサンプルを選んで開く流れ。

サンプルの差し替えで、一覧と配布ファイルがずれた

サンプルPDFのカタログを整備した背景には、開発環境とGitHub Pagesの間で、話数・版数・翻訳版の管理が実際にずれた経験があります。開発中に言語を追加したり、第2版へ差し替えたりするうち、アプリが古いURLを参照し、ダウンロードでエラーが起きました。

作業ログにも、削除済みの旧ファイル名をカタログが参照して404になった記録が残っています。その際は、現行の第2版に合わせてURL、ファイルサイズ、SHA-256を更新しています。さらに10月14日には、配布PDFの更新後にサイズとSHA-256がカタログと一致せず、整合性チェックでダウンロードが拒否された例もありました。URLが正しいだけでは足りず、配布するデータと一覧の内容をそろえる必要がありました。

一覧を実行時に毎回取り直すのではなく、アプリ内へ保持する方針も伝えていました。次の引用では、作者・権利者の個人名を匿名化しています。

筆者のプロンプト(全文・個人名や識別IDは匿名化)

ダウンロードURLは、GitHub Pages側にします。
サンプルPDFの一覧は、アプリのビルド時に取得し、アプリ内に保存します。サンプルPDFを追加する際は、アプリのバージョンアップが必要になることを許容します。
サンプルPDFのライセンスをCC BY 4.0にします。
サンプルPDF(作品)に記載している作者名は異なりますが、実際の作者および権利者は[作者・権利者名]です。
他に確認事項があれば教えてください。

Codexの回答(抜粋)

  • 実行時の一覧取得
    ネットワーク通信は行わず、Bundle内のJSONを読み込む

  • 一覧更新
    サンプル追加・削除にはアプリのバージョンアップが必要

本稿の対象コードでは、SamplePDFCatalog.jsonに作品名、言語、版数を含むファイル名、ダウンロードURL、サイズ、SHA-256などを記載し、アプリのリソースとして同梱しています。SamplePDFStoreはこのカタログを読み込み、取得したPDFのサイズ、先頭識別子、SHA-256を照合してから端末へ保存します。毎回のビルド時にカタログを自動生成する処理は、今回確認した対象コードでは見つかっていません。依頼した方針と、実装で確認できた範囲は区別しています。再発防止として、配布先へHEADリクエストを送り、応答の成功、PDF形式、ファイルサイズとカタログ値の一致を確認するテストも追加されています。

図3

図3 配布PDFとカタログのずれで起きた問題と、その確認方法。

公開ページの素材は、対象と言語を絞って準備する

サンプルPDFは、アプリを試す入口になると同時に、公開ページで使い方を見せる素材にもなりました。次は、その画面をどの地域・言語向けに用意し、どう撮影するかを考えました。

国内での公開を先行し、紹介素材の言語を絞る

将来は海外への展開も考え、アプリの多言語対応を進めていました。ただし、販売地域も紹介素材の言語も最初から広げると、準備や確認が大変になります。まずは国内のみでの配布・販売を目指し、公開ページなどで見せる言語も絞る方針で作業していました。

本稿の対象コードの文字列カタログでは、13言語を確認できます。イタリア語は今後追加する予定です。アプリ本体が対応する言語と、最初に販売する地域、スクリーンショットや動画で紹介する言語は、それぞれ分けて考えていました。

Appleの案内では、App Store Connectに追加した言語のスクリーンショットには、主要言語のものが初期設定されます。全対応言語の別画像が一律に必須なのではなく、紹介素材も段階的に用意する方針でした。Appleのローカライズの説明

スクリーンショットと動画の作成もCodexに依頼する

スクリーンショットやApp Preview(公開ページ用の動画)は、最初は手動で作っていました。ただ、画面や設定を変更するたび、撮影済みの素材も見直す必要があります。そこで、内容の企画から撮影・確認、登録時の対応まで、Codexに依頼するようにしました。

8月29日の作業ログには、App Store Connect向けのスクリーンショット作成を依頼した記録があります。9月10日にはPDFを指定し、横向きで撮り直すよう依頼しました。9月29日には、日本語・英語とiPhone・iPadを組み合わせたApp Previewの作成を依頼しています。10月2日には、購入画面の変更に合わせて動画の変更が必要かを確認してもらいました。

撮るだけでなく、意図した画面が写っていることの確認も必要でした。Codexにスクリーンショットの自動撮影を依頼すると撮影を失敗するケースが多く、何度も指示を変えながらやり直していました。例えば10月11日には、過去の失敗例を具体的に挙げて検証機能を依頼しています。

筆者のプロンプト(全文)

SimluatorのiPhone 18 ProとiPad Pro 13-inch (M5)を使う前提で、撮影手順を計画してください。なお、以前の撮影では失敗画像が含まれるケースが多かったので、撮影した画像を検証する機能を追加してください。黒画面やホーム画面、無関係のダイアログが表示されている、システム言語が異なるなど。

Codexの回答(抜粋)

  • 対象アプリがフォアグラウンドか
    • Home画面や別アプリを撮影した場合に失敗
  • 撮影対象の画面要素が存在するか
    • 例:pdfViewerScreen、settingsScreen
  • アプリ内に予期しないアラートがないか

AppStoreScreenshotTestsとAppStoreScreenshotValidatorには、閲覧、見開き、右開き、検索、ページ移動、設定の6場面を撮影・検証する実装が残っています。当時のログには、日本語・英語についてiPhoneとiPadの合計24枚が検証を通過したとの報告があります。後に韓国語・簡体字も追加され、対象コードの撮影テストは4言語に対応しています。アプリ本体の13言語すべての素材を掲載済みという意味ではありません。

図4

図4 App Store Connect向けに作成したスクリーンショットの例。iPad Pro 13インチ(M5)のSimulatorで、日本語のサンプルPDFを見開き表示した保存済みの撮影画像です。

アップロード後の確認も必要でした。9月29日には、App Store Connectで「アプリプレビューのオーディオがサポートされていないか、破損しています」と表示されたことをCodexへ伝え、対応を依頼した記録があります。CodexにApp Preview(動画)の撮影・編集を詳しい仕様抜きで依頼したところ、オーディオトラックのない動画が作られることがありました。当時のログでは、新しい2本の動画に音声ストリームがないことを確認し、AAC-LC・48 kHz・ステレオの無音トラックを追加しています。修正後には映像・音声のデコードエラーがないことまで確認していますが、今回参照した記録だけでは、修正した動画のアップロード成功までは確認できていません。

図5

図5 国内での公開を先行し、撮影する端末・言語を絞って素材を準備する流れ。

試す入口と、使い方を伝える素材を整える

サンプルPDFは、公開ページを飾るためだけのものではありませんでした。Android版のクローズドテストで感じた手間をきっかけに、アプリを起動してから試し始めるまでの入口を見直しました。さらに、PDFの差し替えや翻訳版の追加に合わせてカタログを整え、撮影素材も繰り返し作り直せるようにしていきました。

次の第8回では、無料・広告なしの方針に合わせて用意した任意の応援と購入復元、購入テストでつまずいた点を紹介します。App Store審査への返信と、契約・登録情報の手続きは第9回で取り上げます。

ソースコードと本稿の対象

ソースコードはGitHubのtyamada/MihirakiPDFViewerで公開しています。本稿の対象コードは、10月20日時点で確認したtestingブランチの91f0853です。10月8日に追加したサンプルダウンロード機能など、審査中の提出版より後の変更も含めて振り返っています。

今回、ダウンロード操作や撮影テストは再実行していません。提出した版と開発中の版の詳しい区別は、第9回で整理します。


前の記事:第6回:コード評価からView分割・描画改善・CI導入へ

次の記事:第8回:任意の応援と購入復元を整え、購入テストで確かめる

0
1
0

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
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?