ハクソク

世界を動かす技術を、日本語で。

HNに表示: MacのElectronアプリをRustで書き直しました

362日前原文(desktopdocs.com)

概要

  • Desktop Docs はAI搭載のファイルエクスプローラー
  • 画像・動画の内容 で高速検索を実現
  • 完全ローカル処理 でプライバシーを確保
  • サブスクリプション不要 の買い切り型
  • Rust/Tauri への移行で軽量化と安定性向上

Desktop Docs：AIファイルエクスプローラーの特徴

  • AIによるコンテンツ理解 画像や動画を ファイル名ではなく内容 で解析・検索

  • 100%ローカル処理 全データ処理が Mac上で完結、クラウドアップロード不要

  • 圧倒的な検索速度 0.3秒以内 で検索結果表示

  • 買い切り型ライセンス サブスクリプション不要、一度の支払いのみ

  • 世界中のプロが信頼 制作スタジオやクリエイター の導入実績多数

    • 50以上のアクティブスタジオ
    • 1000人以上のプロクリエイター

  • AI Tech Suiteで高評価 2024年の トップレートアプリ に選出

主な機能とメリット

  • 自然言語検索 「夕日の写真」「犬が映っている動画」など 直感的なクエリ に対応
  • 画像類似検索 参考画像をアップロードし、 類似・重複・関連画像 を即座に抽出
  • クロスフォーマット対応 主要な 画像・動画フォーマット を一括管理
  • 完全ローカルのファイル管理 ファイルはすべてMac内 で管理、データ流出リスクなし
  • インデックス無制限 無制限のファイル登録 で大規模ライブラリも一元管理
  • クイック編集 重いアプリ不要 で軽微な編集が可能
  • 知識ベース化 ファイルの 体系的な整理・活用 を実現

導入効果とユーザーの声

  • 管理作業の自動化 AIが面倒なファイル探しを代行
  • 10倍速いファイル検索 従来比10倍のスピード で目的のファイルを発見
  • インスピレーションの源泉 クリエイティブな混沌を整理 し、創造性を最大化

ファイル互換性とサポート

  • 全主要フォーマット対応 画像・動画すべて を一括管理
  • FAQとアップデート情報 活用法・最新情報 を随時提供

Rust/Tauri移行の舞台裏

  • ElectronからRust/Tauriへの全面リビルド
    • アプリ容量83%削減 ：1GB → 172MB
    • インストーラー容量70%削減 ：232MB → 69.5MB
    • インデックス速度向上 ：38分の動画も約3分で処理（従来は10-14分）
    • 安定性大幅向上 ： ランダムクラッシュ解消
  • Electron時代の課題
    • 大容量・高負荷 ：Chromiumベースで200MB消費
    • 大量ファイル処理の非効率 ：複雑なワーカーシステムが必要
    • UIの複雑化 ：旧UIの移植ではなく ゼロから再設計
  • Rust/Tauri採用の決断理由
    • Swift未経験・Rust初心者 からの挑戦
    • パフォーマンスと安定性重視 の選択
  • 技術的チャレンジ
    • Rust/Tauriコミュニティの成熟度不足
    • Redisバンドルの権限管理
    • CLIP埋め込みによるローカルセマンティック検索
  • リビルドの成果
    • コア機能の圧倒的向上 ：インデックス・検索のパフォーマンスが飛躍
    • 作り直しの価値 ： 既存コードの破棄も最適解

AMA（なんでも質問受付）

  • Rust/Tauri移行の詳細
  • Redisバンドルの課題と解決策
  • CLIP埋め込みによるローカル検索の仕組み
  • Electronの限界とRust/Tauriの優位性

Hackerたちの意見

目的地がMacアプリだったなら、Rust/TauriじゃなくてSwift/SwiftUIの方が良かったんじゃない？ちょっと気になっただけなんだけど。

└

見てくれてありがとう！Desktop Docsの目標はクロスプラットフォーム対応なんだ。Windowsサポートのリクエストがたくさん来てるから、Rustを選んでWindows版に向けて準備してるんだよ。

└

同じ質問をしようと思ってた。Swiftって結構いい言語だし、Rustの利点もいくつか持ってるみたいだよね。別のコメントでも聞かれてたけど、CLIPsの統合についての詳細も知りたいな。アプリをポートする必要があった理由の話、面白かったよ。

└

私も気になる！デスクトップアプリを作る予定なんだけど、Swiftはしばらく使ってないし、Rustもまだ初心者なんだ。Tauriはすごく期待できそう。Electronアプリは本当に嫌い。超速いマシンでも起動が遅すぎるから。何かアドバイスあったら教えて！

最近、逆のことをやったよ（Tauriでプロジェクトを始めて、Electronに移行した）。異なるプラットフォームで使われるウェブビューのレンダリングの違いにフラストレーションを感じたから。切り替えてからクロスプラットフォームのUIバグに遭遇した？あなたのUIのニーズはシンプルそうだけど、計算は複雑だから、追加のQAのトレードオフはまだ価値があると思う。私の経験が珍しいのか、レンダリングの違いが一般的なのか気になってる。Tauriは2.0にしたの？1.0の途中で2.0の安定版が出たけど、移行は大変だったし、ドキュメントも全然足りなかった。ドキュメントは整理された？

└

レンダリングの違いって言うと、実際のHTML/CSSのレンダリングのことを指してるの？それともJSのサポートの違いについて言ってるの？

└

私はウェブ開発者で、TauriやElectronはあまり使ったことがないんだ。なんで異なるプラットフォーム間のレンダリングの違いがそんなに問題になるのか疑問なんだ。ウェブアプリを作るときも同じような課題に直面するから、あまり変わらないと思うんだけど。

└

実は、Tauriのバージョンではまだクロスプラットフォームサポートを展開してないから、どうなるか見てみるつもり。幸い、私たちのUIのニーズはシンプルなんだ。Tauriでどんなレンダリングの違いを見たの？あなたのアプリにとって最も良かったプラットフォーム、または最悪だったプラットフォームはあった？次はWindowsをサポートしたいんだ。Electron版では、IntelチップのMacでバンドルしたバイナリが動かない問題があって、すごく頭を悩ませたから、Tauriでの再構築ではまず一つのプラットフォーム（AppleチップのMac）に集中することにしたんだ。Tauri 1.4を選んで、今のところ問題はないよ。2.0の移行のドキュメントも確認してみないとね。

└

Tauriでのレンダリングの違いに対処するのは、普通のウェブアプリを作るのとそんなに難しくないよね？

└

https://kreya.app ではシステムウェブビューを使ってる（Tauriじゃなくてカスタム実装だけど）。プラットフォームの違いはあまり問題にならないよ。ポリフィルでほとんどの問題は解決できてるし、Linuxで自動化されたエンドツーエンドテストを実行してるから、大体の問題は見つかる。個人的には、ユーザーがどれくらい古いウェブビューのバージョンを使ってるかを把握するのが一番難しいと思う。特にLinuxとmacOSでね。WindowsはWebView2の実装がうまくいってる。

└

同じような経験をしたよ。1ヶ月後にTauri 2.0からElectronに切り替えた。UIの不一致があっただけじゃなくて、SafariはポップオーバーAPIみたいな面でChromeに遅れをとってるし、Tauriのビルドやコードサイン、CDエコシステムはめちゃくちゃ散らばってる。使ってた時は、IAPもTauriにはあんまり選択肢がなかったし、ドキュメントやリソースも見つけられなかった。

└

もうハネムーン期間は終わったね。「XからYに移ったけど、すごく好きだった」っていう投稿は、ハネムーンのポストカードみたいなもんだよ。

└

最近Tauriが発表したんだけど: 「今年はCEFやSERVOベースのウェブビューなど、たくさんのエキサイティングなイノベーションを用意してるよ…」彼らのDiscordからの情報だね。

└

Tauriが異なるプラットフォームで異なる表示を引き起こすのが気になるな。Tauriのフロントエンドはウェブサイトだから、プラットフォームでウェブサイトが同じように機能するなら、アプリも同じはずだと思う。もしウェブサイトがブラウザの違いを隠す何かを使っているなら、Tauriのアプリ開発者もそうすべきだよね。

└

もしChromeOSプラットフォームだけが残ったら、ウェブはもっと良くなると思う。標準や複数のベンダーなんて必要ないよね。

私はMacユーザーでもないし、うちのチームもRustでの書き直しを検討してるわけじゃないけど、この投稿には感謝してる。これが「Show HN」から期待する内容だね。実際の小さなビジネスのために必要な技術的なトレードオフを、ちょうどいい長さでまとめてくれてる（その部分は仮定だけど）。経験をシェアしてくれてありがとう。

└

経験をシェアできて嬉しいよ。これについては長い間議論してたんだ。すでにある程度動いているものを再構築するのは大変だけど、今回は結果に満足してる。

前の会社ではWindowsとmacOS用のデスクトップElectronアプリを維持してたけど、すごく重かったし、Squirrelでのアップデートが面倒だった。GUIはウェブSPAアプリ（Infernoを使用）にして、C#とSwiftで小さなネイティブアプリを2つ作って、ウェブビューを読み込んだり他の作業をさせた。アプリのダウンロードサイズとメモリ消費は約90%減ったよ。配布とアップデートも各プラットフォームのアプリストアに移したし、すごく良い決断だった。

└

いいね。移行にはどれくらい時間がかかったの？

└

ネイティブアプリストアを通じた配布とアップデートを褒めてるのを初めて見たよ。ユーザーへのアップデートの時間や、承認プロセスを通過するかどうかの不確実性が理由の一部だね。Squirrelについては何も知らないけど、ネイティブに移行して改善された点は何だったの？

  • メインLPの「試す」というアクションは、トライアルがあることを示唆してるけど、結局買うページに飛ぶだけだね。1週間くらいのトライアルは絶対に必要だよ。 - 永続的なフォールバックライセンスのファンだけど、$99は高いハードルだね。もっとクリエイターやスタジオをターゲットにしてるんだろうけど、一般消費者向けなら$20-25くらいが妥当だと思う。 - この投稿ではパフォーマンスについて言及してるけど、ランディングページでは全然触れてないね。38分の動画は多くの潜在顧客にとってすごく重要だと思う。いろんなマシンでのベンチマークや、並列タスク処理、VRAMの影響や要件についての情報が欲しい。何百時間から何千時間の動画処理がどうなるのか、知りたい。 - Electronがどうやって処理のボトルネックを引き起こして、10-14分から3分に短縮されたのか、驚いてる。ElectronはCLIPやおそらくffmpegへの作業のオーケストレーションだけを担当してたんじゃないの？どうしてそんなにオーバーヘッドが増えたんだろう？ - 私も似たようなメディア検索ツールをElectronで作ったけど、パフォーマンスの問題にはあまり直面しなかった。 - Electron（またはTauri）で作る動機の多くはクロスプラットフォームだと思うけど、なんでMacだけなの？特にNVIDIAが活躍できるようなバルクメディア処理のために。 - 私も最近、10年ぶりにSwiftをコードして、Tauriを調べたけど、新しいアプリのためにSwiftを選んだら、今のところすごく楽しくて、2014年頃の最後のSwiftアプリと比べて劇的に改善されてる。 - LPのアクティブユーザーについての情報が本当なら、すでにそこそこ成功してるみたいだね（おめでとう）。スタジオやクリエイターの周りに関係やオーディエンスはもうあったの？マーケティングについても聞いてみたいな。
└

フィードバックありがとう！トライアル用のインフラはまだ整えてないけど、将来的には考えてるかも。似たようなツールを作ったのはすごいね。リリースしなかった理由は何だったの？需要があれば、次の数ヶ月でWindowsとLinux版を出す予定だよ。HNやRedditでいろんなローンチを通じてユーザーを獲得して、最小限のLinkedInプロモーションで進めてる。ほとんど口コミで、すごく期待できる結果が出てるよ。Electronと動画処理のパフォーマンスについては、深く掘り下げることがたくさんあるね。Electronの専門家だとは思ってないから、もしかしたらワーカーの使い方が間違ってたのかも。Rustへの移行の一環として、フレーム数を減らすためにシーン検出を実装したら、処理負荷がかなり軽減されたよ。ffmpegにGPUアクセラレーションのフラグも追加して、意味のある改善が得られた。画像埋め込みのバッチ処理も、ある程度までは良い改善だったけど、モデルインスタンスがクラッシュし始める前に限界があったね。

開発者がどれだけ苦しむ覚悟があるか（そしてユーザーにも苦しんでもらう）を見るのは悲しいね。HTML/CSS/JSスタックを手放したくないから。そもそも正しく設計されてないスタックなのに、現代のUIアプリには向いてない。例えば、Flutterの方がデスクトップアプリにはずっと良い選択だと思う。

└

どういうこと？

└

Flutterではまだ複数ウィンドウが使えないから、デスクトップアプリの開発には向いてないね。

└

一方で、彼らは製品を出荷して、実績を示し、最初の有料顧客を獲得したのはウェブスタックでのことだったね。そして、HNのトップコメントスレッドでは、Tauriのクロスプラットフォームの欠点について話している人たちがいる。残念ながら、すべてはトレードオフだね。

└

ちゃんとしたデスクトップGUIアプリを作りたいなら、wxWidgetsかQtWidgetsがいいよ。

チームが効率よく働けるように、小さな内部ツールをたくさん作ってるんだ。これまではWinFormsを使ってたけど、最近WinUI3を試してみたら、ひどいことになった。全然準備ができてなかったよ。その後、Reactを使ってAzureの静的サイトにアップロードして、誰かが実行可能ファイルを欲しがったらTauriを追加することにした。君が言ってることがわかるよ。Tauriはほとんどの部分をカバーしてくれて、競合よりもファイルサイズがずっと小さいのがいいね。Webとデスクトップで同じコードを出荷できるのは、本当に嬉しい。

└

Tauriを使って、Electronアプリでサポートしていたのと同じ機能を、ずっと小さいバイナリでサポートできるのは嬉しいね。

現代のクロスプラットフォームフレームワーク、例えばTauri、Flutter、Electron、React Nativeなどを比較した最新のベンチマークが見てみたいな。重要な指標としては、- ターゲットバンドルサイズ - メモリ使用量（RAM） - スタートアップ時間 - 負荷時のCPU消費 - ディスク使用量 - などが考えられるね。それに、Tauriのようなフレームワークには、WebViewの互換性マトリックスを含めるといいと思う。プラットフォームごとに使われるWebViewのバージョンによって、レンダリングの挙動やパフォーマンスが大きく変わるから（例えば、macOSのWKWebViewとWindowsのWebView2、またはLinuxのGTK WebKitなど）。この違いはUIの忠実度やパフォーマンスに影響を与えるから、そういう違いを視覚的なフォーマットや表で示すと、開発者がより良い選択をするのに役立つと思う。

└

こういう比較が見てみたいな。

すごい仕事だね、移行がどれだけ面白かったか想像できるよ。もしよければ、なんでRedisを使っているの？sqliteみたいなもので十分じゃなかったの？Tauriでの一番の課題は何？私もElectronアプリで作業していて、ローカルの埋め込みもやってるんだけど、CPU集中的な作業はRustで書かれたnodejsアドオンで行っていて、Neonを使ってるんだ（https://neon-rs.dev、このライブラリには本当に感謝してる）。これが私たちにとっていいバランスなんだ。

└

ありがとう！Rustを選んだのは、sqliteをベクター検索拡張で調整できなかったからなんだ。Redisの代わりに使うのも可能だと思うけど、それはまた別の最適化の話だね。Neonもチェックしてみるよ。

自分のプロジェクトでも同じことをやったよ。USB顕微鏡用に最適化したシンプルなウェブカメラビューアを作ったんだけど、これに合うものが見つからなかったからね。基本的に、機能は全部レンダラーに実装したんだ。App Storeに提出する予定で考えてたら、500MBのウェブカメラビューアはあんまり良くないなって気づいて、Tauri V2に移植して15MBくらいまで減らしたよ。

└

それ、めっちゃいいね！お疲れ様！名前は何ていうの？今週、アプリストアの提出作業してるんだ。