20,276 文字
近頃AIで生成されたWebアプリが溢れかえっているのは誰の目にも明らかです。今やTwitterをスクロールすれば、誰かがcursorやv0などを使って1日で作ったものが10個は見つかります。しかし、モバイルアプリについてはまだ少し様子が違います。モバイルアプリの生成が難しいのは、コードを書くのが大変だからとか、Macが必要だからというだけでなく、ビルドの設定やAPIの扱い、配布など、モバイルアプリの生成に必要な全工程がかなり複雑だからなのです。
私自身もモバイルアプリを作ろうとして、この経験があります。皆さんにもそういった経験があるかもしれません。しかし今日、状況は大きく変わり始めています。bolt.newがモバイルアプリのサポートを開始したのです。これは、誰がアプリを作れるのかという点で、ゲームチェンジャーになる可能性を秘めています。
私の人生の大半において、膨大な経験やツール、そして配布に必要な全ての要素を持っていなければ、モバイルアプリを作ることはほぼ不可能でした。しかし、それが今まさに変わろうとしているのです。そのことについて、なぜこれまで難しかったのか、何ができるようになるのか、そして実際にアプリを作ってみることについて、お話ししたいと思います。
その前に、今日のスポンサーからのメッセージです。最近はReactアプリを立ち上げるのは簡単です。create next appやcreate T3 appを実行すれば、たいていうまくいきます。React Nativeがそれほど簡単だったらいいのですが。確かにExpoのようなツールのおかげで、これまで以上に始めやすくなっていますが、優れたモバイルアプリを作る全工程は、Webで何かを作るのと同じようには簡単ではありません。
多くのWeb開発者がモバイルアプリに貢献したいと思っても、それはそう簡単にはいきません。むしろ危険かもしれません。少なくとも、ちょっとした助けがなければ。そこで今日のスポンサーであるinfinite redの出番です。少数のWeb開発者や、あるいは大勢のモバイルエンジニアと素晴らしいモバイルアプリを作ろうとしているなら、彼らが助けてくれます。
彼らはReact Nativeの業界をリードする専門家で、アプリの立ち上げからエッジケースのデバッグ、大規模チームのオンボーディングまで、何でもやってくれます。70人以上を対象としたワークショップも問題なくこなします。つい最近、サンフランシスコで大規模なワークショップを開催したばかりです。
彼らは小規模なスタートアップだけを支援しているわけではありません。もちろんそういった支援もしますが、Amazon、Zoom、Starbucksといった、少し大きな企業もクライアントに持っています。最大手とまではいきませんが、お分かりいただけると思います。
React Nativeを正しく使いたい、チームを軌道に乗せたい、あるいは困難な部分のほとんどを任せられる外部チームの助けが必要な場合、彼らに相談するべきです。私がそう言えるのは、CTOのJamonが私の親しい友人で、我々が最終的にT3チャットアプリを作ることになった時に一緒に仕事をすることになる相手だからです。
私は彼らが大好きです。これはお金をもらっているから言っているのではありません。React Nativeの世界で、彼ら以上に信頼できる相手はいないと思っているからです。このことをきちんとやりたいなら、彼らに相談してください。今すぐsoy.l/infinitredでチェックしてください。そして、theoaからの紹介だと伝えるのを忘れずに。
では、本題に入りましょう。アイデアからApp Storeまで、挑戦してみましょう。公平を期すために、Firefoxベースのブラウザではなく、そうでないブラウザで試してみます。
おお、これは面白い。「Expoでモバイルアプリを作る」というのをクリックすると、そのまま埋まるんですね。モバイルアプリを作ってみましょう。チャット、何を作るべきでしょうか？皆さんの助けが必要です。T3チャットモバイルアプリ？そうですね、T3チャットが明確な選択肢のように思えます。AIにT3チャットアプリを生成させてみましょう。Vercel AI SDKを使って、OpenAIのAPIと通信するようにします。
他にも面白い機能がありますね。superbaseへの接続やデプロイボタンがあります。これは非常に強力です。disclosure（開示）しておくと、以前bolt.newは私の動画でスポンサーになったことがあります。短い広告のような形でしたが、今回のことは彼らは私に知らせていませんでした。これは全くスポンサーされていません。私は純粋にAIアプリ生成のアイデアに興味があり、そしてExpoの人たちとも親しいので、彼らのことが大好きなのです。そういったバイアスは考慮に入れてください。
しかし、これが本当に何ができて何ができないのか、純粋に見てみたいと思います。Expo routerを全面的に採用しているようですね。これは興味深いことです。Expo routerのような機能があることで、アプリのワンショット生成が以前よりもずっと簡単になっていることは確かです。
さて、いよいよ始まりました。もう多くの考えが浮かんでいますが、まずはこれが動くのを見てみましょう。自分のモバイルデバイスでプレビューするように求められています。もしご存じない方のために説明すると、React Nativeの面白い点の1つは、React Nativeレイヤーがネイティブレイヤーに何をすべきか指示を出すという仕組みです。
試してみましょう。カスタムアプリをビルドするためのXcodeの設定がない場合、電話でテストする方法は、Expo Goアプリを使用することです。今インストールしていますが、すでに持っているはずです。そうですね、持っていました。
App StoreからExpo Goアプリを入手するだけです。開く必要すらありません。iOSのカメラスキャナーアプリを使えば、カメラを開いてスキャンし、開くをタップし、ローカルネットワークアクセスを許可すれば…AI reactモジュールを解決できないというエラーが出ましたね。
少し幻覚を見ているようです。APIキーを要求していますが、それは後で対処します。クライアント側で幻覚を見ているようですね。use chatがAI reactになっているようです。そんなものはないはずです。AI SDKは常にそうですが、AIを使っても少し調査が必要なのは変わりません。
use chatはSDK reactの間違いでしたね。ここに戻って…AI reactというパッケージはありません。use sdk reactを使用する必要があります。また、ここでnative windを呼び出しているのも面白いですね。ご存じない方のために説明すると、native windはTailwindをモバイルで動作させようとする試みです。
もう一度ここに戻ってみましょう。うまくいきそうです。指を交差させて…バンドルしています。来ました…とても近いです！動きました！実際の電話が映し出されています。これは本当にすごいことです。実際のAIチャットモバイルアプリです。まだ動作しません。AIキーがないので動きませんし、いろいろな部分が壊れていますが、とにかくここまで来られたことがすごいです。
明らかにこれはまだ使えるものではありません。正直に言って、コードの書き方を知らないふりをしてみましょう。入力時にエラーが出ると伝えてみましょう。「undefinedのプロパティvalueを読み取れません」というエラーが出ます。修正してくれるか見てみましょう。
誰かが既に表示されている9つのエラーについて質問していましたね。「まだマウントされていないコンポーネントでReactの状態更新を実行できません」、「handle submitをhandle submit content inputに変更してください」、「接続されたソースがありません」…いいえ…
プロジェクトがクラッシュしていたようです。キャッシュをクリアしました。「try datファンクションで予期しないコンマ」というエラーが出ています。そのファイルを見てみましょう。HMRサーバー…それは私たちには修正できないものですね。
やり直してみましょう。「Expoでモバイルアプリを作る」、基本的なAIチャットボットアプリにしましょう。2回目の試行でどうなるか見てみましょう。QRコードは隠さないと、誰かが使ってしまう可能性がありますね。今回は隠すようにします。
まだ生成中です。まだExpo routerを使用していて、異なる場所に配置しています。QRコードを皆さんに見られないように隠しながら取得します。
さて、入りました。見てください。チャットと設定ボタンがあり、よく似ていますね。送信ボタンはありますが、見えないだけです。実際に動いています！1回目…いや3回目の試行ですが、とにかく動きました。AI SDKを使うように指示しなかった時は苦戦していたようですが、今回は単純に何かを作って、それを構築しました。
モックAIレスポンスも含まれているので、すべてが動作しているのが確認できます。これは本当にすごいことです。このようなものを適切に始めるのは、特にExpo、React Native、ルーティングの管理方法の基本を知らない場合、世界で最も簡単なことではありません。
しかもこれはiPhoneアプリだけでなく、Androidでも動作します。ただ両方にコンパイルする必要があります。でも私が本当に気になっているのは、このデプロイボタンです。App Storeへのデプロイオプションがありますが、それをクリックする前に、なぜこれが重要なのか、そしてなぜこれまで大変だったのかについて、時間をかけて議論する必要があります。
私は多くの皆さんがWeb開発の仕事をされてきたことを知っています。私もそうでしたし、ここに集まっている多くの人々もそうだと確信しています。モバイルアプリは、Web中心の開発者には理解しがたい理由で難しいものです。
モバイルアプリの問題は多岐にわたります。まず第一に、アプリが構築されるプラットフォームに完全に依存しているということです。Webでよくやることの1つは、実質的にプラットフォームを再発明することです。Webが必要な機能を持っていない場合、私たちは自分たちで作ることができます。
例えば、WebAssemblyを使ってPythonコードやGoコードをブラウザで動かしたり、Canvasを使って独自のエンジンをブラウザで構築したりできます。しかしモバイルの場合、ほとんどの部分でプラットフォーム自体と、そこに組み込まれた機能を使うように推奨されています。
これには別の厄介な問題が付いてきます。プラットフォームを満足させ続けないと、すべてを失うリスクがあるのです。多くの人々は、App Storeの問題はAppleの問題だと考えがちです。確かにAppleはこれをひどく台無しにしていることには同意します。
しかし、それはAppleだけの問題ではないと思います。実際、Googleはしばしばもっと悪いです。彼らの規制はより意味が分かりにくく、アプリを規制したりアップデートを制限したりする時、より少ない情報しか提供せず、しばしば間違ったことをして説明もしません。Android Storeで出荷しようと最善を尽くすのは面倒な作業になり得ます。
私はEpicがGoogleとの裁判で勝訴し、Androidマーケットプレイスが少し開放されることを強制されたことを本当に嬉しく思います。ただ、それがAppleにも起こればいいのにと思います。この2社がApp Storeを運営する方法は嫌いです。iPhoneストアにアプリをデプロイするために基本的にMacを所有する必要があるというのは笑い話です。
しかし、AIにとって最大の問題はこれらではありません。最大の問題は、公開されているコードとアクセス可能なAPIの比率です。これは複雑な問題で、私なりに説明を試みます。Webでは明らかに多くの異なるソリューションがあります。これをスタイルソリューションと呼びましょう。ここには多くの異なるものがあります。バニラCSS、Bootstrap、Tailwind CSS&JSなどがあります。ご想像の通りです。
Webには様々なスタイルソリューションがあります。これだけ多くのオプションがあると、AIが混乱するのではないかと思うかもしれません。ランダムにそれらを切り替えてしまうのではないかと。重要なのは、これらのオプションの1つ1つに膨大な量の参照資料があるということです。
これはTailwindを使用したソースコード、これはCSS in JSを使用したソースなどです。そのため、オプションの数自体は、考えられているほど重要ではないのです。より重要なのは、これらのオプションが持つ参照資料の量です。
現在の業界スタックの場合、特に私を含めた多くの人が好んで紹介するReact、Next、Tailwind、TypeScriptのスタックは、インターネット上に膨大な参照資料があります。私が作成したチュートリアルを人々がコピーしてオープンソース化したものを考えてみてください。cursorなどのツールを使って、意図的であれ偶然であれ、すべてのソースコードを送信している巨大なコードベースを考えてみてください。様々な開発者や企業が作成した例をすべて考えてみてください。
これらのテクノロジーの例の量は非常に多いため、AIがこれらを生成するのは非常に簡単です。なぜモバイルアプリに関するビデオでWebのスタイルソリューションについて話しているのか？モバイルについて話しましょう。
ルーティングソリューションについては、特にReact Nativeに入ると、多くのオプションがあります。今回はReact Nativeに限定しても、React Navigation、React Native Navigation、そして今ではExpo Routerがあります。これらの異なるオプションがあります。
問題は、これらのうちのどれか1つについて、どれだけの参照資料があるかということです。React Navigationを使用しているオープンソースコードの量はおそらくかなり少ないでしょう。あまり見たことがありません。React Native Navigationも同様で、参照資料があまりありません。
可哀そうなExpo Routerは、まだ新しく、より多くの参照資料を作る努力がなされていますが、まだ新しいため、さらに少ないのです。ここでの問題は、モバイルのオプションの数がWebのオプションの数と比べて意味のある程度少ないわけではなく、これらのオプションの1つ1つについての参照資料の量も非常に少ないということです。
では、これをどうやって解決できるでしょうか？多くのモバイル開発者は好まないかもしれませんが、これらのオプションを既存のオプションとより似たものにすることで解決できます。
多くのスタイルソリューションが、Tailwindのうまくいっている部分を取り入れようと努力してきました。これにはUno CSS、WY CSS（今は終了したと思います）、Panda CSS、その他多くが含まれます。これらはすべて、それぞれの利点と欠点を持つ素晴らしいソリューションです。
しかし、これらのうちのどれか1つについて参照資料を探すと、あまり多くは見つからないでしょう。これはAIがなくても困ることです。なぜなら、Unoで問題を解決しようとしても、参照や例があまりないからです。しかしTailwindを使用している場合、Web上にほぼ無限の例があります。
しかし、もしUno、Wendy、PandaがすべてTailwindスタイルの構文をサポートしているなら、Tailwindの世界からの解決策がこれらでも機能する可能性が高いです。このような方向に向かってアーキテクチャが動いているのを多く見てきました。
もう1つの面白い例はReact Compilerです。Reactが最後のフレームワークであるという動画をまもなく公開予定です（もう公開されているかもしれません）。これが私の言いたいことです。Reactの構文は今や非常に一般的になっており、それをサポートするものが大量にあります。
これは部分的にHTMLに似ているからですが、ほとんどは一定のレベルのトラクションを得たからです。現在、Reactを使用するための例となる資料の量は途方もないものです。これは彼らを追い込むことになります。なぜなら、ReactチームにはもはやそれほどReactの構文を変更する機会がないからです。
例えば、完全に理論的な考えですが、props equalsをこのように書くのは実際には良くないと気付き、それを単にインラインで書くべきだと気付いたとしましょう。これは彼らができない変更です。なぜなら、私たちのアプリの多くを書くことになるAIにとって、新しい構文について知るのに十分なデータがないからです。
もちろん、システムプロンプトでこの異なる新しい構文を使うように指示することはできますが、参照資料がそこにないため、結果として同じようにうまく機能しないでしょう。では、この問題をどうやって解決するのでしょうか？
React Compilerは、基本的に二度と構文を変更する必要がないと約束することで解決しました。コンパイラはそのようなものを受け入れます。例えば、インラインでpropsを書く方が良いという理論的な例を使うと、コンパイラは私たちのためにコードを変更し、最適なことを何でもしてくれます。
つまり、私たちは構文を変更する必要がなく、より重要なことに、AIは新しいことを学ぶ必要がありません。その結果として得られるアプリは単に良くなります。私はstylex nmanの作者が、実際にTailwindのために同様のものに取り組んでいることを知っています。
Tailwindコードをstyxexを通してコンパイルし、ReactとReact Nativeでうまく動作する、より効率的なCSSとJSSのソリューションを持つことができます。しかし、あなたの愛するTailwindの構文を置き去りにする必要はありません。これは本当にすごいことです。
ある意味で、これはAIが私たちを後退させる可能性がある方法です。実際のツール、つまりコードや言語、構文の意味のある改善は、ソフトウェア開発の歴史上、これまで以上に正当化が難しくなっています。
しかし、これは全てモバイルにどのように関係するのでしょうか？ここを見てみましょう。React、Next、Tailwind、TypeScriptの素晴らしい例が大量にあることには同意しましたね。しかしReact Nativeはそうではありません。
React Nativeのオープンソースプロジェクトはそれほど多くありません。最近まで、Nextに相当する良いものはありませんでした。例えばReact Navigationは、それほど多くありません。Tailwindはオプションではありませんでした。RN Stylesheetがありました。そして、もしFacebookに過度に注目していれば、それらのモバイルアプリではFlowを使用していたかもしれません。
あるいは、React Nativeでさえなく、Swiftを使用している場合、Swiftのナビゲーション関連がどのようなものか分かりません。そのため、それは空白のままにしておきましょう。SwiftUIを使用している場合でも…ここでも、SwiftUIはメジャーバージョン間で多くの変更があり、重要な機能をランダムに非推奨にしたりその逆を行ったりしています。
そして、SwiftUIは依然として、Swiftアプリの過半数で使用されているとは思えません。そのため、古いUIのものに行き着く可能性があります。その名前は…Core何とかでしたっけ？私はいつも忘れてしまいます。私はSwiftUIの初期の頃に入ったので…
ああ、UI Kitですね。ありがとうチャット。つまり、iOSの正しい道筋についての参照資料がそれほど多くないのには理由があります。これらのものがうまく機能するコードのほとんどがオープンソースではないからです。そして、これらのオープンソースの例を至る所で共有する文化もありません。
また、任意のSwiftUIバージョンでの変更量が多いため、3年前にAIがトレーニングに使用したかもしれないコードは、今日ではほとんど動作しません。これは私のSwiftUIでの経験です。Xcodeの更新に対処した後、古いSwiftUIプロジェクトを開くたびに、過去に使用していたものが変更されたり、もはや存在しないために多くのエラーが発生します。
誰かがReactのコードベースのメンテナンス性について不平を言うのを聞くと不思議です。私は基本的にSwiftアプリをアップグレードすることができないのですから。しかし、それぞれに好みがあるでしょう。
ここで私が言いたい主な点は、トレーニング用の資料が、存在する物事の量、そしてより重要なことに、これらの物事の中の任意のものの変更量に比べて十分ではないということです。
では、これをどうやって解決するのでしょうか？先ほど言ったように、これが黄金のスタックであることは分かっています。これらのものがあり、AIはそれらを生成するのがかなり得意だということが分かっています。このテクノロジーが良いかどうかについては一日中議論できますが、私は気にしません。
AIがこれらのものを生成するのが得意だということは議論の余地がありません。React、Next、Tailwind、TypeScriptのスタックでのAI生成が全体的にかなり良い状態にあることに同意する他のソリューションのファンボーイと多く話をしてきました。
では、この問題をどうやって解決するのでしょうか？違いがそれほど重要でなくなるように、モバイルスタックをできるだけ似たものにしようとしたらどうでしょうか？
ReactからReact Nativeへ。これは当たり前ですね。Nextはもう少し課題があります。なぜなら、React Navigationを見ると、これは非常にモバイル特有のものだからです。モバイルのナビゲーションは非常に異なるからです。
これは私がしばらく作りたいと思っていた動画のテーマです。スタックの概念は、履歴の概念とは非常に異なります。モバイルで良いルーターを作ることは難しいです。特に、モバイルでできることすべてを最大限に活用したい場合は。
ここにはスタックナビゲーターと、ネイティブスタックルーターがあり、これら2つの異なるスタックを作成できます。そしてナビゲーションスタックルーターをネイティブスタックナビゲーターを使用してレンダリングします。これは、Webdevとして慣れているものとはまったく異なります。
これが良いか悪いかを言っているわけではありません。実際、これは私がモバイル開発とWeb開発の違いをより良く理解するために重要でした。私が絶対的に言えることは、これはWebdevで使用しているルーターとはまったく異なるということです。その結果、理論的に生成できるコードは、それほど良くないものになります。
Expoは意図せずにこれを解決しました。Expo routerは、React navigationのようなものよりも、NextやRemixのようなものにずっと似ています。そのため、Nextがどのように機能するかについての多くのデータが、Expo routerのコードを出力しようとする際に突然より有用になります。
これには、バックエンドの扱い方についても本当に便利な副次的な利点があります。しばらく前に学んだ厳しい現実があります。サーバーインフラ側とJSで構築されたsoy boy側のスペクトルがあるとすると、このスペクトルは多くの開発者が当てはまるものです。
私は真ん中あたりにいると思います。私は多くのバックエンド開発をしていますが、皆さんが認めたくないかもしれませんが、おそらく皆さんは私をここにいると思っているでしょう。私はおそらく2つの間のどこかにいます。
しかし、重要なのは、あなたがいる場所が、どちらの側で作業することに快適さを感じるかを決定するということです。ここにいる場合、サーバー側よりもJS側に少し傾いて快適に感じるかもしれません。
しかし、FFmpegのアセンブリコードについて話すとなると、これはスペクトルからかけ離れすぎていて、スペクトルの右側にいる人々にとっては恐ろしい考えになります。
モバイル開発者はこのスペクトルのどこに位置するでしょうか？チャット、教えてください。モバイル開発者はこのスペクトルのどこに位置するでしょうか？第三の次元があるという興味深い理論ですね。インフラとsoy devを超えて、両側を嫌う…でも認めない…それはあまり間違っていません。
私が経験した厳しい現実は、私の推測が間違っていたということです。平均的なNext.js開発者がここにいるとすると、つまり平均的なNext開発者がここにいるとして、私の推測では、平均的なモバイル開発者はこの側にいる、ここあたりにいるだろうと思っていました。しかし、モバイル開発者ともっと話をし、upload thingをモバイルユースケースにより対応させようとしたり、もちろんサーバーコンポーネントについても多く話をした後、私は痛烈な気づきを得ました。
モバイル開発者は、私たちJS中毒のsoy boyよりもさらに右側にいるのです。彼らはサーバーを恐れています。モバイル開発者にサーバーを構築するよう頼むと、宇宙人を見るような目で見られます。JSONを返すエンドポイントを提供するよう頼むと、冷や汗を流し始めます。
Firebaseのような恐ろしく悪いものが存在できる理由は、モバイル開発者がそれほど遠くのものに触れたくないからです。その結果、ほとんどのモバイルツール、React Nativeでさえ、意図的にサーバーサイドから距離を置いています。Firebaseを使って自分で安全でないものを構築することを許容して、サーバー側の処理を避けてきました。
Expo routerはそれを変えました。Expo routerはAPIエンドポイントを導入し、今ではサーバーレンダリングも導入しています。Expo routerでのサーバーコンポーネントの素晴らしい機能について、私は全編の動画を作っています。
Expo routerはWebへのエクスポートも可能にしました。アプリを構築するために必要なすべての要素が揃い始めています。なぜなら、アプリを構築する時、ただの派手なUIを作るだけではないからです。それが接続する何かも構築する必要があります。ほとんど常にそうです。サーバーの形態を持たない、使う価値のあるアプリはほとんどありません。
しかし、AIにアプリを構築するよう依頼し、これらのことについて何も知らない場合、サーバーが必要だということすら分かりません。そしてAIがクライアントとは別にサーバーを構築しなければならない場合、より多くのものが分離され、より重要なことに、異なるファイルや、さらに悪いことに異なるコードベースに存在する場合、AIはその全体像を扱うのが苦手になります。
Expo routerは、フロントエンドファイルのすぐ隣にバックエンドファイルを置くことを可能にし、Nextに似た構文で、ほとんどそのまま動作させることができます。これを最もよく理解するには、Expo routerプロジェクトを構築してみてください。Next開発者であれば、すでに慣れ親しんでいる多くのものが引き継がれることに驚くでしょう。
では、残りの部分はどうでしょうか？ここにTailwindがありますが、モバイルでTailwindを使うことはできないのでしょうか？Native windは本当に素晴らしいプロジェクトです。実際、Native windは現在Expoで働いている開発者によって構築されました。Native windの目的は、React Nativeのコンポーネント内でTailwindを効果的に書くことをずっと簡単にすることです。
問題は解決したように見えますね？まあ、Native windの世界には残念ながら多くの注意点があります。それでも本当に素晴らしく、私が今モバイルアプリを構築するなら…そうですね、もうすぐモバイルアプリを作らないといけないんですよね。
とにかく、Native windは本当に素晴らしく、意味のある場所では間違いなく使おうとするでしょう。そのため、問題はある程度解決されました。これで、Tailwindとほぼ同じ構文を持つものができました。そのため、すべてのトレーニング資料もまだ有効です。
TypeScriptについては、もう誰もFlowを使っていません。私たちは完全にTypeScriptに移行しています。TypeScriptには、エラーを提供し、それらのエラーをAIが問題を修正するためにより適切に使用できるという追加の利点もあります。
はい、すべて解決しましたね？これで、この人気のあるWebスタックにとても似たツールキットができました。完璧な資料ではないかもしれませんが、十分近いので、少し先に進むことができるかもしれません。そしてそれは事実のようです。
ここで生成されたコードを見ると、Webで同じものを構築した場合とよく似ているでしょう。実際に試してみましょう。興味深いですから。「Next.jsでWebアプリを構築する」、基本的なAIチャットボットアプリにすべきですね。出力コードがどれほど似ているか見てみましょう。私にはある予感があります。
これがReact Nativeバージョンです。おお、ブラウザ内プレビューのようなものまでありますね。これは本当に便利です。メッセージ、チャット画面、input、setInput、messages、addMessage、flatlist…これが最もReact Nativeらしい部分です。flatlistは混沌としています。
こちらに移動すると、input、setInput、messages、setMessages、isLoading、setIsLoading、handleSubmit…このバージョンにはAIレスポンスのシミュレーションがあります。実際のマークアップを見てみましょう。ここでは賢く、KeyboardAvoidingView、flatlist、viewを取り込んでいます。
このバージョンでNative windを使用しなかったのは興味深いですね。パッケージすら持っていないようです。魅力的です。彼らはここに私が思っていた以上の努力を注いでいるかもしれません。これは本当に素晴らしく、とても興味深いものです。
ルーティングを比較して、それがより似ているか見てみましょう。ここのルーティングは非常にミニマルですね。layout、route、page、そしてglobalsがあります。そしてこちらではルーティングをさらに進めて、例としてhandleClearChatボタンを持つ設定ページも作成しています。
これはすべて、異なるものでトレーニングされているようです。予想していたほどの重複はありません。チャットストアがこちらでどのように処理されているか見てみましょう。もしあるとすれば…ありませんね。単にmessages、setMessagesだけです。興味深い。
これら2つにもっと重複があると予想していました。魅力的ですね。代わりにNative windを使ってみましょう。ターミナルエラー。問題は何でしょうか？.pluginsが良くない…古いMetroエラーですね。修正を試みさせてみましょう。
かなり壊れた状態になってしまったようです。元に戻しましょう。そうですね、だめでした。試してみる価値はありました。これは面白いですね。モバイルでの私の実際の開発経験にとてもよく似ています。常に最も途方もなく意味の分からない方法で壊れます。
えらくエラーが出ていますね。リセットで直ることを願います。はい、できました。誰かがAndroidでそのコードをスキャンしたんですね。なんてオタクな…でも、それができるのは本当にすごいことです。ここでアプリを作業していて、チームの誰かに素早く試してもらうためにコードを渡せるということです。
ここで私が最も興奮しているのは、完成する前にアプリを試すことができるというアイデアです。Appleは歴史的に、App Storeで何を許可し、何を許可しないかについて本当に厳しかったです。
面白いことに、Expoは主にこのために存在します。より多くのアプリのような機能ができる良いモバイルブラウザを構築しようとしていたのですが、Appleに禁止されてしまいました。そこで、新しいタイプのアプリのためのプラットフォームを構築することができなかったため、代わりにアプリを構築するより簡単な方法を作ることにしました。
AppleがApp Storeの運営方法について直面している法的問題のすべてにより、アプリが許可されるべきか否かの境界線で実験する人々に対して、少し寛容になってきたように見えます。他のアプリの機能を使用させることを…これらすべてが今まとまってきているのを見るのは素晴らしいことです。
しかし、ここでブラウザ内にReact Nativeアプリがあります。もしまだご存じなければ、React NativeはiOSやAndroidのようなネイティブプラットフォームだけでなく、コンソールでも動作します。しかし、より重要なのは、React NativeはWebでも動作するということです。
面白い事実：React Native for Webは元々Twitterのために構築されました。TwitterはiOSやAndroidでReact Nativeを使用していませんが、今日でもWebサイトにReact Nativeを使用しています。
私たちは多くのことを試してきました。壊れやすいことは認めます。そうでないふりはしません。モバイルのエコシステムは常にそうです。特にこのようなモバイルアプリ構築ツールキットをブラウザで実行している場合は。しかし、最後の怖いボタンを押してみたいと思います。App Storeにデプロイです。
これがどういうことになるのか、まったく分かりません。一緒に試してみましょう。App Storeに提出…これはホストされたサービスなのでしょうか？ああ、これはただのeas submitですか？私はすでにeas submitを知っています。
App Storeに何かをデプロイするのに何が必要かをご存じない方のために説明すると、公式のApple開発者アカウントを持つために年間100ドルの料金を支払う必要があります。App Store提出用に署名されたネイティブアププリバイナリを作成する必要があり、それをAppleに提出する際には、すべての指示とメタデータが必要です。
特に権限関係については、例えばカメラ権限が必要な場合、Appleがアプリを見る前に、アプリでカメラを使用する理由を説明的に記述する必要があります。そうしないと、Appleは単に却下して、「これをより良く説明してください」と言うでしょう。
すべてそれが完了したら、Appleに承認してもらえるかどうかを確認するためにバイナリを提出できます。署名して、そのすべてを行うのは楽しいことではありません。私はアプリを適切に署名するためにXcodeと何度も戦ってきました。
Expoはこれをずっと簡単にしました。eas submitコマンドを実行するだけで、これらのステップのほとんどを実行してくれます。適切なAppleキーを持っていない場合は、それを処理するためのリンクを提供してくれます。それらの部分は面倒ですが、機能します。他の選択肢よりもはるかに良いです。
正直に言うと、Expoを使わずに今すぐアプリをデプロイできるとは思えません。ステップが多すぎて地獄のようだからです。App Storeにデプロイボタンがあると思っていましたが、気になります。ここでeas submitを実行できるでしょうか？
エラー：実行する実行可能ファイルを決定できませんでした。それは理にかなっています。boltとstack blitzの以前の作業の仕組みは、私たちがSSHで接続するサーバーで実行されているのではなく、効果的にboltが私のブラウザでWebコンテナとして実行されているということです。
つまり、実際に私のブラウザで実行されているミニノードのようなものがあり、そのnode VM内で効果的に、Web標準V8に基づいて、外部の個別サーバーを必要とせずにブラウザで多くのことを実行できます。
しかし、これはWindowsでもMacでもLinuxでもない、この奇妙な第4のものだということを意味します。これが実際の伝統的なプラットフォームではないため、es buildのような、スクリプトとJavaScriptコードをコンパイルしてバンドルするためのGoの代替手段のような、ネイティブプラットフォームを期待する特定のものがあります。
es buildはgoで書かれており、ネイティブバイナリが必要です。幸いなことに、es buildにはこのようなものに使用できるwasm互換のバイナリがあります。ブラウザでVを使用している場合、es build wasmバイナリを使用することになります。
しかし、eas submit…これはより難しくなるでしょう。Expoがアプリをバンドル、コンパイル、レビュー用に提出するために必要なすべての統合を構築することを…それをすべてWebで動作させることは不可能でしょう。しかし、今すべてが理解できます。
まだWebにデプロイすることはできます。なぜならReact Native for Webは存在するからです。しかしApp Storeへのデプロイは、まだあなたの問題として残ります。このビデオに従えば15分で全体を完了できるようになったことは本当に素晴らしく、見るのが楽しみです。でも、まだ手作業が必要です。
私たちは多くの問題を解決したように見えます。アイデアから出荷までのスペクトルがあり、Webではそのスペクトルは比較的短いです。つまり、Webアプリのアイデアから出荷までに必要な労力は比較的小さいのです。
モバイルの場合、必要な労力は著しく大きく、より多くの痛みを伴う停止点があります。ここに「自分のマシンで動作する」という線があるとすると、その線はWebの場合、出荷の線にかなり近いところにあります。モバイルの場合、その線は全体的にずっと後ろにありますが、準備が整うまでの時間という点では早くなります。
私の電話やiPadで完全に問題なく動作するアプリを持っていても、15以上のステップを経て、最終的にバイナリをビルドし、私のApple開発者アカウントで承認され、アプリがレビューに提出され、すべてのレビューに合格し、ようやく出荷できる…というのがどれほどのことか、お伝えできません。
これらのステップが多すれば多いほど…これをどう説明すればいいでしょうか。このアイデアから出荷までの全スペクトルは、bolt.new、v0、lovableなどのAIツールでほぼ解決されています。これらは今や、ほとんど経験がなくても、アイデアから出荷まで非常に簡単に進めることができる段階に来ています。
構築したものが素晴らしいものになるか、本当に信頼性高く動作するか、多くのトラフィックを処理できるか…そうですね、それは分かりません。しかし、このプロセス全体を今やAIを使って比較的迅速に実行できます。
これが私が本当に強調したい重要な部分です。このボックスが構築に必要な労力だとすると、モバイルでは単にそれを構築するだけでも、Webで全体を出荷するよりも多くの労力が必要です。
これは多くの点で残念なことです。なぜなら、もしあなたがboltやExpoの作成者であれば、このボックスを最適化し、より良くするために何年もの仕事を注ぎ込むことになり、それに対する注目は少なくなり、スペクトル全体への影響も少なくなるからです。
Web開発者がこの部分を修正する場合、あるいは「自分のマシンで動作する」から出荷までのこの部分だけを修正する場合でも、ExpoでBoltを動作させるのに必要な労力よりもずっと少ない労力で済みます。しかし、これはより魅力的に見えます。
これまでにそこまで到達するのにこれほどの労力が必要だということは残念なことです。これらの残りのステップすべてにさらに長い時間がかかるという事実は、特にここでもう少し現実的になると…私のアプリがレビューに提出されてから、すべてのレビューに合格するまでの空間が、Webのアイデアから出荷までのパイプライン全体に匹敵するということです。
これらの直感的な感覚は、私の経験からすると、おおよそ同じ長さです。そうですね、私はboltとExpoのものがもう少し先に進むことを期待していました。ここまで私のために達成してくれることを望んでいました。しかし、それができない理由は理解できます。それは非常に多くの混沌とした追加作業を必要とするからです。
この部分は、boltとExpo routerが助けているところです。この部分は、eas buildが助けているところです。開発者アカウントの承認の部分はそれほど悪くないので、それをここに移動させましょう。これは単に良いドキュメントと言えます。
私たちはその部分を気にしますか？とにかくやってください。アプリをレビューに提出するのは面倒ですが、それほど悪くはありません。これについては、eas submitが本当に優れています。私の矢印では、eas submitがここで役立ちます。
そして最後のこの部分…ああ、この最後の部分…Appleのカンファレンスでの素晴らしい言葉を借りれば、ここで助けになるのは「勇気」だけです。そうです、これが問題です。
私は、モバイルアプリの出荷がWebアプリの出荷と同じくらい簡単な世界を夢見ています。この部分、そして今やこの部分までもがますます解決されているのは素晴らしいことですが、スペクトルの残りの部分はまだ最悪です。
そのため、アイデアを持っている誰かが、Webバージョンから始められるのに、モバイルアプリから始めることを正当化するのは本当に難しいのです。これは私のNext.js AIチャットアプリで、boltで生成されました。
データベースを追加したい場合は、superbaseに接続をクリックして接続できます。明らかにNextではサポートされていないようですね、それは面白い。そして準備ができたらデプロイをクリックするだけで、vercelにライブで公開されます。
モバイルではそこまでいっていません。そしてAppleが特定の変更を加えない限り、そこに到達するまでには長い時間がかかるでしょう。なぜなら、現実的に言えば、ここのほとんどすべてがAppleが難しくしているせいです。Googleも公平に言えば同様です。
この部分は、モバイルアプリ開発を必要以上に難しくしているものです。この部分も最悪です。この側面での革新には多くの努力が払われてきましたが、これこそが最初のモバイルアプリの出荷、そのモバイルアプリの維持、そしてソフトウェア構築のリリースサイクルでの本当の成功を最悪にしているものです。
現実的に言えば、私たちが苦心して作り、おそらく1日に10回のアップデートを出荷しているT3チャットのようなものは、そのスピードで出荷できる方法では構築されていませんでした。
悲しいことですが、モバイルアプリ開発とモバイルアプリプラットフォームは、5年前のWeb開発の水準にさえまだ追いついていません。今やAIの登場により、笑えるほど遅れているように感じます。
私は正直に思います。iOSであれAndroidであれ、どちらのアプリプラットフォームでも、最初にこれを諦めて平坦化する方が、iPhoneが最初にApp Storeを追加して以来見られなかったレベルのモバイルソフトウェアの革新を目にすることになるでしょう。
そして、これをAppleやGoogleで働いていることを知っている人々への挑戦として提示したいと思います。誰が最初にこれを打ち砕けるか、誰が最初に、これは依然として自分のサーバーを購入し、倉庫に行って自分でラックに設置するのと同じことですが、誰が最初にverselやnetlifyへのジャンプを実現できるか、この問題を解決できるか、それがプラットフォームの勝者となります。
Expoのようなこれをよりスムーズにするための企業の努力はすべて、出荷するために必要不可欠です。しかし、モバイルアプリを構築する人の数の指数関数的な曲線、指数関数的な成長を見たいなら、私たちの電話でアプリケーションでできることの革命を見たいなら、AppleとGoogleの周りをハックし続けることはできません。
AppleかGoogleが、これがすべてどのように起こるかを根本的に変える必要があります。AppleとGoogleは、iPhoneの発表時のスティーブ・ジョブズの元のビジョンに立ち返る必要があります。
「モバイルデバイス向けのアプリケーションを作成する革新的な新しい方法を手に入れました。本当に革新的です。そしてそれは、iPhoneが完全なSafariを内蔵しているという事実に基づいています。完全なSafariエンジンがiPhoneの中にあり、それは今日までのモバイルデバイスで可能だった以上の大きな能力を私たちに与えてくれます。
そのため、iPhoneのアプリと全く同じように見え、全く同じように動作する素晴らしいWeb 2.0とAjaxアプリを作成することができます。これらのアプリはiPhoneのサービスと完璧に統合できます。電話をかけることができ、メールを送ることができ、Google Mapsで場所を検索することができます。
作成した後は、即座に配布できます。配布について心配する必要はありません。単にインターネットサーバーに置くだけです。そして更新も本当に簡単です。本当に複雑な更新プロセスを経る必要はなく、自分のサーバー上のコードを変更するだけです。そして…申し訳ありません…」
これを振り返って聞くのは本当に面白いです。なぜなら、彼がこれを良いアプリプラットフォームにする理由として挙げているすべてのことを、彼らはApp Storeで台無しにしたからです。それぞれすべてについてです。
「AmazonやBankとの取引で使用するのと同じ種類のセキュリティで安全であり、iPhoneで安全に実行されるので、その信頼性やセキュリティを損なうことはありません。そして驚くべきことに、必要なSDKはありません。iPhoneのための素晴らしいアプリを今日書くために必要なものは、最新のWeb標準を使ってアプリを書く方法を知っているだけです。」
おそらく、ただおそらく、AppleはiPhoneが発表された時のスティーブ・ジョブズの約束を思い出し、光を見るでしょう。そしてある日、彼が描写したのと同じくらい良い経験をモバイルでアプリを展開できるようになるかもしれません。
なぜなら、ジョブズはそれを理解していたように見えるからです。素晴らしいモバイルユーザー向けアプリを作るために、それらすべての狂ったことをする必要はなく、そのすべてのハードルを越える必要はないはずです。
そしてその一覧を振り返り、元の約束の良い恩恵からAppleがどれほど遠ざかってしまったかを認識するのは、振り返ってみると本当に面白いことです。そしてこのビデオが、Appleが良い開発者体験だと知っているものからどれほど遠く離れているかを示すのに役立つことを願っています。
スティーブ・ジョブズが今まさに、iPhoneの素晴らしい点として挙げたすべてのことは、現時点では当てはまりません。そうですね、おそらく将来的には、今説明されたのと同じくらい簡単にモバイルでアプリを展開できるようになるでしょう。
しかし今のところ、私たちはまだそれらを構築する方法を理解しようとしている段階です。数年を経て、アプリの作成がより簡単になるどころか、より難しくなっているということは少し狂っています。一方で、Webサイトの作成は常により簡単になっているというのに。
うーん、これは有用な動画だったでしょうか？なんて狂った脱線の数々…皆さんの考えを聞かせてください。次回まで、ではさようならナードたち。
コメント