Nativefierをどう選ぶか｜4つの条件で残る道が決まる

Nativefierを使うべきかどうかで手が止まっているなら、比べ方を変えたほうが早く終わります。機能の一覧を眺めて優劣を付ける作業は、どの候補にも長所があるため結論が出ません。決まるのは、自分の側にある条件を先に確定させたときです。この記事では、順に当てるだけで候補が落ちていく4つの条件と、間違えたときに戻す費用の見積もり方を並べます。

決まらないのは、候補を機能で比べているから

サイトをアプリにする道具は、どれも同じ説明文を掲げています。URLを入れれば、Dockに置ける独立したアプリができる。この一文はすべての候補に当てはまるので、ここを起点にすると比較が終わりません。

比較が進まないもう1つの理由は、機能表の項目が自分に関係あるかどうかを判断できないことです。拡張機能を持ち込めるか、タブを持てるか、複数のブラウザエンジンから選べるか。項目としては意味が分かっても、それが自分の使い方で効くのかは表を見ても出てきません。

だから順番を逆にします。候補を見る前に、自分の側の条件を4つ確定させる。渡す相手は誰か、更新を押す人は何か月後にもいるか、相手のサイトは何を要求しているか、手元の環境はそのビルドを通せるか。この4つは、どれも調べれば10分以内に答えが出ます。そして4つとも答えが出た時点で、残っている候補はたいてい1つか2つになります。機能表は、最後に残った候補の中を見るときにだけ使います。

条件1: 作ったアプリを、誰の端末で開くのか

最初に決めるのは配る範囲です。自分1台だけで開くのか、チームに配るのか、社外の相手に渡すのか。ここで結論が大きく変わります。

自分1台だけなら、署名や公証の手続きは省けます。開くときに警告が出ても、自分の判断で越えられます。この場合、Nativefierは選択肢として生き残ります。手元でコマンドを叩き、できたものを自分で使うだけなら、保守が止まっていることの影響は中身のエンジンが古いという一点に絞られます。

チームに配る段になると、事情が変わります。受け取った側の端末でも同じ警告が出ますし、macOSが管理されている職場では管理者の設定で開けないこともあります。配る人数だけ「越え方」を説明する作業が発生し、その説明を新しく入った人にも毎回することになります。この時点で、署名と公証を提供元が引き受けている有料の道具か、ブラウザの機能でそれぞれに入れてもらう形か、という2択に寄ります。

社外へ渡す計画があるなら、さらにライセンスの確認が入ります。Nativefier自体はMITなので条件は緩いほうですが、候補の中には配布の条件が厳しいものもあります。配る範囲が「自分だけ」から1段でも広がるなら、この確認を条件1の中でまとめて済ませてください。

条件2: 更新を押す人が、何か月後にもいるか

次に決めるのは、中身のエンジンを新しくする作業を誰が続けるかです。ここはNativefierを選ぶかどうかの分かれ目そのものになります。

エンジンを同梱する形の道具では、作った時点の版がアプリの中に固定されます。新しくするには誰かが作り直します。Nativefierで作ったアプリの場合、既定で入るのは2023年時点のElectronです。Electronの公式ドキュメントには、保守の対象が明記されています。

The latest three stable major versions are supported by the Electron team. For example, if the latest release is 42.1.x, then the 41.0.x as well as the 40.2.x series are supported. 出典: electronjs.org

Electronはおよそ8週間ごとに新しいメジャー版を出すため、3つ分という範囲はおおむね半年程度です。つまり同梱型を選ぶということは、半年に一度作り直す係を置くという意味になります。その係が半年後にもいるかどうかが、条件2の答えです。

「いる」と答えられるなら、Nativefierは残ります。ビルドはコマンド1行で、設定をファイルに残しておけば同じものを再現できます。手順が自動化しやすい点は、定期的に作り直す前提と相性がいい性質です。

「いない」または「自分がやるとは言い切れない」なら、同梱型は候補から外してください。残るのは、OSのWebViewを使う形か、インストール済みのブラウザを使う形か、ブラウザの機能で入れる形です。どれも、更新を押す人が自分ではなくなります。

条件3: 相手のサイトが何を要求しているか

3つ目は、アプリにしたいサイトの側の事情です。ここは調べないと分かりませんが、調べれば白黒が付きます。

動画を扱うサイトを包む予定があるなら、DRMの扱いを先に確かめてください。Nativefierの公開ドキュメントには、Widevineを使う一部のサイトでは動画の読み込みが拒否され、外部の仕組みで署名しないと再生できない場合がある、と注記されています。この作業は追加の手順になるので、動画が主目的なら条件3の時点で候補が絞られます。

ログインの経路も見る必要があります。社内システムがシングルサインオンを使っている場合、認証の途中で別ドメインへ飛び、そこで戻れなくなる形があります。Nativefierは内部として扱うログインページの一覧を持っていて、代表的なサービスは最初から通るようになっていますが、社内独自の認証基盤はその一覧に入りません。この場合、どのドメインを内部として扱うかを自分で指定する作業が要ります。指定する仕組みを持たない候補は、ここで落ちます。

ブラウザの拡張機能に依存している場合も条件になります。パスワード管理や翻訳の拡張を毎日使っているなら、拡張を持ち込めない形の道具では手順が変わります。インストール済みのChromium系ブラウザを土台にする道具なら、既存のプロファイルごと持ち込める形があります。

通知とファイルの扱いも同じです。そのサイトから通知を受け取っているか、ファイルのアップロードやダウンロードを日常的にしているか。していないなら条件から外し、しているなら候補側に同じ挙動があるかを見ます。

条件4: 手元の環境が、そのビルドを通せるか

最後は自分の機械の話です。ここは調べるのに5分もかかりません。

Nativefierを動かす場合、公開されている必要条件はmacOS 10.13以降と、Nodeとnpmです。配布物の設定にはNodeが16.16.0以上、npmが8.11.0以上と書かれています。加えて、アイコンを変換するならImageMagickかGraphicsMagickが必要で、convertとidentify、またはgmがパスに通っている必要があります。Windows向けの実行ファイルをMacから作るならWineも要ります。つまりコマンドを1行叩けば終わる話ではなく、周辺の道具を揃える作業が先にあります。

ここで引っかかるなら、道具を揃えるか、別の候補にするかの判断になります。似た系統の候補も条件は軽くありません。RustのTauriで作られた候補を手元でビルドする場合、Rustの1.85以降とNodeの22以降が求められます。

逆方向の条件もあります。画面から作る形の有料の道具は、動作するmacOSの版が決まっています。公開されている情報では、Chromium系ブラウザを土台にする道具がmacOS 13.5以降、macOS標準のWebKitを使う道具がmacOS 15以降となっています。古いMacを使い続けているなら、この条件で候補が先に消えます。手元のMacの版は、この4つ目の条件を当てる前に確認しておいてください。

4つを順に当てると、残る道は1つか2つ

4つの答えが出たら、次の形に当てはめます。上から順に見て、最初に全部当てはまった行が残る道です。

条件1の答え	条件2の答え	残る道
自分1台だけ	自分が作り直し続ける	Nativefierを含む、コマンドで作る形
自分1台だけ	続ける自信がない	ブラウザの機能、またはWebKit系の道具
チームに配る	係を置ける	同梱型で、署名の手順も併せて用意する
チームに配る	係を置けない	署名と公証を提供元が引き受けている道具
社外に渡す	いずれでも	ライセンスと署名を先に確認してから候補を絞る

条件3と条件4は、この表で残った道に対する足切りとして使います。残った道に、必要だった機能（URLの内部指定、拡張機能の持ち込み、DRMの再生）が無ければ、1つ下の行へ移ります。手元のmacOSの版が足りなければ、その候補を消します。

この順番で当てると、機能表を1枚も開かずに候補が2つ以下になります。残った2つを比べる段階になって初めて、細かい機能の差を見る価値が出てきます。

選び直しの費用を、先に見積もる

どの道を選んでも、後から変える可能性は残ります。だから決める前に、戻す費用を数えておくと判断が軽くなります。

戻す作業の中身は、作り直し、ログインのやり直し、通知の許可の取り直し、Dockへの並べ直しの4つです。アプリ1本あたり10分程度で、5本作っていれば1時間見ておく形になります。この見積もりが分かっていると、「とりあえず試す」が現実的な選択肢になります。

高くつくのは、配ったあとで変えるときです。受け取った側の端末でも同じ4つが発生し、説明する手間が人数分かかります。だから条件1で「チームに配る」と答えた場合だけは、試してから決めるのではなく、決めてから配る順番にしてください。

もう1つ、費用として数えにくいものがあります。作り直しが必要だと気づくまでの時間です。同梱型のエンジンは、古くなっても見た目には分かりません。動かなくなって初めて気づく形になり、その日は業務が止まります。条件2で「係を置ける」と答えたなら、作り直す日を先に決めてカレンダーに置いてください。

料金とよくある質問から読み取れること

4つの条件のうち、答えが割れやすいのは条件2と条件4です。ここで「自分では続けられない」「手元の環境を揃えるところから始めたくない」と出た人は、作る作業そのものを外に預ける形に寄ります。

その場合に何が済んでいて何が残るのかは、できることに項目として並んでいます。条件3で挙げたURLの内部指定や拡張機能の持ち込みは、ここで有無を確かめられます。実際にどのサイトがどう扱われているかは対応サービス一覧にあり、社内の管理画面のような一般には出てこないサイトも含めて、240以上のプリセットからすぐ作れる形が用意されています。条件3を自分で1つずつ調べる代わりに、一覧で近いサービスの設定を見るという回り道もあります。

条件1で本数が増えると答えた人は、費用の形も確認しておく価値があります。料金には作れる本数と費用の関係が書かれていて、1本だけ試す段階と、5本10本と増やす段階では判断が変わります。条件2の「作り直しを誰が押すか」に関わる扱い、たとえばOSを上げたあとどうなるのかといった点はよくある質問に並んでいます。

選び方の話は、突き詰めると「自分がこの先も手を動かし続けるか」の一点に戻ります。続けると決めたならコマンドで作る形が最も自由度が高く、続けないと決めたなら更新が自動で乗る形が最も安く済みます。どちらでもない状態のまま機能表を見比べている限り、答えは出ません。