単行本この商品を含むブログを見るボツネタ詐欺師症候群について延々と説いていたらそれだけで埋まってしまったので全部消しました。Apps開発のエッセンス」のブログ版記事です。CfP提出後に内容は二転三転しまして、当初は最新Web開発事情について技術的に突っ込んだ内容にしようと目論んでいたのですが、「iOSエンジニア」へ「伝えたいこと」という軸で作っているうちにこの内容に落ち着きました。当日聞きに来てくださった方、声をかけていただいた方。このような場を下さったiOSDCスタッフの方々にはたいへん感謝しています。Workersが実装され「iOSがPWAをサポートした」というニュースが業界内で話題になりました。Workersについては後ほど解説します)このニュースは憶測や曲解を呼び、時には「ネイティブアプリの時代が終わった」という強い主張になって話される場面もありましたので、みなさんもどこかで目にしたことがあるかもしれません状況を整理しましょう。Workersが使えるようになったは事実です。これは既にその時点での開発計画にありましたので規定路線でした。Manifestファイルに対応してアイコンなどを指定できるようになりましたしかし実際のアップデートはこれだけで、間違ってもAppleの誰かが「PWAに対応しました」などの声明を出したわけではありませんこのようにPWAを取り巻く情報の解釈は複雑です。私が思うに業界内で刺激的な話題が先行してしまったのは、Webとネイティブアプリ開発それぞれの側面で技術をただしく評価できていなかったからではないかと感じました。Safariのことを理解するのが必要だと考えています。このトークの前にiOSアプリ開発をしている知り合いのエンジニアたちへ「PWAという言葉を聞いてどう思うか」と質問してみました。そこではUIやUXのクオリティやアプリストアでのファイダビリティの懸念などの意見をいただきました。そこで気づいたのですが、PWAと名前が付けられたことによってネイティブアプリと比較して優劣を語る人の多さでした。ここの思い込みを先ず解かないといけなさそうですまた現状はAndroidのChrome上での体験とSafariでの体験は全く別物であると言えます。その為、同じPWAという言葉を使って話していても、iOSユーザーとAndroidユーザーで捉えている像がそもそも噛み合わないということが起りえました「PWAがネイティブアプリを置き換える」というストーリーは本質的ではありませんまず私が主張したいのがこれです。Chrome開発者らによって提唱されましたPWAに限らずGoogleは一枚岩の組織ではありませんから、Googleのどのチームの人達が言っているのかというのに注目するのがよいと思います次に各プラットフォーマーにとってPWAがどのような意味を持っているのかというのに触れたいと思います。Appsなどあらゆる方向からWebをよりよくする為の改善を続けています、その延長線上にPWAがあるのは不思議ではありません。StoreへのPWAの登録を可能にしました。タブレットやデスクトップ向けのアプリ開発市場を活性化させたい意図が見えます。OS)しかしAppleさん、完全にノーポジです。Workersは実装されましたが、Appleは基本的にPWA関連の戦略を発表していません。SDK誕生以前、アップルはサードパーティの開発者がWebアプリとして自分のアプリを公開するような構想を持っていましたこれはセキュリティ上の理由による決定だったらしいのですが、開発者らの猛反発にあい現在のネイティブSDKの提供となったわけですPWAとは元々、ネイティブアプリでは実現できるがWebアプリではできない体験の溝を埋めるために、ブラウザ側に実装された新機能を使うべしという側面があります。「Webページ」という層より更に低レイヤー・ネイティブに近い層として処理を記述できる仕組みが用意されています。Workersと組み合わせて使うという例がよく出てきます。それは「ブラウザのオフライン基盤」と捉えるのがより本質的だと思います。「プログラミング可能なネットワークプロキシ」という表現もされています。この「ローカル」というのを「アプリがインストールされる」と考えるとiOSエンジニアにも理解しやすいと思います。Workersの登録・アップデートの管理をブラウザが透過的に行ってくれる仕組みを含んでいます。これによってWebページによるアプリの表の面とシステム上で動く「裏の面」が表現されているのです。3G時代から存在しました。Manifest(JSON形式)をサポートしました。APIはiOSにくる未来はおそらくないのでしょう。支払い関連のAPIも最新のSafariで利用できます。Payは利用できますし、この機能はうまくWeb標準とAppleの仕様が噛み合った例としてうまく機能しています。PWAとは、ブラウザに実装された、新機能を使うと、従来のWebアプリに不足していたUXが実現できる。いうだけの話なんです。」ということと「柔軟な配布方法」できる。いうことがあげられるかと思いますWebアプリは外部アプリのWebViewの中からでも起動できますし、ブラウザさえあればどこでも動作します(そしてホーム画面からでも)Webアプリの柔軟な配布方法についてです。Workersによってイントールする単位をインクリメンタルに管理することも可能になりました。ここでいうオフラインファーストとは何でしょう。それは、データを取得しなくてもUIを構成できるということです。具体例としてはキャッシュされたアセットやレスポンスから読み込むことができます。ShellモデルというのもChromeチームが提唱したWebアプリのアーキテクチャの名前で、ネイティブアプリのメンタルメデルに近いのでiOSエンジニアには理解しやすいかと思います。iOS開発でオフラインファーストを意識する場面はどの程度あるでしょうか?ネットワークのリトライ処理やキャッシュのハンドリングなどを独自に実装されている方も多いと思います。WebアプリがWebであるがゆえに根本的に抱える問題というのもあります。OSが持つ機能との接続はAPIが存在するか次第でありますし、ネイティブに見た目を近付けるほどその違和感が出てくるジレンマなどもあります。UI遷移などはおもたる例で、ブラウザ上のレンダリングエンジンでOS権限でグラフィックAPI叩けてハードウェアに近い最適化のできるネイティブな実装に近付けるのは指南の技でしょう。Safariの課題としては、Windows版Safari廃止以降に進んだOS独自機能の取り込みというのがあげられます機能によってはWeb標準への準拠の動きはコンフリクトするため、うまく統廃合する必要があるでしょうまたiOSではChromeやFirefoxなどのサードパーティのブラウザはWebKitの利用を強制され、システムのデフォルトにできません。ホーム画面にショートカットを置けるのもSafariだけです。いうことですiOSエンジニアがWebアプリ技術に注目しておいた方がいい理由2014年に話題になった「ロードマップ指向とエコシステム指向」というブログ記事があります。それは技術の革新を牽引する存在がプラットフォーマーなどの大きな企業から、それぞれの意思を持つ小さなコミュニティに移り変わったことだと思います例えば、Googleのように。モバイルOSの開発をしつつブラウザ体験をよくする、しかしそれを置き換えるような新プラットフォームも開発している。いう企業はそれぞれの方向性は違うが時には統合して進化している。いう点が、非常にエコシステム的であるといえますここで注目したいのは現代でエコシステムを中心に急成長してきた技術としてのWeb開発環境ですブラウザベンダーは標準化された仕様の実装でそれぞれ競争し、サードパーティのライブラリは各分野で御互いのいいところを取り込んだり、もっと良いやり方を提案したり巨大なOSSプロジェクトを戦略的に企業が運用・参加していますWeb技術のコミュニティではエコシステムで進化を促進する仕組みが機能しているのです。いうのを本日は知っていただきたいのです。Web技術の進化が早くなるのか。それは、Webに関わる人口の多さが関係しているのだと思います。ウェブブラウザやデバイスの利用環境は多様化していますし、Webアプリのフロントエンド開発技術はJavaScriptに集約されています。思い起してみると今から10年前の2008年に「iOSエンジニア」という職業は存在しませんでした。この10年、CocoaからiOS開発の環境は目紛しく変化しました。毎年OSやIDEが一新され、アプリは壊れ、プログラミング言語すら切り替わってしまいました。AppStoreとわたしたちデベロッパーが作り出したアプリ開発のエコシステムが「iOSエンジニア」を作りだしたわけですそれと同じようなことはWeb開発の世界では今起っています。AppleのロードマップによるiOS開発環境の進化を待つだけでは、もはや劇的な進化は訪れません。私たちデベロッパーがエコシステムを乗りこなし、iOSの開発環境を進化させるべきだと思います。Swiftなどはまだまだ未成熟なので、非常にコミットする余地のある領域だと思います10年後の「iOSエンジニア」を思い浮かべてみてください。*1この記事を書いたきっかけniconegoto.hatenadiary.jp「PinQulをクローズします」にて事業のふりかえりをしている文章の中に「アプリビジネスは完全にダウントレンドにある」という一節があって、ここから話題が広がっていったのを機に上記の記事を読みました。思うところがあったのです。アプリビジネスは完全にダウントレンドというのは自分も前から思っていた。リッチな体験、通知を遅れることはアプリの利点だが、他PFからの流入なども含めたプロダクトのコアな検証はwebモバイルが1番早いはず。2018(Twitter上で多くの共感を集めた投稿)例えば「モバイルアプリがWebに負けはじめた理由」ではWebアプリがモバイルアプリに比べて優れているでろうという点を分析させています。僕が注目したのは以下の部分についてもっとサービスレベルの話でいくと、初めからwebでやればよかったというのもミスだったと感じている部分です。最初にアプリで出すことにこだわりすぎてしまい、プロダクトの検証が遅くなってしまいました。ライブコマースの視聴・購入体験をよくするためにアプリでなければならないと思っていましたが実際にはwebでもほとんど遜色ないものを提供することができました。これまでの軌跡をみると、2017年10月にiOS版リリース。2018年04月にAndroid。いう情報がありました。iOS版をリリース後に少なくとも半年はAndroid版やWeb版を開発しつつ、iOSアプリの方向性を変えPMF(プロダクト・マーケット・フィット)を探っていたことになる。その期間を3プラットフォーム並行開発するよりWeb版一本でフォーカスしたかったな、という後悔が出てしまうのは共感できた。我々も同じような状況で悩み、現在モバイルアプリを開発しているからです。そんなPinQulのIF...を元に、改めてスタートアップが新規プロジェクトなモバイルアプリを今0から作りはじめるとき、技術的な観点でどの道具を選択するのか、というのを考えてみたかった。新規プロジェクトというのは俗に言うスタートアップでなくても1企業の新規事業部が0から作り出すソフトウェア製品のことでもいいです。2012年のビーンボール最初にPinQulの記事を読んだ時に2012年のマーク・ザッカーバーグのインタビューから起ったネイティブ/Web論争を思い出してしまいました。Hewittを中心に開発されたネイティブ実装で評判もそこそこ良かったFacebookの公式iOSアプリを、ある時に全面的にWebベースのハイブリッドアプリに置き換えようとした所、パフォーマンス問題などが顕著になりネイティブアプリに作り替えた時のものです。マーク・ザッカーバーグのこのきわどい発言は、その場では投資家向けの弁明も含むもので、補足もされたのですが。様々な反論や憶測を呼び、業界を騒がせることになりました。Nativeを軌道に乗せているわけで、先の弁どうりWeb技術を諦めていない。いうのはガチであったことが伺えます。ビジネスのフェーズが全く異なるにも関わらずダブって見えます。2012年時点で「Webアプリはダウントレンドで、我々はネイティブアプリにフォーカスする必要がある」という空気が業界を襲ったことへの揺り戻しを感じさせるからでしょう。当時の時代背景を知る手段として「Webはクソ。ブラウザはマジなんとかしろ」の記事をあげます。ここでは進化の遅く足並みの揃わないWebアプリ開発プラットフォームはネイティブアプリに比べて遥かに劣っているという意見が述べられています。blog.mirakui.comいま、Webは重要な転換期の中にいると私は思う。Webはデスクトップアプリケーションと同等になるのに10年以上かかってるし、しかもイマイチだ。ネイティブアプリが加速していく中でWebは絶滅の危機に瀕している。PosterousのCEO「Webはクソ。——そして話は現代に立ち戻りますモバイルWebファーストと貧者のツール「貧者のツール(道具、技術)」とは、より少ないリソースしか消費できない環境で、なんとか道具を工夫して製品開発を達成するための考え方の通称で、「人ナイ物ナイ金ナイ」のスタートアップ向きであると言えます。この貧者のツールとして、スタートアップが新規プロジェクトにモバイルWebファーストを採用する利点としては以下があげられると思います。チームのエンジニアや開発するコードベースを最小にして高速に開発できる通常のアプリ開発プロジェクトではWebバックエンド/iOSアプリ/Androidアプリ/フロントエンド。技術やプラットフォームによって開発担当者をアサインすることが多いかと思います。モバイルWebファーストにすることで、iOSアプリやAndroidアプリの開発に1-2人ぶんのリソースが取られることはなくなります。Webアプリ開発者はバックエンド開発の片手間にフロントエンド開発も身に付けている人材が多いので、API→アプリクライアントサイドのコミュニケーションも短縮できる可能性があります。高速に仮説検証できる変更する対象コードが少なくデプロイも早い。担当する開発者間のコミュニケーションも省ける。いうのが想像できると思います。留意すべき点しかしモバイルWebファーストの良い面の裏に、思わぬ落し穴が隠されているケースもあります高速な開発を実現する為に選んだモバイルWebファーストが逆に開発の遅延を招く可能性も考慮すべきです。「QRコード決済アプリ」。これを僕が最初に想像した時はMediaDevices系のインターフェイスでWebでもサクっと実現できそうだなー、という印象でした。デモコードを見るとC言語のライブラリをJavaScriptに変換し、バックグラウンドでカメラをオーバーレイしたcanvasから抜き出した画像データを送りつける、という過激な実装で実現されています。デバイスに近いAPI、OSの機能を呼び出して実装するアプリはウェブで自力実装しづらいだけでなく、実現不可能=詰み状態が訪れる危険性もあり、注意が必要です。いうのは結局両プラットフォームに精通した視点が要ります。いうのは怪しかと思います。0ベースの状態で断言できるエンジニアはいないと思います。スタートアップはスピードが命ですから、もしそれをやるにはプロジェクトの開発が決定する前からアイデアの技術的な検証を普段から行っていないとできません。いう考え方があります。理想的なプロジェクトではバックエンド開発に携わる工数を大幅に削減でき、貧者のツール的であると言えます。この思想でFirebaseをフル活用して作られたサービスに、クックパッド新規事業「Komerco」というアプリがあります。jp.techcrunch.comKomercoは2018年6月にリリースされ、現在はiOSアプリしか提供されていません。Komerco開発チームがこのままAndroidアプリやWeb版を開発するつもりなのか、iOSだけでサービスを検証してゆくのかは注目どころです。」という名スピーチがあります。ソフトウェア業界の技術トレンドは、一見振り子のように同じ場所に戻ってくるように見えるが、螺旋状に変化している。螺旋を作り出す技術要素の差分と、変化の中でも変らない抽象的な考え方に注目することの重要さが説かれています。www.publickey1.jpこの螺旋の原則でいうと。HTML5ショックの2012-13年です。Mobileによるハイブリッドアプリ技術を選択し、メルカリはネイティブアプリSDK開発を選びました)。多くのサービスは先ずデスクトップ向けサイトがケータイ対応し、それを元にスマホ対応→アプリリリース。開発うるのが通例だったと思います。この時期にネイティブアプリのUXを高めることにすべてを投資したプロダクトは現在も伸びています。2018年にモバイルWebファーストで開始するサービスはどうなるでしょうか、非常に気になるところです。私たちのケース締め括りに身の上話をさせていただくと、先日私たちもPinQulと同じような状況でネイティブアプリ開発に舵を切りました。NativeやFlutterでの開発を考えて綿密にプロトタイプ開発をして準備を行っていましたが、スタートアップにありがちな「ある日状況が変わった」というやつが発生しました。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。