AndroidとiOSの両方でアプリを公開してみると、同じ「アプリストア」でもかなり違うことに気づきます。

どちらも、

アプリを作る

↓

ストアに登録する

↓

審査を受ける

↓

公開する

という流れなのですが、実際にやってみると、それぞれ違った大変さがあります。

特に大きく違うと感じたのが、公開前のテストです。

Google Playは公開前のテストがある

Google Playで個人開発者としてアプリを公開するとき、対象となる新しい個人開発者アカウントでは、公開前にクローズドテストを行う必要があります。

現在の要件では、

12人以上のテスターに参加してもらい、14日間継続してテストする

という条件があります。

これが個人開発では結構大変です。

「アプリを作ったから公開！」とはならない

最初は、

「アプリが完成した」

↓

「Google Playにアップロード」

↓

「審査」

↓

「公開」

くらいに考えていました。

ところが、実際には公開前にテストがあります。

テスターを集める。

テスターに参加してもらう。

14日間テストしてもらう。

その条件を満たしてから、公開申請へ進む。

つまり、

アプリが完成しても、すぐに一般公開できるとは限りません。

テスターを集めるのが意外と大変

プログラムを書くのは自分一人でできます。

でも、

テスターを12人集める

となると話が変わります。

知り合いにお願いしたり、テスト参加者を募集したり。

個人開発では、ここが意外なハードルになります。

「アプリを作る技術」と「テスターを集める力」は別物です。

アプリを公開するだけなのに、ちょっとした営業活動まで必要になります。

そして14日間

さらに、

「12人集めた！終わった！」

とはなりません。

14日間の継続したテストが必要です。

その間に、

「ちゃんとテストしてもらえているかな？」

「条件を満たしているかな？」

と確認することになります。

個人開発者にとっては、かなり独特な公開プロセスだと思いました。

App Storeはまた違う

一方、App StoreではGoogle Playとは違った流れになります。

iOSアプリを作って、App Store Connectに登録。

スクリーンショットなどを用意して、

審査へ提出。

そしてAppleの審査を待ちます。

こちらは、Google Playのような「12人以上のテスターで14日間」という公開前の条件とは違います。

ただし、App Storeも審査があります。

実際にリジェクトされたこともありました。

Appleは審査でハマった

App Storeでは、

「アプリは完成した」

「設定も終わった」

「これで公開できる」

と思って申請。

ところが、

リジェクト。

Appleから指摘内容が届きます。

原因を確認して修正。

そして再申請。

この繰り返しです。

Google Playでは公開前のクローズドテストに苦労し、App Storeでは審査に苦労する。

それぞれ違うところでハマります。

Google PlayとApp Storeの違い

個人的な体験をざっくりまとめると、こんな感じです。

※Google Playのテスト要件は、対象となる個人開発者アカウントに適用されるものです。

Flutterなら全部同じ、ではなかった

Flutterを使うと、アプリ本体のコードを共通化できます。

これはかなり便利です。

ただ、

「FlutterだからGoogle PlayとApp Storeへの公開も同じ」

というわけではありません。

アプリを作るところは共通化できても、

ストアへの登録。

テスト。

審査。

スクリーンショット。

公開手続き。

このあたりは、それぞれのプラットフォームに合わせる必要があります。

両方やってみると違いが分かる

実際にGoogle PlayとApp Storeの両方にアプリを公開してみると、

「同じアプリストアなのに、こんなに違うんだ」

と感じます。

Google Playでは、

「テスターを集めて14日間」

という壁。

App Storeでは、

「審査を通過させる」

という壁。

どちらも、

「アプリを完成させたら終わり」

ではありません。

まとめ

Google PlayとApp Store。

どちらもアプリを公開するためのサービスですが、公開までの道のりはかなり違います。

Google Playでは、対象となる個人開発者アカウントの場合、

12人以上のテスターに参加してもらい、14日間継続してクローズドテストを行う

必要があります。

一方、App Storeでは、App Store Connectから申請してAppleの審査を受けます。

Google Playではテスター集め。

App Storeでは審査。

それぞれ違うところで苦労しました。

アプリを作る。

↓

テストする。

↓

ストアに登録する。

↓

審査を受ける。

↓

公開する。

アプリ開発は、コードを書いて完成ではありません。

「どうやってストアに公開するか」まで含めてアプリ開発。

実際に両方経験してみて、そんなことを実感しました。

App Storeにアプリを公開したので、今度はどうやってアプリのページに来てもらうかを考えるようになりました。

App StoreのURLをブログに貼るだけでもリンクは作れます。

でも、せっかくなら、

「ここをクリックすればアプリをダウンロードできます」

と一目で分かるものを置きたい。

そこで今回は、SVGでアプリのダウンロードバッジを作ってみました。

普通のテキストリンクでもいいけど……

例えば、

「App Storeはこちら」

とテキストリンクを置く方法があります。

もちろん、これでも問題ありません。

ただ、アプリを紹介するページなら、もう少し目立つほうがいい。

そこで、

アプリのダウンロードボタンとして使えるバッジ

を作ることにしました。

SVGで作ってみる

今回使ったのはSVGです。

SVGなら画像を拡大・縮小しても、基本的に画質が荒くなりません。

ブログに掲載するバッジとしても使いやすいです。

また、HTMLに直接貼り付けたり、画像として表示したりできるので、WordPressとの相性も良さそうです。

アプリごとにバッジを作る

今回のブログでは複数のアプリを紹介しています。

そのため、アプリごとにApp Storeのリンク先が違います。

そこで、

アプリIDを指定して、それぞれのダウンロードバッジを作る

ようにしました。

例えば、

「このアプリのバッジを作りたい」

となったら、そのアプリのApp Store IDを使ってリンク先を設定します。

これならアプリが増えても対応できます。

サイズも変更できる

最初に作ったバッジをブログに貼ってみると、

「ちょっと小さいな」

ということもありました。

そこで、表示サイズも調整。

例えば200px程度の幅にすると、ブログの記事内でもかなり見やすくなります。

画像サイズを調整するだけなので、用途に応じて大きさを変更できます。

ブログの中に設置してみる

実際にブログ記事に設置してみると、

文章だけのリンクよりも、

「ここからアプリを見られる」

ということが分かりやすくなりました。

アプリを紹介する記事なら、読者が記事を読んだあとにApp Storeへ移動できる導線があるのは重要です。

せっかくブログに来てもらっても、App Storeへのリンクが分かりにくければ、そのまま離脱してしまうかもしれません。

アプリを作ったら「見てもらう」ことも必要

個人開発を始めたころは、

「アプリを完成させること」

ばかり考えていました。

でも、App Storeに公開したあとに気づきます。

公開しただけでは、アプリはダウンロードされない。

アプリを知ってもらう。

↓

アプリのページを見てもらう。

↓

App Storeへ移動してもらう。

↓

ダウンロードしてもらう。

この流れを作る必要があります。

そのためにも、ブログからApp Storeへの導線を少しずつ改善しています。

SVGなら使い回せる

今回作ったバッジは、ブログ記事ごとに使い回せます。

アプリ紹介記事。

固定ページ。

アプリ一覧ページ。

など、いろいろな場所に設置できます。

アプリが増えるたびに同じようなバッジを作ることになりますが、基本となるSVGを用意しておけば、リンク先やアプリ名などを変更して対応できます。

作ってみると意外と楽しい

最初は、

「App Storeへのリンクをボタンにするだけ」

くらいに考えていました。

でも実際にSVGを作って、

サイズを調整して、

WordPressに設置して、

実際のApp Storeページに移動できることを確認する。

こうやって一つずつ作っていくと、ブログそのものが少しずつアプリ紹介サイトらしくなってきます。

アプリを作るだけではなく、

アプリを知ってもらうための仕組みも自分で作る。

これも個人開発の面白いところです。

まとめ

今回は、SVGを使ってアプリのダウンロードバッジを作ってみました。

App Storeへのリンクをただテキストで貼るのではなく、

「アプリをダウンロードできます」

と分かりやすいバッジにすることで、ブログからApp Storeへの導線を作ることができます。

アプリを公開する。

↓

ブログで紹介する。

↓

ダウンロードバッジを設置する。

↓

App Storeへ誘導する。

少しずつですが、アプリを知ってもらうための仕組みを作っています。

アプリ開発は、コードを書いて終わりではありません。

どうやって見てもらうか、どうやって使ってもらうか。

ここからも試行錯誤が続きそうです。

WordPressをカスタマイズしていて、Code Snippetsを使ってコードを追加していました。

今回やりたかったのは、ブログに関連記事などを自動表示する仕組みを追加すること。

コードを書いて、

「よし、これで保存！」

と思って保存ボタンを押しました。

すると……

403エラー。

「コードが間違っているの？」

最初に疑ったのは、当然コードです。

「PHPの書き方がおかしい？」

「何か危険なコードとして判定されている？」

「どこかにミスがある？」

と思って、コードを確認します。

修正して、もう一度保存。

しかし、

403エラー。

また保存できません。

WAFを疑ってみる

WordPressで403エラー。

しかも、コードを保存するときだけ発生する。

そこで、

「もしかしてWAF？」

と考えました。

レンタルサーバー側のWAFが、Code Snippetsに入力したコードを不正なリクエストとして判断している可能性があります。

そこでWAFを確認。

そして、

WAFをOFFにしてみました。

これでいけるはず。

もう一度保存。

……403。

「WAFじゃないの？」

ここで少し焦りました。

WAFをOFFにしても403。

ということは、別の場所でブロックされている？

WordPress側なのか。

サーバー側なのか。

プラグインなのか。

それともCode Snippetsなのか。

原因が分からないと、かなりモヤモヤします。

とりあえず小さなコードで試す

いきなり大きなコードを保存するのではなく、もっと単純なコードで試してみました。

すると、

保存できた。

「あれ？」

と思います。

今度は少しずつコードを追加していきます。

そして、あるところまでコードを追加すると……

403。

どうやら、コードの内容によってサーバー側のセキュリティに引っかかっているようでした。

コードが正しくても保存できない

ここが今回一番ややこしかったところです。

PHPとしては正しいコードでも、

「サーバーのセキュリティが危険なリクエストだと判断する」

ことがあります。

つまり、

コードが間違っている

↓

保存できない

とは限りません。

コード自体は正しくても、

保存処理の途中で403としてブロックされる

ことがあります。

403エラーは「アクセス拒否」

403というのは、ざっくり言えば、

「その操作は許可されていません」

というエラーです。

今回の場合、

「Code Snippetsが壊れている」

という単純な話ではありませんでした。

WordPress、プラグイン、レンタルサーバー、WAFなど、いくつかの仕組みが関係しています。

こういうところが、WordPressのカスタマイズで難しいところです。

そして、最終的には保存できた

コードを確認しながら、

どの部分で403になるのかを切り分けていきました。

少しずつ変更して、

保存。

エラーが出ない。

さらに追加。

保存。

また確認。

そんな感じで原因を切り分けていき、最終的には無事にCode Snippetsへ保存できました。

そして、作りたかった関連記事の自動表示も動かすことができました。

個人開発ではエラー調査も仕事

今回改めて思ったのは、

プログラムを書く時間より、エラーの原因を探している時間のほうが長いことがある

ということ。

コードを書く。

↓

エラー。

↓

調べる。

↓

設定を確認する。

↓

また試す。

↓

別のエラー。

↓

また調べる。

個人開発をしていると、これが普通にあります。

でも、原因が分かってエラーが消えた瞬間はかなり気持ちいいです。

まとめ

今回は、WordPressのCode Snippetsでコードを保存しようとしたところ、403エラーになりました。

最初は、

「コードが間違っているのかな？」

と思いました。

WAFも確認しました。

それでも403が出て、原因の切り分けに苦戦しました。

WordPressのカスタマイズでは、

• WordPress


• プラグイン


• PHP


• レンタルサーバー


• WAF


• セキュリティ設定

など、いろいろな場所が関係します。

だから、

「403が出た＝コードが間違っている」

とは限りません。

エラーが出たときは、一つずつ切り分ける。

今回もそれを改めて実感しました。

そして、無事に保存できたときは、

「やっと通った……！」

という感じでした。

個人開発、今日もコードを書く前にエラーと戦っています。

WordPressでアプリ関連の記事を書いていると、記事がどんどん増えてきました。

今回、自分のブログではアプリごとに、

app001、app002……app029

というカテゴリを作っています。

アプリが増えるたびにカテゴリも増えていき、気がつけば29個。

そこで問題になったのが、

「関連記事を毎回手作業で設定するの、面倒じゃない？」

ということでした。

アプリごとにカテゴリを作っている

自分のブログでは、アプリごとにカテゴリを分けています。

例えば、

• app001


• app002


• app003


• …


• app029

という形です。

アプリごとに記事をまとめられるので、

「このアプリについて書いた記事」

を探しやすくなります。

ただ、記事数が増えてくると、別の問題が出てきます。

関連記事を手作業で追加するのが大変

例えばapp001についての記事を書いたとします。

その記事に、

「app001の関連記事はこちら」

と過去の記事へのリンクを追加する。

ここまでは簡単です。

でも、app001の記事が10本、20本と増えてきたらどうでしょう。

新しい記事を書くたびに、

「過去にどんな記事を書いたっけ？」

と探す必要があります。

さらに、過去の記事にも新しい記事へのリンクを追加したくなります。

記事が増えるほど、この作業が大変になります。

そこでカテゴリを利用することにした

せっかくWordPressにカテゴリがあるので、

カテゴリを関連記事の判定に使えばいい

と考えました。

app001の記事なら、app001カテゴリの記事を自動表示。

app002の記事なら、app002カテゴリの記事を自動表示。

このようにすれば、記事を書くときに関連記事を手作業で設定する必要がありません。

29個のカテゴリを手作業で管理したくない

今回のポイントはここです。

カテゴリが、

app001

だけなら、手作業でも何とかなります。

でも、

app001〜app029

まであります。

今後さらにアプリを作れば、app030、app031……と増える可能性もあります。

そう考えると、

「カテゴリが増えるたびに設定を変更する仕組みにはしたくない」

と思いました。

WordPress側で現在設定されているカテゴリを利用して、自動的に関連記事を表示する仕組みにしました。

固定ページも自動表示

さらに、関連記事だけではなく、

カテゴリと同じスラッグを持つ固定ページ

も表示するようにしました。

例えば、

カテゴリが app001

なら、

app001 に対応する固定ページも表示。

その下に、app001カテゴリの記事を表示する。

という形です。

これなら、アプリごとのまとめページとしても使えます。

記事を書くときはカテゴリを設定するだけ

仕組みを作ったあとは、

記事を書く

↓

対応するカテゴリを設定する

↓

公開する

これだけ。

あとはWordPress側で、

そのアプリに関連する固定ページや記事を自動的に表示

してくれます。

関連記事を毎回探してリンクを貼る必要がありません。

「記事を書くこと」に集中できる

ブログを続けていると、

記事を書くこと以外の作業がどんどん増えていきます。

関連記事を設定する。

内部リンクを追加する。

カテゴリを整理する。

固定ページとのリンクを考える。

こういう作業も大切なのですが、全部手作業でやっていると記事を書く時間が減ってしまいます。

だから、できるところは自動化する。

今回の関連記事表示も、その一つです。

個人開発者なので、結局自動化してしまう

アプリ開発でも、

「この作業、毎回やるの面倒だな」

と思ったら自動化したくなります。

WordPressでも同じでした。

「app001〜app029の関連記事を毎回手作業で管理するのは面倒」

と思ったので、自動化しました。

ブログを書いているのか、ブログを開発しているのか、だんだん分からなくなってきます。

まとめ

今回は、WordPressのカテゴリを利用して関連記事を自動表示する仕組みを作ってみました。

現在のカテゴリは、

app001〜app029

まであります。

アプリごとのカテゴリを利用して、

• 対応する固定ページ


• 同じカテゴリの関連記事

を自動的に表示します。

記事を書くたびに関連記事を探す必要がなくなったので、かなり楽になりました。

記事数やアプリ数が増えてくるほど、こういう自動化は効いてきます。

アプリを作る。

ブログを書く。

ブログの管理が面倒になる。

仕組みを作って自動化する。

そして、またアプリを作る。

個人開発って、こういうところまで含めて面白いのかもしれません。

アプリが完成しました。

動作確認もしました。

スクリーンショットも用意しました。

App Store Connectの設定も終わりました。

そして、ついにApp Storeの審査へ。

ここまで来ると、

「あとは審査が終われば公開だ」

と思います。

ところが、そう簡単にはいきませんでした。

Appleからメールが届く

審査に提出して、しばらく待ちます。

そしてAppleからメールが届きました。

「審査が終わった！」

と思って内容を確認すると、

リジェクト。

一瞬、

「えっ？」

となります。

アプリ自体は普通に動いています。

自分で何度も確認しました。

それでも、審査では別のところを見られます。

自分では問題ないと思っていた

個人開発で一番難しいのが、ここかもしれません。

自分では、

「ちゃんと動いている」

「これで問題ない」

と思っている。

でも、審査する側から見ると、

「ここを確認してください」

という部分が出てきます。

自分のアプリを客観的に見るのは、意外と難しいです。

指摘された内容を確認する

リジェクトされると、Appleから理由が書かれています。

最初は、

「何がダメだったんだ？」

という気持ちになります。

でも、内容を一つずつ確認していきます。

すると、

「なるほど、ここか」

と分かってきます。

リジェクトされたこと自体よりも、

「なぜリジェクトされたのかを理解すること」

のほうが大事だと感じました。

修正して再申請

原因が分かったら修正します。

コードを変更することもあります。

設定を変更することもあります。

App Store Connect側の情報を修正することもあります。

そして、もう一度審査へ。

ここでまた待ちます。

一度審査に出したあとにリジェクトされると、

「また審査か……」

という気持ちになります。

個人開発では、この待ち時間もなかなか大きいです。

そして無事に審査を通過

再申請したアプリが無事に審査を通過しました。

App Store Connectを確認して、

「公開できる状態になった」

ことを確認したときは、かなりホッとしました。

一度リジェクトされたからこそ、

「今度こそ大丈夫だった」

という嬉しさもありました。

リジェクトされて分かったこと

今回の経験で思ったのは、

「審査に出すことも開発の一部」

ということです。

アプリを作って、

「完成！」

と思っても、App Storeに公開するにはまだやることがあります。

審査で指摘される。

修正する。

再申請する。

場合によっては、また修正する。

これもアプリ開発の工程の一つなんだと思いました。

リジェクトはちょっと怖い

初めてリジェクトされると、結構焦ります。

「公開できないのでは？」

「何か重大な問題があるのでは？」

と考えてしまいます。

でも、まずはAppleから届いた内容を落ち着いて読む。

そして、何が問題なのかを確認する。

必要なら修正して、再申請する。

この繰り返しです。

一度経験すると、

「リジェクトされても、やることはある程度決まっている」

と思えるようになります。

個人開発では全部自分

会社でアプリを作っていれば、レビュー担当者や申請担当者など、いろいろな人がいます。

でも個人開発では、基本的に全部自分です。

開発する。

テストする。

申請する。

リジェクト内容を確認する。

修正する。

再申請する。

そして、また待つ。

なかなか大変です。

でも、その分、

自分で作ったアプリがApp Storeに公開されたときの達成感も大きい

と思います。

まとめ

App Storeの審査でリジェクトされたときは、正直ちょっと焦りました。

「完成した」と思っていたアプリが、公開できない。

でも、リジェクト理由を確認して、必要な修正をして、再申請。

そして無事に審査を通過しました。

今回のことで、

アプリが完成した＝公開できる

ではないことを改めて実感しました。

App Storeに公開するまでには、

開発。

テスト。

App Store Connectの設定。

スクリーンショット。

審査。

修正。

再申請。

いろいろな工程があります。

そして、その一つ一つでハマります。

でも、それも個人開発の面白さなのかもしれません。

次はリジェクトされないようにしたい。

……と思いつつ、また何かで引っかかる気がしています。