本文へスキップ

開発記

規約を2箇所に置いて、片方だけが古びた

アプリの規約とプライバシーポリシーを、外部のページとサイトの両方に置いていました。当然のように、片方だけが古びました。

配信済みのアプリは、古い URL を開き続ける

まず前提として、アプリの中に焼き込んだ URL は後から変えられません。 次のビルドでリンク先を変えても、いま入っている版はそのまま古い URL を開きます。

だから外部のページを消す、という選択肢は最初からありませんでした。消すと、いま使っている人の手元で規約が開けなくなります。

両方に置いた結果

サイト側にも条文を持たせました。同じ内容が2箇所にある状態です。片方を直したとき、もう片方を直し忘れました。

アプリのコンセプトを作り直したあとも、外部の法務ページは却下される前の記述のまま公開され続けていました。すでに存在しない機能や、やめたプラン名がそこにありました。

「両方に置く」は、直す手間が2倍になるだけではありません。どちらが正しいのか誰にも分からなくなります。

「両方に置く」をやめて「片方を転送にする」

いまは条文の正本をサイトの中の1箇所だけに置き、外部のページからは条文を消して転送だけを残しています。消していないので古い版のアプリからも開けますし、中身は1箇所しかないので古びようがありません。

ただ、GitHub Pages は 301 を返せません。 そこで3つ重ねています。

  • <meta http-equiv="refresh"> —— ブラウザはこれで飛ぶ
  • <link rel="canonical"> —— 検索エンジンに正本を伝える
  • JavaScript —— ハッシュ付きの URL を扱うため

そして本文に、転送先への素のリンクを残しています。 JS も meta refresh も辿らずに取得するクローラがいるためです。App Store の審査もそこに含まれます。 転送だけにすると、審査から見て「規約が空のページ」に見えかねません。

ハッシュを渡すか、渡さないか

2つのアプリで作りが違ったので、転送の仕方も分けました。

  • ファイルごとに分かれていたほう … 転送先を1対1で固定する。受け取ったハッシュは渡さない —— サイト側の見出しの id が違うので、渡すと存在しないアンカーに着く
  • 1枚に節が並んでいたほう … ハッシュを引き継ぐ。あちらはハッシュが節の識別子そのものだった

順番を間違えました

最後にひとつ、やり直せない失敗です。転送板にする前にサイトを公開すると、同じ条文が2箇所で生きます。 検索側では重複として扱われます。

正しい順は「転送板にする → サイトを公開する」でした。実際には逆になり、2日間、同じ条文が2箇所で生きていました。

次のアプリでは順番を守ります。急ぐ理由が無いのに逆にしてしまった、というだけの話です。

Notes 一覧へ戻る