2022.1.24
業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (後編)
前回の投稿で、WebクリップとMDMを活用すれば、ネイティブアプリをいちいち開発しなくてもネイティブアプリのような体裁で提供ができることを紹介しました。(まだ前編を読んでいない方は先にご覧下さい)
もちろん制約はあります。紹介した手法は、Webシステムをネイティブアプリのように見せかけているに過ぎないため、ネイティブアプリでしかできないことはどうやってもできません。
ただ、逆に考えると「ネイティブアプリにしかできないこと」が分かって、それらについて「別にできなくても構わない」とか「代替手段でなんとかなる」と割り切れるならネイティブアプリ開発は不要といえるわけです。
何か業務用iOSアプリの開発を検討中でしょうか？その計画には、ネイティブアプリにしかできないことがある→だからネイティブアプリを開発するのだ、という論理がありますか？ただ何となくアプリ開発を進めようとしていないでしょうか。
もしあまり吟味せず開発を始めようとしているなら、是非本稿をご覧下さい。ネイティブアプリ開発が本当に必要なのか判断するための情報を得ることができます。また本稿は、ネイティブアプリ開発はリソース的に難しい、でもアプリは欲しい…という悩みを抱える方にとって朗報・打開策になるかも知れません。
ネイティブアプリでなければ実現できないこと？
以下のような要件がある場合、ネイティブアプリを開発しなければならないとされています。
- (A) ハードウェアを活用する
- (B) オフライン利用を想定している
- (C) PUSH通知を送りたい
- (D) その他のiOS固有の機能を使いたい
どれか1つ以上に当てはまるとネイティブアプリ開発を考えるのですが、さて、これらは本当にネイティブアプリにしかできないことでしょうか？
それぞれで具体例をあげるなら、
- (a) QRコードを読み取りたいからやはりネイティブアプリ….
- (b) オフラインの機能を持たせたいからネイティブ開発…
- (c) やっぱりPUSH通知は送りたいからアプリ開発…
- (d) ARを使いたいからやっぱりアプリ…
こんなところでしょうか。ですが、これらの理由でネイティブアプリ開発にGOサインを出すのはまだ早計です。Web技術だけでできることは日増しに増えていますし、100%要件通りに実現できなくても代替手段で補える場合もあるからです。
以下、例を上げながら1つずつ見ていきましょう。
A. Webからハードウェアを活用する
業務用アプリあるあるな要件に、以下のようなものがあります。全てiOS端末のハードウェアを使います。
- (1) カメラロールの画像やカメラ撮影した画像をアップロードしたい
- (2) 動画撮影・録音したファイルをアップロードしたい
- (3) リアルタイムにカメラ映像にフィルタをかけて表示したい
- (4) GPSやコンパスやジャイロで位置情報や方角、傾きや加速度を検出したい
- (5) バーコードやQRコードを読み取りたい
しかし、これらの要件はネイティブアプリでしかできない…わけではありません。細かくは書きませんがザッと以下のような感じで全てWeb技術だけで実現できます。
| 要件 | 対応iOS | 解説 |
|---|---|---|
| (1) カメラロールや撮影 | iOS6以降 | type=”file”の<input>要素を使ってアップロードできる |
| (2) 録画・録音 | iOS6以降 | |
| (3) 撮影＆フィルタ | iOS14.3以降 | MediaStreamでカメラやマイクのデータをストリーム取得可能に |
| (4) GPS/コンパス | iOS4.2以降 | DeviceMotionEventやDeviceOrientationEvent。当初より取得可能 |
| (5) バーコード/QRコード | iOS14.3以降 | MediaStreamと組み合わせてQuaggaJSやjsQRなどを使用 |
OS標準だけに限った話ではなく、例えば(5)の用途向けにはScanditのようにWebアプリ用にWebAssemblyを使った業務用高速リーダJavaScriptライブラリを提供しているサードベンダーもいます。
(Scandit社のjsライブラリのページ。同社はネイティブ向けのSwift用のライブラリも提供している)
一方で、WiFiやセルラー回線を使ったTCP/IP通信、BLE/Bluetooth通信、NFC等のコネクション系、その他バッテリ関係、光・近接センサ系のハードウェアはWebからは使用できません。これらをWebから使えるようにするWebAPIもありますが、Apple は iOS 上の Safari で対応しないと明言しています。
(プライバシーの懸念から対応しないことを決めているWebAPIが多数ある)
従ってこれらのハードウェア要件に含まれるならネイティブアプリを選択するしかありません。このように、一言で「ハードウェアを使う」といっても様々です。本当にWebだけで実現できない要件なのか、精査する必要があります。
B. オフライン利用を想定している
WiFi環境のない工場や、電波の届きにくい山間部や海洋上での利用が該当します。オフライン要件ならネイティブアプリ開発…と即断したいところですが、オフライン要件もWeb技術が一部解決しようとしていることも念頭に置いておくと良いでしょう。
ServiceWorker を使えば JavaScript で書かれたWebアプリをオフラインで動作させることができます。
(一度取得したWeb上のリソースを保持し、次回以降はそれで応答するような実装が可能になる)
さすがにWebへの初回アクセスは必要なので、現場展開時から廃棄まで一度たりともオンラインにならないiOS端末では使えませんが、ある程度オンラインとオフラインを行き来できる環境なら ServiceWorker によるオフライン対応は検討するに値します。
また、LocalStorage を併用すれば(iOSの場合は)5MBytes未満のデータやファイルを扱うことも可能となります。極端な話、数百kbytes程度のPDFを閲覧する程度ならWebアプリでオフライン対応簡易PDFビュワーが開発できます。
C. PUSH通知を送りたい
PUSH通知を理由にネイティブアプリを開発するケースは意外に多いです。中には、起動後はWebViewでWebサイトを開いてるだけという「ガワ」アプリもあります。
(2017年に行ったガワアプリについての講演資料から)
ここで考えたいのは「独自のネイティブアプリからPUSH通知を送る」のは本当の要件なのかということです。多くの場合、真の要件は「従業員に伝えたい情報が即時的に業務用iOS端末に届く」ことではないでしょうか。
であれば、
- メール
- チャット
で代替できる可能性もあるかも知れません。ネイティブアプリ化しようとしているシステムからメールを送れば良いだけですね。メールアプリが通知を送ってくれます。
メールだと他の情報に埋もれやすくて嫌だということなら、昨今業務での利用が進むチャットサービスとAPI連携して、システムから各従業員アカウントにメッセージとして送れば良いのです。システムからのメッセージに特化したBOTを開発してもいいでしょう。いずれにしてもチャットアプリが通知を送ってくれます。
PUSH通知機構を持ったネイティブアプリを別途開発することに比べれば、導入済みの業務用コミュニケーションツールに便乗して通知要件を満たすほうが遥かにリーズナブルです。
それでもPUSH通知の見え方はやっぱり専用アイコンでないと困る…という方もおられるでしょう。そんな方には朗報があります。iOS15から Communications Notification という仕組みにより、チャットアプリからの通知なのに専用BOTやグループから直接通知が届いたように見える実装が可能になりました。SlackやLINE等はいち早く対応しています。
(WWDC2021の資料より。チャットアプリからの通知だが、グループやシステムから通知が届いたような表現にできる)
この Communications Notification に対応したチャットサービスを使えば、ほぼ専用ネイティブアプリからの通知と変わらないPUSH通知を実現することができます。
また更に iOS15.4 のベータ版に Web アプリからPUSH通知が送れるようになると思われる記述も見付かっています(2022年2月時点)。そう遠くない将来にWeb技術でPUSH通知が容易に送れるようになるかも知れません。
D. その他のiOS固有の機能を使いたい
ケースバイケースとなりますので、「本当にWeb技術で実現できないのか？」という視点で都度調べてみることをお勧めします。
調査の過程で使えそうなWebAPIを発見したら、WebAPIが各種ブラウザで使えるかどうかを調べられる Can I use… のサイトでiOSのSafariの対応状況を調べると良いでしょう。
(各種WebAPIのブラウザ対応状況を確認できる。上図は MediaStream API の対応状況を調べている様子)
iOSの欄がもしSupported(緑色表示)で、iOSバージョンに問題ないのであれば、やろうとしていることが当該WebAPIを使って実現できないかを検証します。
例えば、昨今のメタバースやXRというバズワードの煽りをうけてAR(Augmented Reality)をやりたいとしましょう。iOSにはネイティブで使える ARKit や RealityKit 等がありますが、まずWeb技術で実現できないか調べます。調査を始めるとすぐに WebXR Device API というWeb技術にたどり着く筈です。
早速 Can I use… で調べるとiOSは非対応であることが分かります。
(2022年2月時点最新版のiOS15.3でも次期バージョンでもサポートされないことが分かる)
ここで、ようやくネイティブアプリ開発するしかないという判断を下すわけです。
あるいは、更に深堀り調査して AR Quick Look なるApple公式の技術があることまで辿り着ければ、これで要件を満たせそうだ、とネイティブアプリ開発は不要の判断を下せるかも知れません。(単に3DモデルをAR表示したいだけであれば十分)
(Pixarが開発したUSDZという3Dモデルデータの表示にSafariは標準対応している)
このように最新のWeb技術をよくよく調べることが重要です。またそのような情報に詳しい人に聞いてみても良いでしょう。弊社のコンサルティングサービスにお問い合わせ頂いても結構です。
以上、長々と書いてきましたが、少々乱暴にまとめると、Web技術でできることは沢山あるし増えているので、早計にネイティブアプリ開発に舵を切らないようにしましょうということです。
お断りしておくと、弊社はネイティブアプリ開発を否定したいわけではありません。2008年から幾つも業務用ネイティブアプリを開発してきましたし、今でもご支援を継続させて頂いています。iOS向け業務用サービスを自社開発して数百社に提供してきた経験もあります。それら経験から言えるのは、やはりネイティブアプリが最善策だということです。
しかし、以前の投稿に書いた通りネイティブアプリは本当に本当に大変です。(参考 : 社内用独自アプリを開発しようと思ったら最初に考えるべきこと)
開発して終了ではなく、保守運用に大きな罠も潜んでいることを関係者が認識できていない場合もあります。業務用ネイティブアプリの独自開発は、長期に渡る予算を継続的に確保できるか、内部に開発部隊を抱えているか、のどちらかでなければ将来の足かせとなる可能性に留意すべきです。
Webでやってみる選択肢も是非検討して下さい。一般消費者向けアプリと異なり、エンタープライズiOSではMDMやWebクリップの技術を組み合わせれば、ネイティブアプリと遜色ない体験をWeb技術だけで提供が可能です。ネイティブアプリ化の検討はその後でも遅くありません。
