Nativefierの使い方｜ビルド前に決める順番

Nativefierの使い方でつまずくのは、コマンドの綴りではありません。つまずくのは、作ったあとで「名前を変えたい」「このリンクは外のブラウザで開きたくない」と気づいて、同じ作業をもう一度やり直す場面です。この道具は指定した内容を生成時にアプリの中へ書き込む作りで、あとから設定画面を開いて直す経路がありません。だから使い方の要点は、どのオプションを知っているかではなく、どの順番で決めるかに寄ります。ここでは、決め終えてから1回で作り切るための順番を並べます。

あとから変えられない項目を先に並べる

最初にやることは、コマンドを打つことではなく、固定される項目を把握することです。生成後に変えられるものと変えられないものは、はっきり分かれています。

項目	生成後の扱い
アプリ名、アイコン	作り直しか上書きが必要
対象アーキテクチャ	作り直しが必要
内部として扱うURLの範囲	作り直しが必要
二重起動の抑止、常駐の形	作り直しが必要
ウインドウの初期サイズ	起動後に動かせるが、初期値は固定
ログイン状態、閲覧データ	アプリ側に蓄積される

右の列がほぼ「作り直し」で埋まる点が、この道具の性格です。つまり作業の実体は、ビルドの1コマンドではなく、その前に置く判断の列にあります。判断を飛ばしてとりあえず作ると、たいてい3回から4回作り直すことになります。

なお全体の前提として、動作条件はNode.jsが16.16.0以上、npmが8.11.0以上と書かれています。導入は npm install -g nativefier で、ビルドの基本形は nativefier [オプション] [対象URL] [出力先] です。ここから先は、このオプションの部分を埋める順番の話になります。

決める順番1 出来上がったものの置き場所

意外に効くのが置き場所です。出力先を指定しないと、コマンドを打ったディレクトリにアプリが落ちます。デスクトップやダウンロードフォルダで作業すると、そこに置かれたまま動くことになり、あとで整理したときにリンクが切れます。

指定の方法は2つあります。1つはコマンドの末尾に出力先を書く方法。もう1つは環境変数 NATIVEFIER_APPS_DIR を設定しておく方法です。公式の説明では ~/.zshrc などに export NATIVEFIER_APPS_DIR=~/Applications/ を書いておくやり方が案内されており、これを済ませておけば、以降は出力先を書かなくてもアプリケーションフォルダに直接置かれます。

先に決める理由は単純で、あとから移動させると面倒だからです。生成されたアプリは自分のフォルダ構成を前提に動く箇所があり、特に --upgrade で上書きする場合は、生成時と同じ場所にあることが条件になります。置き場所は最初に固定しておくのが後の手間を減らします。

決める順番2 どちらのMac向けに作るか

次に確かめるのが対象アーキテクチャです。指定しない場合、生成されるアプリはビルドに使ったNode.jsの種類に従います。ここに落とし穴があり、Apple Silicon搭載機であっても、Rosetta経由で入ったNode.jsを使っているとIntel向けのアプリが出来上がります。見た目では分からず、動きはするものの、翻訳層を1枚かぶった状態になります。

確認は1行で済みます。node -p "process.arch" と打って、返ってくる値が arm64 か x64 かを見ます。x64 が返ってきてApple Silicon機を使っているなら、-a arm64 を明示するか、Node.jsを入れ直します。両方の機械で同じアプリを使いたい場合は -a universal という指定もあり、これはmacOS向けのビルドでのみ選べます。

同じ要領で、対象OSは node -p "process.platform" で確認できます。既定は今動かしているOSで、別のOS向けに作りたい場合だけ -p を指定します。アーキテクチャとプラットフォームは別の指定であり、混同すると「Mac用のつもりでIntel指定をした」といった取り違えが起きます。

決める順番3 最初の1本はオプションを付けずに作る

置き場所と対象が決まったら、いきなり作り込まずに、URLだけを渡して1本作ります。この道具は対象サイトから名前とアイコンを拾ってくる仕組みを持っているため、まず自動で何が付くかを見たほうが早いからです。名前がサイトのタイトルそのままで問題なければ -n は不要ですし、アイコンが拾えていればそこも省けます。

この1本で確認するのは3点です。起動するか。ログインが通るか。ふだん使う操作が一通り動くか。特にログインは、次の節の判断材料になります。認証の画面が別ドメインへ飛ぶサービスでは、ここで外のブラウザが開いて止まることがあり、その挙動を見てから範囲の指定を決めるほうが確実です。

試作の段階では --no-overwrite を付けずに作り、同じ場所へ何度も上書きしていくのが手早い進め方です。本番として残す1本を作るときだけ、名前と出力先を確定させます。

決める順番4 リンクがどこで開くかを決める

ここが実務でいちばん詰まる場所です。生成されたアプリは、リンク先が「内部」か「外部」かを判定し、外部と判定したものは既定のブラウザへ渡します。既定の判定は、www. を除いた基準ドメインが同じかどうかです。つまり foo.com と app.foo.com は内部、abc.com は外部になります。

この既定で困るのが、認証が別ドメインで行われるサービスです。この点については既知のログインページが内部扱いになる仕組みが後から加えられており、accounts.google.com、login.microsoftonline.com、okta.com、id.atlassian.com、github.com/login などが対象に入っています。判定は指定した範囲より先に働くため、これらのサービスであれば追加の設定なしで通ることが多くなります。

一覧に無い認証基盤を使っている場合は --internal-urls に正規表現で範囲を足します。社内の管理画面のように、外へ出る想定がまったく無いのであれば --internal-urls ".*?" で全部を内部として扱う書き方もあります。逆に、基準ドメインでの自動判定を止めて指定した範囲だけを内部にしたい場合は --strict-internal-urls を併用します。さらに厳しくして、外部への遷移そのものを止めたい場合は --block-external-urls を付けると、外部リンクはエラー表示になります。

キオスク用途や、業務専用の窓として固定したい場合は、この3つの組み合わせで挙動が決まります。ここを決めずに配ると、使う人が意図しないページへ迷い込む経路が残ります。

決める順番5 窓の出方と常駐の仕方

見た目と常駐の指定は、使う頻度で選びます。1日に何度も行き来するものなら --single-instance を付けておくと、二重に開かず既存の窓が前に出ます。これを付けないと、Dockのアイコンを押すたびに新しい窓が増える場面が出てきます。

閉じるボタンで終了させたくない場合は --tray です。メニューバーにアイコンとして残り、窓を閉じても終了しません。--tray start-in-tray と書くと、初回の起動で窓を出さずに常駐だけします。1点だけ制約があり、macOS以外の機械からmacOS向けに作った場合、メニューバーのアイコンが表示されないことが公式の説明に書かれています。Macで使うアプリはMacで作るのが無難です。

窓の大きさは --width と --height で指定でき、既定の横幅は1280pxです。--always-on-top で常に手前に置く、--title-bar-style でタイトルバーの形を変える、といった指定もあります。タイトルバーを薄くする場合は、--inject でCSSを差し込み、サイト側のヘッダーをドラッグ可能な領域として指定する対応が案内されています。この2つは組みで使う前提です。

持ち出して使う場合だけ読む注意

USBメモリなどに入れて持ち歩きたい場合は --portable があります。利用データをアプリのフォルダ内に置く形になり、機械を移っても同じ状態で開きます。ただしこの指定には、使い方を誤ると重い結果になる注意が付いています。

IMPORTANT SECURITY NOTICE: when creating a portable app, all data accumulated after running the app (including login information, cache, cookies), will be saved in the app folder. If this app is then shared with others, THEY WILL HAVE THAT ACCUMULATED DATA, POTENTIALLY INCLUDING ACCESS TO ANY ACCOUNTS YOU LOGGED INTO. 出典: github.com

要点は、ログイン情報がアプリのフォルダごと相手に渡るという1点です。公式の説明では、配布する場合の手順として、作る、試す、いったん消す、同じ手順で作り直す、開かずに配る、という順番が示されています。自分で持ち歩くだけなら問題は起きませんが、人に渡す用途と持ち運ぶ用途を同じ1本で兼ねないことが前提になります。

作ったコマンドを1行残しておく

最後にやることは、使ったコマンドをそのまま記録することです。テキストファイルでも、シェルの履歴から抜き出したメモでも構いません。理由は2つあります。

1つは作り直しのためです。この道具は指定内容をアプリに書き込むため、半年後に同じものを作ろうとすると、どのオプションを付けたか思い出す作業から始まります。記録が1行あれば、その手間がゼロになります。

もう1つは上書きのためです。--upgrade <既存アプリのパス> を使うと、既存のアプリから指定内容を読み出して作り直す動きになります。便利ではありますが、この操作は同じ場所のアプリを置き換える形で進むため、公式の説明でも事前にバックアップを取るか、別の出力先を指定することが勧められています。記録が残っていれば、上書きに頼らず最初から作り直す選択も取れます。

なお、中身のソースを1つの書庫にまとめたい場合は -c を付けます。差し込んだCSSやJavaScriptがそのまま読める状態になるのを避けたい場合に使う指定で、配布を考えるなら併せて決めておく項目です。

順番を決めきれないときに見る材料

ここまでの順番を通しても、最後に残る問いが1つあります。そのサイトを独立させる価値があるかどうかです。判断の材料になるのは、開く回数と閉じる機会の2つで、1日に何度も開いて滅多に閉じないものほど効果が出ます。

どの種類のサイトがその条件に当てはまりやすいかは、実際に外へ出されている顔ぶれを見ると分かります。240以上のプリセットからすぐ作れる形で並んでいる対応サービス一覧には、業務の管理画面、会計、タスク管理、会話の窓口といった常時開いておく種類が中心に並んでいます。ここに載っている種類のサイトであれば、判断の材料はすでに揃っています。

窓として何を引き受けるかを比べたい場合はできることに範囲がまとまっています。名前とアイコンの指定、保存領域の分離、通知といった項目は、コマンドで指定していたものと同じ内容で、どの方式でも共通して必要になる判断です。作ったあとの直し方や消し方の手順は使い方ガイドに並んでいます。

費用の条件は料金で確かめられます。コマンドで作る方式は金銭的な費用が発生しない代わりに、上の順番を毎回自分で通す時間と、作り直しの手間を引き受けることになります。年に1本しか作らないなら前者が安く、10本以上を保守するなら後者のほうが時間の総量は少なくなります。導入前に確認しておきたい条件はよくある質問に整理されています。

決めるべきことを1つに絞るなら、内部として扱うURLの範囲です。ここだけは作り直さないと変えられず、しかも実際に使い始めてから不都合に気づく項目だからです。最初の試作で認証の流れを最後まで通してから、本番の1本を作る。この順番を守るだけで、作り直しの回数は目に見えて減ります。