nativefier 古いビルドエラーの直し方｜再ビルドで消えない理由

毎朝開いていた社内の管理画面が、ある日から起動のたびに警告の窓を出すようになる。タイトルは「Old build detected」で、その下にChromeとElectronの話が1行だけ書かれている。閉じればアプリは今まで通り動き、サイト側にも異常はない。nativefier 古いビルドエラーと呼ばれているこの表示は、故障ではなく、アプリの中に焼き込まれたタイマーが切れた合図です。押して消す方法を探すよりも、3つある出口のどれを選ぶかを決めたほうが早く終わります。

この警告が測っているもの

判定しているのはサイトでもmacOSでもなく、アプリの中身です。この道具で作られたアプリは、パッケージした日付を自分の中に保存しています。起動してメインの窓が作られた直後に、保存された日付と現在時刻の差を計算し、決め打ちのしきい値と比べます。そのしきい値は90日で、アプリ本体のソースに定数として書かれています。超えていれば、起動のたびに1回、警告として窓が出ます。

本文は、ビルド時に上書きしていなければ次の文言で固定されています。

This app was built a long time ago. Nativefier uses the Chrome browser (through Electron), and it is insecure to keep using an old version of it. Please upgrade Nativefier and rebuild this app. 出典: github.com

この1文をそのまま読めば、誤解の大半は片付きます。証明書が切れたのでも、通信が遮断されたのでも、サイトの仕様が変わったのでも、新しいmacOSと相性が悪くなったのでもありません。このアプリの中に封じ込められたChromeが、少なくとも3か月のあいだ修正を受け取っていない、と言っているだけです。ブラウザなら裏で自分を更新してこの問題を解決します。包んで固めたアプリには更新の仕組みがないので、途中で止めて知らせる以外にできることがありません。

毎回同じ窓が出るのも同じ理由です。アプリを終了しても、Macを再起動しても、サイトのデータを消しても、アプリの中の日付には触れません。日付が変わるのは、新しくビルドし直したときだけです。

90日という数字は、適当に決められたものではなく折り合いの結果として読めます。短期の用事で1つ作っただけのアプリなら、使い終わるまで一度も邪魔をしない長さです。一方で毎日使い続けるアプリは、1四半期のうちに必ず引っかかります。そのため、この窓が出たこと自体が中身の年齢を示す情報にもなります。出始めたばかりのアプリはおよそ3か月前のビルドで、1年前から出続けているアプリは、Dockで隣に並んでいるブラウザより1年以上古い描画エンジンを抱えていることになります。

再ビルドしても、中身のブラウザは新しくならない

警告の文面は「道具を更新してアプリを作り直せ」と言っています。作り直すこと自体は効きます。新しいアプリには今日の日付が入るので、そこからまた90日は静かになります。ただし、多くの人が期待している変化は起きません。

道具そのものの更新が止まっているためです。npmに公開されている最後のバージョンは52.0.0で、公開日は2023年8月25日です。それ以降のリリースはありません。このバージョンが既定で使うElectronは25.7.0、対応するChromeは114です。つまり今日この道具で作り直しても、中に入るのは2023年半ばの描画エンジンで、日付だけが今日になったアプリが出来上がります。警告は3か月だけ黙り、警告が指していた中身は何も変わっていません。

更新が止まった理由は、開発元自身が公開の場で説明しています。リポジトリは2023年9月に公開のまま凍結されました。

Nativefier is unmaintained and has been publicly archived. Users who want to build and use their own website wrappers should strongly prefer these options as they are protected from security vulnerabilities by the browser's self updating mechanism. 出典: github.com

ここで名指しされている性質が、この話の核心です。サイトをアプリの形にすること自体に問題があったわけではありません。エンジンを固定したまま更新の担い手がいなくなった包装は、自分を修正できない。ブラウザはできる。その差だけが残りました。

警告に関係する2つのビルド時オプション

用意されている選択肢は2つあり、どちらも起動時ではなくビルド時に指定します。出来上がったアプリのメニューから設定を変えることはできません。

1つ目は --disable-old-build-warning-yesiknowitisinsecure です。長い名前がそのまま説明になっており、公式の説明も「古く、おそらく安全でないElectronを使う、ずいぶん前に作られたアプリを開いたときに出る警告を無効化する」という趣旨です。ビルド時の指定なので、使うにはどのみち作り直しが必要で、その時点で日付もリセットされます。この指定が本当に役に立つのは、公式の説明が例に挙げている用途です。管理下にある社内サイトだけを表示する固定端末のように、ビルドを意図的に据え置く前提の場面では、警告は雑音でしかありません。

2つ目は -e（--electron-version）です。バージョン文字列を渡すと、既定ではなくそのElectronを取り込みます。この道具から新しいChromeを引き出す方法はこれだけです。注意すべき点は、52.0.0のアプリ側のコードがElectron 25のAPIを前提に書かれていることです。新しいメジャーバージョンでは、そこで呼んでいるものが削除されたり名前が変わったりしています。組み合わせによっては問題なく動き、別の組み合わせでは窓が開いた直後に壊れます。毎日の仕事を移す前に、実際の作業で試してから判断してください。

補助的なものも2つあります。--upgrade は既存のアプリの実行ファイルのフルパスを渡すと、当時の指定を引き継いだまま作り直します。長いコマンドを記憶から復元しなくて済みます。--arch arm64 は、ビルドする機械と使う機械の系統が違うときに要ります。前提条件として、Nodeは16.9以上、npmは7.10以上、macOSは10.13以降が求められています。

3つの出口と、それぞれの代償

横に並べると、どこで判断が分かれるのかがはっきりします。見るべき列は「中のエンジン」です。

選ぶ道	警告への効果	アプリの中のエンジン	続けて必要な手間
既定のまま作り直す	90日だけ止まる	Chrome 114のまま	3か月ごとに作り直す
抑止オプションを付けて作り直す	恒久的に出なくなる	Chrome 114のまま	作り直し後は不要
新しいElectronを指定して作り直す	90日だけ止まる	動けば新しいChrome	作り直しと動作確認
ブラウザからサイトをインストールする	最初から出ない	ブラウザ本体のエンジン	不要
更新の続いているWebアプリ化ツールに移す	最初から出ない	ツール側が更新	不要

何年も前に作ったアプリが複数ある場合は、判断の前にもう1つ確かめる価値があります。Intel専用のアプリはApple Silicon機ではRosettaを通して動いており、Finderの情報を見るウィンドウでは「アプリケーション（Intel）」と表示され、起動中のものはアクティビティモニタの「種類」列でも同じことが分かります。これはエンジンの古さとは別に、上に重なっているもう1つの期限です。

Gatekeeperの手順も変わりました。この方法で作ったアプリは署名されていないため、現行のmacOSでの初回起動は、システム設定の「プライバシーとセキュリティ」を開いて「このまま開く」を押す経路になります。Finder上の簡便な回避手順は、Appleの案内からは外れています。

ブラウザから入れた場合に何が変わるか

凍結を告知した本人が勧めているのは、ブラウザ自身のインストール機能です。ただしChromeは項目の名前を変えたため、以前のやり方を覚えている人ほど見つけられなくなりました。Chrome 128以降、「ショートカットを作成」はタブでページを開くブックマークを作る項目になり、独立した窓のアプリを作る動作は別の項目へ移りました。

Starting in Chrome 128, the Create Shortcut menu item in More > Save and share now creates a bookmark on the user's desktop or homescreen. The previous behavior of this menu item on desktop has moved to the Install Page as App option. 出典: developer.chrome.com

現在の経路は、右上のメニューから「キャスト、保存、共有」を開き、「ページをアプリとしてインストール」を選ぶ形です。出来上がるものには専用のアイコンがあり、Dockに並び、タブバーのない窓で開き、期限の切れる日付は入っていません。macOSでは、利用者のホーム直下のアプリケーションフォルダの中にある「Chrome Apps」に置かれます。

代償は、ブラウザとの結び付きです。この方法で入れたアプリは、作成したブラウザのプロファイルに属し、Cookieも拡張機能もログイン中のアカウントも共有します。同じサービスで2つのアカウントを使い分けるなら、プロファイルも2つ用意することになります。1人が1アカウントで使うサイトなら、この結び付きは目に見えません。仕事用と個人用を1日中行き来する人にとっては、これが問題そのものです。

内部データから見た、専用ツールが残る領域

凍結の告知が勧めている道は、多くの場合に正しい既定です。それでも埋まらないのが、そもそも包む道具に手を伸ばした動機のほうです。どのブラウザプロファイルが選ばれているかに関係なく、アプリごとに独立したログイン状態を保ち続けること。これは、エンジンを固定し直すことなく、更新の続いているサイトをアプリにする道具で満たせます。更新されるのは1つ1つのアプリではなく、道具の側だからです。

実務での差は3か所に出ます。1つ目はログイン状態の分離で、同じドメインの管理画面と個人アカウントを、プロファイルを切り替えずに同時に開けます。2つ目はアイコンと窓の扱いで、ブラウザから受け継ぐのではなくアプリごとに決められます。3つ目は準備済みのサービス一覧です。手作業のビルドで時間を取られるのは、実のところ特定のサービスに合ったユーザーエージェントと窓の大きさとログインの挙動を突き止める工程で、そこが300以上のプリセットからすぐ作れる形になっていれば丸ごと省けます。どのサービスが用意されているかは対応サービス一覧で確認でき、包む道具に求めていた挙動が実際にあるかどうかはできることを見るのがいちばん速い確認になります。作る手順そのものを先に把握しておきたい場合は使い方ガイドに一通りまとまっています。

費用の形も、乗り換えを決める前に見ておく項目です。買い切りなのか継続課金なのか、対応するmacOSがどこまでかは料金にまとまっており、判断に迷いやすい点はよくある質問で確認できます。ビルドを自分で管理し続ける手間と、そのまま使える状態を維持する費用のどちらを取るかという比較になります。

ブラウザからのインストールで足りるなら、それで終わらせるのが妥当です。足りない場合に比べるべき相手は、2023年で止まったビルドではなく、いま更新されている道具のほうです。