36,608 文字
こんにちは。ご依頼いただいた動画の書き起こしを日本語に翻訳します。この動画はモバイルアプリとウェブの基本的な違いについて解説しています。正確に翻訳していきますね。
このチャンネルではよくウェブについて話しています。時々アプリについても触れますが、十分ではありません。今日はその不均衡を少し是正したいと思います。ただアプリについてばかり話すのではなく、アプリとウェブの動作の違いを浮き彫りにしたいと思います。
これは異なるプラットフォーム向けの良いソフトウェアを構築する哲学について少し深く掘り下げていきます。多くの開発者が一方のプラットフォームは単に他方の劣化版だと考え、それらの間の微妙な違いを根本的に誤解しているように感じます。これはFlutterとReact Nativeとネイティブのどちらが優れているかという話ではありません。
これはウェブアプリをモバイルアプリに埋め込むべきかという話でもありません。これはプラットフォーム間の根本的な違いについての話です。もしあなたがウェブ開発者でモバイル向けに構築しているか、モバイル開発者でウェブ向けに構築しようとしているなら、これらの異なるプラットフォームに対して正しいことをするための良い出発点になるかもしれません。
これらすべてについて掘り下げるのが本当に楽しみですが、その前に収入を得る必要があります。今日のスポンサーからの簡単なメッセージの後、本題に入りましょう。
皆さんに正直に言いますが、ウェブアプリを構築するのはこれまでになく簡単になりました。しかしモバイルアプリは、改善されたとはいえ、まだ始めるのは全く滑らかではなく、間違いを犯すのもあまりにも簡単です。
それは今日のスポンサーであるInfinite Redに最初に連絡しない限りの話です。Infinite RedはあなたのReact Nativeアプリを可能な限り最良の方法で始める手助けをしてくれます。すでにReact Nativeアプリを持っていて洗練させ作業しやすくしようとしているか、ゼロから構築しようとしているか、あるいは会社の多くの人が貢献できるようにネイティブアプリをReact Nativeに移行しようとしているなら、連絡すべき人たちは他にいません。
彼らはオンボーディングのブートキャンプからアプリをゼロから構築することまで、何でもやってくれます。彼らが単なるランダムなコンサルタント会社なら懸念も理解できますが、そうではありません。彼らは私が知る中で最もコミュニティに深く関わっている人たちです。スポンサーモデルに切り替えた時、最初に連絡してくれた一人がJamonでした。
彼は長年の私の良き友人であり、最初のサポーターの一人です。彼は私たちがやっていることをほぼすべて見ています。彼は深いコミュニティメンバーです。チャットに定期的にいる人たちに聞いてみてください。彼らはおそらくJamonのポッドキャストを見ています。彼は理解しています。私の言葉を信じる必要もありません。
Infinite Redと協力したことのある信じられないほどのブランドリストを見てください。彼らはAmazonからExpensifyまでStarbucksまで、あらゆる種類の異なる製品で多くの企業を支援してきました。結果は自ら語っています。これらの企業が戻ってくるには理由があります。Infinite Redは素晴らしい協力相手ですが、もし私の言葉を信じるなら、私がT3 Chatのモバイルアプリで間違いなくInfinite Redと協力することになるだろうということを知りたいかもしれません。
彼らは私がそのような形で本当にコミットするのに十分信頼できる唯一のグループです。はい、私は彼らをそれほど信頼しているので、私のビジネス全体を彼らに賭けています。彼らがスポンサーしているかどうかにかかわらず、私は一瞬でも彼らを推薦するでしょう。彼らがそうしているという事実はそれをさらに簡単にします。Infinite Redに今日のビデオのスポンサーになってくれたことに改めて感謝します。
soyv.link/infiniteで今日彼らをチェックしてください。
最大の違いは、まず何よりもルーティングだと思います。これが何を意味するかは後で詳しく説明します。次に考慮すべき大きな部分はプラットフォームです。ウェブプラットフォームとモバイルプラットフォームは非常に異なり、考慮すべき多くのニュアンスがあります。
次に機能があります。これはプラットフォームの一部ですが、カメラやストレージなどとのインターフェースなど、話す価値があるほど十分に異なります。また、アプリケーションのバックグラウンド機能も重要です。そしておそらく最も苛立たしいのはデプロイメントです。アプリケーションの異なるバージョンをデプロイし管理するプロセスは、ウェブとはまったく異なります。
これは私たちが取り組むための良い出発点だと思いますし、確かに途中で多くの異なる接線に入っていくでしょう。ルーティングは長くなるでしょうから、まずデプロイメントから始めたいと思います。そうしましょう。ここを見ている人のほとんどはすでにウェブ開発者か、少なくとも最新のサイトを構築したことがあると仮定します。
そうでない人のために、ウェブでのデプロイがいかに簡単かを手短に示しましょう。index.htmlに触れてみましょう。素晴らしいHTMLファイルができました。インターネット上に置いてみましょう。NPX Vercelデプロイ。はい。はい。いいえ。デモデプロイ。これで大丈夫です。完了しました。なんと難しい挑戦でしょう。
ウェブへのデプロイはとても大変です。明らかにこれは非常に単純で基本的なプロジェクトですが、もっと複雑なものを構築することもでき、デプロイパイプラインが必ずしも複雑になるわけではありません。モバイル側では、そうではありません。リリースするだけの複雑さのレベルは本当に高いです。
しかし、アプリケーションがより複雑になっても、デプロイがそれほど難しくなるわけではありません。これをアプリの複雑さに対するデプロイの複雑さという観点で考えてみましょう。この下の軸をアプリの複雑さ、もう一方の軸、y軸をデプロイの複雑さとします。ウェブアプリをデプロイする場合、ウェブアプリの複雑さがデプロイの複雑さを必ずしも意味ある形で増加させるわけではありません。
アプリが単純である限り、デプロイも非常に簡単に始まります。アプリが少し複雑になるにつれて、デプロイの複雑さもわずかに上がりますが、モバイルではこれが少し異なります。はるかに高いレベルの複雑さから始まり、追加の権限やAppleのレビュー中に煩わしいものがある場合、少し複雑になるかもしれませんが、それほど多くはありません。
アプリがより複雑になるにつれて、デプロイの複雑さには非常に小さな曲線の上昇がありますが、はるかに難しいポイントから始まります。このギャップは、ウェブアプリとモバイルアプリの開発者体験を比較するとき、私がよく話すことです。なぜならこのギャップは最悪だからです。ウェブで作業しているプロジェクトを人々に試してもらうためにリリースするのはとても簡単です。
ウェブプロジェクトを構築していて、母に素早く試してもらいたい場合、リンクを送るだけで彼女は試すことができます。アプリを構築していて母に試してもらいたい場合、すでに彼女をTestFlightに登録していることを願うだけです。そうでなければ、頑張ってください。これはiOSやAndroidのようなアプリケーションプラットフォームの最大の欠点の一つだと思います。
すべての素晴らしいAIアプリビルダーなどのツールで経験を生成することがこれまでになく簡単になっている世界では、このギャップは最悪です。アプリを構築する実際のプロセスでは、複雑さまで本当に遠くまで行けますが、人々にそれを届けるためにはアプリストアのウィザードにならなければなりません。これは最悪です。これらの素晴らしいツールや技術を使って一日でここからここまで行けるのに、それをデプロイするのに一週間かかるとしたら、それはAppleの扱いに苦労するでしょう。それは最悪です。
Androidもここではより良くありません。多くの点で、Androidは実際にはより悪いと信じられないかもしれませんが、そうなのです。そう、デプロイメントは厳しいです。これが存在する最大の理由は、資本主義の利点と欠点のようなものです。ウェブは比較的自由市場です。ウェブへのデプロイには非常に多くのオプションがあります。
私は今現在5つを使っていて、常に新しいものが出てきています。Vercelのような素晴らしいオプションがあり、最新のウェブツールとテクノロジーを活用して、サーバーレス環境全体で自動的に構築、デプロイ、スケーリングしてくれます。Netlifyのような製品があり、既存の古いレガシーシステムの上に最新のウェブインフラを追加しようとしている企業にとって、それをさらに簡単にしています。
Cloudflareのような企業があり、世界中どこでもデータを処理することを非常に簡単にし、デプロイはこれまでになく簡単になりました。以前はHerokuのような友人たちが革命を起こし、当時は画期的で、アプリケーションをデプロイする経験に新しい基準を設定しました。
モバイルでは、AppleとGoogleとExpoのような一部のプロセスを合理化する時折の努力しかありません。しかし、ウェブやサーバーという一般的なものを構築しているわけではないため、はるかに難しいです。常に期待が変わる非常に特定の混沌としたプラットフォームのために構築する必要があります。
ExpoよりもVercelを構築する方が著しく難しいです。信じられないかもしれませんが、完全に信じていますが、一週間でVercelのMVPを構築できるというのが私の狂った大胆な声明です。Expoは構築できません。これは狂っているように聞こえるかもしれませんが、1000%信じています。Verselのようなデプロイメントプラットフォームは、その能力において信じられないほどです。
彼らがやっているいくつかの素晴らしいインフラ作業を複製することはできないでしょうが、GitHubリポジトリにリンクしてAWSにデプロイするというアイデアは、本当に望むならほとんど知らないAzureのようなプラットフォームでもDIYできるでしょう。しかしExpoはできません。Expoアプリケーションサービスは、コンピュータ上のコードを取得してネイティブアプリ用に構築・デプロイするのを実際に簡単にしたという点で、ソフトウェア開発における信じられない成果です。しかし、始めるのは非常に難しいです。
そして、EASを使用している場合でも、これらのプラットフォームは非常に奇妙なため、問題が発生するでしょう。Jamがチャットにいます。彼を知らない場合、彼はInfinite RedのCTOです。彼は古い友人で、皆さんが私を知る前からのチャンネルのファンです。また、彼らが今日のエピソードのスポンサーである可能性も高いです。
そうでなくても、彼らは将来他のものをスポンサーするでしょう。彼らは一緒に働くのに素晴らしいです。React Nativeアプリの助けを探しているなら、彼らに連絡してください。この部分は有料ではありません。これは単に彼らを愛しているだけです。モバイルウィザードであるJamonさえも、AppleとGoogleのコンソールで証明書やプロビジョニングプロファイルに費やした時間の量で、別の子供を持つことができたと言っています。
そうですね。そして子供にどれだけの仕事があるのかわかりませんが、それが多いことは知っています。なぜならそれは狂っているからです。また、ExpoはApp Store上にExpo Goを持っていたことが指摘されました。URLやQRコードを送ることで誰でも自分の電話で読み込むことができ、それは素晴らしかったです。
残念ながらAppleは数年前にそれを殺しました。Expo Goに詳しくない場合、それはExpoチームが作った本当にクールなものの一つです。ラップトップでローカルにアプリを作業しているとき、変更するたびに新しいネイティブバイナリを構築して電話に送信する代わりに、Expo Goと呼ばれるクライアントを開くことができます。
CLIで生成されるQRコードをスキャンすると、あなたの電話はホットリロードでコンピュータからのコードを実行するようになります。選択したエディタでコードファイルを保存すると、電話が最新バージョンで自動更新されます。それは素晴らしいです。誰かがこれは嘘だと言っています。Expo Goはまだ機能していて存在します。
ローカル開発では機能します。以前にできたことは、そのQRコードをサーバーのどこかに実際のURLにデプロイして、ユーザーがスキャンしてアプリでネットワークからデータをロードしてアプリを試せるというものでした。それは本当にクールでした。Snacksではありませんでした。これは独自の別のものでしたが、Appleはそれを潰しました。なぜなら人々はAppleが承認していないソフトウェアを使用するためにそれを使用していたからです。
ここでの私の熱い見解、そしてこれが私がこのビデオを作りたかった理由の一つですが、Appleの支配は終わるかもしれません。AppleとGoogle、Epic Games、およびいくつかの他の利害関係者の間のさまざまな裁判を注意深く見ていましたが、特にGoogleのケースは悲惨でした。そのGoogleケースの最終結果は信じられないものでした。
この部分で引用を間違えていなければいいのですが、覚えている限りでは、Googleに対する5年間の判決で、まず他のすべてのアプリストアにGoogle Play Storeカタログへの完全なアクセスを許可する必要があります。これは狂っています。ジャッジがGoogleの独占が非常に不条理で潜在的に違法だと判断し、5年間すべての他のアプリプラットフォームにアプリカタログへの完全なアクセスを許可することで対抗しなければならなかったという事実。
また、Google Play Storeを通じて他のアプリストアを配布できるようにする必要があります。本当に狂っています。これがすべて文書化されると、Epic StoreやAmazon Fire StoreをPlay Storeを通じてインストールできるようになります。そして間違いなく最も重要なことに、Googleはもはや独占的にそのアプリストアをバンドルするためにメーカーに支払うことができなくなります。
以前、Googleはサムスンのような会社に対して、Play Storeのみを持ち、他のストアを持たないように支払っていました。GoogleはPlay StoreがAndroidのアプリのための唯一のプラットフォームになることを本当に望んでいました。裁判で非常に大敗したため、今後数年間でAndroidで最も人気のないプラットフォームになる可能性があります。本当に狂っています。
この判決について私は興奮しています。なぜならGoogleとAppleの両方がストアの運営方法が、違法でないとしても違法であるべきだと私が主張する方法で行っているからです。モバイルプラットフォームのように重要なプラットフォームでは、選択したソフトウェアをインストールできるはずです。ユーザーが電話を購入するとき、彼らは使用が制限されているアプリケーションについて考えません。
2020年にiPhoneを購入し、2022年にXboxゲームストリーミングアプリが使えないことを知ったとしたら、Appleが映画ストリーミングと音楽ストリーミングは完全に問題ないが、ゲームストリーミングはリモートソフトウェアプラットフォームであり、それはアプリストアの代替であるため許可しないことを決定したからということになります。
それは許されるべきではありません。Appleは異なるアプリのカテゴリが存在できるかどうか、ユーザーがデバイス上で持つことができる異なる経験を制御できるべきではありません。変更する必要があります。これは今変わり始めていると思います。このGoogle判決はAppleの以前の勝利をはるかに脆弱にします。
これを前例として持つことは、次に誰かがApp Storeでの制限についてAppleを訴える場合、はるかに勝訴する可能性が高いことを意味します。これをすべて言っている理由、そしてこれは法的アドバイスではなく、私は弁護士ではありません。実際、これらのことの一部について話すのにも資格がないと言えるでしょう。現実を見ましょう。
私はAppleに挑戦する人を望んでいます。これはどういう意味でしょうか？私は非常に具体的なことを意味します。私の夢は、アプリのアイデアを持つ人、それが本当にクールなものや、友達との世界を作るようなゲームのような馬鹿げたものでも、そのアプリが存在するように、Bolt、V0、AZなど何でも使ってプロンプトできることです。
彼らは素早く何かを手に入れて、電話で遊び、感動し、誇りに思うことができます。ここで彼らはリンクやQRコードなどのスクリーンショットを撮り、友達に送り、Twitterに投稿し、TikTokで見せることができます。そして他の側にいるあなたはそれをスクリーンショットできます。
私はTikTokを見ています。彼らは「私のアプリを試したい場合、これを使ってください」と言います。あなたはスクリーンショットを撮ります。あなたは魔法のプラットフォーム、何と呼びたいかをオープンします。今のところTMPと呼びましょう。TMPアプリを開くと、写真へのアクセスがあり、これがスクリーンショットにあることを認識します。瞬時にその体験を開き、必要なコードをロードします。おそらくReact Nativeかそれに似たものです。
このネイティブレイヤーを制御できるので、私は本当にこれが欲しいです。ほぼExpo Go 3.0のようなものを想像しています。問題は大手プレイヤーはこれができないことです。なぜなら彼らはAppleとの良好な関係を危険にさらしているからです。Appleとの関係を気にしないなら、これを検討すべきです。
もしやるなら教えてください。そして動作したら、小切手を受け取るかどうか教えてください。正しいインセンティブを持つ誰かがここで魔法のようなことをする可能性は非常に高いと思います。ただし、Appleはあなたと戦うでしょう。解決すべき多くの他のエッジケースがありますが、これを実現できれば、素晴らしいことができます。
そして私は本当にAppleが潜在的な大規模な法的問題なしにアプリストアからあなたを追い出すのに、これまで以上に苦労すると思います。そしてもしこの過程でEpicのティム・スウィーニーをあなたの味方につけることができれば、実際には勝つ可能性が高いです。いずれにせよ、デプロイメントには他にも多くの部分があります。
この複雑さ曲線のため、追加の問題がたくさんあります。私が最も気にしている一つは、ユーザーを最新バージョンに保つことです。バグがある場合、これは私がTwitchで実際に経験したことです。我々は特定のサイズの電話向けのモバイルアプリを構築していました。これを通常の電話プロと呼びましょう。
通常の電話プロはこのサイズです。突然、Appleは通常の電話ミニを出します。申し訳ありませんが、Appleではありません。この無作為の会社が通常の電話ミニを出し、それは少し小さいです。意味のある小さいと言えます。少し小さいとします。もしこのUIのどこかにバーがあったとしたら、例えば1、2、3、4があったとします。これが私たちのUIです。下にこれら4つのボタンがバーにあります。
おっとボタン4が切れてしまいます。電話が小さいからです。ディスプレイのフレックスがそのサイズになるとは予想していませんでした。ウェブ開発の世界では、フレックスコンテナのようなクールなものに慣れていますが、モバイルの世界、特にiOSでは、以前は異なる解像度のセットが限られていたため、より多くのものをハードコードしていました。
しかし新しいディスプレイの解像度が出てきたり、しばらく触れていなかった古いものが出てきたりすると、小さいサイズに対処するのは本当に問題でした。では、なぜここでこれを持ち出すのでしょうか？なぜなら、我々はこのバグを見つけるとすぐに修正しましたが、その後1年半の間、このバグについての報告を受け続けました。
なぜ2日で修正したバグについて、2年間バグ報告を受け続けるのでしょうか？理由は、彼らが電話上のバイナリを更新しなかったからです。この時点で、古いバージョンのTwitchアプリを使用していた場合、何も対処することはありませんでした。あなたは単に古いバージョンのままでした。
その後、Twitchモバイルチームは「アップデートする必要があります。アップデートする必要があります。最新バージョンをインストールする必要があります」とアプリ内で非常に積極的に表示されるように変更しました。しかしそれ以前は、最新版がリリースされてから1週間後でも、古いバージョンのユーザーが最大50%いることがありました。これは非常に一般的でした。
そして今日でも毎日これに対処している多くのアプリケーションがあります。iOSとAndroid上では、ユーザーがアプリケーションの最新バージョンを使用しているという保証はありません。もしネイティブに完全に依存している場合、それを強制する方法は実質的にありません。そのため、多くのこれらの企業は全体の体験をネイティブにすることから離れてきました。
例えば、このタブバーがアプリにハードコードされたSwiftコードではなく、これらのボタンの各々を実際にレンダリングするコードはSwiftコードかもしれませんが、1がここに、2がここに、3がここに、4がここにという記述は、アプリのレイアウト方法を記述するサーバーからフェッチされたJSONから来ている可能性があります。
これはニュースフィードのようなものにとって非常に一般的です。このアプリにフィードがある場合、テキスト投稿があるかもしれません。ビデオ投稿があるかもしれませんが、また祝日なのでSt.パトリックデーの投稿もあるかもしれません。そして、アプリに新しいカスタムタイプの投稿を作りたい場合、それが独自のレイアウト、独自のビューであり、真ん中に何らかの素敵なアニメーションがあったり、テキストが緑色だったりすると、これをアプリに事前に何週間も何か月も前に入れる必要があります。
なぜなら、これをアプリに入れて、機能フラグの下に置いて隠す必要があり、そして最終的にSt.パトリックデーが来たら、この独自のタイプの投稿をサポートできるようになります。なぜなら、すでにアプリに埋め込んであるからです。しかし、誰かが古いバージョンのアプリを使用していて、St.パトリックデーの投稿タイプを含むアップデートをインストールしなかった場合。
これはエラーを起こすかもしれません。間違ってレンダリングするかもしれません。単に失敗するかもしれません。わかりました、St.パトリックデーです。あなたたちは私をガスライティングしています。フルネームで呼ぶだけで止めておきます。いずれにせよ、アプリにこのコードがすでにない場合、それをレンダリングすることができません。おそらくこれはエラーを起こすかもしれません。間違ってレンダリングするかもしれません。単に失敗するかもしれません。わかりました、聖パトリックの日です。あなたたちは私をガスライティングしています。フルネームで呼ぶだけでこれ以上指摘されないようにします。とにかく、アプリにこのコードがすでに存在しない場合、それをレンダリングすることができません。そして皆さんはこのJSONがどのように見えるか想像できるでしょう。
ここで示そうとしているのをうまく理解してほしいです。投稿を取得するために何らかのAPIにアクセスします。各投稿にはタイプ、コンテンツ、その他期待される項目があります。そして今、私たちのアプリはここからフィールドを取得する必要があります。どのコンポーネントまたはUI要素をレンダリングするかを判断するためにタイプを使用し、その投稿コンポーネントタイプが期待するコンテンツやURLなど他のものを使用して、その投稿の正しいビューをレンダリングします。
このパターンは、投稿タイプを変更し、ユーザーが最新バージョンのアプリを持っていない場合、最新タイプの投稿を表示するためには上手く機能しません。そこで多くの企業が始めたのは、このデータを送信しないことです。代わりにサーバー駆動UIパターンと呼ばれるものを送信し、投稿タイプを示す代わりに、この投稿がどのように見えるべきかを記述します。そのためJSONを送信する代わりに、アプリがその形をレンダリングできるように、HTMLに近いものを送信することがあります。
考え方としては、重要な2つの部分があります。アプリ内のボックス、いわゆるコンポーネント、つまり物事がレンダリングされる形があり、そしてデータがあります。これはそのボックスに詰め込まれ、見えるものに変えるための部分です。これは全体としてUI=状態関数、またはこの場合データ関数のようなものです。
問題は、関数（UIを作るもの）が正しい部分をまだ持っていない場合、状態にはUIを記述するのに十分な情報がないということです。もしユーザーがどのバージョンのアプリを使用しているかを知らずに新しいものを送信したい場合、状態にはUIのより多くを含める必要があります。これはバランスの問題です。
UIがどのように見えるかをどれだけ状態に入れるか、アプリケーションバイナリ自体に入れるかという問題です。ネイティブアプリは歴史的にネイティブレイヤーに大きく依存していました。そのため、JSONが入ってくる様々な方法を調整し、対処方法がわからないものをフィルタリングするか、古いバージョンを使用している場合はエラーを表示するしかありませんでした。
しかし、サーバーがレンダリングされるべき形を送信する場合、アプリのバージョンはかなり重要ではなくなります。これがFacebookからGoogleまで、YouTubeからSlackまでのすべての企業がUIをアプリケーションバイナリ自体ではなく、サーバーによって定義されるように移行し始めた理由です。
もし私がFの部分がReact Nativeから来ると言ったら、このパラダイム全体がはるかに簡単になりますが、それは別の議論の話です。ここで主張しようとしているのは、アップルがアプリをユーザーに送信するのを待つことなく、サーバーが必要とするすべての異なるものをレンダリングできるようにするために、ウェブでは心配する必要がなかった方法でこの関係を根本的に変更しなければならなかったということです。一部のユーザーは何をしても古いバージョンのままでしょう。
これでデプロイメントについて言うべきことすべてをカバーしたと思います。長いビデオになると思います。少し短いものをやりましょう。これがどれだけ悪くなるか知っていることを自覚して言っています。プラットフォームについて話しましょう。これはウェブ開発者が理解するのに苦労する微妙なことの一つですが、モバイル開発者もウェブから理解するのに苦労します。
これらのプラットフォームはすべて非常に異なります。プラットフォームとは少なくとも主要なもの、iOS、Android、ウェブです。これらはすべて非常に異なります。ほとんどの人がおそらく最も馴染みのあるところから始めましょう。それはウェブです。ウェブはオープンスタンダードです。人々がそれについて議論するので引用符をつけています。
気にしません。それは本当に比較的オープンです。多くのコンピューティング実装があります。認めたくないかもしれませんが、これらの実装は驚くほど互換性があります。現在私はZenでFirefoxベースのブラウザを使用していて、主に開発ツール用にChromiumベースのブラウザを開いています。
Firefoxプラットフォームが遅れていると言いたいことはたくさんありますが、99%は達成しています。これほど遠くに来たのは本当に驚くべきことです。本当にクールです。そしてウェブがオープンプラットフォームでありオープンスタンダードであることには他にも多くの利点があります。問題を解決する方法に多くのオプションがあるということです。
支払いを処理する方法、データを保存する方法、ウェブとインターフェースする方法、どのAPIメソドロジーを使用するか、アプリケーションを構築するためにどのテクノロジーを使用するか、アプリケーションをデプロイする方法など、これらすべてがウェブを素晴らしくしている要素の一部です。ほぼすべてのレイヤーに非常に多くのオプションがあります。iOSとAndroidはそれほどではありません。
iOSは確かにオープンスタンダードではありません。人々がよく使う言葉は「囲い込まれた庭」です。それは公正だと思います。彼らは何らかの理由でSwiftをオープンソースにしましたが、実際に誰かがAppleプラットフォーム以外の意味のあることにそれを使用しているのを見たことがありません。最も近いものはArcでしたが、それがどうなったかは見ました。
ほとんどのことに対して二つの祝福されたオプションがあります。元のObjective CベースのアプリケーションプラットフォームレイヤーであるコアUIキットと、現在はSwift UIも持っています。Swiftとその古いコアUIキットやObjective Cのものの両方を持つ理由は、Objective Cが古くて衰退した言語で少し混乱しているからです。
それは厳しいです。そしてSwift UI、面白いことに、Reactのようなツールから正しい教訓を学び、アプリケーション開発をはるかに悪くなくするためのこころみでした。そしてiOSコミュニティがどう感じているかを見たいなら、これをチェックしてください。ほぼ即座にチャットで「Objective CはSwiftより優れている。」「Swiftは本当に過小評価されている」という意見が出ています。
そうです、これが現状です。内部でも二つの祝福されたオプションについての議論があり、両方に多くの問題があり、どちらも適切に完成していないと私は主張するでしょう。今はちょっと厳しいですね。また、これらはどちらもAppleプラットフォームです。SwiftとSwift UIでアプリを構築すると、Macではまあまあ動作するかもしれませんが、他のどこでも動作させることはできません。厳しいですね。
また、Swift UIは2019年6月に発表されたことも注目に値します。Reactは2013年5月に発表されました。Appleがreactが教えてくれた教訓を学ぶのに6年かかり、今でもそれらを適用しようとしています。まだ十分に安定していると考えないため、多くの開発者がまだSwift UIを使用していないことを知っています。
これは問題です。プラットフォーム自体に依存しているため、iOSやAndroid上でより良いアプリプラットフォームやネイティブUIレイヤーを構築することは実際にはできません。Flutterのようにプラットフォームを完全に無視しない限り、それはかなり悪いことがわかります。これらのデバイスの機能は信じられないほどですが、ユーザーの期待も非常に高いです。
そしてそれらの期待は、電話が特定の方法で動作することに慣れているため、アプリケーションが特定の方法で動作するということです。Flutterがバージョン3.29を発表したとき、ブログ投稿を読みましたが、冗談抜きで、ブログ投稿の最初のスクリーンショットに、検索バーで今まで見た中で最悪の配置がありました。
彼らは下部に配置しています。冗談でしょうか？これがデフォルトです。これが彼らの例です。そしてFlutterアプリを使用すると、この奇妙な不気味の谷の感覚を得るでしょう。そしてこれは開発者や、これに焦点を当てている人だけが得るものではありません。私の母は初めてeBay Motorsアプリを使用しようとしたとき、その違いを感じました。
それは良くありません。そして私が彼らを批判したので、彼らはこれを隠しました。ちなみに、これはもはやブログ投稿の上部にはありません。以前はここにありました。私が批判したので、彼らはスクリーンショットを削除しました。それは良くありません。しかしそれが問題でもあります。私たちは現在この期待を持っています。
そして、ネイティブ部分を使用せずに、プラットフォームに存在するコアUI要素を使用せずに構築しようとすると、ユーザーが持つ期待を満たすためにそれらを再作成するか、ユーザーの期待が転覆し完全に回避されるほど異なることをする必要があります。また、これらすべてに非常に重要な部分があり、それはアクセシビリティです。
Appleはこれらのネイティブ要素に優れたアクセシビリティを組み込むことで素晴らしい仕事をしました。Swift UI内で実際のボタンやタッチ要素を使用し、適切にラベルを付けると、スクリーンリーダーを使用するユーザーにとって素晴らしく機能します。それは本当に素晴らしいことです。iOSは、アプリを構築する際にプラットフォーム内のすべてを適切に使用すると、盲目や聴覚障害のある人、または他の多くの物事でソフトウェアのナビゲーションを難しくする人にとって素晴らしい経験を作り出します。
Appleはアクセシビリティの分野で本当に画期的です。その点では最高の企業の一つです。そして馬鹿に聞こえるかもしれませんが、彼らが1、2年ごとに素晴らしいものを示すアクセシビリティのコマーシャルを行うとき、麻痺した女性が自分のコマーシャルを編集しているのを見せた時、私は泣きました。わかりません。
あなたがソフトウェアで物事を行うためにとても懸命に働くこれらの信じられない人々の一人に会ったことがなければ、この件について話せる誰かを見つけることをお勧めします。なぜなら私たちが毎日行うことを、アクセシビリティのニーズを持つ人々が経験する課題は、ドラッグアンドドロップのような単純な操作が何十万人もの人々にとって完全にアクセスできないものであるからです。
Appleはモバイルプラットフォームとモバイルのソフトウェア開発キットでここで素晴らしい進歩を遂げました。しかし別の道を少しでも下ると、ほぼすべてを自分で再実装する必要があります。Appleのプラットフォームがアクセシビリティをサポートする方法のすべての利点を失い、自分で実装しようとすれば失います。
ゲームを構築しているのでなければ、プラットフォームに組み込む必要があるという方法で締め付けられています。他のオプションは無責任であり、何十万、何百万の人々とそのソフトウェアを使用する能力を害することになります。React Nativeがネイティブプラットフォームを使用するのは良いことではないですか？しかし、ここで私が言おうとしていることがわかるでしょう。
プラットフォームは良く、他の誰もができないことを彼らは行いました。ウェブは単にこれを念頭に置いて最初から構築されたため、iOSほどアクセシブルなプラットフォームになることはありません。そして彼らが押し進めた標準化により、ウェブが古く、サポートされているものでもできないことが可能になりました。それは信じられないことです。
素晴らしいことから転換して、Androidについて話す必要があります。Androidは技術的にはオープンソースです。また技術的にはLinuxです。現在では誠実に言うのが難しいほど激しくフォークされていますが、他のほぼすべての点ではiOSのようですが、より不安定です。良い点もあります。
Cotlinは素晴らしい言語です。しばらくの間、防御的なJavaビデオを作る予定でしたが、オペレーティングシステム向けにJavaとJVMを使用することは、私たちが起こるべきではなかったほど呪われたアイデアです。ああ、そうですね、Androidは興味深い獣です。以前はAndroidの世界に深く入り込んでいました。常にカスタムROMに貢献し、Androidコアにも貢献しようとしていました。
高校生のときは世界で最も好きなものでした。そしてiOS 7が登場し、私の脳が書き換えられました。いずれにせよ、ここで強調したいのは、おそらくAndroidプラットフォームを使用すべきですが、Flutterのようなものがandroid上でより多くの意味を持つほど脆弱でもあるということです。
実際、Androidのネイティブランタイムに比較的似ています。また、これがiOSでFlutterを使用すると、お粗末なAndroidアプリのように感じる理由の一つでもあります。Flutterの人たちを思い出します。なんてこと。Flutterウェブでテキストを選択すると、テキストの実際のDOM要素を配置し、選択したテキストの位置に正確に重ねようとしますが、そうしようとするとその30％を見逃します。
これはFlutterがアクセシブルにするためにしなければならないことです。なぜならプラットフォームを使用していないからです。プラットフォームの上に独自のレイヤーを使用し、それでもアクセシビリティのような基本的なことを行うためにプラットフォームに戻る必要があります。ここで私の知識のギャップを少し示しそうです。後悔しないことを願います。
Jetpack Composeは本当に良いと言われています。これはAndroid向けの構築とバンドルのためのツーリングエコシステムです。絶対的なゴミから今では驚くほど良くなったと聞いています。それは素晴らしいことです。Androidが滑稽なほどiOSより悪い開発体験から、議論の余地はあるが少し良くなったと考えるのは信じられないことです。しかし、そうなのです。
実際、完全に透明に言うと、私がsyanogen modのようなものに貢献していた大きな理由の一つは、Android向けのアプリを構築するよりもAndroid自体を変更する方が簡単だったからです。ナンセンスです。しかし、現在のAndroidエコシステムの状態について本当に良いことを聞いています。以前は恐ろしく悪かったので、良いことです。
ここでの核心点は、これらのどちらからも離れすぎると、多くの痛みを伴うということです。ただし、ウェブと比較して、これらのプラットフォームには利点もあります。ここで言わなかった一つのことは、ウェブは何も廃止できないということです。ウェブには現在の、しばしば壊れた状態で何百万のウェブサイトが使用しているために変更できない劣悪なAPIが非常に多くあります。それは恐ろしいことです。
ウェブの廃止が問題である私のお気に入りの例の一つはSmoosh Gateです。テレビの受信状態を修正するために叩く必要があったほど年配でなければ、おそらくこれについて聞いたことがないでしょう。ここにいる皆さんのために言うと、昔は配列を平坦化する方法がありませんでした。
ネストされた配列の配列があり、それを平坦化したい場合、基本的に困っていました。これを行ういくつかのライブラリがあり、当時はそれらをすべて使用していました。moo toolsやjQueryのようなものです。しかし、ウェブ標準委員会はこれを実際のウェブ標準にしたいと考えていました。一般的なことなので、標準にすべきです。
最初に行ったのはarray.flatでした。つまり、このような3重にネストされた配列があるとします。array.flatを呼び出すと、それが平坦化されます。flatと無限のような数を呼び出すことができ、それを本当に適切に完全に平坦化するために継続的に呼び出されます。
これは私が大好きなflat mapが来た提案でもあります。私はflat mapを乱用しています。おそらく使うべきでない場所で使っています。それはとても素晴らしいです。問題は、彼らはflattenを使いたかったができなかったことです。新しいツールをインストールすると、flattenの配列プロトタイプキーをオーバーライドし、独自の実装を作成します。
彼らの実装はウェブ標準が試みていたものとは異なりました。新しいウェブ標準をflattenと名付けると、moo toolsユーザーにとって競合し、問題を起こすでしょう。恐ろしいです。本当に悪いです。多くのウェブサイトで問題が発生するため、この古いライブラリを使用している人のために実装する際に、APIに異なる名前を付け、異なる方法で実装しなければなりませんでした。異常です。
そしてこのようなことは常に起こります。ありがたいことに、ライブラリは今では配列プロトタイプを常にオーバーライドしないことを知っています。しかしそうでなければ、これは悪くなる可能性があります。これがウェブプラットフォームの状態です。すべてを永遠にサポートし、20年前のウェブサイトに行って今でも機能することを期待することで、物事を廃止することはできません。
物事を削除することはできません。物事の動作方法を変更することはできません。時々、Appleがそのように動作すればいいのにと思います。なぜならSwift UIの動作方法を4年間連続でメジャーリリースごとに変更したからです。しかしそれがここでの違いです。最後にプラットフォームについてもう一つ言っておきます。これまでにも触れてきましたが。
ツールはその上に構築されるべきです。ウェブに存在しないものを構築する試みがありました。最大の2つはFlashとJava、群れの中の拒否はFlutterです。これらのテクノロジーはウェブ標準の一部ではありません。これらのどれも標準化されていません。Javaは多少ありますが、ほとんどありません。
これらのテクノロジーは、ブラウザ自体ではなくオペレーティングシステムの一部であるネイティブプラグインを介して、ブラウザに異なるものを構築する試みでした。これらはあなたが異なる体験を実行できるようにするでしょう。Flutterは明らかにブラウザでキャンバスを使用していますが、FlashとJavaはどちらもコンピュータにインストールし、ブラウザ内でプラグインとして使用するものでした。
これによりウェブプラットフォームははるかに速く進歩することができました。なぜなら最初はウェブはあまりインタラクティブではなかったからです。FlashとJavaはほぼ完全にインタラクティブでした。そのため、突然これらを埋め込み、ブラウザが以前にできなかったことができるようになりました。私はまだflashゲーム革命を切実に恋しく思っています。
それ以来、適切に置き換えるものは何もありませんでした。実際、近い将来「AIゲームの擁護」というタイトルのビデオを計画しており、新しいAIゲーム構築の取り組みと私が育った旧きflashの日々の関係について話す予定です。
私がそのときにflashゲームに夢中になった方法がなければ、おそらくプログラマーにはならなかったでしょう。それ以来、Flash と Java が必要だったものをプラットフォームに組み込みましたが、これらの標準は使うのが十分に難しいため、昔の Flash で見られたような小さなゲームのレベルでのイノベーションと本物の革命は見られていません。
それについて考えるたびに心が痛みます。これらはすべて、ウェブ標準の一部ではないものをブラウザに構築しようとする試みでした。そして、これら3つのどれも、ウェブページで使用すると予想されなくなった理由があります。ウェブプラットフォームの上に何かを構築することは、ウェブプラットフォームが最終的に常に勝つため、最悪です。
そして、構築しているブラウザで何とか機能するものがある場合、あなたの抽象化が他のブラウザや他の場所で適切に機能する可能性は比較的低いです。FlutterのクレイジーなキャンバスハックがSafariで完全に壊れてもびっくりしません。FlashがOh待って、iOSでは機能しなかったことに驚かないでしょう。
Steve Jobsがそれを許可しなかったからです。そしてAndroidで機能した場合でも、Androidでは機能しませんでした。Flashのダイハードの一人として高校生の時、Androidフォンでflashを持つことに非常に興奮していました。Androidのために構築された2つのFlashゲームを試しましたが、どちらも壊れていて、タッチを処理したり、低遅延で何かをすることができず、電話でflashゲームを使用するのをやめました。
また、彼らは私のバッテリーを食い尽くしました。冗談ではなく、私のDroid Xのバッテリーはflashゲームを1時間プレイすると恐らく死にました。そんなものでもありません。そう、これらはより速く進むことを可能にしましたが、ウェブがどこに向かうべきかを示したため、死にました。使いづらさのために一緒に旅行することはありませんでした。
では、iOSとAndroidはどうでしょうか？ここでも試みがありました。CordovaとIonicのようなものがありました。これらは基本的にいくつかのネイティブプラットフォームアクセスを持つブラウザを構築する試みでした。良くありません。これらのテクノロジーで構築されたアプリを使用して実際に楽しいと思ったことはありません。明らかにReact Nativeがあります。
Microsoftが買収して徐々に死んだ他のものがありました。Xamarinですね。そう、Xamarinです。そんな災害でした。そして再び、Flutterの友人たちです。ここで私のより熱い意見の一つを紹介します。ウェブでは、私たちはオープンプラットフォームを持っています。ウェブがオープンプラットフォームであるため、ウェブは消費する方法に多くの異なるオプションを持つプラットフォームです。
ウェブは消費する方法に多くの異なるオプションがあるため、これらの抽象化のいずれかがウェブプラットフォームの大部分で機能することを保証することは基本的に不可能です。だからこそ、最初の2つはそれを処理するためにネイティブの何かをインストールする必要があったのです。そしてそれがFlutterがウェブのために誰かが実際に誠実に使用するものではない理由です。
モバイルでは、何千もの実装を持つ一つのオープンスタンダードがありません。2つのプラットフォームがあります。それらは閉じていますが、限られています。それらは大規模ですが、限られています。したがって理論的には、iOSで正しいもの、Androidで正しいものを使用するため上に適切なレイヤーを構築できれば、それらは異なりますよ。
ウェブの問題は、すべてが独自の実装を持っていることですが、実装はプラットフォーム間で異なる動作をする可能性があり、その上に構築するのは地獄です。React Nativeのようなものでは、iOSでネイティブタブバーを使用し、Androidで2つの別々のものである2つの別々の標準であるネイティブと同等のものを使用できます。
全体的にはるかに多くの作業になりますが、そのプラットフォームを構築すると、Flashのようなものを通じてできるよりもはるかに一貫してこの抽象化から一貫してネイティブの物事を呼び出せるのです。そしてこれは直感的ではありません。なぜならウェブは一つの標準を持ち、モバイルは二つを持っているからです。一つの標準の上に二つの上よりもプラットフォームを構築する方が簡単ではないでしょうか？実はそうではありません。この一つの標準の中の多様性のために。
これら二つのプラットフォームは比較的固定されているため、二つの異なるプラットフォームがあるにもかかわらず、それぞれに一つの実装しかないため、非常に一貫しています。Meta社がReact Nativeでしたように、何百人もの技術者がReact Nativeの開発に長年取り組み、Microsoft社やAmazon社からも多くの人が参加しています。
彼らはこの抽象化を構築するための努力を惜しまず、プラットフォーム自体は問題を引き起こすほど変化したり異なったりすることはできません。結果は本当に印象的です。これらのオプションのいくつかでは、実際に全体のネイティブプラットフォームを使用することができます。これは本当にクールです。もっと多くがそうであればいいのに。プラットフォームは考慮すべき非常に重要なことです。プラットフォームの機能。
iOSやAndroidのようなプラットフォームでできるクールなことがたくさんあります。ジャイロのようなもの、カメラのようなもの、ファイルシステムアクセスのようなもの、位置情報アクセスのようなもの、すべてがネイティブAPIであることは本当にクールです。しかし、私が今挙げたすべてのものはブラウザにも存在します。同じように、ウェブが新しい開発者体験の期待をもたらし、Reactのようなものが、より良い開発者体験を作るためにiOSとSwift UIで追いつくように強制したように。
ネイティブプラットフォームがこれらの素晴らしい機能と統合をプラットフォームに組み込むことで、ウェブも追いつく必要があるという結果になりました。しかし、ネイティブプラットフォームが最初になる傾向があります。ネイティブはデバイスの新しい機能を最初に持つ傾向があります。カメラアクセス、ファイルシステム、BluetoothのBS、ウェアラブルなど、発表されるすべての驚くべきことのように。
基本的に私が言っているのは、新しいiOSリリースが出ると、それらの機能は一般的に言ってネイティブアプリ開発者だけがアクセスできるということです。ここには例外がありますが、AppleがiOSに素晴らしい新機能を追加した場合、ウェブはそれを得られることは幸運です。通常は得られませんが、得られたら素晴らしいでしょう。
ウェブプラットフォームにも問題があります。それはiOSやAndroidと競合しているからです。なぜなら彼らはあなたにプラットフォーム上でネイティブアプリを構築させて30%の取り分を得たいからです。これについては後で詳しく話します。そのため、AppleとGoogleはウェブプラットフォームを本当に良くすることを抑制しています。
その結果、モバイル上のウェブプラットフォームには多くの制約があります。AppleはPWAをしばしば制限してきました。彼らはPWAを破壊するために何年もの間多くのことをしてきました。通知機能を実際に実装したことに驚いています。彼らはそれを決してしないように見えました。今は動作すると思います。しばらく確認していませんが、それが起こることが発表されたことを覚えています。
チャットの誰かがお確かめください、今のiOSのPWAは通知を持っていますか？それは本当ですか？そしてあなたたちの誰かが実際にそれを使用して動作するのを見たことがありますか？良いですね、チャットはYesと言っています。難しいですが、はい。はい、持っています。OK、それはクールです。PWAの実装はひどいですが、より多くの機能を得ています。しかし、必要な場所からはまだ非常に遠いです。
ネイティブのものは素晴らしくても疑わしいです。Bluetoothのようなものにアクセスしようとすると、機能する可能性がありますが、別のタブに移動したりアプリを離れたりするとすぐに、何が起こるかわかりません。バックグラウンド処理は基本的に起こりません。バックグラウンドで何かをする必要がある場合、幸運を祈ります。楽しんでください。
例えば全画面表示のようなものでさえ、本当に、Appleはモバイル上のウェブで適切な全画面表示を行うことを非常に難しくしました。ビデオプレーヤーをレンダリングしていないなら、全画面表示を機能させて、Safariのタブバーなどをすべて隠すことはとても難しいです。将来のSafariバージョンでそれが来ると発表されたと思います。幸運を祈ります。
楽しんでください。ページの上部にある「アプリを開く」ボタンがどれだけうまく機能するかを見たことがあれば、ウェブでよりアプリのような体験を作るというAppleの試みがどれだけうまくいくか分かるでしょう。それは絶対に災害です。そう、ここからあなたを遠ざけるAppleのインセンティブ、そしてGoogleのインセンティブも非常に現実的です。
仮にウェブ自体や公式のウェブ標準委員会がこれらのAPIをより多く導入したとしても、Appleがあなたにそれらへのアクセスを与えることはおそらく低いでしょう。仮に与えられたとしても、それは何年も後になる可能性があります。「PWAは今やついにタブバーを隠すことができます。素晴らしい！」とのことです。しかし、パフォーマンスはどうでしょうか？Jamonが言ったように、非常に重要です。
ウェブでのパフォーマンスはまだ問題です。特に60FPSのアニメーションや特にジェスチャーに追従するアニメーションになると。そうですね、Appleはウェブブラウザを通してデバイスの完全なGPUとCPUパワーを与えていません。現在、電話上のウェブページを通じてCPUをフルスロットルで実行することはできません。なぜならAppleは、あなたがページを素早く読もうとしているときに、ニュースサイト上のあらゆる種類の粗悪なトラッキングや広告があなたの電話のバッテリーを消費することを望んでいないからです。
なぜ彼らがそれを望んでいるのか、なぜそれを推し進めているのか理解できます。しかし、彼らはウェブプラットフォームがアプリケーションプラットフォームになることを望んでいません。Appleはウェブを閲覧用に、アプリを体験用にしたいと考えています。彼らは中間を望んでいません。彼らのインセンティブはウェブ標準委員会が望んでいるものと根本的に合致していません。
そして彼らは自分たちのプラットフォームを非常に厳密に制御しているため、私たちが望む柔軟性がありません。そして一方では、これはiOSが非常に成功している大きな理由です。それはスパイウェアやウイルスのようなものがほとんどない理由です。私はiOSが最初の主要なコンピューティングプラットフォームで、大規模なスパイウェアやウイルスの問題を持たなかったと主張します。
他のすべての主要なプラットフォームは、ある時点または別の時点で、かなり重大な問題を抱えていました。私の父が昔Androidフォンに持っていたゴミの量を見て、それは私にとって恐ろしいものでした。彼のBlackberryはどういうわけかさらに悪かったです。Windowsについては、皆さんご存知の通りです。Macは主要なコンピューティングプラットフォームではありませんでした。
Linuxの人たち、ビデオのここまで来られなかったでしょう。あなたのオーディオドライバーは機能していません。しかし他の皆さんにとって、iOSはこれらの方法でセキュリティにおいて画期的だったし、他のプラットフォームよりもはるかに高い体験の基準も持っていました。素晴らしい。理解します。良い体験を作りたい開発者のために障壁を下げる必要があります。特に彼らがたくさんの障害なしに他の人と経験を共有できるようにするために。
もし私が悪いアプリを作ったとしても、おそらくそれをアプリストアに出すことはできないかもしれませんが、おそらく友人にリンクを送って試してもらい、なぜそれがひどいのかについてフィードバックをもらい、もっと学んで修正することができるかもしれません。そのループはモバイルには存在しません。基本的に、それをうまく行うためには、あなたの隣で手を取り合ってくれる本当に優れたモバイル開発者が必要です。
そしてそのすべての報酬として、Appleは30%を得ます。これをAppleとGoogleのプラットフォーム上での取り分についてのビデオにしたくありません。おそらくプラットフォームのセクション中にこれについて話すべきだったでしょうが、理解すべき重要なことです。ウェブでは、支払いをする多くの方法があります。それは昔からそうではありませんでした。
iOSが初めて登場し、アプリストアが最初に出てきたとき、ウェブでクレジットカード決済を処理することは課題でした。アプリストアはいつ登場しましたか？アプリストアは2008年に登場しました。Stripeは2011年に登場しました。アプリストアが登場したとき、特にアプリやウェブサイトで支払いを処理する良い、シンプルで信頼性の高い方法はありませんでした。
そのため、ゲーム配信から期待されていたものと一致するAppleの30%の取り分は、当時は適切な意味を持っていました。それ以来、基準は変わりました。Xbox、PlayStation、Nintendo、Google、Appleなどのプラットフォーム。そしてSteamも。これらのプラットフォームはすべて、あなたの収益の約30%を取ります。これはそれほど悪くないように聞こえるかもしれませんが、Epic Games Storeのような何かと比較すると、それはデフォルトで12%で、Unreal Engineのライセンス費用も免除されます。それは通常3%なので、効果的には9%の料率になることが多いです。
それは3分の1だけです。しかしStripeのようなものを見ると、Stripeははるかに小さな取り分を取ります。そのまま言うと信じられないかもしれません。国内カードの成功した課金ごとに2.9%プラス30セントです。それは信じられないほど低いです。これらの他のオプションと比較して滑稽なほど低いです。
ここには問題があります。このリストからゲーマーの脳の腐敗を引いたとしても、他のオプションはありません。これらの会社の一つを通じて購入する必要があります。そうしなければ、それらのプラットフォーム上でアプリやゲームを販売することはできません。Epicはゲームを購入する方法のオプションです。PCにも他のオプションがあります。そのため彼らの取り分はより競争的であり、また彼らがそれを選択する理由でもあります。
彼らがこれを最初に作った理由です。Stripeは一般的な決済処理ソリューションになろうとしています。そのため、彼らの取り分ははるかにはるかに低いです。これが人々にどのように影響するかを示すために、興味深い例を挙げます。私は現在Twitchでライブストリーミングをしています。Twitchで私を購読している人がたくさんいて、それぞれに非常に感謝しています。
Twitchでの購読はYouTubeのようなプラットフォームとは同じように機能しません。それらは有料です。Twitchでのフォローはユーチューブのサブと同等です。TwitchでのサブはユーチューブのメンバーまたはPatreonに参加するのと同等です。ここでの私のサブは、ほとんどが月額約5ドルを支払っています。
Amazon Primeの購読者である場合、毎月Twitchで無料のサブを得ることができます。それを私に投げることができます。少しサポートしてください。本当に素晴らしいです。そうしてくれる皆さんありがとう。しかしPrimeを使用していない人は、ティアワンサブに約月5ドルを支払っています。はい、Primeを持っていれば無料でサブできます。
それは本当に素敵なことであり、私にお金を払います。では、なぜこれを持ち出すのでしょうか？長い間、モバイルではサブはありませんでした。Twitchのサブの分割は興味深いものです。サブが5ドルかかり、私がTwitchのクリエイターの特定の層にいない場合、この5ドルは半分に分割されます。私に2.50ドル、Twitchに2.50ドル。
十分に大きなクリエイターである場合、またはTwitchと交渉した場合、これを70/30の分割に変更できます。さて、私は有名です。その場合、5ドルは少し異なる形で分割されます。私に3.50ドル、Twitchに1.50ドルです。これはTwitchが取るためにはたくさんのお金のように思えるかもしれません。それはそうだからです。しかし、Twitchは当時、視聴者がクリエイターに直接貢献する方法を提供するという本当に独自のものを提供していました。これはその瞬間には実際に存在していなかったので、これをはるかに正当化できるものにしました。YouTubeが登場し、デフォルトで30%を取りました。
つまり、上ではなく下の数字です。Patreonが登場し、約5%を取りました。しかし、それから彼らはそのパーセンテージを本当に奇妙で少し有害な方法で何度も上げてきました。これは分割です。そして私はTwitchがこの下の数字を取ることを擁護します。
上のものは擁護しません。なぜならTwitchでの詐欺率は狂っているからです。なぜなら誰かのチャンネルでたくさん購読すると社会的な報酬を得るからです。50や100、500サブを誰かに寄付すると、彼らはあなたを称え、それは大きな瞬間になります。そのため、クレジットカードを盗んでTwitchで人々を騙すのは楽しい場所です。
そしてTwitchには多くのクレジットカード詐欺があります。そのため、彼らはこの部分を少し増やして、できるだけ多くの詐欺に対処する必要があります。なぜなら詐欺は高価だからです。Stripeでのチャージバックは15ドルかかります。詐欺が彼らが対処するために適切なバッファーを必要とするほど大きな問題であることは残念ですが、それはまたTwitchの主な収入源でもあります。
そのため、この数字はさまざまなものの間で混ざり合っています。それにもかかわらず、それはそれです。なぜここでこれについて話しているのでしょうか？まあ、モバイルについてはどうでしょうか？私が有名で、モバイルだとしましょう。5ドルがあります。1.50ドルがTwitchに行きますが、Appleもここで割り込みました。1.50ドルがAppleに行きます。誰かがモバイルアプリに5ドル寄付した場合、Appleは私がした金額とほぼ同じほど稼ぎます。それは惨めです。
もし私が良好な有名層にない場合、2.50ドルがTwitchに行き、1.50ドルがAppleに行き、残りは1ドルです。それは狂っています。そしてTwitchはこれが狂っていることを知っていました。そのため、この方法ではなく、変更しました。Twitchで購読するのに6ドルかかります。Twitchは少ない分を取ります。だいたい1.20ドルくらいだと思います。
Appleは2ドルまたは彼らが取る金額を得て、残りはあなたが得ます。それは約3.80ドルか、2.80ドルくらいだと思います。そうですね、約2.80ドルです。そのため、もしあなたが有名ではなく、特別な分割を持っておらず、モバイルでサブを得ている場合、Twitchよりも少し多くを得ることになります。Twitchでは2.50ドル得ます。
ここでは2.80ドル得ます。しかし私は30セント多く稼いでいます。視聴者は1ドル多く支払っています。Twitchはボロを見ています。これはAndroidでも同じケースです。これはAppleに特有のものではありません。彼らがこれほど多く請求することは狂気です。Appleの取り分がTwitchで私にサブしたことと何の関係もないのに、私のものにこれほど近いというのはどれほど狂っていることでしょうか？
おそらく、あなたはApple Pay統合がなければサブしなかったかもしれません。しかし、ウェブサイトですでにクレジットカードを付けている場合、モバイルアプリではそれを使用できません。Appleはデジタル取引にApple Payを使用させるため、既存のクレジットカードにデフォルト設定することを許可しません。
UberやAmazonを使用するときにクレジットカード番号を使用できると思っているかもしれません。Appleはここで最も恣意的な区別を持っているため、できます。サービス、特に実世界のサービスについては、カットなし。デジタル商品は30%です。これがAppleがこれらのカットをどのように分割するかのルールです。
誰かがあなたの車を掃除しに来る支払いをしている場合、誰かがあなたを運転する支払いをしている場合、Best BuyやAmazonで物理的な商品を注文している場合、彼らはカットを取らず、Apple Payやすべてを使用できます。Appleはあなたにそれをさせます。Bank of Americaのような会社はその開発者ライセンスのためにAppleに年間100ドルを支払い、それだけです。
インディーゲーム開発者は開発者ライセンスのために100ドルをAppleに支払い、すべての収益の30%を払います。つまり、インディーゲーム開発者はアプリストア上でAmazonや大銀行を補助しています。なんてこと。どうしてこうなったのか？どうしてこれがOKなのでしょうか？AmazonやNetflixのような企業はこれらのルールに従うことを拒否しました。
ちなみに、Netflixは完全に撤退し、モバイルで購読できないようにしました。モバイルではサインインのみができ、購読はできません。Appleに30%を与えないため、ウェブで購読する必要があります。彼らはこれをNetflixがしないようにしようとしたAppleとの複数の裁判に行き、負けました。
Netflixはアプリ内であなたにウェブに行かなければならないと伝えることもできません。なぜなら、人々がより良い価格のためにウェブに行けることを伝えると、Appleはアプリストアからあなたを追放するからです。これがEpicに起こったことです。狂気です。AmazonがAmazon BooksやAmazon Prime、特にPrime Videoで同様の動きをする準備ができたとき、彼らはOKプッシュしてApple Payで全く支払うことをサポートしないつもりでした。
AppleはこのAppleビデオパートナープログラムという新しい発表をしました。AppleはNetflixを失った後にPrime Videoを失うことを非常に恐れていたため、iOSを通じてビデオ配信を行っている特定の企業により良いカットを与えるためにこれを発表しました。そのデールは15%のみを取ることです。
つまり、70%ではなく85%が残ります。当時はPrime Videoだけでしたが、今では更新されて、より多くの企業があります。ただし、2年間はPrime Videoだけでした。彼らはこれをAmazonが離れないようにする方法として発表しました。そして今、彼らはこれらの他の巨大企業をすべてサポートしています。Netflixがまだここにないことに注意してください。
そうですね、何かが客観的に独占的だと言うのはまれですが、これは客観的に独占的です。なんてこと、Apple？Androidでは良くありません。しかし、彼らがこれらの数字を請求し、これらの恣意的な線と区別を引き、彼らが持っていた方法でそれを逃れられるのは狂気です。不条理です。
そしてStripeに戻ると、これはすべて問題ではありません。ここでの問題が分かることを願います。Appleがアプリ内で支払う唯一の方法を制御しているため、彼らは恣意的なルールや区別を作り、一部の企業を他の企業より優遇し、インディーゲーム開発者のお金で大銀行を補助することを選択することができます。
彼らがしたいことは何でもできます。なぜなら、これらは彼らが実装することを選んだプラットフォームの機能であり、彼らが強制することを選んだプラットフォームの制限だからです。個人的には、これは違法であるべきだと思いますし、裁判所で解決されるべきだと思います。しかし、それは私の見解です。
これらすべてを述べた上で、このビデオを作るきっかけとなった部分に踏み込む必要があります。Jamが来なくて残念です。この点について責任を持って説明できることを願っています。ルーティングとナビゲーションです。
正直なところ、これは独自のビデオになったかもしれませんが、アプリでの体験がウェブでの体験とどのように異なるかを理解する上で非常に重要なことです。単純な方から始めましょう。それはウェブです。ウェブサイトにアクセスするとします。website.comに行きます。
私はwebsite.comにいます。興味のあるリンクを見つけたのでクリックします。今私はwebsite.com/aboutにいます。そして、サインインすると何か違うものが得られるかもしれないと気づきます。そこでwebsite.com/loginに行きます。Googleの認証ボタンをクリックします。
それをクリックすると、素早くgoogle.com/oauthまたは類似のものにリダイレクトされ、その後website.com/successまたは類似のものに戻されます。ここで面白いのは、このスタックを編集できることです。なぜなら、スタックを作成したからです。
website.com/successにいて、これがホームページに戻るだけなら、これをすべて経てwebsite.comにいて、戻るとすれば、successには戻らないかもしれませんし、google.comにも戻らないかもしれません。ブラウザ履歴スタックを正しく設定していれば、website.comから戻ると、これをスタックからポップして/loginに戻り、再び戻るとそれをポップしてaboutに戻り、さらに戻るとそれをポップしてwebsite.comに戻るはずです。
ウェブを移動しているとき、ほとんど常に垂直に移動しています。訪問したURLのスタックに物事を追加しています。戻るボタンを押すと、前にいた場所に戻ることができます。ログインのことで示そうとしている一つのことがあります。このスタックの特定の場所で、その要素にあるものを入れ替えることができますが、それはあまり一般的ではなく、通常はリダイレクトや一時的な訪問のためだけです。
スタック内のどこにいるかを入れ替えることはそうしない限りありません。ここでの簡単な例はGitHubのプロフィールです。github.com/t3.ggに行きます。URLバーをより簡単に見れるようにブラウザを切り替えます。ここで私のGitHubプロフィールにいることがわかります。リポジトリをクリックすると、?tab=repositories&type=sourceに変わります。
しかし、このタブにいるときに他のタブにも変更できます。プロジェクトに行くことができます。スターに行くことができます。そして今戻ると、期待通りに、移動したさまざまなタブを通過します。これらのタブを切り替えるときに現在の位置を置き換えることもできますが、それは非常に直感に反する体験になるでしょう。
一般的に言えば、ユーザーが何かをクリックして移動するとき、期待されるのは、彼らが移動した場所から戻れることです。モバイルはそれほど単純ではありません。議論したい最後の部分は、これらのURLの構造です。ここに戻って、GitHubでどこにいるかを見ると、少し奇妙です。
彼らはここでクエリパラメータを使用しています。ほとんどのサイトはこれよりも/t3.gg/reposや/projectsや/packagesのような形式を使うでしょう。なぜなら/t3.ggがトップレベルのページで、そこからルートが続くからです。一般的なウェブでのワークフローを見てみましょう。ダッシュボードページがあるとします。これを私のダッシュボードと呼びましょう。
ダッシュボードには「マイダッシュボード」というヘッダーのトップナビゲーションがありますが、さらに異なるコンテンツ部分に移動できるサイドナビゲーションもあります。例えば「概要」「分析」「ユーザー」「設定」などがあります。
デフォルトでは、/dashboardにいます。/dashboardにはヘッダー、サイドバー、そして「ダッシュボードへようこそ」のようなコンテンツがあります。ここで分析をクリックしたとします。ウェブのユーザーとして私の期待は、分析に行くとURLが/dashboard/analyticsになるということです。
するといくつかの変化が起きます。現在この場所にいるため「分析」がハイライトされ、このページのコンテンツが「あなたの分析」に変わります。そして、いくつかのグラフがあります。面白くしましょう。「時間経過によるユーザー数」。ほとんどの皆さんのアプリの現実的なダッシュボードですね。
このURLの方法で興味深いのは、異なる次元でスタックしていることです。訪問した異なるページの履歴という垂直スタックがありますが、異なる役割を持つ水平スタックもあります。ここで水平に進むと、ダッシュボードがあり、これがコアルートで、トップナビとサイドバーを定義しています。しかし、このメインセクションのコンテンツを制御し、サイドのセクションにも若干の変更を可能にする/analyticsもあります。
メンタルモデルとしては、/dashboardがここのセクション以外のすべてを持ち、このセクションでより多くのことをしたいときにURLを拡張します。おそらくもう少し複雑です。dashboard/id/analyticsのようになるでしょう。分析からユーザーへ、設定へと異なる場所をクリックするとき、まだその垂直スタックに追加しています。
そのため、前後に移動できて、ブラウザは期待通りに動作します。これはページがどのコンテンツをレンダリングするかを選択する方法です。ナビゲーションは、スタックとどこに前後に行きたいかを選択する方法です。ここでの二つの方向について考えてみましょう。垂直スタックがあり、これは我々がアクセスしたリンクです。
/dashboardに行くなら、最初にホームページに行くとしましょう。つまりsite.com/です。実際には下から始めます。スタックなので、site.comに行きます。次にsite.comから/loginに行きます。これはログインを行うために変な流れを通すかもしれませんが、最終的にはスタックに残るのはこれです。次に/dashboardにリダイレクトされます。
ここで私は特定のアプリ用の/dashboard/1に行きます。次に/dashboard/1/analyticsに行きます。これが私のスタックです。これは垂直スタックです。これは私がサイトをナビゲートするときにナビゲーションスタックに新しいリンクと訪れた場所を追加することです。
しかしここには水平成分もあります。サイトをナビゲートするにつれてURLは長くなり、より多くの情報が追加されます。時にはこの水平スタックを入れ替えることもあります。/dashboardは最初のページで、dashboard/1は特定のアプリのデータを提供し、/analyticsはアプリ内のどのタブにいるかを教えてくれます。
水平方向は見えるものを記述します。垂直方向はそこにどのように到達したかを記述します。この方向は私たちがレンダリングするコンテンツで、この方向はそこにどのようにたどり着いたかです。水平はコンテンツです。垂直はナビゲーション履歴です。このモデルはかなり優れています。非常に標準化されていて、特定の方法で動作することが期待され、ほとんどのウェブサイトはここでうまく動作します。
いくつかの興味深いエッジケースがあります。ここに面白い例があります。投稿した写真に行くと、この背景にページのコンテンツが見えるのは、これがモーダルとして開かれているからです。しかしURLを見ると、これがモーダルURLであることを示すものは何もありません。
SL Theoステータス、このID、photos1。ハードナビゲートすると全く異なるビューになります。なぜならリンクをクリックするとモーダルとして開かれますが、リンクを読み込むとページビューとして開かれるからです。これは非常に興味深いです。なぜならリンクをクリックする動作とリンクに行く動作が異なるということです。
ここには私が掘り下げられる多くの複雑さがありますが、それも比較的まれなことです。今ではNext.jsでこれが機能として構築されましたが、それはそれほど頻繁には必要ありません。現時点では不必要な複雑さのためにこれは無視することにします。しかし複雑さについてはそれだけです。
ウェブをナビゲートするとき、シングルページアプリを持っていれば、つまりこれらのURLごとに新しいHTMLを読み込まない場合、いくつかの興味深い奇妙なことができます。しかしほとんどの場合、URL=特定のHTML。JavaScriptの世界では、URLは常に同じHTMLファイルを指すかもしれませんが、読み込まれるJavaScriptがそこからページのコンテンツを変更します。
一般的に言えば、URLはページに表示されるHTMLを決定します。これは皆さんにとって理解できると思います。では、モバイルはどうでしょうか？モバイルを意味ある形で異なるものにする点を認識する必要があります。一つ目は、モバイルにはURLがありません。アプリにURI対応を組み込むことはできます。
アプリのURLのようなものを作ることはできます。しかしデフォルトでは、モバイルアプリにURLの概念はありません。通常、アプリケーション、特にアプリプラットフォームにはナビゲーションスタックの概念があります。このナビゲーションスタックはモバイル上で異なるビューをレンダリングする独自の方法です。そしてウェブのものとは非常に異なる動作をします。
最初は似ているように見えるかもしれませんが、深く掘り下げていくほど、それがいかに異なるものかに気づき始めます。例としてTwitterを使いましょう。Twitterモバイルアプリで自分を画面共有したいくらいです。これをスタック上に表示すると、現在の場所、我々がいる場所はホームです。
これを少し違った形で視覚化します。すべてを積み上げます。ホームビューは現在いる場所です。実際にはタイムラインビューのようなものでしょう。下部の他のタブに行くことができます。検索ボタンを押して検索タブに行くことができます。
横方向にドラッグしても戻ってこないです。サイドバーや他のアカウントに連れて行かれます。しかしここに行くと、つまり私のプロフィールに行くと、突然戻るようにスライドできます。理由はナビゲーションスタックに追加したからです。プロフィールビューを追加しました。これにはメタデータがあります。クリックしたプロフィールがTheoのプロフィールだということを知っています。
では現在プロフィールビューがスタックにあります。ここから興味深くなります。ここで異なるタブをタップするとどうなるかを見てください。投稿から戻ってもメディアには戻りません。投稿プロフィールビュータブからメディアプロフィールビュータブに戻って投稿に戻ることはなく、ホームに戻るだけです。これらのナビゲーションスタックの各スポットで起こることは、それぞれが独自の水平レイヤーを持っていることです。
このプロフィールビューは実際にはプロフィールビューではなく、プロフィール上の投稿ビューです。そして今それをメディアビューに切り替えました。これはスタック内のこの場所で投稿ビューを置き換えました。特定のナビゲーションはスタックに追加されます。ここで投稿をクリックすると、例えば20万ヒットした投稿をクリックすると、再びスタックに追加されます。
これで単一投稿ビューができました。この投稿ビューにはプロフィール指示子がありますが、投稿IDもあります。なぜならこのビューをレンダリングするためにはその情報が必要だからです。前にいた場所、メディアタブに戻ることができます。そして再び戻ることができます。しかし今わかるのは、アプリをナビゲートするとき、垂直にスタックに追加するか、周囲をナビゲートするときに水平に追加するかのどちらかです。
ここでの違いは、周囲をナビゲートするとき、例えばダッシュボード例を使い、異なるセクションに切り替えるとき、戻るボタンを押すと以前いたセクションに戻ることです。x.com/t3.ggに行き、異なるタブに移動して、ブラウザで戻ると、URLが変更されたため、以前いたタブに戻ります。
/mediaに行くと、今はt3.gg/mediaになります。水平にナビゲートしているわけではなく、常に垂直にナビゲートしています。ウェブでリンクに行くとき、リダイレクトのような自動的に起こることでない限り、それが垂直スタックに追加されて追加される可能性が非常に高いです。
モバイルでは、これについて決断する必要があります。それはブラウザがやることを全員が行うという無料のものではありません。アプリにナビゲーション機能を追加するたびに、これについて考える必要があります。この投稿ビューで投稿を見ているとき、私のプロフィールに行くべきか、それともスタックを上るべきか、水平に行くべきかについて考える必要があります。
見ている投稿を切り替える場合、スタックを上るべきか、水平に行くべきか。Twitterでは、新しい投稿や何かの新しいインスタンスに行くと常に垂直に追加されます。しかし、現在いるものの異なるビューに行く場合は、水平に行きます。ここで投稿に行き、返信やサブスクリプションに切り替えると、水平ナビゲーションが得られますが、スタックには追加されません。
これはすべて聞こえるよりもはるかに重要です。なぜならこれらのすべては、二本指で左右にスライドするようなジェスチャーから、ネイティブの戻るボタンが適切に処理されることまで、すべてが処理されるからです。そして最も重要なのはアクセシビリティです。
一部の人々は電話をナビゲートするのに指を使用しません。これを行うためのカスタムコマンドやレイヤーを持っています。プラットフォームが期待する方法でナビゲーションを処理しないと、彼らのナビゲーション方法が完全に機能しなくなる可能性があります。これはアプリについて考え方の大きな違いです。
特定の方法で機能するリンクを持つウェブページを取り、それをアプリに入れて機能すると期待できない理由です。ウェブテクノロジーに基づいたアプリを使用するとき、あるいはもっと悪いことに、モバイルを理解していないウェブ開発者によって構築されたアプリを使用するとき、彼らは単に各URLを電話上の特定のビューに移植します。
そして今、あなたは常にこれらの巨大なナビゲーションスタックを構築しています。Blue Skyが最初に登場したとき、これに非常に悪かったです。プロフィールを通ってナビゲートし、何らかの情報を見ていた場合、始めた場所に戻るために20回ほどスライドする必要がありました。Twitterのようなものでのほとんどのナビゲーションフローでは、数レイヤー下に行くだけです。
そして全くレイヤーを下りないナビゲーションもたくさんあります。ホームフィードから検索に行くとき、それはスタックを垂直に変更するナビゲーションではありません。iOSでこれを考える方法は実際のレイヤーのようなものです。この投稿を開くとき、それは今上に開いています。
戻るとき、上にあるこのレイヤーが押し出されているのが見えます。そして私のプロフィールに行くとき、その上に新しいレイヤーがスライドしているのが見えます。これはTwitterアプリのカスタムエンジンで構築されたものではありません。これはネイティブプラットフォームの動作方法の一部であるため、Twitterアプリの動作方法の一部です。
これらの垂直ナビゲーションのスタックは、モバイルアプリを体験する方法に不可欠です。そしてURLを押し込み、ウェブと同じ方法でナビゲーションを処理すると、アプリは本当に不安定に感じます。これは非常に一般的です。モバイル開発者がReact Nativeについて不満を言うとき、これが最も不満の一つです。
React Nativeがウェブのように動作させるからではなく、多くのReact Native開発者がウェブ開発者だからです。そしてそれらのウェブ開発者はURLでのこのナビゲーション方法に慣れています。そのため、それらを合わないモバイルアプリに強制します。これは非常に興味深い力学であり、おそらく考えるべき以上に考えています。
このアイデアは、私のプロフィールが投稿の上に開いていて、それがタイムラインの上に開いているということです。そして今ここでナビゲートするとき、私はまだ上のそのレイヤーにいます。ただその中を移動しているだけです。これがこれらのナビゲーション方法がいかに異なるかのアイデアを与えるのに役立つことを願います。
ウェブ開発者がモバイルには違いがなく、ウェブサイトを移植するだけで大丈夫だと装っているのにうんざりしています。そしてモバイル開発者が自分たちのナビゲーション方法が明らかに優れており、ウェブの方法には利点がないと主張するのにうんざりしています。ランダムなウェブページで小さな「開く」ボタンをタップしてウェブページからアプリで開こうとするとき、それが機能しない理由です。
ウェブとモバイルでのナビゲーションの動作方法の間には根本的な非互換性があります。そして私はツーリングだけでこれを解決できるとは思いません。これらはアプリを構築する際に注意して決定する必要がある決断です。良くも悪くも、React Nativeを使用することは、あまり気にしない開発者をもたらすことが多いです。なぜなら最も気にする開発者は自分のプラットフォームに最も執着している人たちだからです。
彼らはネイティブツールとテクノロジーを使用して構築しています。これは逆も同じです。ウェブ上でFlutterを使用している場合、ウェブプラットフォームを気にしない可能性が高いです。たとえFlutter for webが理論的に本当に良いとしても、ほとんどのFlutter for webウェブサイトは悪いでしょう。なぜならそれを使用している人々はウェブテクノロジーを好まない、または理解していない人たちだからです。React Native開発者はアプリがどのように機能し、それらをどのように使用すべきかを知る可能性が低いです。
モバイル開発者はウェブがどのように機能し、どのようにナビゲートすべきかを知る可能性が低いです。そしてモバイル開発者が作ったウェブアプリを使用しているとき、またはウェブ開発者が作ったモバイルアプリを使用しているとき、それは非常に明らかです。これもウェブとモバイルの両方で同時に動作するプロジェクトを目指すツールのファンではない大きな理由です。なぜならナビゲーションが根本的に異なるため、両方で動作するものを作ると、どちらにも最適ではないからです。
これはアプリの中で最も複雑なコードでもありません。Twitterのナビゲーションスタックを処理するコードは、おそらく数百から数千行程度です。それらのアプリケーションのコードの1%にも満たないでしょう。それほど複雑ではありません。しかしウェブとモバイルにコンパイルする単一のプロジェクトを作るとすぐに、一つのルーティングパラダイムを持つ必要があります。
そしてその一つのルーティングパラダイムを持つとすぐに、すべてを最適でなくしてしまいます。はい、ここで言いたいことすべてをカバーしたと思います。なんと長い旅でした。このビデオがこれほど長くなるとは思っていませんでした。最後まで付き合ってくれたことに大変感謝します。何かを得られたことを願います。
モバイルとウェブの違いについて考えるためのより良いメンタルモデルが得られたことを願います。そして多分、ウェブへの配信が今日のように簡単なモバイルへの配信を見ることができる未来があるかもしれません。しかしそれまでは、主にウェブにこだわります。誰よりもT3チャットアプリが欲しいですが、そこに到達するには多くの作業が必要です。
コメント