Tauri on mobile 現状確認会

tauri.app

Tauri とは

Electron代替として作られたRust製のGUIアプリケーション開発ツールキット。

ユーザーは各プラットフォームのWebViewで動くHTML+JavaScriptでUI開発をして、裏側はRustで書いたネイティブバイナリにコンパイルされるプログラムを呼び出す。

実際の実装のイメージが以下で、Electronに使い方は似せられている。

tauri.app

Electronは特製ChromiumとNode.jsをユーザーのアプリケーションに同梱することでポータビリティを担保させているのに対して(find /Applications -name "Electron Framework.framework" コマンドを実行してみると大抵どんな環境にもElectronが10匹ぐらい居る)

TauriはOSが用意しているWebViewにリンクして、スクリプトもネイティブバイナリにするので早くて軽い、というアーキテクチャのようだ。

GUIツールキット界隈ではこのようにプラットフォーム側かエンジン側のどちらに寄せるかという選択自体はよくあり、プラットフォームや動作環境の差異で挙動が変わったり、安定するかわりに成果物が重くなったりと一長一短の歴史ではあった。

ここ何年かの変化としてはWindowsのバージョンシェアやWebView開発環境が一新されてレガシーに引きずられることがなくなったという部分がある。

あとGoやRustのように依存が少ないシングルバイナリをクロスコンパイルできるツールの発展もTauriが出てきた背景としてありそう。

時系列的にはこうだと思う。

製品	時期
Electron	2013年
Tauri	2019年
WebView2	2020年

そしてElectronはApp Storeレギュレーション的にiOS版ビルドを吐くのは難しそうだけど、Tauriならできそうというわけでモバイル対応が進んでいるらしい。

WRYとは

github.com

このディオ・ブランドーみたいな名前のコンポーネントはWebView Rendering librarYの略で、WebViewで動くアプリケーションとバックエンドのブリッジとして機能しているらしい。

内部的にさらにtauri-apps/taoというコンポーネントと組合せてWebViewに任意URLを与えて直接Windowを持つアプリケーションとして実行できるようになっていた。

https://github.com/tauri-apps/wry-mobile というリポジトリも作られているが更新されていなく、モバイル系の開発はどうやらtauri-apps/wryの方からリンクされているHackMDページに情報があるらしい。

hackmd.io

このドキュメントからさらにリンクされているのが cargo-mobile というツールで。gomobileのようなモバイルアプリ向けのビルドをサポートするツールのようだ。

cargo-mobile

なぜかこっちも分裂していて、さらにそれぞれのリポジトリでコミットされている。

• https://github.com/wusyong/cargo-mobile
  • https://github.com/BrainiumLLC/cargo-mobile

すこし眺めてみたところ、オリジナルとTauriメンテナのwusyongさんによるフォークという関係のようだった(wry-mobileのドキュメントからリンクされているのはwusyong/cargo-mobileの方。)。

TauriはもともとRust界隈のやる気勢たちによってコミュニティでメンテナンスされているが、モバイル対応をメインでやっているのはwusyongさんだけだった(モバイル開発まわりには明るくないらしい)。

あくまでも検証中の段階らしく、IPCの動作の確認とシュミレータ向けのビルドやデバッグをしていることが分かる。

tauri-apps/tauri

tooling/bundler/src/bundle/macos/ios.rs

アプリケーションのバンドル化のコードにmacos->iosがあることが分かる。

iOS SDKとのインテグレーションがあるというわけではなく、アセットファイルの生成ぐらいの処理が定義されている。

2021年に最初にコミットされたバージョンからあまり変更がなかった。

tauri/tooling/bundler/src/bundle/settings.rs

ビルドできるバンドルの種類。Androidの定義はなく、apk,appbundle,ipaなどのフォーマットに関するコードも今はない。

/// The type of the package we're bundling.
#[derive(Clone, Copy, Debug, Eq, PartialEq)]
#[non_exhaustive]
pub enum PackageType {
  /// The macOS application bundle (.app).
  MacOsBundle,
  /// The iOS app bundle.
  IosBundle,
  /// The Windows bundle (.msi).
  WindowsMsi,
  /// The Linux Debian package bundle (.deb).
  Deb,
  /// The Linux RPM bundle (.rpm).
  Rpm,
  /// The Linux AppImage bundle (.AppImage).
  AppImage,
  /// The macOS DMG bundle (.dmg).
  Dmg,
  /// The Updater bundle.
  Updater,
}

分かったこと

• モバイル対応はまだ検証中
• iOS/Android SDKと連携する部分の開発はされていない。
• wusyongさんの助けが必要

ここまで書いたけど単にWebViewで動くHTML+JavaScriptでアプリ開発をしたいだけならIonicを使うのがいいと思う。

ionicframework.com

Rust好きやデスクトップアプリケーションとの共通化を見据えてTauriの開発に参加したい人にはフィットするかもしれない。

iOSDC JAPAN 2022にプロポーザル提出した #iosdc

iosdc.jp

nextstep.fm でみんなすごい気を遣ってSwiftの話をしていたので、ウッ・・後ろめたい・・！　と思ってiOS界隈に為になることをするぞとやる気になってiOSDC JAPAN 2022にプロポーザル提出した。

(このようにただの感想ブログにリンクを張ったら先方にPVが流入してしまうということがよくあるのが最近の困まりどころ)

fortee.jp

「全部Swiftで作るWebアプリケーション」はいわゆる縛りプレイ系の内容で、特定の技術のカンファレンスでまぁまぁ行われている伝統的な手法。僕の記憶に残っているのはyouchanさんがOpal芸をよくやっていた気がする。

全部Swiftで作れるかは今をもっても判明していなくて、SwiftWasmではじめるWebアプリ開発 があるからどうにかいけるのでは？？？　程度の目論見がある。

僕は普段からkateinoigakukunさんの活動を尊敬しており、SwiftWasmをカンファレンス駆動開発で実際に使ってみたいと思ったこともあります。

fortee.jp

「サーバーサイドSwiftで学ぶバックエンド開発」は上記のトークを需要を伺いよりオーソドックスな路線に下げたもので、フロントエンド側をあきらめバックエンド側に重点を置いた。

最近Cloudflare Workers上のノンフレームワークな環境でコード書いていて、ルーティングとかJWT認証やCookieの暗号化を意識して実装する必要があったため馴染みがあり。実装例もVaporを読み解けば分かりそうだなと感じたので、この内容にした。

過去のiOSDC JAPANを思い起すに僕は抽象的な話ばかり好んでいた傾向があったので、次何かやるならストレートにコードがたくさん出てきそうな内容にしたいなぁと前から思っていた。

いづれにせよ数年iOS開発から遠ざかってしまって愛機もAndroidなので、アウトサイダー感もありつつ。採択された暁にはまたSwiftをがんばってキャッチアップしないといけなさそう。

仕事でやっていないということは余暇をこれに当てるしかないので単純に他のことできなさそうでつらい。

そんなブログたちを集めたリンク集(!?)がこちらです

fortee.jp

iOSDC Japan 2022のチケットはこちらで販売中です。

www.eventbrite.com

マネーの教育

www.youtube.com

Youtubeでタレント動画を消費するような視聴者は投資について「今は貧しいけど頭を使ってかしこく大金ゲット」というコンテンツを期待しているが、本当に語りたいことは「所得を増やして資産運用」なので、地味であんまりウケないらしい。

そもそも他人の事業の労働以外の方法で所得を得るということを実践している人がまわりにいないと想像すら難しく。あっちゃん氏やプペル氏が自分の視聴者に向けて事業で所得を得ることを説くと詐欺師や守銭奴的な扱いを受けバッジングを浴びることになる。こうして世間の人に批判され続けることがマネー教育なんだなぁと語っていた。

動画に出てくる投資家(事業家?)はホリエモンのようなタイプのことで、労働で所得を得る想像力の人が思い描くお金を稼ぐ人というは「有名企業で出世して年収何千万」みたいなロールモデルだと思うけど、僕はあんまりどっちにも惹かれてない。Micro ISV や37signals はワナビー的にいいなと思っているけど。

それは新興業界の中のプログラマーという職業が今の時代にたまたま労働条件に恵まれていて、生活環境的にも追い込まれていないってことだと思うが、仮に地方都市で製造業やサービス業に従事していたとしたらどうなっていたのだろう。

ブログのリセット

blog.kyanny.me

Re:のRe:ブログになっていて何やねんという感じだけど関心のある話題だったので反応。

関係ないけど本来のTumblrマイクロブログはこういう使い方をしていた気がする。

閑話休題、自分自身がブログサービスのプロバイダーにいるエンジニアでユーザーたちのことを好きだったらどうするかな、というのを考えていた。

エクスポートツールを勝手に作るのはたぶんやると思う。現にnoteからJSONファイルをダウンロードするツールを速攻作っている。関係者を説得してオフィシャルに実行できるのかはパワーバランスとか人間関係とかあるので自信はない。

note自体はMarkdownを変換して投稿するツールも自作するぐらい使っていた。IPアドレス確認事案(以後、本件と呼称します。以後出てきませんが)の際にnoteの考えるユーザー保護の考えとのズレを感じて使わなくなってしまったけど……

エクスポート機能もMarkdownエディタも、note社のロードマップ自体にはあるようだ。

noteは2022年4月の発表会では、エクスポート機能について「開発が遅れている」と説明していました。 https://news.yahoo.co.jp/byline/yamaguchikenta/20220526-00297873

自分は一般的なブロガーより「サイトが死後にどうなるか」という話題を頻繁にしていると思うのだけど、行動は結構矛盾していてサイトのログやアーカイブ、ドメイン契約はしょっちゅう消失してしまっている。

バックアップとしてはてなグループを使っていたこともあるんだけど、はてなグループ自体が解体されてしまった。

このブログも無数にある投稿先の候補から選んでいる1つだけど、あんまり使い分けるポリシーも定まっていない。

あまりアーカイブの保護をがんばらない理由は、めんどくさいのというのもあるけど、インターネットに公開されているものを他人が自由にできる権利の方を大切に思っているからだと思う。

なくなって困る人自身が保存し、公開すべきであるという意思を持つ人によってホストされてほしい。

例えば趣味のWebデザインというサイトには他人のサイトを転載するためのページがある。

こういう厄介おたくそうなウェブのコンテンツに対する思想は『パターン、Wiki、XP』という本が売れていた時代に結構持っている人々がいた。

その環境の影響を僕も受けているのだと思うし、みんな大好き東亜飯店画像という内輪ネタがあるんだけど、これも僕はそのコンテキストで使っていた。ほんとかよ。

贋作NFTアート

「トークンが紐づいたこの画像こそがオリジナルだ、だからオリジナルの所有権を手に入れるためにトークンを買ってくれ」というのを別のトークンでやった場合、大多数の人たちは「どっちのトークンが本物か」を判別できないのではないか。どちらも「トークンが紐づいた同じ画像」ではあるので。

■ - @kyanny's blog

同じことを思っていたので想像してみた。

なんらかのアート作品がトークンAとトークンBとしてマケプレにあるとする。

(ちなみにこの分野は知識がないので情報は正確ではないが、ただしい知識を得たら訂正する気はある)

トークンを見る

自分が買い手側なら  https://etherscan.io/ などで履歴を見てみる。

取引が行われていたらその量などを見る。

そこで差があったらトークンAの価格はこれぐらいだな、トークンBはこのぐらいだからどっちを買うかと決める、

しかし、明くる日の朝に目がさめたらトークンCで同じ画像がアナウンスされていた。トークンAもトークンBも贋作だったのである。

スマートコントラクトでなんとかする

数量限定トークンにはECRだか何だかの仕様とOSS実装があって。スマコンはそれを継承している。

なのでそのスマコンのアドレスから発行したトークンを辿って本物かどうか特定する。

とかできるの?(知らない)

個人的にはFirefoxのアドオンがあなたの個人情報を抜いてないかどうかインストールする前に解凍してJS読みましょうと言われる並にめんどくさい。

偽スマートコントラクト登場

しかし、明くる日の朝に目がさめたらスマートコントラクトDで同じ画像がアナウンスされていた。昨日のスマートコントラクトが偽物だったのである。

私はかぶっていたメタマスクのその場に叩きつけ、星新一SSSBTDAOミートアップへジョグで出掛けるのであった。

Swiftがこの先生きのこるには

Apple系デベロッパーの人たちがSwift普及のいかんともしがたい現状について話していたので考えてみた。

サーバーサイド用途

サーバーサイドSwiftは現状あまり利用したいケースが見当たらず、モバイルアプリ開発組織のマイクロサービス開発の共通化においてはJVMが枯れているのでKotlinの方に傾きがち。

WindowsやVSCodeやIntelliJ系の非Xcode系開発環境のサポートのハードルも越えるぐらいモチベーションが必要である。

ただユーザー規模はそこそこあり、DenoやDartやHaskellが有効な程度にはWeb開発用途には使えると思われる。苦労しそうだけど。

Wasm化

Wasmにしてブラウザサイドでコードを動かそうという向きもある。拡張用途では周辺ツールの多いRustやCのライブラリ資産のポートもありレッドオーシャンであることは変わりないが、Swiftに限らずWasmアプリケーション化はstdlibを動かす部分(ランタイムというんですかね?)を含めたコードサイズとの闘いも上乗せされそう(にもかかわらずJSのが早かったり)。

あるとしたらiOS/macOSアプリケーションのコードをピンポイントでWeb活用して共通化、という使われ方を想像した。

iPhoneがあと20年ぐらい使われる

iPhoneが今後10年ぐらい使われ続けてそのアプリ開発にSwiftが使われ続けるのは想像にやさしいところだけど、2040年となるとSwiftにももうひとまわり大きな変化が起きていそう。そうしたらSwiftはもっと広く使われているのではないか。

新世代デバイス向けのスクリプティングレイヤーに採用される

3Dゲームを作る時に使われるUnity並に普及したXRスタジオな何かを拡張する手段としてLLVMコードが要求され、なぜかSwiftが組込まれて使われていくという世界線が来る。

Xcode for Windows

Appleにもナデラ的なリーダーがあらわれクロスプラットフォームな開発者取り込み戦略を進めてゆく。なぞの魔術WinObjCとかではなく、Apple自身がWindowsネイティブに動くアプリケーション開発環境を開発する。

ただなんやかんやでみんなそれぞれWebViewで実装し、Electronプロセスを立ち上げ続けるのであった。

新ブラウザ発表

突如としてSafariに変わるまったく新しいエンジンを積んだブラウザをAppleがリリースする。それでは期待されたWeb標準APIが充分に完備され、JSでアプリが作成でき、envoyのようなアーキテクチャでSwiftでブラウザ拡張も作れる。そしてSwiftはWASM生成元として地位を確立するのであった(私はRustで書きます)。

サーバーレスSwift

Testflightのような力技でAppleがどこかのmBaaSを買収。Xcodeからワンボタンでデプロイ可能になり、Apple系デベロッパーはもうこれ以上VPSを借りなくていいんだよ・・と御告げが来る。

あんまり使われなさそう。

まとめ

Appleの将来に依存し過ぎている

メディアに出ているひろゆきを見て10年越しにモヒカン族 (ネット用語) を理解したような気がする

報道番組でのひろゆきの芸風を見てマジレスおじさんの役割を担っているなと思っていたのだけど、それはモヒカン族 (ネット用語) で説かれていた特性に似ているなと思った。

ひろゆきのやっていることは

1. 問題について比喩を使って単純化する
2. 解決方法について空気を読まずに発言する

これの繰替えしであると言える。

比喩を多用するのは自分の視聴者に問題を分かりやすく説明する手段で。「空気を読まない解決策」というのは一部の人には感情的には受け入れられづらいけど客観的には問題に対する論理的に正しい答えであると感じる、ぐらいの意味。

問題を単純化する過程で自分の意図と似わない抽象化がされると詭弁や論点ずらしに感じる人もいそうだなと思った。

でもなんかどこかで聞いたことあるような……　と感じてモヒカン族 (ネット用語)のことを思い出した。

ちょっと検索してみたら「J-CAST ニュース」の記事でotsuneさんによって似た解説がなされていた。

漫画『北斗の拳』の悪役雑魚は平和な村に出没し、村民を斧で殺戮する。一方、ネット上の「モヒカン族」のイメージは、「誤字脱字の指摘は人格否定とは思わない」「ネット上の場の空気が読めない」「殺伐とした議論を求む」「理系の淡々としたノリ」「詭弁と例え話と断言を使いこなす」などだ。 「正しいけれど、シラケる発言」をするので、イラつく。また、古くからネットに接しプログラムやシステムに強い人が多いようで、単なる「荒らし」ではなく、「ぶっきらぼうなのでぎょっとするが、実は単なる天然で悪意が無く、淡々と指摘をしている学者肌の人」が真の正体だとotsuneさんは見る。 https://www.j-cast.com/2006/10/22003464.html?p=all

ひろゆきの場合、飄々とした態度を取るのでぶっきらぼうというよりは、研究分野の専門家が「素人質問で恐縮ですが——」と投げていくるような威圧感があるのだろう。

これらの芸風は掲示板上のテキストでの相互コミュニケーションと相性が良さそうに見えるけど、まさかこれが令和インターネットの動画世代でバカウケするとは思っていなかったので意外な感じだけど、よく考えてみたら匿名掲示板のジャーゴンが巡り巡って若者語やギャル語になっていたのを繰替えし見てきたので既定路線なのかもしれない。

若者にウケるのはなんだろう・・みんな年長者に空気を読むのに疲れているから心地良いんですかね?　といってみるテスト。