10 年間 1 人で 1 つの iOS アプリを保守してきた話

はじめに

10 年前の今日、2012/02/03 に Just Quick Search という iOS アプリをリリースした。

個人で開発を行い、100% すべての要素を自分で考え作り上げてきた。
今日はこのアプリに関する 10 年間の思い出と技術的な部分についてをアツく語りたいと思う。

アプリ紹介

Just Quick Search は検索補助アプリである。
このアプリを使うと普段 iPhone で行っている 検索 というアクションをほんの少しだけ 速く 実行できるようになる。

以下がキーワード iphone を検索している時の挙動だ。

ip と入力したところで候補に出てきた iphone をタップし、キーボード右下の search をタップすると Safari が立ち上がり Google での検索結果が表示されるというものである。
メインの機能はこれだけだ。

一見ただ検索をしているだけに見えるが、このアプリ最大の魅力は 素早く検索できる こと。
アプリの起動/再開時は常に同じ画面が同じ状態で表示されるようになっており、前に開いていた画面やテキストの入力状態に関わらず、入力欄は空っぽでキーボードが表示されるよう設計・実装した。
この仕様によりユーザーはアプリを立ち上げた瞬間に任意のキーワードを即座に入力開始できるというわけだ。
このシンプルなアプリは 何度も利用することで その良さを実感できるようになっている。

入力補完機能にもこだわっており、入力中の文字列に対して Google サジェストの補完と検索履歴からの補完を同時に表示するようにしている。
履歴からの補完に関しては C/Migemo というライブラリを使用した。
これはローマ字から日本語をインクリメンタルサーチできるというスグレモノである。
i と入力するだけでひらがなの い、カタカナの イ、漢字の 一 などを検出できる。
続けて文字を入力することで絞り込みも可能だ。

i 入力中	it 入力中

以下の動画は Apple の審査用として 6 年前に作成したものである。
アイコンデザインや機能は多少変わっているが基本的な UI は同じなので、興味がある方には見ていただきたい。

私はこのアプリをリリースしてから 10 年間毎日使い続けている。
もっと多くの人に使ってもらいたいのだが、なかなかダウンロード数が伸びない。

残念なことに、このアプリ

非常に 地味 なのである。

地味な部分

すべてが地味と言っても過言ではない。
派手な部分は見つけられず、無いと困るという機能も存在しない。
あればちょっと便利になるというだけなのだ。
このアプリを使わなくても検索はできるし、前に開いていた画面やテキストが残っていたとしても目的の画面に戻ってテキストを削除すればいい。

何度か同僚や知人にアプリを見せたことがあるが、反応はいつもイマイチだった。
「良さそう」とは言ってもらえるものの、その後「使ってます」と言われたことはほとんどない。
体感的には 1 割以下だ。

そもそも Just Quick Search というアプリ名がもうダメだ。
全然キャッチーじゃないし、その上長い。
当初は「Quick Search」というアプリ名にしようとしたのだが、App Store には 同名のアプリはリリースできない という制約がある。
既に「Quick Search」というアプリが存在していたため、安易に「Just」を付けてしまったというわけだ。
失敗した。

しかし 名前は大事 ということにリリースから 3 年後くらいに気づくことができた。
これに関しては成功だ。
今となってはそんなダメな名前も私は好きだ。

非常にレアではあるが、この地味なアプリを気に入ってくれているユーザーは一定数存在しているようだ。
数ヶ月に 1 度くらいの頻度で以下のようなレビューコメントをいただくことがある。

• ○年以上使っています
• 毎日使っています
• 日に何度もお世話になっています

すごく嬉しいです。
ありがとう。

このアプリには一言でアピールできる強力な武器は存在しない。
だが地味な機能がいくつも合わさって、ものすごく便利になるよう仕上がっている。
これまでそれらを誰かに詳しく説明することはなかったが、10 年という節目でもあるので本記事にて時系列順に解説していきたいと思う。

これまでのダウンロード数と収益

その前に今までの実績を振り返って公開してみる。

リリースから今までのアプリダウンロード数は 約 3 万、収益は 20 万円 ~ 25 万円 くらいだ。

以下が開発者向け管理サイト App Store Connect の集計ページである。
ユニット数は 29.4K。
最近だと一週間に多くても 5 ダウンロード程度だ。
訳あって Just Quick Search というアプリが複数存在するが、これらについてはあとで説明する。

以下が純粋に Apple から振り込まれた金額 $545。
こちらは主に 広告非表示 アドオン購入の収益である。

本アプリでは現在 Admob というモバイル広告を導入しており、それによる収入が一番大きい。
と言っても最近では 一月 ¥1,000 くらいだ。
調子のいい月で ¥3,000 ほどだったので合計すると広告の収益だけで 20 万円 行くか行かないかというところ。

ダウンロード数は置いておいて、10 年間で 20 万円 という金額をどう捉えるか。
全然低いな。
私は全く満足していない。

他の人からすると 何もしないで 20 万ならいいじゃん と思われるかもしれない。
いや、メチャクチャやってるから！

仮に最初の 1 ヶ月だけ開発して、残り 9 年 11 ヶ月は何もしていなかったとしよう。
この場合でもその人は 何もしなくても稼げるよう考え行動した人 なのだ。
本当に何もしないで稼いでいる人なんて存在しないと思う。

私はまだまだこのアプリで稼ぎたい。
未だに一攫千金を夢見ている。
よってこの記事を見てくれている人にはダウンロードして使ってもらえるよう精一杯アプリの魅力を伝えていきたい。
おそらくこれが Just Quick Search 最後のチャンスになるだろう。

アプリリリースの動機

ここから昔話が始まる。

2011 年の 12 月、iOS 開発を始めて 1 年半ほどの私は次なるスキルアップを目指していた。
前職での冬休み中まとまった時間も確保できたので、このタイミングで「アプリをリリースしてみよう！」と決心した。

なにか特定のアプリを世に出したかったわけではない。
単純に アプリをリリースするための手順 を知り、体験したかったのだ。
それまでは仕事で iOS 開発に関わっていたものの、やっていたことはアプリの実装と動作確認までだった。
Apple の審査からリリースまでのステップが自分の中で全く未知数だったため、明確にしたいというのが狙いだ。
そこで学んだことは今後絶対に役に立つだろう、と。

その考えは正しかった。
当時習得した知識は今でも私の中で生き続けている。

最初のアプリ

実は Just Quick Search は最初に考えたアプリではなかった。
最初に開発し Apple の審査に提出したアプリ名は Just LED Flash。
こちらも最初は「Just Flash」という名前にしたかったのだが、既に登録されていたため「LED」を挟んである。
Just Quick Search の名称は確実にこいつに引きずられている。

以下がそのアプリの画面である。
今では存在しないシステムカラーを背景色に採用した 1 画面のみの作りだ。（広告も無し）

機能はいたってシンプル。
ユーザーが画面を触っている時だけ iPhone カメラのフラッシュが点灯するというものだ。
それまでフラッシュアプリは ON/OFF のボタンが付いているものが主流だった。
このアプリではスイッチの切替が不要ということになる。
言い換えれば画面全体がスイッチだ。

このシンプルなアプリをリリースしてみるという手段で、アプリ公開までの手順を学ぼうとした。

iTunes Connect での作業

現在 iOS アプリの管理を行うサイトは App Store Connect だが、当時は iTunes Connect という名称だった。
ここで何をしなければいけないかを一つ一つ調べ、設定していった。

今でこそ日本語化されずいぶん見やすくなっているが、当時はすべて英語で設定すべき項目もよくわからなかった。
検索しても情報はそんなに多くない。
うろ覚えだが、以下のような作業を実施したと思う。

• 開発者情報の登録
  • 会社名
  • 住所
  • 振込先口座
• アプリ情報の登録
  • アイコン
  • スクリーンショット
  • 説明文
  • キーワード
  • サポート URL

少し困ったのが 会社名 だった。
個人開発なのに会社名が必要なのか。
しかもこの項目は設定後の変更が不可だった。
少し考えた私は Mill White という（架空の）会社名を設定した。
これは当時実家で飼っていた ウエスト・ハイランド・ホワイト・テリア という犬種の ミル と名付けた愛犬から取った名だ。
自分のネーミングセンスにしてはまぁまぁ良い方ではないかと思っている。
この会社名のおかげで毎年この時期になると、ミルのことを思い出すことができる。

後から知ったがこの会社名という項目は割となんでもいいらしく、個人開発者の場合は自分の名前をそのまま登録している人も結構いる。
私の場合だと Keisuke Tanaka でも問題なかったということだ。

そして血の気が引いた項目がアプリ情報内の サポート URL である。
無いよ、そんなの。

意外な割り込み作業

アプリ開発を行っていると結構な頻度でこのようなことが発生する。
本来やりたいことではない、やらなければいけない 作業の強制割り込みだ。

サポート URL？
自分は iOS アプリをリリースしたいだけなのに、サポートページを作らなければいけないということなのか？
iOS エンジニアが Web アプリを？
当時の私のスキルでは「できらぁ！」と言えないことが非常に残念で悔しかった。（今もできるかは不明）

会社で開発しているのであれば、最低限その会社のホームページ URL を載せておけばいいだろう。
だが個人開発だとそうはいかない。
ホームページなど存在しないのだから。

割と絶望してたと思う。
そもそも視野が狭かったのだが当時の自分にはできる気がしなかった。
だが諦めたくなかった。
あと少しでアプリのリリースができそうなのだ。
この記事ではサラッと書いているが、ここまで到達するのにも結構な時間をかけていた。
ひたすら考え悩んだ結果、一つのサービスに行き着いた。

SuppApp

SuppApp はモバイルアプリ向けのユーザーサポートサイトをホスティングしてくれるサービスである。
有限会社ランカードコム が運営していたサービスだ。
私はこのサービスを利用し、サポート URL に設定した。
残念ながらサービスを終了してしまったが、当時の私にとってはまさに救世主だった。
開発者やユーザーは Twitter 認証でこのサービスを利用し、質問、アイディア、称賛、問題 などをジャンルごとにメッセージングできた。
特に アイディア のページでは一部のユーザーと活発にやり取りし、新機能を開発するきっかけにもなった。

この場を借りてお礼申し上げます。
ランカードコムさん、SuppApp を作ってくださりありがとうございました。
このサービスがなければ私のアプリはリリースできていませんでした。
また、このサービス上でユーザーとやり取りした体験はとても素晴らしいものでした。

後日談

少し先の話になるが 2014 年の夏頃にこのサービスは終了した。
代わりとなるサポート URL をまた考えなければならない。
私は Twitter のアカウント URL を指定した。
審査が通った。

それで通るんかい！

初めての審査提出、そして・・・

ようやく準備が整った。
あとはアプリを審査に出して承認されればリリースができる。
色々あったけど、そんなに難しくはなかったかな。
満足満足。

ここからが地獄の始まりだった。

2011/12/31、Just LED Flash を Apple の審査に提出した。
2012/01/08、レビュアーからフィードバックあり。

結果は Reject

メッセージは以下。

2.11
We found that your app duplicates the content and functionality of apps currently available on the App Store.

App Store Review ガイドライン の項目（当時の）2.11 に該当。
似たようなアプリが既に大量に存在するため NG。

そうなのか。
ちなみに私はここで初めてレビューガイドラインの存在を知った。

現在のガイドラインにも以下の規約が存在する。

すでに飽和状態のカテゴリにAppを追加することは避けてください。App Storeには、おなら、げっぷ、懐中電灯、占い、デート、宴会用ゲーム、カーマ・スートラといったAppがすでに多数存在します。こうしたAppは、ユニークで高品質な体験を提供するAppでない限り、却下されます。

確かに懐中電灯アプリはいくつもある。
でもこのアプリは他とは違う。
ほとんどの懐中電灯アプリは、ボタン、スイッチ、タップでライトを点灯させており、このアプリのように画面をタッチしながら点灯させるアプリは無いんだ。
私はアプリをリリースしたい一心で慣れない英文を駆使し、レビュアーに熱意を伝えた。

全然ダメだった。
定型文が返ってきて終わった。
私は Just LED Flash のリリースを諦めた。

Just Quick Search の誕生

さてどうしようか。
ありふれたアプリは NG で、ある程度の機能を持たなければならない。
少しだけ考えた。
自分はどんなアプリを使いたいか。

最近あんまり漢字が書けないな。
漢字がわからない時、iPhone で調べているな。
でもそれをする時は何かのアプリを開いて入力欄をタップしないといけないな。
よし、すぐに文字入力ができる 漢字を調べるアプリ を作ろう。

コンセプトが決まれば後は実装のみ。
目的は アプリリリース なので、複雑な機能も不要。
爆速で作り上げたアプリは以下のような画面だった。

起動画面	文字入力中

アプリ起動時（& 再開時）には入力欄が空、キーボードが表示されている状態。
ユーザーはすぐに調べたい漢字を入力して確認できるというものだ。

ご覧の通り Just Quick Search のベースはこの時点で既に完成していた。
自慢になるが、このアプリの UI は 10 年間ほとんど変わっていない。

iOS では検索用の UI コンポーネントとして UISearchBar というものが用意されている。
Safari で言うと Web サイト名や URL が書かれている部分だ。
しかし私はそれではなく UITextField というただの入力欄を採用した。
UISearchBar の場合、通常そのコンポーネントは画面最上部に配置することが多い。
デザイン的にそれ以外に配置すると違和感が出るのだ。
そもそも私は（この時点では）検索をしたいわけではなかった。
文字列を入力して漢字を調べたいだけなのだ。

この時の選択は大成功だった。
なぜなら今後 iOS デバイスは縦長に進化していくこととなる。
画面最上部に配置する UISearchBar を採用していた場合、よく使う重要なコンポーネントがどんどんタップしづらい場所（上の方）に移動してしまうのだ。
それを回避しようとするとアプリのデザインを根底から覆さなければならなく、継続するのが困難になっていただろう。
Just Quick Search を使用する際の指の動きは縦方向ではなく 横方向 がメインとなる。
かつ重要なコンポーネントが画面中央に集中しているため、指の運動量は比較的少なくて済む。
たまたまだったかもしれないが、この時に決めた画面デザインは本当に良かったと思っている。

ここで気付いた。
この漢字調べアプリ、オチがない。
漢字は調べられるものの、キーボードの return キーをタップしても何も起こらない。
さすがにまずい気がしたので検索機能を付けた。
文字列を入力して search ボタンがタップされたら以下の URL を Safari で開くようにした。

https://www.google.com/search?q=<入力された文字列>

Just Quick Search 誕生の瞬間である。

2 度目の審査提出、そして・・・

本当に速かったと思う。
この頃の熱意はすごかった。
Just LED Flash がリジェクトされた翌日には Just Quick Search を審査に出していた。

この時点でのアプリの機能は以下の通り。

• シングルビュー
  • 画面遷移なし
• 起動時/再開時はいつも同じ画面で文字入力可能状態
  • 入力欄は空
  • キーボード表示済み
• search ボタンタップで Safari が開く
  • Google 検索の結果を表示

あとはレビューを待つだけ。

現在は審査提出から 1, 2 日でレビューが開始され結果がわかるようになっているが、10 年前は 1 週間以上待たされるのが普通だった。
この待ち時間が開発者にとって、ものすごく苦痛なのである。

2012/01/18、レビュアーからフィードバックあり。

結果は Reject

4.2
We found that the usefulness of your app is limited by the minimal amount of content or features it includes.

App Store Review ガイドライン の項目 4.2 に該当。
最低限の機能性が無いため NG。

なるほど、機能が少なすぎたか。
じゃあ検索履歴の機能を付けよう。
その日に実装し、再提出した。

結果は Reject

4.2
We found that the usefulness of your app is limited by the minimal amount of content or features it includes.

これでもダメか。
では Google 検索以外に Wikipedia の検索機能も付けよう。

結果は Reject

4.2
We found that the usefulness of your app is limited by the minimal amount of content or features it includes.

何をしてもダメだった。

辛かった。
私は気付いた。
このアプリには最低限の機能が無いためリジェクトされているわけではない。
役立たずの使えないアプリだからリジェクトされているのだ、と。

機能はシンプルかもしれないが真剣に考え実装し、数々の困難を乗り越えここまでやってきた。
しかしその先に待っていたのはレビュアーからの

お前のアプリはクソアプリ〜 m9(^Д^)

というメッセージだったのだ。

このリジェクト理由でダークサイドに堕ち、アプリのリリースを断念してしまった iOS エンジニアが一体何人いるのだろうか。
でも諦めないでほしい。
きっと道はある。
一つの方法としてだが Just Quick Search というアプリが通った道をここに記す。

実はこの 4.2 という項目、最悪のリジェクト理由 だったのだ。
何をすればいいという具体的な指示はなく、漠然と 役に立つ 機能を考えなければならない。
そもそも私にとって有用だと思っているから審査に出したのだ。
役に立つかどうかは人によって異なる。

少し時間をおいた。
リジェクト回数自体は 3 回だったが、昔ということもありこれらのやり取りだけで 2 週間近くかかっており、かなり疲れていた。
審査に提出しても反応があるまで数日待たなければならない。（リジェクトからの再提出時は次のレビューまで多少待ち時間が短縮される）
その上、時差の関係で結果が出るのはいつも夜中の 2 時前後だった。
その頃は夜中にうなされて目を覚ますことも多くなった。
目を覚ましてもレビューは開始されておらず、やっとレビューされたと思っても結果はリジェクトなのだ。

考えた。
色々考えた。
もともと Just Quick Search は全世界を対象として作成したアプリだった。
どうせなら多くに人に使ってほしかったからだ。
日本に限定する理由は特にない。
しかし、今のままではうまく行かないことは明白だった。
そこで日本向けに特化した Just Quick Search をリリースすることにした。
その名も Just Quick Search for Japan。
ひどい名前だ。

検索結果の表示を google.com から google.co.jp に変更し、iOS の内蔵辞書機能を利用して英和・和英辞書の検索機能も追加した。
結果的に機能が追加された形だ。
狙いはもう一つあった。
日本の App Store でのみ利用可能とするため、アプリの説明文を英語ではなく日本語にした。
これによりレビュアーも日本語が読める人間、あわよくば日本人になるかもしれない。
その場合、同じ日本人（もしくは日本好き）ということで多少情けをかけてくれるのではないかという浅はかな考えだ。

この時はレビュアーを変えたいという思いが強かった。
毎回リジェクトしてくるレビュアーは同一人物のような気がしていた。
Just Quick Search がこの人にとって「役に立たない」ものであればこれ以上やり取りしていても不毛である。
このアプリを「役に立つ」と思ってくれるレビュアーを引き当てたかったのだ。
・・・自分は一体何をやっているのだろうか。

2012/01/24、審査提出。
2012/02/03、レビュアーからフィードバックあり。

結果は Accept

嬉しかった。
やっとここまで来れた。
一体何が上手くいった要因なのか、そんなことはもうどうでもよかった。
とうとう目的だった アプリリース が実現できたのだ。
それだけで満足だった。

この時の画面キャプチャがこちら。

この日も例によって明け方に目が覚めてしまい、iPhone を確認したところ上記の通知が表示されていた。
声にならない声を上げ、何度もガッツポーズをした。

Ver.1.0

リリース日：2012/02/03

記念すべき Just Quick Search (for Japan) ファーストバージョンのスクリーンショットは以下の通り。

左画面	右画面	履歴画面

左画面の History ボタンをタップすると履歴画面が表示される。
検索履歴は 100 件（現在は 300 件）まで保存でき、全て削除することも 1 件ずつ削除することもできるようにした。

右画面の Save というスイッチはアプリ起動/再開のたびに検索対象を記憶しておくために利用する。
OFF の場合はアプリ起動/再開時に検索対象が最上部のもの（ここでは Google）にリセットされる。
ON では以前選択したものになったままという動きだ。

なおこのバージョンではまだキーワードの補完機能は実装していなかった。

色々あったせいか私はこのアプリを漢字調べに使うのではなく、普通に検索手段として使うようになっていた。
冒頭にも書いたが、Just Quick Search は使えば使うほどその便利さがわかってくるのだ。
はじめはそこまで期待していなかったが 素早く検索するだけ というシンプルなアクションが快感に変わり、いつしかそれが当たり前になっていった。
普段使いしていると「もっとこうしたい」というアイディアがどんどん湧いてきた。
今まではリリースすることが目的だったが、この時点で新たな目的 もっと多くの人に使ってもらいたい ＆ お金を稼ぎたい に変わった。

ここから怒涛のアップデートが始まる。

紹介が遅れたが、以下が Ver.1.0 のアプリアイコンだ。

めちゃめちゃ不評だった。

だってしょうがないじゃないか。
私は iOS エンジニアであってデザイナーではない。
アプリアイコンのデザインなんて専門外だ。
それでもすべてを自分一人で行いたかった私は Mac の Keynote アプリで正方形の図形を配置し、真ん中に 速 の字を書いた。
このアイコンデザインは今でも気に入っている。

ちなみに以下が Just LED Flash のアイコンだ。

私はこれらを自分の iPhone のホーム画面に隣り合わせで配置し 光速 の文字列を完成させたかったが、それは叶わぬ夢となった。

もう一方の Just Quick Search

さて、日本版の Just Quick Search は無事にリリースできた。
2 週間ほど期間は空いたが、機能は変えずダメ元で海外版も審査に再提出してみた。

結果は Accept

通るんかい！

これ以降は日本版で先行して機能実装し、ある程度まとまったら海外版にも移植してリリースするという方針で進めていった。

Ver.1.1

リリース日：2012/02/28

リリースノート

• 入力補完機能の実装
• AppBank Network の導入

入力補完機能の実装

前述の通り、Google による補完と検索履歴からの補完を実装した。
これにより Just Quick Search の利便性は飛躍的に向上した。
正直、私は Ver.1.0 + Google の補完機能だけでこのアプリは完成してると思っている。
その他の機能はあくまでオプションにすぎない。

検索履歴からの補完はこの時点では C/Migemo を導入していない。（スキル的にも不可能だった）
その上なぜか候補のマッチ条件を 前方一致 としてしまっていた。
部分一致 でよかったではないかと今でも悔やんでいる。
よってこの頃の履歴補完は使い物にならなかったと思う。

AppBank Network の導入

Just Quick Search は無料アプリだ。
いくらダウンロードされてもそれだけで稼ぐことはできない。
そこで多くの無料アプリではモバイル広告を実装することになる。
このアプリでもモバイル広告を組み込もうと考えたのだが、どの広告会社を選んで良いかがわからなかった。

ここで目についたのが、当時の日本最大級 iPhone, iPad 情報掲載サイトの AppBank である。
今ではあまり見かけないが、昔は iOS, Android アプリの紹介サイトが山ほどあった。
新たにリリースされたものや隠れた優良アプリなどを実際に使用してレビューを書いてくれるサイトだ。
アプリのプロモーションを行ってくれる、特に個人開発者にとってはとてもありがたい存在だった。

どうやらその AppBank がファンコミュニケーションズ提供の nend というプラットフォームと連携し、独自のアドネットワーク AppBank Network をリリースするらしい。
嬉しいことに AppBank Network に加入すると AppBank のサイトで優先的にアプリのレビュー記事を書いてもらえるのだ。
私はその情報に飛びつき、早速登録して SDK を Just Quick Search に組み込んだ。

結果は驚きである。
それまで 1 日 3 ~ 5 ほどのダウンロード数が AppBank のページにちょこっと載っただけで 313 まで跳ね上がった。
メディアの力は偉大だ。

当時やり取りさせていただいた AppBank の脇さんには本当に感謝している。
見返してみるとかなりウザい感じのメールも送っていた。
ありがとうございました。
あの頃は毎日がドキドキでした。
そしてウザくてごめんなさい。

その後、ダウンロード数は失速したものの確実に以前よりは平均値が上がっていった。（日に 5 ~ 20）
これによって僅かではあるが Just Quick Search が認知され、時折個人ブロガーが本アプリの紹介記事を書いてくれたりもしていた。
現状のダウンロード数 3 万 まで到達できたのは間違いなく AppBank のおかげである。

Ver.1.2

リリース日：2012/03/08

リリースノート

• マップ検索機能の実装

マップ検索機能の実装

これまで以下の 4 つだった検索対象に マップ を追加した。

• Google
• Wikipedia
• 国語 / 英和
• 和英 / 英英

マップを選択し検索を実行すると、当時 iPhone に標準インストールされていた Google マップアプリが開き、キーワードとして入力された場所が表示されるという機能だ。
ここからしばらくの間 Just Quick Search の検索対象の数は 5 で固定される。

Ver.1.3

リリース日：2012/03/13

リリースノート

• 設定画面の実装
• UI カスタマイズ機能の実装

設定画面の実装

今後の機能追加に備えて設定画面を用意した。
設定と言えばよくあるアイコンは 歯車 であるが、私のイメージでは歯車アイコンはナビゲーションバーと呼ばれる画面上部にあるツールバーとセットだった。
このアプリにはナビゲーションバーは存在しないし付けるつもりもない。
そして設定画面を開く頻度も少ないので目立つところに配置したくはなかった。
ノイズは可能な限り除去したい。
そこで私は右の画面（検索対象選択画面）の下部に ★ のボタンを配置した。
これがこのアプリにおける設定ボタンだ。

★ マーク自体は小さいが、タップ検知の領域は広めにとってある。
これにより タップしてるけど反応しない という事象は起きづらく、ユーザーもストレスなく操作できるようになる。
こちらは Apple が提供する Human Interface Guidelines の思想に準拠したものである。

Provide ample touch targets for interactive elements. Try to maintain a minimum tappable area of 44x44 pt for all controls.

（訳）インタラクティブな要素には十分なタッチターゲットを設けてください。すべての操作部について、タップ可能な領域を44x44 pt以上確保するようにしてください。

Just Quick Search では ユーザーが操作しやすいように を常に心がけている。

UI カスタマイズ機能の実装

「背景を選べるようにしたい」という当時の職場の先輩の声に応え、以下の 3 つを変更できるようにした。

• 壁紙
• ステータスバー
• キーボード

これでユーザーは自分の好きなようにアプリの見た目を変えることができる。
ステータスバーとキーボードに関しては ダーク or ライト を選択できる。
壁紙に関しては単色カラーもしくは任意の画像を設定できるようにした。

壁紙画像の最適なサイズは端末によって異なる。

• iPhone 12 Pro Max, 13 Pro Max
  • 1284px x 2778px
• iPhone XS Max, 11 Pro Max
  • 1242px x 2688px
• iPhone 12, 12 Pro, 13, 13 Pro
  • 1170px x 2532px
• iPhone X, XS, 11 Pro, 12 mini, 13 mini
  • 1125px x 2436px
• iPhone 6 Plus, 6s Plus, 7 Plus, 8 Plus
  • 1242px x 2208px
• iPhone XR, 11
  • 828px x 1792px
• iPhone 6, 6s, 7, 8, SE(2nd)
  • 750px x 1334px

壁紙設定時の画像トリミング機能は大変そうだったので実装していない。
上記のサイズにマッチしない場合、画像は縦横比が維持された状態で画面内に収まるようになっている。
壁紙は単色カラーと画像両方が指定可能なので、画像余白の色も自由に設定できる。

こちらが当時の設定画面とカスタマイズ例だ。

設定画面	カスタマイズ例

壁紙設定機能の実装時に 面白そうだから という理由で私は以下 2 つの画面を実装した。

Colors	RGB

左はこちらが用意した特定のカラーを選択する画面。
右は RGB（Red, Green, Blue）の値を変更し、ユーザーが独自のカラーを作成する画面だ。

わざわざ単色カラーを設定する人などほとんどいないだろうと思いつつも、技術的にトライしたかったのでやってみた。
なお Just Quick Search ではアプリサイズをできる限り小さくしたいためアイコン以外の画像は一切使用していない。
（威張ることではないが）左の画面のカラーアイコンはすべてプログラムで描画している。
このように 要望があったのですぐ対応 や 自分がやりたいことを実装する を実現できるのが個人開発ならではの醍醐味である。

Ver.1.4

リリース日：2012/03/31

リリースノート

• Sleipnir 連携機能の実装

Sleipnir 連携機能の実装

Google, Wikipedia の検索結果を Safari だけではなく Sleipnir でも開けるようにした。
かなり人気のウェブブラウザであり、更に連携すると制作元フェンリルのホームページにてアプリを紹介してもらえるということで実装してみた。

Use Sleipnir が ON の時だけ検索結果が Sleipnir で開く仕様にした。
強制ではなくあくまでユーザーに 選択させる というポリシーは今なお持ち続けている。

Sleipnir 連携機能の効果は上々だった。
こちらも根強いファンがいるようで、特定の人の心を掴むことができた。

Ver.1.5

リリース日：2012/04/06

リリースノート

• ホームページ表示機能の実装

ホームページ表示機能の実装

Just Quick Search におけるホームページを設定し、素早くそのページを開けるようにした。
ユーザーは設定画面にて任意の URL を登録しておけば、入力欄が空の状態で検索を実行するとそのページが表示されるという仕様である。

設定画面	発動条件

私は居住地域の天気予報ページを登録している。
キーワードに日本語が含まれる場合は URL エンコードを行う必要があり、札幌 天気 の検索ページを表示したいのであれば URL は以下になる。

https://www.google.co.jp/search?q=%E6%9C%AD%E5%B9%8C%20%E5%A4%A9%E6%B0%97

Ver.1.6

リリース日：2012/04/17

リリースノート

• ペーストボタンの実装

ペーストボタンの実装

検索画面に 1 つのボタンを追加した。
クリップボードに保存されている文字列を貼り付けるためのボタンだ。
Safari で調べ物をしている時に気になる用語を発見し、コピーして再び本アプリで検索をかけようとした場合などに有効なボタンとなる。

設定画面の Paste Button を ON にすると、検索画面に P ボタンが表示される。
このボタンを押すことでユーザーは画面を長押しすることなく簡単にペースト作業が行えるというものである。

設定画面	検索画面

本機能はあるユーザーからのリクエストで取り入れたものだ。
このユーザーさんはサポートページの SuppApp で初めて アイディア を投稿してくれた方だ。
何度かやり取りをさせていただいたが、この方のコメントはとても嬉しかったことを覚えている。
今でもこのアプリを使ってくれているのだろうか。

AppBank による再フィーチャー

AppBank Network 公式リリース後、私のアプリは再びサイト内で取り上げられた。
そのおかげで（たしか）AppBank Network 導入アプリを対象とする独自ランキングで 1 位を獲得することができた。

これによって 200 ~ 300 のダウンロード数が 1 週間ほど続いた。

順風満帆だった。
Ver.1.0 以降 Apple によるリジェクトもなく、徐々にアプリも認知されてきた。
モチベーションも上がり、新機能のアイディアもこれまで以上に湧いていた。
次はどんな実装をしようかなぁ。

不穏な動き

Ver.1.7 の審査はいつもと様子が違っていた。

2012/04/17、Ver.1.6 がリリースできたのでさっそく次のバージョンの審査出しを行った。
この頃は審査提出からレビューまで 1 週間ほどあったので、その期間で出たアイディアはすぐに実装していた。
よって、審査が通ったタイミングですぐに次のバージョンを審査に出していたのだ。

2012/04/24、レビュアーからフィードバックあり。

Your app requires additional review time

なんだこれは・・・

ものすごく怖かった。
2 日経ってもステータスは変わらなかった。
たまらず私は自ら Ver.1.7 の申請を取り下げた。

なにかの間違えかもしれない。
もう一度審査に出せばいつも通り上手くいくはずだ。
私は再度 Ver.1.7 を提出した。

2012/05/03、レビュアーからフィードバックあり。

Your app requires additional review time

変わらなかった。
それと同時にメールも届いた。

（訳）連絡したいことがあるので電話番号を教えてください

怖っ！
ワタシハデンワシタクナイ

しかし、ここまでされたらもう従うしかない。
しぶしぶ電話番号を伝えて待機した。

1 週間放置された。

2012/05/11、私はメールを送った。

（訳）電話してくれ

あれだけ電話するのが怖かったのに 1 週間待たされると電話が待ち遠しくなった。
人間は不思議な生き物である。

2012/05/16、昼頃 Apple から電話がかかってきた。
外国人だとは思うが、日本語の上手な人だった。

曰く

• あなたのアプリは iOS の内蔵辞書機能を利用している
• Apple と辞書提供会社との契約により、メインの機能として使うことは避けてほしい

とのこと。

参ったなぁ。
これは以下の検索機能を削りなさいという通達だった。（見づらくてごめんなさい。この画像しかありませんでした）

転機

内蔵辞書検索に代わる機能を実装する必要があった。
単純に機能を削除するだけ（デグレード）という選択肢は私にはなかった。

項目 4.2 のリジェクトに比べれば屁でもない。
やることは明確で、新たな機能を考えて実装すればいいだけなのだから。
そもそもプログラマーはそれを考えるのが楽しいのだ。

閃いた。

検索対象をユーザーに決めさせよう。
少し難易度は高いが自由度は上がる。

これまではアプリ側ですべての検索対象とその URL を固定していた。
Google 検索だと以下の通りである。

https://www.google.co.jp/search?q=<入力された文字列>

この https://www.google.co.jp/search?q= までをユーザーが自由に決められるようにした。
Google ではなく Yahoo! で検索がしたい人は https://search.yahoo.co.jp/search?p= を設定できるように。

またこの頃は Sleipnir が実装していたように アプリ連携 も流行っていた。
あるアプリから他のアプリを起動する仕組みだ。
これを実現するためには開かれるアプリ側で カスタム URL スキーム という文字列を設定する必要がある。
Sleipnir の場合は sleipnir がそれに該当する。（複数設定も可）

以下の URL を設定すれば Google の検索結果が Sleipnir で 表示できるというわけだ。

sleipnir://www.google.co.jp/search?q=<入力された文字列>

一度追い詰められることにより、以前よりも拡張性の高い機能が生まれることとなった。

Ver.1.7

リリース日：2012/06/01

Ver.1.6 からは 1 ヶ月半ほど期間が空いてしまったが、無事にリリースすることができた。
審査に出してレビューを待っている間に新機能を思い付き、実装を完了させて我慢ができずに 一度取り下げて再提出 というムーブを 4 回ほどキメていた。
Just Quick Search 史上最多の機能追加バージョンだった。

リリースノート

• カスタム検索機能の実装
• Wikipanion 連携機能の実装
• バックワード/フォワードボタンの実装
• オートコピー機能の実装
• Twitter トレンド表示機能の実装
• サポートページの実装
• カスタム URL スキームの実装
• 内蔵辞書検索機能の削除

カスタム検索機能の実装

国語 / 英和 と 和英 / 英英 辞書検索に代わる新たな機能、ユーザーが独自に検索対象を設定できる カスタム検索機能 の誕生だ。
この時点で検索対象は以下 5 つとなった。

• Google
• Wikipedia
• マップ
• Custom 1
• Custom 2

ユーザーは設定画面にて 2 つのカスタム検索の タイトル と URL を自由に設定できるようになった。
比較的上級者向けの機能だ。
URL のうち、キーワードが代入される部分は _._ で表現することにした。
特に意味はない。
強いて言えばキーボードでそれぞれの記号が近くにあってタップしやすかったからだ。

翻訳サイトの DeepL で英語を日本語に翻訳したい場合は https://www.deepl.com/translator#en/ja/_._ を設定すればいいし、YouTube アプリで動画を検索したい場合は youtube:///results?q=_._ と設定する。
このようにユーザーの希望に合わせてあらゆる検索が可能となった。

設定画面	カスタム検索設定画面

個別の設定画面	検索対象選択画面

また、これに合わせて検索対象の並び替え機能も実装した。
組み込みの検索 Google, Wikipedia を含め、検索対象を自由に並び替えることができる。

設定画面	ソート画面

並び替え中	検索対象選択画面

ソート対象の項目が画面内に収まる場合、テーブルビュー自体は上下にスクロールしないように実装した。
項目右側の並び替えアイコンをドラッグした時、たびたびアイテムではなく画面全体が動いてしまうことがあったからだ。
少しでも操作しやすくするための私のこだわりである。

拡張性の高い便利な機能が追加された。
しかし、ユーザーは自分の希望する URL を自力で発見しなければならない。
場合によっては目的のアプリのカスタム URL スキームを調査する必要もある。
分かる人にとっては良いかもしれないが、ライトユーザーお断り的な機能である。
ここを境に、最初の シンプルなアプリ からは徐々に離れていってしまったと思う。

私はある機能に特化したシンプルなアプリを作りたかった。
だが、シンプルすぎると 機能が少ない という理由でリジェクトされてしまうのだ。
このジレンマはきっと多くの開発者を泣かせてきたことだろう。

Wikipanion 連携機能の実装

Sleipnir 同様、Wikipanion という Wikipedia 閲覧アプリとの連携機能を実装した。
Use Wikipanion が ON の時だけ Wikipedia の検索結果が Wikipanion で開く仕様だ。
私が Wikipanion を使っていたため実装した機能である。

バックワード/フォワードボタンの実装

ペーストボタンと同様、検索画面に 2 つのボタンを追加した。
設定画面の Backward Button、Forward Button を ON にすると、検索画面に B、F ボタンがそれぞれ表示される。

設定画面	検索画面

入力欄にテキストがある場合 B ボタンタップで 1 文字後方（Backward）に、F ボタンタップで 1 文字前方（Forward）にカーソルが移動する。
この時はタップでしか移動できなかったが、のちのアップデートにより現在では長押しにも対応している。

最近の iOS では space キー長押しでカーソル移動モードになるため、これらのボタンの効果は薄れている。
しかし 長押しする時間も待てない というせっかちな人のためには良い機能ではないだろうか。

オートコピー機能の実装

クリップボードに関する機能、第 2 弾だ。
いつものように設定画面から有効化することで、検索を実行した際のキーワードを自動でコピー できるようになる。

Ver.1.6 でリリースしたペーストボタンと組み合わせることで、Google で検索した後に「Wikipedia でも検索したい」となった場合に P ボタンをタップするだけで直前に検索したキーワードを入力できてしまう。
履歴からキーワード選択することもできるが、そのワンアクションすら無くすための機能である。

Twitter トレンド表示機能の実装

私のお気に入り機能だ。
リアルタイムの Twitter トレンドを画面上部に表示する機能である。

当時の iOS バージョンは 5 であり、この iOS 5 には Twitter.framework というフレームワークが存在した。
これを利用することで Twitter に関する操作を実行できるようになる。
ユーザーは iOS の設定アプリから Twitter にログインし、その認証情報の使用許可を得たアプリは自身のアプリ内で Twitter の API を叩けるのだ。
私は trends/place API を利用し、この機能を実装した。

設定画面	検索対象選択画面

現在は設定画面で Twitter Trends を ON にすると認証画面が表示される。
そこでログインを実行することで本機能が利用可能となる。
ツイート内容やフォロワーなどのデータは扱っていないため、捨て垢でログインしても問題はない。

表示されているアイテムをタップするとそのキーワードの検索結果が Twitter で表示されるという動きだ。
Exclude Hashtags を ON にするとハッシュタグ（# 付き）のツイートが非表示になる。
また Display Area で表示場所を変更することもできる。
ただし、表示場所を変更するためには 広告非表示アドオン を購入しなければならない。
オススメはもちろん検索画面上部への配置だ。
アプリの起動/再開と同時にその時のトレンドがチェックできるため、Twitter のトレンドチェッカーとしても優秀なアプリとなる。

現在の trends/place API のレートリミットは 75 requests / 15 min である。（昔は 15 requests / 5 min だった気がする）
15 分の間に「アプリを立ち上げてバックグラウンドに回す」を 75 回繰り返さない限りトレンドは正常に取得できるので、通常の使い方では上限に引っかかることはないだろう。

金曜の夜はだいたいその日の金曜ロードショーで何を放送するか（しているか）がわかるし、日曜の午後には競馬情報が目に付くようになる。
私は起床後必ず Just Quick Search を立ち上げて Twitter のトレンドをチェックしている。
閲覧した回数はもしかしたら検索を実行した回数より多いかもしれない。
非常にお気に入りの機能である。

サポートページの実装

設定画面からサポートページ（SuppApp）に飛べるようにした。
これによって以前に比べて明らかにユーザーから問い合わせや機能追加の要望コメントが多く届くようになった。
App Store のプロダクト画面でも App サポート というリンクは用意されているのだが、そこまで到達できるユーザーは少ないのだろう。

Just Quick Search 設定画面	App Store プロダクト画面

今ではアプリ内のリンク先は Just Quick Search の Twitter アカウント となっている。

カスタム URL スキームの実装

Sleipnir や Wikipanion に倣って Just Quick Search もカスタム URL スキームを実装することにした。
他のアプリからこのアプリを起動したり、それ以上の処理を行うための機能である。
今の知名度では他のアプリから呼び出されることなど無いかもしれないが、そういう入り口を用意しておくことは重要である。

設定したカスタム URL スキーム名は justquicksearch。
長いって！

実装した内容は以下 2 つ。

• justquicksearch://
  • 本アプリを起動する
• justquicksearch://"キーワード"
  • 本アプリを起動し、入力欄に "キーワード" を自動入力する

かなり学びになった記憶がある。
アプリ連携や URL 関連は技術的に面白かった。

内蔵辞書検索機能の削除

Ver.1.0 から共に戦ってきた機能に別れを告げる時が来た。
非常に残念だ。
だが、おかげで Just Quick Search は新たな形に生まれ変わることができた。
ありがとう。

Ver.1.8

リリース日：2012/06/15

リリースノート

• マップ検索機能の削除
• ホームページ表示機能の仕様変更
• Tweetbot 連携機能の実装
• クリップボード監視機能の実装
• オートサーチ機能の実装

マップ検索機能の削除

Ver.1.2 で実装したマップ検索機能を削除した。
これにより本アプリの検索対象は以下 5 つとなった。

• Google
• Wikipedia
• Custom 1
• Custom 2
• Custom 3

これまで通りマップ検索を実行したい場合はカスタム検索の URL に comgooglemaps://?q=_._ を指定すればいいし、マップ検索を使わないユーザーにとってはカスタマイズできる項目 1 つが増えたということになる。

ホームページ表示機能の仕様変更

Ver.1.5 で実装したホームページの URL について改良を加えた。
これまでは http または https で始まる URL しか許容していなかったが、その制約を取り除いた。
これによって外部アプリのカスタム URL スキームから始まる URL も設定できるようになり自由度が上がった。

札幌 天気 の結果を Sleipnir で開きたい場合は次のように設定すればよい。

sleipnir://www.google.co.jp/search?q=%E6%9C%AD%E5%B9%8C%20%E5%A4%A9%E6%B0%97

単純にアプリのカスタム URL スキームを指定することでアプリランチャー的な使い方も可能だ。
以下の例だと、Just Quick Search を起動してすぐに search ボタンをタップすれば YouTube アプリが起動する。

youtube://

Tweetbot 連携機能の実装

Sleipnir や Wikipanion 同様、Tweetbot という Twitter のクライアントアプリとの連携機能を実装した。
Use Tweetbot が ON の時だけ Twitter トレンドのアイテムをタップした時の検索結果が Tweetbot で開く仕様だ。
これまた私が Tweetbot を使っていたため実装した機能である。

クリップボード監視機能の実装

こちらは UIApplication クラスの beginBackgroundTaskWithExpirationHandler: というメソッドを利用した機能だ。
このメソッドを利用すればアプリをバックグラウンドに回しても、最大で 10 分間はアプリ内での処理を継続して実行できる。
これを利用してクリップボードの監視を行った。

クリップボードに新たな文字列がコピーされた場合はその文字列が通知される。
通知をタップすると、その文字列が入力された状態で Just Quick Search が起動するという動きだ。

文字列をコピー	通知が届く	通知タップでアプリが起動する

Safari やその他の別アプリで文字列をコピーし、通知をタップすることで瞬時に Just Quick Search に戻り、その文字列を検索することができるようになった。

残念ながらこの機能は今はもうなくなっている。
正確には思い出せないが、iOS 7 くらいからバックグラウンド処理の制約が厳しくなり、このような処理は実行できなくなってしまったのだ。

オートサーチ機能の実装

外部のアプリから検索文字列付きで Just Quick Search が起動された際に自動で検索を実行する機能だ。
この機能を ON にするとユーザーはキーボードの search ボタンタップが不要となる。

上記のクリップボード監視機能を例に取ると、通知をタップして本アプリが起動した後、自動で Safari が立ち上がり Just の検索結果が表示されるという動きである。
アプリの切り替えは激しいが、ユーザーのアクションは少なくなる。

1. Safari で文字列 abc をコピー
2. 通知をタップ
3. abc が入力された状態で Just Quick Search が起動する
4. すぐに検索が実行され abc の検索結果が Safari で表示される

クリップボード監視機能はもう存在しないため、現在は以下のようなカスタム URL スキームからの起動時にのみ有効となる機能だ。

• justquicksearch://abc

ランクイン

AppBank Network の管理画面を見ていたら、突然広告のインプレッション数（表示回数）が跳ね上がった。
急速にダウンロードされ始めたのだ。
原因を探ってみたところ 1 つの記事 に辿り着いた。

どうやらここではクリップボード監視機能が取り上げられており、多くの人がそれに食いついたようだ。
記事には次の一文が書かれている。

このアプリを起動すると検索フォームがポツンとあるだけ。しかしこのアプリの本来の機能はこれではないのだ。

いいえ、違います。
それが本来の機能です。

意外だった。
私としては技術的に面白そうで実装した おまけ機能 が理由でダウンロード数が伸びていったのだ。
実際私はほとんどこの機能を使っていなかった。
しかしユニークな機能ではあったのだろう。
それ故、記事にもしやすかったんだと思う。
やはり地味なアプリはアピールしづらい。
本記事のように長くなってしまうからねぇ。

なにはともあれ、ダウンロード数が増えたのは嬉しかった。
嬉しかったどころではない。
当時はヤバいくらい脳汁が出ていた。
App Store を開き直すたびにランキングが上がっていったのだ。

まさに桃源郷。
なんという僥倖。
神様・・・ありがとうございます！

最終的にその日のダウンロード数は 約 1,100、ランキングはユーティリティカテゴリで 10 位以内、無料総合で 100 位ちょい だったと思う。
Just Quick Search 史上最高のランクとなった。

画像データを消失してしまったことが悔やまれる。
これ以降、iPhone のキャプチャ画像は少なめである。

夢のような一日だった。
私はこれまで仕事で iOS アプリをリリースし、何度かランキング 1 位を獲得したことはあるが、これほどまでに興奮したことはなかった。
やはり Just Quick Search は私にとって特別だったのだ。

Ver.1.9

リリース日：2012/07/03

リリースノート

• オートリターン機能の実装

オートリターン機能の実装

検索対象をタップした時に自動で左画面（検索画面）に戻る機能だ。
検索対象を選んだ後、自分でスワイプするのが面倒だったので付けてみた。

検索対象（ここでは Wikipedia）をタップすると勝手に画面が移動する。

こちらもお気に入りの機能だ。

Ver.2.0

リリース日：2012/08/10

リリースノート

• アプリアイコンの変更
• 広告削除機能の実装

アプリアイコンの変更

ユーザーから最も要望の多かったアプリアイコンの変更を実施した。
いいアイディアが湧いてきたのだ。
なんとなく アイコンを変える時はメジャーバージョンを上げたい という想いがあったため、アプリバージョンも 1 系から 2 系に更新した。
それまでのアイコンに対するコメントは以下の通り。

きっとみんなも気に入ってくれる。
そう思った。

これが Ver.2.0 のアプリアイコンだ。

ダメだった。
気に入ってもらえなかった。

フォントを変更し、速 の字をかっこよくしてみた。
明らかに Ver.1.0 のそれよりクオリティは上がっているはずだ。
だがどうやらユーザーが求めていたものはそうではなかったようだ。
それどころか人によってはむしろ 改悪 とまで感じた人もいたようだ。

万人受けするデザインを考えるというのはとても難しい。

変わったばっかりなんですけど！？

ただこれらのレビューコメントは開発者に対しては効果的である。
高評価を付けた上で要望を書くと、作り手は嬉しくなり よし、やってみようかな という気持ちになるものだ。
アイコンがダサいので ☆-1 というユーザーもアイコンを変えることで評価を上げてくれるかもしれないという希望が持てる。

逆に低評価で「アイコンがダサい」など一言だけ書かれるとやる気は全く起きない。
その人のために頑張ろうという気持ちにはならないし、対応したところでその人が評価を上げてくれる保証は無いからだ。

これはアプリをレビューする際の極めて重要な要素として覚えておいていただきたい。
開発者は人間である。
高評価や良いコメントを貰えれば嬉しくなるし、低評価や酷いコメントを見た時は悲しくもなる。
さらに開発者は自身のプロダクトに対するレビューコメントには必ず目を通す。
あなたのコメントはそのアプリの作者に届くのだ。
よってレビューコメントを書く際はその場の勢いだけではなくじっくり内容を考えて、開発者が嬉しくなり要望にも対応したくなるようなものを送信してもらえるとありがたい。
良いアプリは開発者からの一方通行ではなく、ユーザーからのフィードバックにより作られていくのだ。

広告削除機能の実装

こちらもリリース当初から要望の多かった機能の実装となる。
検索画面上部に表示される広告を非表示にできる機能だ。
非表示にするためにはユーザーは 広告非表示アドオン を購入しなければならない。
StoreKit というフレームワークを利用して App 内課金 の処理を実装した。

設定画面	広告設定画面

当時の広告非表示アドオンの価格相場は Tier 1 と呼ばれる最低ランクの価格帯、日本円では ¥85 だった。
現在は為替の影響で Tier 1 は ¥120 である。
Just Quick Search もこの価格でアドオンを提供することにした。（今は Tier 3 の ¥370）

私はこの機能は実装したくなかった。
お金が関わる機能のためミスが許されず、バグを埋め込んでしまった場合のインパクトが計り知れないからだ。
さらにこの頃 iTunes Connect には現在の「アナリティクス」という以下のページは存在しなかった。
AppBank Network の管理画面では広告の表示回数やタップ回数が時間単位で確認できたが、広告が表示されないとなるとそれらのデータも確認できなくなってしまう。
これはアプリがどれだけ使われているかが把握できなくなるということである。

苦労して機能実装しても購入価格が低いので、仮に多くの人がアドオンを購入しても私にとってはメリットが少なかった。
結果も振るわず、リリースから 2 ヶ月間の購入回数は 89。

売上は 89 x ¥85 の ¥7,565、このうち開発者の取り分は 60%（現在は 70%）の ¥4,539 となる。
まったくもって割に合わなかったが、アプリ内課金のプログラミングスキルを習得できたのでヨシとしよう。

ここで得た知見としては、リストア機能が無いアプリ内課金はリジェクト対象 ということである。

アプリ内課金のプロダクトタイプは以下 4 つに分類される。

• 消耗型
• 非消耗型
• 自動更新サブスクリプション
• 非更新サブスクリプション

消耗型のわかりやすい例はソシャゲの 石 であり、ユーザーは魔法石やジェムというプロダクトを購入しそれを使用してガチャを回すことができる。
非消耗型は一度購入するとその後は無期限で利用できるものであり、本アプリの広告非表示アドオンはこれに該当する。
自動更新サブスクリプションはサービスまたはコンテンツへのアクセスを提供するものであり、ユーザーがキャンセルするまで定期的に自動更新される。
非更新サブスクリプションは期間限定で自動更新は行われない。

これらのプロダクトをアプリ内課金としてリリースする場合、アプリはユーザーのすべての iOS デバイスでこれらのプロダクトを利用できるようにする必要があるため、同時にリストア（復元）機能も実装しないといけないのである。（消耗型のみの場合は不明）
App Store Review ガイドライン では以下の規約に該当すると思われる。

返還可能なApp内課金を導入する場合は返還のメカニズムを実装する必要があります。

なお非消耗型プロダクトで一度購入済みの場合、リストアボタンからではなく購入ボタンから再度処理を実施してしまっても二重課金されることはない。
以前購入済みです という旨のメッセージが表示され無料でプロダクトを入手できるのでご安心を。

4 インチデバイスの登場

2012/09/21、iPhone 5 が発売された。
開発者にとっては大きなニュースだ。
なぜなら iPhone 5 はこれまでのデバイスとディスプレイのサイズが異なるからだ。

iPhone 3G, 3GS, 4, 4S はディスプレイのサイズが同じで、横 320pt, 縦 480pt という仕様だった。
1 つの画面を作成すればすべてのデバイスで同じように表示されるため、開発者の負担は少なかった。
iPhone 5 のディスプレイサイズは 横 320pt, 縦 568pt。
縦方向に 88pt 長くなっている。

開発者はこの画面サイズにも対応しなければならなく、さらに今後出てくるであろうあらゆるサイズに適応できる柔軟な画面デザインが求められることになった。
なおこの頃の iPhone 5 のディスプレイサイズに対応していないアプリは画面の上下に 44pt の 黒帯 が表示されるという不思議な見た目となり、ひと目で対応している/していないが判別できた。

Ver.2.1

リリース日：2012/11/22

リリースノート

• オープン URL 機能の実装
• iPhone 5 対応

オープン URL 機能の実装

http:// または https:// から始まる URL を検索した場合、現在選択中の検索対象に関わらずその URL を直接開くという機能を実装した。
それまではその URL の検索結果を Google で開いてしまい、URL のページを開くまでのアクションが 1 つ余計だったからだ。（たいてい検索結果の最上部にヒットする）

さらにスキームを指定することで http 部分をそのスキームに差し替えることもできるようにした。
主にブラウザアプリになるが、http の部分をそのアプリのカスタム URL スキームに置き換えるだけで URL をそのアプリで開くという動きになることが多かったからだ。
例えばスキーム（with Scheme）に googlechrome を指定して https://dev.classmethod.jp を検索した場合、Just Quick Search は googlechromes://dev.classmethod.jp の URL を開こうとするため、Chrome アプリにて DevelopersIO のページが表示されるようになる。

iPhone 5 対応

がんばって対応した。
あまり詳しくは覚えていないが、この時は iOS の Auto Layout という技術は使わずに力技で無理やりねじ込んだ気がする。

縦に増えた画面領域も有効活用し、4 インチデバイスの場合はカスタム検索は 5 つ、3.5 インチデバイスの場合は従来通り 3 つ という仕様にした。

この時点の検索対象は以下の通り。

4 インチデバイス

• Google
• Wikipedia
• Custom 1
• Custom 2
• Custom 3
• Custom 4
• Custom 5

3.5 インチデバイス

• Google
• Wikipedia
• Custom 1
• Custom 2
• Custom 3

悪夢再び

2013/01/11、Ver.2.2 を審査に提出した。
2013/01/17、レビュアーからフィードバックあり。

結果は Reject

4.2
We found that the usefulness of your app is limited by the minimal amount of content or features it includes.

最悪だ。
Just Quick Search は再び「役に立たないアプリ」と見なされてしまった。
それからは何度提出し直しても同じ理由でリジェクトされた。

地獄のような日々が続いた。
アプリのリジェクト理由は App Store Connect の Resolution Center というところに記録される。
仮にレビュアーが変わったとしても、次のレビュアーは（おそらく）その記録を確認し、なぜこのアプリがリジェクトされたのかをチェックしているのだろう。
それ故、一度「役に立たない」というレッテルを貼られると次のレビュアーも先入観を植え付けられ、再度リジェクトとなる可能性が極めて高くなる気がする。
ひどい話だ。

このバージョンでリジェクトを受けた回数は合計 7 回。

2013 年の 9 月、iPhone 史上最大のデザイン変更である iOS 7 がリリースされた。
フラットデザイン が採用されたタイミングだ。

私のアプリはまだアップデートできない。

iOS のフレームワークの変更により Twitter のトレンドが表示できなくなった。

しかしバグ修正版をリリースすることはできない。

2013 年の 11 月、ようやく Ver.2.2 がリリースできた。
だが私のモチベーションは高くはなかった。
Just Quick Search は常にリジェクト項目 4.2 と隣合わせなのだ。
アプリを審査に提出するのが怖くなった。

それ以降の私は頻繁なアップデートは避け、必要な時以外は極力アプリを審査に出さないようになっていった。

Ver.2.2

リリース日：2013/11/14

約 1 年ぶりのリリースだった。

リリースノート

• iOS 7 に最適化
• B/F ボタンの長押しに対応
• Twitter トレンド表示機能の復活
• ページコントロール非表示機能の実装

iOS 7 に最適化

Just Quick Search もフラットデザインに対応した。
といってもこのアプリは基本的に iOS が提供している UIKit をカスタマイズすることなくほぼそのまま利用している。
よってそれほど多くの作業があったわけではなかったと思う。

3.5 インチディスプレイ

左画面	右画面

4 インチディスプレイ

左画面	右画面

B/F ボタンの長押しに対応

Ver.1.7 で実装したバックワード/フォワードボタンの長押しに対応した。
これでより簡単にテキストカーソルを前後に移動できるようになった。

Twitter トレンド表示機能の復活

これまでは Twitter.framework というフレームワークで実装していたが、iOS 6 からは Facebook と Weibo が追加された Social.framework というものに置き換わった。
これによりプログラムも変更しなければならず、Twitter トレンドが表示できていなかったというわけだ。

Twitter に関しては結構振り回されることが多い。
だが Twitter トレンド表示機能を一度味わってしまった私はこのサービスを手放すことは難しい。

なお iOS 11 リリースのタイミングで、この Social.framework も廃止される。

ページコントロール非表示機能の実装

こちらもユーザーの要望による追加機能だ。
iOS では複数のページが左右に存在する場合、UIPageControl というコンポーネントを利用してユーザーにページが存在することをアピールできる。
このアプリにおいては検索画面中央の画面上部に配置している白い丸印だ。

お気に入りの画像を壁紙として設定しており、よりキレイに表示したいため丸印をなくしてほしいとのことだった。
ユーザーの意見を受け止め、自分でもいい機能だと思ったので実装した。

このようにアイディアをいただいた場合は 自分が欲しい機能かどうか を考え、実装する/しないを決めていった。
〜してほしいと要望を受けても「それは自分のポリシーに反するためやるつもりはない。ごめんなさい」と伝えることも多かった。
そのように正直に伝えることでユーザーも納得し応援してくれた。

設定画面	検索画面

iPad 版のリリース

2014/01/24、Just Quick Search の iPad 版アプリ Just Quick Search HD をリリースした。

iPhone 版アプリを iPad に移植する場合、当時は HD (High Definition) をサフィックスとして付けることが多かったため私もそれにあやかった。
これはまぁいいでしょう。
for iPad みたいな長い名称にしなくてよかったと思う。

当時の会社で iPad アプリを開発していたこともあり、勉強がてら個人でも作ってみることにした。
基本的な UI は iPhone 版に寄せ、機能もほぼ同じになるよう作り込んだ。
iPhone 版は縦方向のみのサポートだが、iPad 版はその特性を活かしてすべての向きをサポートしている。

検索画面	検索対象選択画面

キーボード非表示	設定画面

ただこちらは有料アプリとし、当時の価格で ¥500 くらい（正確な金額は忘れた） でリリースした。
無料アプリの iPhone 版と差別化を図ったのが カスタム検索の数 だ。
iPhone 版は多くて 5 つだったが、iPad 版では 無制限 とした。

これまで Just Quick Search 内における設定値の永続化は NSUserDefaults というクラスを利用して行っていた。
あくまで限られた数の固定化されている要素だったため、この手法で事足りたのだ。
しかしカスタム検索は動的であり、どのような要素にも対応する必要がある。
ここで私が採用したのが Core Data と呼ばれる Apple が提供するフレームワークだった。

大変だった。
Core Data は難しい。
しかし諸々ラッピングされている外部のライブラリを使うつもりはなかった。
私は基礎の部分を学びたかったし、iOS 以外のライブラリを使用するとアプリサイズも増えてしまうのだ。

最終的にはうまくいった。
この時のデータベース設計や実装がきっちりハマった時の喜びはすごかった。
やっぱり楽しかったから続けられたんだと思う。
カスタム検索の無制限化はのちに iPhone 版に逆輸入されることになる。

肝心のダウンロード数はまさに「雀の涙」であり、リリースから約 3 ヶ月で 20 ダウンロードに満たなかった。
有料アプリは無料アプリに比べ、遥かにダウンロードされにくいのである。
その後も Just Quick Search HD はダウンロード数が跳ねることはなかった。

「iPad アプリだから」なのか「有料アプリだから」なのかはわからないが、iPad 版の Just Quick Search が審査でリジェクトされることはほとんどなかった。
10 回以上審査に出したが、リジェクトされたのは 1 回だけ。
理由は ストア用スクリーンショットの壁紙にダース・ベイダーの画像は使っちゃダメ だった。
私は素直に従い、その場は事なきを得た。

Just Quick Search HD はリリース 10 周年を記念して、通常価格 ¥610 のところを本日より 無料 で配信中だ。
iPad をお持ちの方はこの機会にぜひダウンロードしていただきたい。

Ver.2.3

リリース日：2015/04/01

リリースノート

• iOS 8 対応
• iPhone 6 / iPhone 6 Plus に最適化
• カスタム検索の追加/削除機能の実装

iOS 8 対応

最新の Xcode でビルドし、iOS 8 でも問題なく動くことを確認した。
正直、何をやったかは忘れた。

iPhone 6 / iPhone 6 Plus に最適化

新たに発売されたデバイスのディスプレイサイズに対応した。
これらのデバイスは縦方向だけではなく横方向にもサイズアップしていたため、もう Auto Layout を使わずに画面のレイアウトを維持するのは不可能だった。

私は UIKit の Container View と Auto Layout を組み合わせ、これまで通りのレイアウトを実現した。

3.5 インチ	4 インチ	4.7 インチ	5.5 インチ

カスタム検索の追加/削除機能の実装

iPad 版で先行実装していた機能を iPhone 版にインポートした。
これによりユーザーは好きなだけカスタム検索を追加できるようになった。

もうひとつ

実はこのバージョンではリリースノートに載せていない重大な更新がかかっていた。
2014 年に発表された Apple の新プログラミング言語 Swift によるソースコードの書き直しだ。

それまで Just Quick Search は Objective-C という言語でプログラムを記述していたが、こちらも学習がてら Swift で作り直してみることにした。
勉強にはなったが、私は Swift をあまり好きにはなれなかった。
Optional の概念がいまいち肌に合わなかったのである。（未だによくわからん）
そもそも Objective-C で全く問題なかったし、null 安全にしなくてもこっちで勝手にガードするからいいよというスタンスだった。

その上この頃の Swift バージョンは 1.1 か 1.2 であり、まだまだプログラミング言語として不安定な状態だった。
アップデートがかかればビルドエラーが発生し、多くの箇所を修正しなければならなくメンテナンス性が低かったのだ。
さらに不安定ゆえにアプリは iOS 内の Swift ライブラリではなく、ビルド時に Swift ライブラリをアプリに組み込んでそれを使用するという挙動になっていた。
結果、アプリサイズは Swift ライブラリ分の 約 20 MB ほど増量してしまっていたのだ。

この仕様に私は耐えられなかった。
約 1 年後のアップデートで Just Quick Search のプログラミング言語は再び Objective-C に戻ることになった。

私は Objective-C が好きだった。

突然の配信停止

Ver.2.3 をリリースしてから 1 週間後の 2015/04/08、Just Quick Search は App Store から姿を消した。
Apple のレビュアーによってストアから削除されてしまったのだ。
どういうフローでそうなったかはわからないが、リジェクト理由はいつもの 4.2 だった。
レビュー時だけではなく、ストアに公開されている間もこんなことが起こるのか。
酷く絶望したことを覚えている。

レビュー用動画の作成

私は Ver.2.3 の審査が通った 2015/04/01 の時点で Ver.2.4 を提出していた。
ストアの復活はこいつにかけるしかない。
祈る気持ちでレビューを待った。

結果は Reject

4.2
We found that the usefulness of your app is limited by the minimal amount of content or features it includes.

いつものやつだ。
もう疲れた。

しかし 今まであった自分のアプリが App Store に存在しない という状況はとても辛かった。
自分の努力の集大成が無かったことにされているのだ。
私は削除された Just Quick Search を取り戻す方法を深く考えた。

・・・そこで気が付いた。
審査が開始してからリジェクトまでが早すぎる。
6:03 にレビューが始まったが、6:14 にはリジェクトされていた。
おそらくこのレビュアーはアプリの説明文を読んでいない。
そう思った。

そこから私は約 6 分にわたる レビュー用の動画 を作成した。
本記事の冒頭で紹介したものだ。
この動画を添えて改めてレビューを申請した。

結果は Accept

よかった。
Just Quick Search は再び App Store に姿を現した。

Apple のレビュアーは必ずしもアプリの説明文を読んでくれるとは限らない。
仮に読んだとしてもその内容が伝わらないこともある。
その結果、単純なアプリと誤解されてリジェクト対象になる場合があるということだ。
今回のように 動画を用意し、動いているものを見せる ことは有効なアピール方法であると学んだ。

Ver.2.4

リリース日：2015/04/14

リリースノート

• 内蔵ブラウザの実装

内蔵ブラウザの実装

アプリの内部で Web ページを開けるようにした。
これまで検索結果はあくまで 別アプリ で開く仕様だったが、この機能実装により アプリ間を遷移せずに 検索できるようになった。

ブラウザの表示には iOS 8 で追加された WKWebView を採用した。
しかしこの WKWebView、なかなかの曲者であった。
App Store のリンクや target="_blank" のリンクなどは手を加えなければ表示できない仕様だったし、キャッシュ周りのコントロールも複雑だった。
カスタマイズ性は高いのだが、それゆえ面倒を見なければいけない部分が多かったのだ。

自分の画面デザインも失敗してしまった。
なるべく大きな画面で表示したかったため、画面上部のナビゲーションバーを取り除いた。
検索画面に戻る場合は 画面をダブルタップしてスワイプ という操作を行う必要があった。
マップアプリで拡大/縮小を行うあの動きだ。
まず初心者にはわからない動きだし、誤検知も多かった。
自分で使っていてもストレスのかかる機能になってしまったのだ。
さらに内蔵ブラウザ表示時はデバイスの横向きにもサポートというチャレンジングな仕様にしてしまい、その結果レイアウトが崩れるようなバグも埋め込んでしまった。
やはりそういうものは長続きせず、近いうちにこれらの機能は削除されることになる。
現在の内蔵ブラウザは WKWebView ではなく SFSafariViewController を使用している。

内蔵ブラウザを有効化する場合は検索対象選択画面にある Internal Browser のスイッチを ON にする。

検索対象選択画面	設定画面	内蔵ブラウザ設定画面

設定画面ではいくつかの項目がカスタマイズ可能だ。

Remain on the page が ON の場合、Web ページが開いている状態でバックグラウンドに回っても再開時はそのページが表示されたままとなる。
OFF の場合は検索画面が表示される。

Hide Switch が ON の場合、検索対象選択画面に Internal Browser のセルは表示されなくなる。
昔ながらの UI のままでいたい人向けの機能だ。

また、ツールバーや各種コントロールのカラーを変更することも可能となっている。

内蔵ブラウザ	内蔵ブラウザ（カラー変更）

カスタム検索またはホームページの表示で内蔵ブラウザを使用したい場合は、スキームを https から jqs に変更することで実現できる。

jqs://www.google.co.jp/search?q=iphone

以上をもって Just Quick Search の主な機能は完成した。
これ以降のアップデートは軽微な修正か、新しい iOS やデバイスサイズに対応するためのものがほとんどとなる。

韓国で人気？

2016 年の 2 月、なぜか韓国でのダウンロード数が伸びた。
短期間で 約 650 ダウンロードだ。

ハングル文字と補完の相性が良かったのか、はたまた特定のインフルエンサーが推してくれたのか。
真相は今も謎に包まれている。

Ver.2.5

リリース日：2016/04/19

リリースノート

• iOS 9 対応
• 内蔵ブラウザの作りを変更

iOS 9 対応

新しくリリースされた iOS 9 に対応した。
iOS 9 のリリース自体は 2015 年の 9 月だったため少し遅めの対応であるが、大きな変更はなかったのでアプリは問題なく動いていた（はずだ）。

内蔵ブラウザの作りを変更

Ver.2.4 で実装した内蔵ブラウザを WKWebView から SFSafariViewController に変更した。
SFSafariViewController はシンプルなウェブブラウジングを行うために利用できる iOS のフレームワークである。
WKWebView と違ってカスタマイズできる項目は少ないが、簡単に Safari ベースのインターフェイスと機能を使用することができる。
User Agent の設定やリンクをタップした時の制御などはできないが、Just Quick Search にとってはこれで十分だった。

これによってアプリ内でのウェブブラウジングはより快適になった。

ここでももうひとつ

前述のように Swift で書き直したソースコードを Objective-C で更に書き直した。
おそらくこのアプリでは Objective-C が非推奨となるまで Swift に戻ることはないだろう。

Ver.3.0

リリース日：2016/04/22

リリースノート

• アプリアイコンの変更

アプリアイコンの変更

再びアイディアが湧いてきた。
検索と言えば虫メガネ という安直な考えは Ver.1.0 の頃から避けていたのだが、虫メガネベースで考えていくつかサンプルを作成した際になかなかいいものが出来上がってしまった。
それがこちらだ。

例によって Mac の Keynote アプリを使用し、丸と直線の図形をいい具合に配置して筆のスタイルを適用した。
まるかいてちょん である。

よって歴代のアプリアイコンはこのようになった。

Ver.1.0	Ver.2.0	Ver.3.0

どうだろう。
シンプルな白黒カラーと 和 を重んじる姿勢は初めから変わっていないため、正当進化と言えるのではないだろうか。
速 の漢字の素晴らしさを世界に発信することはできなかったが、代わりにアイコンを見ただけでどのようなアプリかが推測しやすくなった（のか？）。

しかしこれだけ見ると、Ver.2.0 と Ver.3.0 の間に一体何が・・・ という感じである。

残念なことに、新しいアイコンに関する肯定的なレビューコメントは 1 件だけだった。

幸いにもこれ以降「アイコンがダサい」というコメントを見ることはなかったが、あくまで否定的なコメントが減ったというだけなのでこの時の変更が良かったのかどうかは未だにわからないままだ。

Android 版のリリース

2016/05/07、Just Quick Search の Android 版アプリをリリースした。

この頃仕事で Android 開発を始めて一息ついたため、いつものように更なるスキルアップを求めてやってみた。

検索画面	検索対象選択画面

設定画面 #1	設定画面 #2

やはり「サンプルアプリを作ってみる」よりも アプリをリリースしてみる は習得できるものが段違いだ。
今まで意識していない細かい部分も考える必要があり、ゴールが明確なため作業も実施しやすい。
オススメの学習方法だ。

しかしこの Android 版 Just Quick Search は長続きしなかった。
私が Android のスマートフォンを普段使いしていなかったため、アプリにおける悩みや改善案がなかなか出てこなかったのだ。
機能も iOS に比べてかなり少なめである。
ユーザー数も少なく、おそらく 50 ダウンロードに満たなかったため続けようというモチベーションも低かった。

よって一通り作成してアプリリリースできたことで満足し、いつかの Google のプライバシーポリシーの変更と共に Google Play ストアから姿を消し現在はそのままである。

Android 版 Just Quick Search が再びストアに姿を現す時は来るのだろうか。

Ver.3.1

リリース日：2016/09/24

リリースノート

• iOS 10 対応

iOS 10 対応

iOS 10 ではユーザーの個人情報にアクセスする際のセキュリティが厳しくなった。
各種ユーザーデータを使用する場合は使用目的を示し、ユーザーに許可してもらう必要がある。
Just Quick Search の場合は壁紙を設定する際のフォトライブラリへのアクセス時にこのダイアログが表示される。

その他は非推奨になったメソッドの置き換えであり、UI の変更などは発生しなかった。

Ver.3.2

リリース日：2017/09/20

リリースノート

• iOS 11 対応
• iPhone X に最適化

iOS 11 対応

この時の大きな変更は TwitterKit の導入だ。
iOS 11 からは Social.framework が廃止されたため、iOS の機能で Twitter の認証情報にアクセスすることはできなくなった。
Twitter のトレンド表示機能は引き続き使いたかったため、Twitter が提供する SDK を組み込んで利用した。
しかし、これによりアプリサイズが数 MB 増えてしまったのが残念だ。

iPhone X に最適化

2017 年の 10 月に発売される iPhone X に先駆けてアプリの UI を最適化した。

これでこのアプリがサポートしている画面サイズは 5 種類となった。

3.5 インチ	4 インチ	4.7 インチ	5.5 インチ	5.8 インチ

Ver.3.3

リリース日：2018/01/02

リリースノート

• レビューダイアログの実装
• 特定アプリとの連携機能を削除

レビューダイアログの実装

iOS 10.3 から利用可能な StoreKit の requestReview() というメソッドを試してみた。
このメソッドを利用するだけで簡単にアプリのレビューダイアログを表示できるというものだ。

表示は任意のタイミングに設定可能だ。
ユーザーの満足度が高いであろうタイミングで表示することで高い効果を期待できる。

このアプリの場合は 検索を 100 回実行した後 に表示するよう実装した。
効果は若干あったように思うが、そもそもアクティブユーザーが少ないため効果の測定がしにくく、レビュー数が爆増したというわけではなかった。

特定アプリとの連携機能を削除

これまで Just Quick Search の中で明示的に連携していた以下のアプリとの連携機能を削除した。

• Sleipnir
• Wikipanion
• Tweetbot

理由は主に 2 つ。
私がこれらの機能を使わなくなってきたのと、海外版との差分となるためメンテナンスが面倒になってきたからだ。
これによってソースコードと設定画面が多少スッキリした。

終戦

2019/01/14、Ver.3.4 を審査に出した。
内容は iOS 12 対応と新たなデバイスへの最適化だ。
2019/01/15、レビュアーからフィードバックあり。

結果は Reject

4.2
We found that the usefulness of your app is limited by the minimal amount of content or features it includes.

もはや恒例行事である。

その後の詳細については書けない。
書かないんじゃなく書けない。
私がギリギリ言えるのはそこまでだ。

いずれにせよ、このレビュアーとそれ以上やり取りするのは危険と感じた。
下手をすれば現在ストアでリリースされているバージョンも公開停止されそうな勢いだ。

不本意だったが私は戦うことをやめた。

こうして日本版 Just Quick Search の Ver.3.4 がリリースされることはなくなった。
しかし、これでよかったのだ。

私の戦場はここじゃない。

今、ひとつになる時

こちらも恒例の一人作戦会議の時間だ。
どのようにアプリのリリースを継続していくか。

ここで輝きを放ったのが 7 年前に苦肉の策で分裂させてしまった海外版の存在だ。
これを使わない手はない。
私は Just Quick Search の日本版と海外版を統合することにした。
日本版を App Store から自ら取り下げ、海外版の配信国に日本を含めることで、これまで海外版としてリリースしていたものを全世界版とする作戦だ。

海外版の方は日本版に比べ 4.2 でリジェクトされることがほとんどなかった。
かなり若いバージョンで 1 度あっただけで、それ以降は全く問題なく審査に通っていたのだ。
本当にこのリジェクト理由 4.2 の基準は不明瞭である。

また、これまでは 2 つのアプリを管理するということもありメンテナンスコストがかかっていた。
この頃の私の iOS スキルでは統合は難しくなかったし、むしろチャレンジしてみたい要素だったのだ。

作戦は成功だった。
Ver.3.4 は生まれ変わった状態で世にリリースされることとなった。

海外版の仕様

日本版と海外版の大きな違いは iOS で設定している 言語と地域 による表示項目の最適化である。

Google 補完の候補に出てくるキーワードや Twitter のトレンドはこれらの設定によって変化する仕様だ。
例えば iOS の言語を「日本語」、地域を「日本」として a の文字を入力した場合、候補としては amazon, ana, 明日の天気 という順で表示される。
一方 iOS の言語を「英語」、地域を「アメリカ合衆国」として a の文字を入力した場合は amazon, apple, airbnb が表示される。
Twitter のトレンドは地域のみに依存しており、その地域周辺のトレンドを自動で表示するようにしている。

当時はざっと 20 を超える主要言語と 100 以上の地域で動作確認を行い問題なく動くことを確認したが、各言語と地域で今も正常に動作しているかはわからない。
ちなみに Twitter のトレンド は Twitter の仕様により地域（woeid）を指定してもアイテムが表示されないことがあった。

日本版の Just Quick Search では常に日本向けに設定した状態だったため、言語や地域によって動作が変わるということはなかったが、海外版に統合することでこれらの影響を受けることとなった。
通常の場合であれば以前までの日本版と同様の動きとなるが、iPhone の使用言語を「英語」などに設定しているオシャレさんは Google 補完の恩恵は最大限に受けられないかもしれないのでご注意いただきたい。
最適化の手動設定 は要望があれば対応するかもしれないが、現在のところ実装する予定はない。

Ver.3.4

リリース日：2019/02/08

海外版ということもあり、これ以降の広告表示に関しては全世界に展開できるアドネットワークの AdMob を採用することにした。

リリースノート

• iOS 12 対応
• Google 補完のバグ修正

iOS 12 対応

こちらは非推奨のメソッドを新しいものに置き換えただけで、大きな変更は無し。

Google 補完のバグ修正

致命的なバグだった。
ある時を境に Google の入力補完が全く表示されなくなってしまったのだ。

Google の補完機能には Google Suggest API というものを使用しているが、実はこの API は正式に公開されているものではない。
よって動作が保証されているわけではないしドキュメント等も（たぶん）存在しないのだ。

これまでは API のパラメーターとして ie（input encoding）と oe（output encoding）にそれぞれ utf_8 という値を指定していた。
どうやらこの値 utf_8 が突如としてサポートされなくなったようである。
だが文句を言うのはお門違いだ。
公開されていない API を勝手に使っている私の責任である。

修正方法としては utf_8 を utf-8 に変更するという単純なものだったが、このアプリのメイン機能である Google 補完が使えなくなり、かなり焦った記憶がある。

ここで 1 つ不思議な現象を確認した。
このバグの影響は日本版の Ver.3.3 にも及んでおり、そのアプリを使っている場合はもちろん Google 補完が表示されない。
にも関わらず、未だに 3 年近く更新がかかっていない日本版 Just Quick Search のほうがアクティブユーザーが多いのだ。

私としてはメイン機能と言ってもいいくらいのものが他のユーザーにとってはあまり重要な機能ではないということなのか。
サポートページでは統合版を使うよう案内しているが、そのメッセージは見られていないのか。
そもそもアプリの異変に気付いておらず、今でも満足して利用しているのか。

色々推測はできるが、正確なことはわからない。
今でも解明できていない不思議な現象である。

思わぬ弊害

アプリの統合により予期せぬ事象が発生してしまった。
ダウンロード数の減少だ。

これまでは月平均 50 はあったダウンロード数が 10 程度まで落ち込んでしまったのだ。
理由はいくつかあると思うが、一番は App Store における検索順位の低下 と考えている。
日本版はここまでに約 2 万ダウンロードほどされていたためか、App Store 内で just や search と検索すればトップに表示されるようになっていた。
しかし、おそらく 1,000 程度しかダウンロードされていなかった海外版は検索結果の上位に表示されることはなく、アプリが露出する機会が激減したのだろう。
日本版と海外版は完全に別アプリなのだ。

また、日本版アプリへの App Store リンクは無効になってしまったため、過去に紹介された記事などからは Just Quick Search に辿り着くことはできない。
この App は現在、この国または地域では入手できません。 と表示されるため、ユーザーはそこで諦めてしまうだろう。

残念なことに、このとき日本版ユーザーに統合版を知らせる有効な手段はなかった。
サポートページの Twitter では案内したものの、一体何人がこのメッセージに気付いてくれたのだろうか。
アプリ自体は必要最小限の機能しか実装していないため、Push 通知は組み込んでいなかった。
通知でユーザーに知らせることができればとは思ったが、基本機能としては使用しないものなのでこれは現在でも実装するつもりはない。

一番悲しかったのはアプリに対するレビューの消失だ。
約 7 年かけて集まったレビュー数 43 件 と平均評価 4.5 という数値、また歴史を物語るレビューコメントは現在 App Store Connect 内で私しか確認することができない。

配信停止という最悪の事態は免れたが、今回の事件とその対応による被害は甚大であった。

Ver.3.4.1

リリース日：2019/03/06

リリースノート

• iPhone XS Max, XR に最適化
• 履歴補完の機能強化

iPhone XS Max, XR に最適化

最新のデバイス iPhone XS Max と XR に対応した。
新たなサイズが発売されると画面のレイアウトが崩れる可能性が高いため、だいたい毎回微調整を行っている。

履歴補完の機能強化

C/Migemo というライブラリを利用し、検索履歴からの入力補完を 超強化 した。
以前に一度チャレンジして難易度が高く諦めた実装に再挑戦した形だ。
今度はうまく行った。
Objective-C のプログラムから C 言語で書かれたライブラリを呼び出し、意図通りに処理することができたのだ。
前にできなかったことができるようになる という成長を感じられた嬉しい出来事だった。

前述のように、このライブラリを利用することで i と入力するだけでひらがなの い、カタカナの イ、漢字の 一 などを検出できるようになった。
また日本語入力で い と入力しても、カタカナの イ や 「い」の音を含む漢字 も同様に絞り込むことができる。
以前検索したキーワードを履歴画面を開かずとも、圧倒的スピードで呼び出すことができるようになったのだ。

だが残念ながらこの機能の存在を知っているユーザーはそこまで多くはないだろう。
毎回興奮して使っているのはきっと私くらいだ。
そもそも 履歴からの補完 なので、ある程度履歴が溜まっていないとこの機能は効果を発揮しない。
大抵のユーザーはこの機能に気づく前にアプリを使わなくなっている気がする。
悲しいことだが、それが現実である。

この機能の実装に伴い、保存できる検索キーワードの履歴を 100 件から 300 件 に変更した。
これらの機能強化により、これまではイマイチだった履歴からの補完機能が一気に なくてはならないレベル まで引き上げることができた。

しかし、その強大すぎる力の代償として Just Quick Search は C/Migemo の辞書ファイル 約 5 MB をアプリ内に組み込むこととなった。
このアプリの容量、約 17 MB のうち 9 割は以下の要素で構成されている。

• AdMob（ライブラリ）
• TwitterKit（ライブラリ）
• C/Migemo の辞書ファイル

将来的にアプリサイズは 10 MB を下回りたいものだ。

なお iOS で設定している地域が「日本」以外の場合は C/Migemo による履歴からの補完機能は発動しない。

Ver.3.5

リリース日：2019/09/29

リリースノート

• iOS 13 対応
• ダークモードに対応

iOS 13 対応

例によってライブラリを更新したり非推奨のメソッドを置き換えたりした。
後述のダークモード対応のため、今回は修正が多めだった。

ダークモードに対応

iOS 13 でリリースされた新機能の ダークモード に対応した。
ライトモードとダークモードで Just Quick Search のカラーリングはガラッと変わる。
ライトモードでは従来通りの白基調、ダークモードでは黒を基調としたアプリになるよう仕上げた。

ライトモード	ダークモード

画面の各パーツを細かくカスタマイズしているようなアプリの場合、ダークモード対応はかなり骨の折れる作業となる。
すべてのカラーにつき、ライトとダークの 2 種類の色を定義しないといけないからだ。
しかし Just Quick Search では UIKit のデフォルトコンポーネントを数多く使用しており、それらの場合は自動でライトとダークのカラーリングを調整してくれる。
単純なアプリゆえ、iOS の変更にも柔軟に対応することができた。
シンプルイズベストである。

Ver.3.6

リリース日：2020/09/22

リリースノート

• iOS 14 対応

iOS 14 対応

いつものように最新の Xcode でビルドして警告を解消しておしまいだ。
Just Quick Search に組み込めそうな新しい機能は特に無かった。

Ver.3.6.1

リリース日：2020/11/17

リリースノート

• iPhone 12 シリーズに最適化

iPhone 12 シリーズに最適化

この年はデバイスの種類が豊富だった。
iPhone 12, mini, Pro, Pro Max の 4 種類 が登場した。
Just Quick Search もこれらのデバイスで適切に利用できるよう調整を行った。

試練

AdMob から一通のメールが届いた。
app-ads.txt なるファイルの設定を確認してほしいと。
このファイルをデベロッパーサイトのルートディレクトリに配置することで、不正な広告の配信を防止することができ信頼性を高められるというものだ。
この設定がされていない場合、そのアプリは 広告掲載の対象外 になる可能性があるらしい。

これは一大事である。
広告が掲載されない、それはアプリによる収入がなくなることを意味している。
私はお金がほしい。
広告収入で暮らしたいんだ。

Just Quick Search のデベロッパーサイトは https://twitter.com/justquicksearch であり、ルートディレクトリに配置となると https://twitter.com/app-ads.txt ということである。

できるわけないだろ！

いよいよ自分で Web サイトを作成しないといけないのか。
個人開発者の肩身は狭くなっていく一方だ。
しかし私は諦めなかった。

Web サイトは作らない。

S3 の静的ウェブサイトホスティング

Just Quick Search 史上、初めて AWS の技術を利用したタイミングだ。
私は S3 の静的ウェブサイトホスティングとリダイレクトの機能を利用してこの問題を解決した。

AdMob は特定の周期で app-ads.txt がデベロッパーサイトに存在するかをチェックしている。
ここで言う「デベロッパーサイト」は App Store Connect で設定する マーケティング URL に該当する。
これは「サポート URL」とは別の、独立したページの URL だ。

私は「サポート URL」と「マーケティング URL」は共に https://twitter.com/justquicksearch を設定したかった。
よって実施した対策は以下となる。

• マーケティング URL には http://"S3 のウェブサイトエンドポイント"/index.html を設定
  • この URL にアクセスされた際は Twitter のアカウント URL にリダイレクト
  • index.html のファイルを用意する必要はない
• app-ads.txt を S3 バケットのルートにアップロード
  • AdMob は http://"S3 のウェブサイトエンドポイント"/app-ads.txt で app-ads.txt にアクセス可能

静的ウェブサイトホスティングのリダイレクトルールはこうなる。

[
    {
        "Condition": {
            "KeyPrefixEquals": "index.html"
        },
        "Redirect": {
            "HostName": "twitter.com",
            "ReplaceKeyPrefixWith": "justquicksearch"
        }
    }
]

見事に決まった。
AdMob の検証は無事に実施され、Just Quick Search における app-ads.txt のステータスは有効となった。

App Store のプロダクトページでは以下のリンクをタップした時にリダイレクトが実行されるようになっている。

Ver.3.6.3

リリース日：2021/09/22

リリースノート

• iOS 15 対応

iOS 15 対応

このバージョン（正確には iOS 14.5）からユーザーのプライバシーに関するセキュリティが更に強化された。
このアプリでは広告表示のため、トラッキングの許可ダイアログ が初回のアプリ起動時に表示されるようになった。
ここで Allow（許可）が選択されることで、そのユーザーに合った最適な広告が表示されるようになる。

余談

これまで新 iOS の対応バージョンはマイナーバージョンを上げるようにしていたが、間違えてパッチバージョンを上げてしまった。
今回の場合だと 3.7 にすべきところを 3.6.3 にしてしまったのだ。
動きなどには全く影響はないが、開発者としては少しモヤモヤする。

以上が Just Quick Search のアップデート履歴である。
次回のバージョンは 2022 年の 9 月頃、新しい iOS がリリースされたタイミングでまた実施することになるだろう。

戦績

Just Quick Search（HD 含む）における戦いの記録は以下の通りだ。

• 審査提出: 112 回
• リジェクト: 30 回
• 自ら審査取り下げ: 22 回
• ストアから削除: 1 回
• 自らストアから削除: 1 回

こうして振り返ってみるとすごい数だ。
リジェクト回数は驚異の 30 回。
だが私のアプリはまだ生きている。
よく続けてこれたと自分ながらに感心する。

がんばったな。

しかし戦いは今後も続いていくだろう。
戦わなければ勝てない。
戦え、戦え。

コンセプト

このアプリのコンセプトは シンプルな検索補助アプリ だ。
よってターゲットは すべての iPhone ユーザー となる。
特別なスキルは必要ない。

メインの機能は Google 検索であり、アプリ起動/再開時の仕様と強力な入力補完が検索スピードを加速させる。

結果的に多機能で使い方がわかりづらくなってしまったかもしれないが、その他の機能は使わなくてもいいのだ。
通常の使い方に慣れて、追加で何かしたくなった場合に初めてカスタマイズするくらいでいいだろう。

初心者はそのまま使えるし、上級者は細かく自由に拡張できる。
そんなアプリだ。

作者の設定

ここで私（開発者）の設定を公開する。
このアプリをカスタマイズする際の参考にしてほしい。

検索画面	検索対象選択画面

設定画面 #1	設定画面 #2

壁紙には私の好きなゲーム FC 版ドラゴンクエスト の画像（自作）を設定している。
Windows の「ペイント」で作成した 1125px x 2436px の大作である。（デバイスは iPhone 12 mini）
Single Screen に設定することで右画面にスワイプした際に 竜王の城 がちらっと見えるのがポイントだ。

Twitter のトレンドはもちろん表示している。
ハッシュタグは含めない。
こちらは Double Screen に設定することで画面の横スワイプだけで多くのトレンドが確認できるようになっている。

内蔵ブラウザは ON。
これに関するその他の設定はデフォルトのものを使用。

ホームページ URL には以下を設定しており、これによって 札幌 天気 の検索結果が内蔵ブラウザで開かれる。
このように日本語を設定したい場合は こちらのサイト で変換することができる。

jqs://www.google.co.jp/search?q=%E6%9C%AD%E5%B9%8C%20%E5%A4%A9%E6%B0%97

カスタム検索には以下 6 つを設定。
しかし最も使用頻度が高いのはやはり標準検索の Google である。

• App Store
  • https://search.itunes.apple.com/WebObjects/MZSearch.woa/wa/search?media=software&term=_._
  • 検索結果を App Store アプリで開く
• YouTube
  • https://www.youtube.com/results?search_query=_._
  • 検索結果を YouTube のサイトで開く *
• Amazon
  • https://www.amazon.co.jp/s?k=_._
  • 検索結果を Amazon のサイトで開く *
• Spotify
  • spotify:search:_._
  • 検索結果を Spotify アプリで開く
• Twitter
  • https://twitter.com/search?q=_._
  • 検索結果を Twitter のサイトで開く *
• Maps
  • comgooglemaps://?q=_._
  • 検索結果を Google マップアプリで開く

*: アプリがインストールされている場合はアプリで開く

あるアプリで検索を実行している場合、Just Quick Search からそのアプリを呼び出せる可能性がある。
その際は "アプリ名" ios custom url scheme や "アプリ名" ios deep link などで検索してみてほしい。
このようなページ がヒットし、そのアプリを開くための URL が見つかるかもしれない。

ぜひとも開発者の私も知らない自分だけの素敵な URL を見つけ出し、仲間内でワイワイ楽しんでもらいたいものだ。

長生きの秘訣

10 年間アプリを保守できた要因としては大きく以下 3 つが挙げられる。

• 最新 iOS バージョンのみサポート
• 自分で毎日使う
• 好きなようにやってみる

最新 iOS バージョンのみサポート

これが一番大きかったと思う。
Just Quick Search は常に最新の iOS メジャーバージョンしかサポートしない。
現在だと iOS 15 以上のデバイスでのみインストール可能だ。
iOS 14 以下では使えない。

Ver.1.0 をリリースしたタイミングでは iOS 5 以上、それ以降新たな iOS に対応したタイミングで以前のメジャーバージョンを切り捨ててきた。
理由は２つ。
新たな API を使用するため と 古いバージョンでの動作確認が大変だから だ。

新しい iOS で登場した API を利用する場合、古いバージョンをサポートしているとシンプルにプログラムを書くことはできない。
古いバージョンの iOS ではその API が利用できないため、プログラム中に必ず 分岐 という処理が発生してしまう。
新しい方ではこちらの処理を実施するが、古い方ではその処理を実施しないというフローである。
文字だけで見ると単純で問題なさそうに思えるかもしれないが、この分岐処理は一箇所にとどまらないことが多く、プログラムが複雑化してしまい バグを生む原因 となり得る。

また、バージョンによる分岐を実装するということは バージョンごとに動作確認をしなければならない ということでもある。
旧バージョンの iOS デバイスを持っているとは限らないし、用意しようとすると時間もかかる。
個人開発者の場合はなおさらだ。
仮に用意できたとしても大抵は古いデバイスにインストールされることが多く、バグが発生した際はデバイスが原因なのか iOS が原因なのかの判断がしにくい。

よって プログラムの品質を保ちバグを少なくするため、動作確認にかける時間を短縮するため、ひいては 私（開発者）が新たな iOS リリースを楽しみでいられるため に必要不可欠なポリシーなのだ。
私が 10 年間アプリを保守できた絶対的な要因である。

しかし、仕事でモバイルアプリ開発を行う場合はなかなか実現しにくい要素であることは間違いない。
個人開発だからこそできたことだろう。

自分で毎日使う

こちらもとても重要だ。
私はこのアプリを毎日使っていた。
それによってより良いアイディアが浮かんだり、異変にもいち早く気付くことができた。
iOS の新機能もどうにかしてこのアプリに組み込めないかと 自分事 として考えることができていたのだ。
むしろ私は自分で使うために Just Quick Search を 10 年間保守していたと言ってもいい。

私が普段使っていなければここまで長続きはしていなかっただろう。
あるタイミングで見切りをつけてその後のメンテナンスはしていなかったに違いない。
実際 Android 版はその道を辿っていた。

安心してほしい。
私は今後もこのアプリを使い続ける。
10 年使ってるヤツが言うのだから信頼性はそこそこ高いだろう。
更新頻度は年に数回かもしれないが、新しい iOS やデバイスの登場、バグが発生した時には必ずアップデートをかける。
だがなかなかアップデートがリリースできない時は察してほしい。
色々あるんだ、色々（4.2）。

少しだけ待っていてくれ。
何度でも蘇るさ。

好きなようにやってみる

本当に自由に好き勝手やってきた。
だからこそ続けられたのだ。

iOS のバージョン縛りもそうだしプログラミング言語の選定も、誰に言われることもなく自分の好きなタイミングで考え判断し行動に移していた。
ユーザーからのリクエストも自分なりに解釈・改良して新機能として組み込んだり、面倒な機能や実装は後回しにしたりもした。
問題が発生したり、要望が出てから対応すればいいからだ。
考えすぎて止まるよりも、とりあえず前に進む道を選んできた。

楽しかった。
楽しくてしょうがなかった。
このアプリのことを考えている時は幸せな気持ちになれる。
常に夢を見ていられるからだ。

私はこれからも楽しく自由に好きなようにこのアプリを育てていこうと思う。

得られたもの

Just Quick Search の開発で得た経験や知識はその後の人生で大いに役立った。

私はクラスメソッドに入社して 8 年目になるが、そのうちの 5 年ほどは スターバックス ジャパン公式モバイルアプリ の開発に携わっていた。
現在はプロジェクトを離れてしまったが、スターバックスコーヒージャパンの優秀な方々や頼れる仲間たちと共にこのスタバアプリを開発できたことは私の誇りであり、一生の宝だ。

私はある時 Just Quick Search にも導入している レビューダイアログの実装 を提案した。
低コストで高い効果が期待できたからだ。
それまでのスタバアプリのレビュー数は 約 600、平均評価は 3.2 だった。
導入後の現在はレビュー数 16 万以上、平均評価は 4.7 まで激増した。
みんなで日々メンテナンスを行いアプリの品質自体が上がったことも評価アップの要因と推測できるが、これまで満足して使ってくれていた人のフィードバックを引き出せたことが大きいと思う。
ユーザーは通常満足している時は黙ってアプリを使い、不満がある場合やバグが発生した時は低評価と共にレビューを書くものだ。
狙い通りだった。
満足して使ってくれているユーザーはこんなにも多くいてくれたのだ。
この結果を受け、開発チームの士気が高まったのは言うまでもない。

また、ある時からスタバアプリはバックグラウンドに回ってしばらくすると強制終了するという問題が発生していた。
私はクリップボード監視機能の実装経験を元にバックグラウンド処理のプログラムを見直した。
すぐに分かった。
適切な処理が実施されていなかったのだ。
Just Quick Search で事前に実装していなければおそらく修正はもっと長引いていただろう。

全体的なパフォーマンスに関しても日々改善していった。
アプリの起動速度や画面スクロール時のカクつきなどには特に神経を尖らせていた。
何度か本記事で言及しているが、Just Quick Search は UIKit フレームワークのコンポーネントをほぼデフォルトの状態で使用しているため、動きがスムーズである。
私にとって通常の速度が それ なのだ。
動きが悪かったり違和感がある場合は、無駄な処理を行い UI が引きずられている可能性が高い。
スムーズなのが当たり前 なアプリをいつも触っていたため、ボトルネックとなっている部分にも気づきやすかったということだ。

この他にもまだまだ語りきれない数多くの出来事があった。
もちろん全部が私の成果ではないが、多くの場面で貢献できたと自負している。
すべては Just Quick Search というベースがあったからこそだ。

そもそも Just Quick Search を開発していなければ、私は現在クラスメソッドには所属していなかっただろう。
このアプリを作っていない場合の「今」は想像もできない。

おわりに

以上が Just Quick Search が歩んだ 10 年間の軌跡である。

この記事を読んで少しでもこのアプリに興味を持った方がいれば、ぜひダウンロードして使ってみてほしい。
あなたの iPhone での 検索 というアクションは今よりも必ず快適になるだろう。

人によっては役に立たないクソアプリかもしれない。
しかし誰が何と言おうと、私にとって Just Quick Search は我が子であり、神アプリなのだ。

このアプリに関わってくださったすべての人に感謝します。

ありがとう