私にとってのCapacitorの立ち位置と、Web制作者がCapacitorでアプリをつくれるようになるということ

2020年9月3日 21:32

React Nativeを利用してる @Nkzn さんに「Ionic/Capacitorがどういうケースに適してるかを語ってみろ。React Nativeはちゃんと記事にまとめた！（意訳）」と言われたので、まとめてみます。

ちなみに本記事は全文無料公開（9月3日時点）しています。もし満足してもらえたら、課金してください。

クロスプラットフォームツールの特徴

ここでは、クロスプラットフォーム開発のフレームワーク・ライブラリとして、Cordova、Capacitor、React Native、Xamarin、Flutterを紹介します。どれもがすばらしいのですが、開発思想やクロスプラットフォームを実現するためのアプローチで違いがあります。

1. WebViewでUIをレンダリングするCordova/Capacitor

Cordova/Capacitorは、アプリのUIをWebViewでレンダリングします。つまりは、デバイス側の処理としては1枚のView上にWebView（Webブラウザ）を表示しているだけで、ボタンやテキスト、画面遷移といったUIはすべてそのWebView内で描画されます。

「画像は一切使ってない！？CSS3だけで描いた“ドラえもん”がすごい」みたいなことができる表現力にすぐれたWeb技術でUIをつくることができるのが最大の特徴です。

WebViewはパフォーマンスが悪いみたいな思い込みがありますが、アニメーションでも60fpsでており、WebViewでもNativeViewでも実装次第でパフォーマンスは変わります。

2. ネイティブなUIレンダリングをするReact Native/Xamarin

それに対して、React NativeとXamarinはネイティブなUIレンダリングを行うことができます。各ページにViewを割り当て、ボタンやテキストを配置していきます。UIは独自のタグとStyleを使って構築しますが、実行時にはデバイスのネイティブ言語（iOSはObjective-C/Swift、AndroidはJava/Kotlin）に変換されるイメージです。

const WelcomeScreen = () =>
 <View>
   <Header title="Welcome to React Native"/>
   <Text style={heading}>Step One</Text>
   <Text>
     Edit App.js to change this screen and turn it
     into your app.
   </Text>
  </View>

React Nativeの独自タグ例（ViewやHeader要素）

Cordova/CapacitorのようにWebViewを起動する必要がないので、初回起動時間は比較して0.5秒ほど高速です。また、すべてのUIコンポーネントが実要素としてView上にあるので、「UIのスクロール途中にAdMob（ネイティブコンポーネント）の広告を挿入する」といったことも可能です（Cordova/Capacitorは性質上、上部もしくは下部に固定で配置することしかできません）

3. ネイティブレンダリングで実装するFlutter

Flutterは複数のレンダリング形式があるのですが、PlatformViewを使うと、SwiftやKotlinでつくったレイアウトをFlutterに渡して処理を行うことができます。「Flutter の PlatformView を使って Kotlin で実装したコンポーネントを Widget として読み込む」がとてもわかりやすい説明をしてくれています。

Cordova/Capacitor、React Native/XamarinがUIを共通化することを目指してることに対して、FlutterはUIはネイティブコードにまかせて処理を共通化するアプローチはとても興味深いです。

4. すべてのデバイスAPIはネイティブコードが必要

よく勘違いされているのですが、Cordova/Capacitorも、React Native/Xamarinも、Flutterも、デバイスAPIにアクセスしたり、iOS/Android対応のSDKを利用するのにはネイティブコードを書く必要があります。ただ、各プラットフォームでプラグインが用意されているので、プラグイン利用の範疇ではそれが隠蔽されているだけです。

例えば、Facebook Loginを実装する時に利用するプラグインです。

- Cordova: https://github.com/jeduan/cordova-plugin-facebook4
- Capacitor: https://github.com/capacitor-community/facebook-login
- React Native: https://github.com/facebook/react-native-fbsdk
- Xamarin: https://github.com/HoussemDellai/Facebook-Login-Xamarin-Forms
- Flutter: https://pub.dev/packages/flutter_facebook_login

これらはすべてネイティブコードとクロスプラットフォームツールを自動的につないでくれるので、利用する時にはネイティブコードをみる必要はありません。また、SDKのラッパーなので開発者の思想に実装はさほど左右されません。

けれど、「あなたのプロダクトに100%一致したQRコードリーダー（連続読み取りができて、こういうパターンでは赤縁をだして...みたいな）を作りたい」みたいな時はどのクロスプラットフォームを使っていてもプラグイン開発が求められ、ネイティブコードを書くことが必要になります。

クロスプラットフォームツールの違い

大まかにプラットフォームの思想の違いについてみていきましたが、最終的に何が違うかといえば、以下の2点になります。

・何をどの言語で共通化しているか
・何を隠蔽しているか（ツールが肩代わりしてるか）

Cordovaの場合
CordovaはWeb制作者がネイティブ部分を意識しないで開発できることに重きが置かれてるので、プラグイン開発に着手しない限りはネイティブコードをさわることはありません。iOSのAppDelegateも、AndroidのMainActivityもCordovaがビルドの度に自動生成します（それ故トラブルが起きたら原因究明が難しい一面もあります）。

基本となる開発言語はWeb標準（HTML/CSS/JavaScript）です。また、モバイル向けのUIコンポーネントは自分でデザインする必要があります（Ionic FrameworkなどのUIフレームワークで対応可能）

Capacitorの場合
CapacitorはCordovaのコンセプトを引き継ぎつつ、ネイティブコードは自分で管理していくスタイルです。Cordovaはネイティブコードは（毎回生成されるため）Git管理しませんが、CapacitorではGitで管理するもの、といえばイメージがつくでしょうか。ネイティブの一部をユーザに露出させたことで、ビルドに失敗しにくくなり、またネイティブレベルのカスタマイズが可能になりました。Swiftでつくったプロジェクトの一部にCapacitorを導入するようなことも可能です。

基本となる開発言語はWeb標準です。また、UIコンポーネントはWeb技術でデザインする必要があります（Ionic FrameworkなどのUIフレームワークで対応可能）

React Nativeの場合
Capacitorよりも、よりネイティブ寄りになったのがReact Nativeです。

iOS14でsegmentのデザインが上から下に変わりましたが、Cordova/Capacitorで実装してる場合は同様のものを再デザインしないといけません（※ Ionic FrameworkなどのUIフレームワークを利用してる場合は、フレームワークをバージョンアップしたら対応可能）。

スクリーンショット 2020-09-03 18.44.52

スクリーンショット 2020-09-03 18.45.00

React Nativeは、ネイティブのUIコンポーネントを呼び出しますので、ネイティブのデフォルトデザインが変わった時に、容易に追随できます。

基本となる開発言語はReactです。（書き間違えではなく、筆者個人としてはJSではなくReactと捉えています）

Xamarinの場合
基本的にはReact Nativeと同様ですが、React NativeがJavaScriptCoreを介してネイティブコードを実行することに対して、XamarinはC#で書いて、そのままランタイムで実行する特徴があります。iOSで実行時、Objective-Cで書くよりもパフォーマンスに優れてると話題になったほどです。

基本となる開発言語はC#です。

Flutterの場合
Cordova/CapacitorがWebViewをプラットフォームとしており、React Native/Xamarinが各プラットフォームランタイムを軸にしていることに対して、Flutterはどのプラットフォームにも依存しないコアがあり、そこから各プラットフォームにアプローチしています。

基本となる開発言語はDartです。

Capacitorの技術的な立ち位置
ここまでで、各クロスプラットフォームの特徴を紹介してきましたが、その中でユーザの技術的なCapacitorの立ち位置としては、以下のようになります。

[Web]---Cordova---Capacitor---React Native---[Native]

Web周辺技術を使ったクロスプラットフォーム開発では、完全にWebに寄ってるのがCordova、Nativeに寄ってるのがReact Nativeで、ちょうどその中間になります。UIはWebViewで表示しつつ、ネイティブ部分はネイティブコードを直接さわってGitで管理することができるので、現代の一般的なWeb開発フローに乗せてアプリ開発を行うことができます。より詳細の仕組みの部分については以下記事を参照ください。

Capacitorが `for me` だった部分

どうして私がCapacitorをさわりはじめたかの話になるのですが、ちょっと長い話になって、2016年までさかのぼります。当時のスキルセットでいうと、以下あたりのまぁ一般的なWeb制作スキルでした。

・HTML/CSS/JavaScript
・WordPress
・PHP/MySQL

その時は特にモバイルアプリはつくったことはなかったです。仕事でWebアプリはいくつか作ってたのですが、ビジネスツールだったこともあって、パソコンからWebブラウザを立ち上げて使うような設計ばかりでした。

□ モバイルアプリも対応した方がいい企画を立ててしまった

ところが、あるソーシャルサービスをつくろう！という話なった時にふと思ったんです。企画的には、Facebookみたいなユーザにとって身近なツールになってほしいのですが、ユーザは果たして毎回ブラウザを立ち上げて、ブックマークからアクセスしたいかと。

実体験からもネット上からみたレポートでも、Webは新規訪問率が高い反面、モバイルアプリは一度インストールすると再訪問率（起動回数）が多く、PUSH通知も使える。開発サイドからみたら、Webアプリという「場」があればそれで十分なのですが、ユーザに使ってもらうことを考えると、Webでどんなアプリか知ってもらうのは当然のこと、長らく利用してくれるユーザにはモバイルアプリとして便利に使ってもらいたいなと思ったので、モバイルアプリへの対応を考え始めました。

一応当時いろいろみたのですが、ネイティブ開発は最初から諦めていました。仮説検証段階のアプリを、しかもたったひとりの開発者（※私）がつくるのに、WebとiOSとAndroidの3つを個別に実装してられるわけがないです。無理。今でも無理。

で、当時はCapacitorもFlutterもReact Native for DOMも存在していなかった（未リリースだった）ので、Cordova一択でした。Web技術でUIコンポーネントを再現してるIonic FrameworkをUIフレームワークとして、開発をはじめました。

当時ネイティブの知見はまったくありませんでしたが、Cordovaがすべてネイティブのコードを隠蔽してくれていたのでさほどストレスなくリリースまでこぎつけることができました。

□ Cordovaは運用がつらい

これを書くかどうか悩んだのですが、私の体験ということでご理解ください。Cordovaは悪いライブラリではありませんし、はじめてアプリをリリースした時、Cordovaがなければ私はモバイルアプリに関わることはありませんでした。

けれど、これは言いたい。Cordovaは運用がつらい！

というのもの前述した通り、Cordovaはネイティブコードをすべて自動生成します。これには、Cordovaのバージョンと設定が適切であるだけではなく、Cordova本体と利用してる各プラグインのバージョンがすべてコンフリクトを起こさないという前提があります。つまりは、どれかひとつのプラグインのバージョンをあげた結果、コンフリクトが起きるとすべてがビルドできなくなります。

Cordovaはリリースして仮説検証するのにはとても便利なのですが、運用してバージョンアップを重ねていくと、Cordovaの特徴である「隠蔽」が牙を向きます。

2018年、私のプロジェクトではビルドする度にエラーが起きるという状態になってしまっており、Cordovaからの移行を検討しはじめました。

□ Capacitorへの移行

ちょうどそのあたりで、利用しているモバイルUIフレームワーク「Ionic Framework」を開発しているIonic teamが、Capacitorの開発を発表しました。以下で「新しいプロジェクトをはじめたわけ」が書かれていますが、それがまさに私の抱えていた問題だったため、即座に移行を決めました。

移行はあまり苦労しませんでした。この時はじめてiOSのAppDelegateやAndroidのMainActivityをさわったので「何これ変更していいやつ大丈夫壊れない？（Cordova脳）」でおっかなびっくりだったことは覚えていますがｗ

移行後、フレームワーク特有の運用に関する問題は解消しました。また、Capacitorをさわることを通じて、SwiftやJava、またXcodeやAndroid Studioへの理解を深めることができ、今では普通にプラグイン開発も行っています。

□ React Nativeをどう思うか

React Nativeユーザの@Nkzn さんとTwitterでやりとりしててよく思うのですが、はじめた時期やきっかけがひとつ違ったらReact Nativeでやってたと思います。

私がCordovaをはじめた当時でいうと、React Native DOMやfor Webは存在せず、React Nativeはあくまで「Reactで書けるiOS/Android向けクロスプラットフォームライブラリ」でした。しかし、今ではTwitterが利用してるように、Web向けも開発することができます。

逆に、現在のReact Nativeユーザも、時期が違ったらCapacitorを利用していたと思っています。昨年、Ionic Frameworkは正式にReact対応を行い、ReactユーザはIonicとCapacitorでのアプリ開発を行えるようになりました。デバイスの性能もあがり、React NativeでつくったアプリとCapacitorでつくったアプリは性能でみるとほぼ遜色はありません。

ほぼ唯一の差異は、UIをWeb技術で書いてWebViewでレンダリングするか、独自タグで書いてネイティブでレンダリングするかの違いです。

□ 今の私にとってCapacitorは `for me`

以下のnoteで、アプリをひとりハッカソンで2日でリリースした話を書きました。

どちらかというと企画・経営サイドで仕事をしてる人なので、Capacitorのひとりで2日でアプリをつくってリリースできるこの圧倒的な仮説検証力と、あと長年Webコードを書いてるのでぼーっとしながら手が動く慣れ親しみが私にとっての `for me` です。

Capacitorのおすすめポイント

私はこうだった、をいろいろ書きましたが、まとめとして、別目線からポジション別にCapacitorのおすすめポイントを紹介しておきます。なおポジショントークです。

□ 経営者向け：UIデザイン・コーディングの人材採用・育成が容易

私の観測範囲だと、UIデザインができる上で、SwiftやJavaでコーディングまでできる人材はほぼインハウスで抱え込まれています。Reactも同様ですね。それに対して、CapacitorはWebViewなので、Web制作（HTML/CSS）ができればUIデザインからUIコーディングが一貫して可能です。まじでこれは強い。

ベースのUIデザインフレームワークをベースにしたデザイナ・コーダの採用や育成は（なぜかフリーランススクールがWebデザインとコーディングばかり教えて人材放出するという背景もあり）Webが圧倒的にハードルが低いです。

□ フリーランス向け：アプリ納品ができるという付加価値がつけれる

もちろん人や案件・規模によって単価はわかるのですが、静的なWebサイト数ページで10万円、WordPress化で30万円あたりからが一般的な単価でしょうか。それに対してiOSアプリとAndroidアプリを両方だすなら大体100万円からです。

スクリーンショット 2020-09-03 19.59.33

安いと言われ続けてるLancersの相場で、Webの仕事が6万円からなのに対して

スクリーンショット 2020-09-03 19.59.42

Androidアプリだけで30万円なわけです。クロスプラットフォームでiOSもだすことできますので、2倍で60万円。一般相場はもちろんもっと上です。

身につけたWeb技術の延長線上で、iOSアプリやAndroidアプリをつくれるようになってみませんか？

□ Web制作会社向け

クライアントのWebサイトをつくるというのは広報のお手伝いなわけですが、クライアントの最終目的は利益をあげることです。総合的なサポートとして、アプリの開発提案ができるようにしてみませんか。

先程紹介した、2日でリリースした（※厳密にはその後改善を繰り返しています）食品表示印刷はすでにいくつかの飲食店に導入されており、オペレーションを改善しています。

アプリ「食品表示印刷」を早速採用いただいた、西明石のクールランプリールさんに。自分が作ったものを知らないところで使ってもらえるの嬉しいですね！https://t.co/Y1HZRjFHzr pic.twitter.com/pwYiQPIekc
— Masahiko Sakakibara (@rdlabo) August 22, 2020

広報って最終的には、飲食店だったら席数、通販などでは発送オペレーションがボトルネックになって利益の妨げになるので、それを改善する提案がセットでできるってすごく強いですよ。

ちなみに、初心者向けに、Ionic FrameworkとCapacitorでアプリをリリースする書籍も好評発売中です。というか評価星５をたくさんいただいてありがとうございます🙏

ここまでで全文ですが、「参考になった」という方はぜひ以下からお支払いいただけましたら幸いです！

それでは、また。

ここから先は

0字

¥ 860

ログイン

この記事が気に入ったらチップで応援してみませんか？