ADEPからADPへの移行(カスタムApp化)を進める企業や、新たに独自アプリを作る企業、またそうした企業を支援する関係者の方に役立てて頂けるかと思います。

自社従業員に使わせるアプリで、かつADPを前提としている点はご留意下さい。1枚ものの簡単なチャートになります。

画像貼り付けだと少し見にくいのでPDFも用意しました。以下にチャートの順に解説しますので、別ウィンドウでPDFを拡大しながら読み進めて頂くと良いと思います。

配信方法選定チャートの解説(1) : そもそも論

チャートは左上からスタートです。まず最初の判断は、

ここですね。まさかの「Webにしましょう」です。本サイトでもいくつか関連エントリを書いています。

• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (前編)
• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (後編)

弊社はiOSアプリと関わり始めて2025年6月時点で17年近く。その間、B2C/B2B/自社アプリ/受託アプリこれら全ての組み合わせを色々経験していますが「安易な自社アプリ開発はお勧めしない」が一貫したスタンスです。今も昔も業務用iOSアプリの真理だと思っています。

(10年以上前のセミナー資料。自社アプリを作るのは最終手段であると解説し続けてきた)

MDM/ABMを併用すれば、自社専用のアプリがなくてもWeb技術だけでiOS端末を十分に活用できます。なので、カスタムApp化を考える場合も新規アプリ開発をする場合も、まず真剣に「本当にWebではダメなのか？」を問うてみることをお勧めします。

2025年現在、業務用アプリの9割はWebで十分であるという感触を持っています。以下もご覧下さい。

• Webクリップとは何か(1) -Webサイトのブックマークを配布する-
• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-
• WebクリップはSafariを削除していても使用できる(ようになった) -Webクリップとは何か(4)-

配信方法選定チャートの解説(2) : PoCや実験

Webが無理なら、次はTestFlightの活用を検討して下さい。

TestFlightの最大のメリットは審査関連の面倒臭さがないことです。ユーザが100人以下ならTestFlightの内部テスト、ユーザが100人より多く10000人以下なら外部テストが使えます。外部テストには審査が必要ですが、あってないようなものですし、バージョンを変えない限り無審査というハックもあります。

TestFlightのデメリットは主に以下2つ。

• 有効期間は90日
• AppleIDが必要

ただ前者は1,2ヶ月ごとに定期的にビルドを作ればほぼ解決です。後者は、ABMを使って全社員にAppleID(Manged AppleID)の供与が容易になっているため、昔に比べてハードルは下がってます。Managed AppleID については以下をご覧下さい。

• AppleIDの新規登録方法 2024年保存版 – ABMからの登録 –

従業員が多い場合は EntraID や GoogleWorkspace との連携も活用できますので、TestFlightのAppleID要件はデメリットにならないケースもあります。

配信方法選定チャートの解説(3) : 本番稼働でも審査回避

TestFlight が適切でない場合、AdHoc 配布を検討することをお勧めします。

繰り返しますが、業務用iOSで一番面倒でかつ運用に制約を与えるのは審査関連です。それを避けるためのWebであり、TestFlight であったわけですが、それらがダメなら次は AdHoc です。

AdHoc についての詳細は以下をご覧ください。

• AdHocとは何か
• AdHocアプリを社外ユーザに配布できるのか
• AdHoc配布はテスト用途以外に使用できるのか

Apple Developer Program に明示的に端末識別子(UDID)を登録して稼働させる方法で、端末種別ごとに上限100台以下に抑えられるなら、ADEP の InHouse に近しい運用が可能です。

先に書いたTestFightの「AppleIDが必要」という条件は満たせないが、100台以下のPoCや実験アプリである場合でも有用です。

配信方法選定チャートの解説(4) : AppStoreからの配信

チャートもここまでくると、AppStoreからの本配信しか選択肢がありません。

AppStoreからの本配信にも種類があり、最初に検討すべき配信方法は「公開アプリ」です。我々が個人利用で App Store で見かけるようなアプリと同じ位置付けとなります。社名や関連名で検索した時にアプリの存在を知られても良い場合に採用できます。

公開アプリをまずお勧めするのは、他の選択肢である非公開アプリ(カスタムApp)と非表示アプリに比べて、実績のある開発会社が多くアプリ開発から配信までスムーズに進む可能性が高いからです。

非表示アプリなら追加の特別な審査が必要だったり、非公開アプリ(カスタムApp)ならABM/MDMの知識や運用体制も必要だったりと少々面倒臭くなります。

配信方法選定チャートの解説(5) : カスタムApp or 非表示アプリ

ここまでくるということは、Web技術では実現できず、まとまった端末数で本稼働させる必要があり、世間に知られたくないアプリです。この場合、どんな端末で動作させるのか？という視点で三択になります。

ひとことでカスタムAppといっても配信の仕方には2種類あり、インストールの仕方も変わります。どのような端末に配信するかに応じてどちらかを選ぶことになります。

• カスタムApp (管理対象ライセンス)
• カスタムApp (引き換えコード)

大半の場合(国内従業員向けの非公開アプリ)は、前者です。一方で以下に該当する場合は後者です。

• 端末を会社支給せず個人端末を業務に使わせるBYODスタイル
• MDMが導入できないケース

後者の引き換えコードを選んだ場合、業務用アプリが個人AppleIDに紐づいてインストールされる(つまり退社後も使われる可能性がある)点には注意して下さい。万が一に備えて認証機構を備えたアプリでなければ採用はできないでしょう。

また、日本企業としてABMの利用申請を行った場合、海外従業員のBYOD端末に対しては、カスタムAppの引き換えコードライセンスは使用できません。必然的に非表示アプリを選択することになります。

(研修資料より。AppStoreは国ごとに分かれており、カスタムAppの配信は国単位で閉じる必要がある)

あるいは、端末管理や運用体制まで調整して「国内法人で調達した端末に管理対象ライセンスでインストールして、海外従業員に当該端末を使わせる」という逃げ道を採用することもできます。

海外従業員への非公開業務用アプリの配布は、カスタムAppやライセンスの種類、ABM/MDMの十分な理解がないと難しいので余りお勧めしません。素直にWebアプリにしましょう(笑) というのは冗談で、非表示アプリか公開アプリにしてログイン機構を設けるのがベストです。

以上、ADP前提で自社従業員が使うアプリをどう配信するかの判定チャートを解説してきました。配信方法を決定する社内ルールを作る時の参考として頂ければと思います。もし「このアプリはどの配信方法が良いんだろう？」と気になる場合、こちらよりお問い合わせ下さい。

なお、本チャートは ADEP InHouse は考慮していません。ADEPは意外にもまだ使えている企業が多く、徐々に移行を強いられている印象ですが、まだ使えるなら使い続けるのが最善です。カスタムApp化を考える時に本ページのチャートを参考にして下さい。

また本チャートでは、従業員が使用するアプリを前提としました。もし「販売代理店に使って貰うアプリ」「ソリューションを販売した顧客企業の従業員が使うアプリ」のように自社従業員利用でない場合は少し異なるので注意して下さい。非従業員のケースはまた別の機会に紹介したいと思います。

Appleの審査を避けたい事情はアプリによって様々です。

そもそも審査の手続きが面倒だ、プライベートなAPIを使いたい、本来用途と異なるハック的なAPIの使い方をしている、AppStore Review Guidline に反した事をやりたい…などなど。B2Bの世界では、そもそも「ウチで使う業務アプリをなぜ審査されなくてはならない？」という感覚の方もいます。

理由はどうあれ業務用iOSアプリの世界では、Appleの審査を避けるなら InHouse(ADEP) 一択だ…と誤認されてきました。しかし実は、Appleが InHouse(ADEP) 以外にも審査回避手段を用意していることは意外に知られていません。InHouse(ADEP) が余りにも強力過ぎて(審査不要・無制限配布)、他の手段に目が向けられることがほとんど無かったからでしょう。

そこで本稿では、InHouse(ADEP) を含め、改めてアプリ審査を回避できる配布手段を整理してみたいと思います。当然ながらすべて公式に提供されているもの。まず以下に一覧を示します。

関連する投稿へのリンクも貼っていますので併せて参照して下さい。それでは順に見ていきましょう。

InHouse – ADEP (Apple Developer Enterprise Program)

審査回避手段として一択と誤認されているぐらいですから、真っ先に思いつくのがこちらでしょう。

詳細については以下をご覧下さい。

• ADEP (Apple Developer Enterprise Program) とは何か

しかしAppleは、2019,2020年頃から新規受付を事実上停止しています。また、2022年からその更新も審査制に変わりました。審査の結果、更新を認められなかった、つまり InHouse が使えなくなった企業も出始めています。詳しくは以下をご覧下さい。

• ADEP(Apple Developer Enterprise Program)はもう取得することができないと諦めたほうが良い理由
• そろそろADEP契約更新ができなくなるかも知れない 〜カスタムAppへの移行を急ぐべき理由〜
• そろそろADEP契約更新ができなくなるかも知れない…その後(1), (2)
• 実録！ADEPの更新を拒否されるまでの全て (1), (2), (3)

今後はどうなるか分かりませんが、長らく業務用iOSアプリの世界を見てきた弊社の見解は「新規受付の復活は考えにくいし、更新も徐々に厳しくなっていくと思われる」です。

ADEPの契約が既にできていて且つ2023年現在まだ更新ができている企業の場合、ADEPを使い続けるのが合理的な選択です。そうでない企業がApple審査を回避したいなら、後述の3つの選択肢から選ぶことになります。

AdHoc

ADP(Apple Developer Program)を契約して、その契約の配下で AdHoc 形式の配布を選択することにより Apple の審査を回避できます。(AdHocはADEPでも使えるが実質使い道がない)

(研修資料より)

AdHocはiOSアプリの歴史的経緯から、テスト用の配布手段と認識されていましたが実はそうではありません。ADP契約毎にデバイスごと100台までという上限に注意が必要ですが、本運用で使用しても実は問題ないのです。詳しくは以下をご覧下さい。

• AdHocとは何か
• AdHoc配布はテスト用途以外に使用できるのか
• AdHocアプリを社外ユーザに配布できるのか

AdHoc 形式では1年に一回の Provisioning Profile 更新が必要となります。しかしAdHocもMDMからの配布が(多くの場合)使えることも考えれば、ADEPでのInHouseアプリ運用と大差ありません。InHouseアプリと全く同様に、Appleのアプリ審査を受けることなく端末にアプリをインストールできますので、開発しようとしている業務用アプリの配信端末数が100台以下なら、積極的に検討できる手段です。

TestFlight 内部テスト

TestFlight とは Apple が公式に提供しているテストツールです。元々はあるスタートアップが開発したものですが、買収に次ぐ買収で最終的に Apple が買い上げて洗練させ、公式テストツールとした経緯があります。

(歴史に興味があれば Wikipedia-TestFlight を参照(英語))

関係者の間で評価する場合に使う内部テストと、いわゆる公開ベータ版テストのように第三者の評価協力を募る場合に使う外部テストと2種類の仕組みが用意されています。App Store Connect からアプリをTestFlight向けに登録し、本審査前とは別のテスト用審査を受けることでテスト配信が可能となります。

(研修資料より。InHouseの経験しかない場合、TestFlightの使い方が一番の難所。研修ではテスト設計も解説している)

テストに参加するユーザはテスターと呼ばれ、テスター専用のTestFlight というアプリを介して AppStore 登録前のテストバージョンを受け取ってインストール・テスト・フィードバック送信が可能です。

(研修資料より)

この TestFlight を審査回避の手段として使うことができます。先に「本審査前に別のテスト用審査を受けると」と書きましたが、内部テスト用審査は事実上無審査だからです。アプリである ipa ファイルの正当性・妥当性のみチェックされます。

 → 
(実際にTestFligth内部テストで配信されたアプリと起動後の画面。起動後にlabelしかなくても審査は通る。本審査ではありえない)

この特性を利用することで、事実上の無審査アプリ配布が可能となります。もし作ろうとしている業務用iOSアプリが、実験的開発や評価検証用のPoCである場合は、TestFlight の内部テストを使うことも選択肢に入るでしょう。

ただしPoC を抜けた本番運用のフェーズでは、TestFlight を使い続けることができないことに注意すべきです(TestFlightはテスト用途専用)。とりあえずアプリを作ってみたい評価用プロジェクト向きの手法といえます。

Webクリップ

意外に盲点で余り知られていない手法です。通常、開発会社側にMDMと構成プロファイルの理解がなければ思いつかないアイディアだからですね。(そして開発会社の多くは残念ながらそれらを使う機会がほとんどありません)

• Webクリップとは何か(1) -Webサイトのブックマークを配布する-
• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-

WebのショートカットであるWebClipをMDMから配布すれば、事実上の審査不要・無制限配布可能なネイティブアプリ(擬似)を実現することができます。

(研修資料より)

特に iOS 16.4 で Web Push 通知に対応した点は注目に値します。ネイティブアプリを開発する理由として頻繁に上がってくる Push 通知が、JavaScript だけで実現できるようになったのです。もし iOS16.4 以降を前提にできるなら、

「Push 通知を使いたいならネイティブアプリ開発が必要」

という常識(?)は今や非常識となり、時代遅れな認識です。開発しようとする業務用iOSアプリが、

• 審査を回避したい事情があり、
• Push通知ぐらいしかネイティブアプリ開発する理由が無く、
• 端末の原則オンラインが担保できるなら、

WebClip + MDM の組み合わせ技は有力な選択肢になります。以下の投稿も合わせてご覧下さい。

• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (前編), (後編)

読者がもしネイティブは無理だがモダンな Web システム開発は可能な開発会社だという場合、WebClip は顧客への提案に使える新たなツールとなります。「Web技術だけでインストールから起動からユーザ体験までほぼアプリっぽいことができますよ」と言えるのです。これを機会に MDM + WebClip のあわせ技を学習することをお勧めします。

以上、Appleの審査を回避する手段を4種類紹介しました。諸事情や諸条件によって採れる選択肢は変わってきますが、すべての選択肢を知っておくことは有用でしょう。本投稿が、読者の関わるアプリ開発プロジェクトの開発方針決定に役立てば幸いです。

業務用アプリを配布する方法は、全て列挙すると実に7種類もあります。どの配布方法を選ぶべきかはアプリの特性や各社の状況によりますので、一通り配布方法を知っておくのは良いことです。

(用途やアプリに応じて様々な配布方法がある)

そこで本稿では全ての配布方法の概要を網羅的に紹介します。また、各方式について詳細を記している本サイトの別投稿へのリンクも紹介しますので、詳しく知りたい場合は各リンク先を参照して下さい。

本稿は、アプリの配布方法に迷った時の道標として使えるページです。是非、本稿をブックマークして頂き、アプリ配布方法に迷ったら参照するようにして下さい。

配布方法全7種

以下に一覧を列挙します。

AppStore公開アプリ

AppStore上に公開されている既存アプリは全てABM+MDM経由で配信することができます。例えば Box や DocuSign など既存アプリを業務でそのまま使う場合が該当します。

(業務用バージョンを別アプリとしてAppStore公開しているものもある。上図はBoxの例)

ABMやMDMという言葉が初見という方は以下を参考にして下さい。

• MDMとは何か 〜今さら聞けないMDMの基礎〜
• ABM(Apple Business Manager)とは何か
• iOSDC 2020 Day1 でエンタープライズiOSについて講演しました（YouTubeで収録動画が公開されました）

ABMでAppStoreのアプリを一括購入(VPPということもある)してMDMに同期して、MDMから配布します。

(ABMでAppStoreにあるGMailアプリを一括ライセンス購入する様子)

多くのMDMで、アップデート時の振る舞いをアプリごとに制御できます。

(アプリ毎に自動更新するかどうかを決めることができる。上図はBizMobile Go!)

自動で更新させることもできれば、明示的な更新を強いることもできます。通常は自動更新としておくのが良いでしょう。

カスタムApp

現時点(2022年3月)で、特定企業用の非公開アプリを無制限に配信できる唯一の方法です。

AppStoreのインフラをそのまま使いますので、ADP(Apple Developer Program)の契約が必要で、アプリ毎にAppleの審査が必要です。

(AppStoreに申請する際に、実は「非公開」を選択できる)

審査が通ればそれで完了…ではありません。ABMから当該カスタムAppを一括購入し、MDM経由か引き換えコードを使った配布をする必要があります。カスタムAppについては以下に記事をまとめていますので御覧下さい。

• カスタムAppのカテゴリ全記事 (全記事11件の一覧)

ABMやMDMと連携させて配布する繋がりや全体の流れは、iOSDC Japan 2020 で講演させて頂いた内容が参考になります。以下からご参照下さい。

• iOSDC 2020 Day1 でエンタープライズiOSについて講演しました（YouTubeで収録動画が公開されました）

非表示App

2022年に新たに登場した配布形式です。

AppStore公開アプリではあるものの、AppStoreアプリでの検索に出てこなくなり、当該アプリのURLを知っている人だけがインストールできるという配布形式です。

例えば「特定組織内で限定的に使うわけではないが第三者に見せる必要のないアプリ」で利用できます。

AppStoreへの通常のアプリ審査の他、非表示化を申請して受理される必要があります。申請時に合理的な理由(なぜカスタムAppではないのか)を説明することが求められます。詳しくは以下をご覧下さい。

• 非表示App(Unlisted App)とは何か

InHouseアプリ

ADEP(Apple Developer Enterprise Program)の契約を締結できている組織だけが利用できます。現在その契約を持っていない組織ではこの配布方法は事実上採用不可です。

AppStoreインフラを使いませんので審査は不要です。配布台数制限もなく、MDMとABMの連携も不要で、最もシンプルで理解しやすい配布方法です。詳しくは以下の投稿をご覧下さい。

• ADEPとは
• ADEPはもう取得することができないと諦めたほうが良い理由

なお、ADEPを契約済である企業であっても、2022年春以降からADEP契約の更新で審査を受ける点は注意して下さい。ADEP の更新を Apple に拒絶され更新ができなかったとの報告も幾例かあります。更新を拒否された場合、急いでカスタムAppを使った配布体制に切り替える必要があります。以下を御覧ください。

• ADEP契約を更新せず放置するとInHouseアプリはどうなるのか
• そろそろADEP契約更新ができなくなるかも知れない 〜カスタムAppへの移行を急ぐべき理由〜
• そろそろADEP契約更新ができなくなるかも知れない…その後(1)
• そろそろADEP契約更新ができなくなるかも知れない…その後(2)

ADEPを継続できている企業は、規約違反で契約取り消しとならないよう注意しましょう。以下で規約違反になるパターンをおさえておくことをお勧めします。

• ADEPの契約ができないパターン集

Webクリップ

WebサイトやWebシステムをアプリのように配布する形式です。MDMを使ってWebのショートカットを配布するようなイメージです。

(アプリのように見えるが実はWebサイトのショートカットという例)

ハードウェアの機能を使わない、オンライン前提にできる、通知はメールやチャットで十分、といった条件を満たせる環境なら、わざわざネイティブアプリを開発しなくても擬似的にアプリ配布が可能です。

面倒なAppleへのアプリ申請やABMの操作等が不要になります。MDMさえ用意できればアプリ配布ができますので、ネイティブアプリ開発に課題がある場合、積極的に活用を検討すべき配布方法です。アプリ開発の知見が余りないWebシステム会社にとっては、アプリ開発提案の「亜種」として採用できる可能性があります。詳細は以下にまとめていますのでご覧下さい。

• Webクリップのカテゴリ全記事 (全7記事)

TestFlight

アプリの申請前や、申請後の本配信前に、関係者限定のテスト用途で使用する配布方法です。

前述したAppStore公開アプリやカスタムAppを使って業務用アプリを配布する場合に、アプリの初回配布前のフェーズや、アプリのアップデート版の本配信前テストに使用します。

ADPの Apple Developer サイトでテストしたいバージョンを指定し、テスターをグループ単位や個人単位で紐付けます。

(これまでInHouseでの配布経験しかない企業は TestFlight をよく理解することが求められる)

テスターは情シス担当者、社内評価担当者等が対象となります。テスターのiOS端末には TestFlight なるApple公式専用アプリを予めインストールしておく必要があります。

TestFlightアプリでインストールされたテスト用アプリには、有効期限が90日、旧バージョンにいつでも戻せる、などの特徴があります。なお、TsetFligth は原則、本番運用アプリで使ってはいけません。

AdHocアプリ

上限100台という台数制限があるものの、審査不要のアプリ配信が可能な方法です。動作対象端末のUDID(端末識別子)をあらかじめ収集しておく必要があります。

UDIDを紐付けたAdHoc用の Provisioning Profile を使ってアプリを署名して生成した .ipa ファイルは、UDIDが一致する端末でのみインストール・起動できるようになるという仕組みです。

(UDIDを登録した権限ファイルを生成する様子。生成したファイルをビルド時にアプリに紐付ける)

インストールには有線・無線の両方が使えます。それぞれ以下を参照して下さい。(前者のタイトルはInHouseアプリだが、AdHocアプリでも使用できる)

• Apple Configurator2 で InHouse アプリをインストール・アンインストールする方法と「信頼」について
• OTA(Over The Air)とは何か

また、AdHocアプリ全般や用途・配布先制限については以下を参照して下さい。

• AdHocとは何か
• AdHoc配布はテスト用途以外に使用できるのか
• AdHocアプリを社外ユーザに配布できるのか

以上、業務用アプリの配布方法7種を解説しました。詳細についてはそれぞれ対応する投稿がありますので併せてご覧下さい。

実はこのラベルが長すぎると、いざWebクリップを配布した時に以下のような残念な表示になります。

(ラベルが長すぎて末尾が…の表示になってしまう)

こうならないようにするには、全角6文字、半角12文字程度にするのが良いのですが、Appleの公式ドキュメントには厳密な定義がありません。となると、全角半角が混ざる場合など、ラベルが収まるか収まらないかを確認するため、いちいち構成プロファイルを更新して流し込んで表示する作業を繰り返すことになります。

これは意外に面倒です。そこで本稿では、その面倒さを回避するテクニックを紹介します。この手法を使えば効率よく簡単にWebクリップのラベルを決めることができます。

Safariのブックマーク機能を使う

実は、Safariのブックマークをホーム画面に置く時に使われるラベルの仕様と、Webクリップのラベルの仕様は同じです。このiOS仕様に着目し、Safariのブックマークのラベルでトライ&エラーを繰り返して、Webクリップのラベルとするというわけです。

以下に具体的な手順を紹介します。

(1) まずSafariで任意のページを開き、ツールバー真ん中のボタンから [ホーム画面に追加] をタップします。ラベルの長さを見極めるのが目的ですので、開くページは何でも大丈夫です。
 → 

(2) ホーム画面に配置されることになるアイコンとURLが示されます。ここでラベルを入力できます。

(デフォルトはページ中の title タグや meta タグの文字列)

(3) Webクリップのラベルとして長さが適切かどうか調べたい文字列を入力して、画面右上の [追加] ボタンをタップします。

(4) ホーム画面にアイコンが表示されます。末尾が … になっていないかどうか確認します。

(右側が追加したもの。ギリギリ末尾 … にならない文字列を見い出せた)

(5) もし末尾が … になっていたり、ラベルに指定した文言が気に入らなければ、(1) に戻って同じことを繰り返します。

(6) 納得できるラベルを見いだせたら、その文字列をそのまま構成プロファイルのWebクリップのラベルに指定します。

以上で所望のラベル表示となる構成プロファイルが完成しました。保存した構成プロファイルを MDM や Apple Configurator2 から配布すればokです。

いかがでしょうか。本稿で紹介した手法を使えば、Webクリップのラベルを効率的に試行錯誤できます。Webクリップの作成時に是非使ってみて下さい。

もちろん制約はあります。紹介した手法は、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技術だけで実現できます。

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技術だけで提供が可能です。ネイティブアプリ化の検討はその後でも遅くありません。

(昨今はXcodeやSwiftを使いこなせるエンジニアや外注先の確保が大変)

本稿は、そんな選択肢に待ったをかける投稿です。

本稿を読めば、業務用iOSアプリ提供の選択肢がネイティブアプリ開発だけではないことが理解できるでしょう。2008年からアプリ開発を生業にしてきた弊社が書くのもおかしな話ですが、ある程度のユーザ体験(UX)を妥協できるなら、実はネイティブアプリ開発は不要にできるのです。

一体どういうことか。2回に分けて解説していきます。

Webをネイティブのように動かす

はじめにお断りしておくと、本稿で紹介するのは「Web技術でネイティブアプリを開発する」方法ではありません。

世の中には React Native や ionic や Monaca のように Javascript を使ってネイティブアプリを開発できる技術もありますが、それらの紹介は本旨ではありませんので取り上げません。Flutter や Xamarin のようなマルチプラットフォーム対応のネイティブアプリ開発フレームワークにも言及しません。

本稿で紹介するのは、あくまで既存Webシステムをネイティブアプリのように提供するテクニックです。

まずは実例を見ていただいたほうが早いので、以下動画をご覧下さい。ある企業で配布されたある業務用iPad…という想定です。HOME画面に業務で使う「アプリ」が最初からありますね。これをタップして起動してみます。

これは、Apple Business Manager (ABM) のiPadOS用ネイティブアプリ…のようなものを操作している様子です。ABMはiOSの業務活用で主に管理部門が触るWebシステムです。(ABMについてはこちら)

何となくネイティブアプリっぽく見えませんか？ABMを普段お使いの方なら「あれ？ABMってAppStore にアプリあったっけ？」と思われた方もいるかも知れません。

もちろん ABM に AppStore で公開されたネイティブアプリはありません。大事なポイントは、ネイティブアプリが存在しない既存Webシステムをネイティブアプリのように振る舞わせることができている点です。

ちなみに、Safariのブックマークをアイコン化してホーム画面に配置する方法があることをご存じの方もいるでしょう。こんなやつですね。

(Safariでは表示中のサイトブックマークをホーム画面に保存できる機能がある)

この方法でもホーム画面にアイコンを置くことができます。が、タップすると以下のような表示のされ方になります。

明らかにブラウザで開いていることが分かりますね。アドレスバーを含めてブラウザ付随の色んな機能も使えてしまいます。これらを非表示にするような html の書き方もありますが、いずれにしてもブックマーク登録作業を全従業員にやって貰うことは現実的ではありませんね。業務用のアプリは配布端末に最初からインストールされているべきです。

Webをネイティブのように動かす種明かし

既存のWebをネイティブアプリのように提供するには、2つの技術を組み合わせます。

1つ目は以下の画像の通りWebクリップです。

構成プロファイルで指定するWebクリップを「Webサイトがネイティブアプリに見える」ような設定で作成しているのですね。もちろんURLの欄はWebシステムのURLです。詳細は以下をご覧下さい。

• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-

2つ目の技術はMDM。ネイティブっぽく見える設定にしたWebクリップを含む構成プロファイルを、MDMから端末に配信します。そうすると配布端末は勝手に以下のようになってくれます。

(MDMなら予めWebクリップをアイコンとして表示できる。見た目上はネイティブアプリと違いは無い)

再掲しますが、これをタップすると以下のように動作するわけです。

さて、これはネイティブアプリでしょうか。それともWebでしょうか。余り詳しくない方が見れば、これを言い当てるのは難しいでしょう。

十分にスマホ/タブレット最適化されたWebを適切にWebクリップとして設定し、適切にMDMから配信した時、そのWebはネイティブアプリと区別できないのです。

このように、使っている様子を切り取ってもほぼほぼネイティブアプリですね。

(Webクリップ起動状態からタスクスイッチする様子。個別のネイティブアプリのように見える)

HOME画面上にアイコンとして表示されて、起動してもアドレスバーやツールバーがなく、画面遷移してもその状態が維持できて、インストールに特別な手間が不要で、普通に業務がこなせるなら、それはもう立派なiOS端末向けの業務アプリです。

WebクリップとMDMの知識は必要になりますが、Swift言語でプログラムを1行も書かずともXcodeを1秒も触らなくてもアプリ(と遜色ないもの)を提供できるというわけです。何だか「業務用アプリ」の可能性が広がると思いませんか？

以上、本稿ではWebクリップとMDMを使って、既存Webシステムをネイティブアプリのように提供できることを紹介しました。もちろん全てのWebシステムに適用できる考え方ではありませんし制限事項もあります。次回は、この手法を採用できる条件や制約について説明します。

(Webクリップを使えば、ブックマークをネイティブアプリのように配布できる。詳しくはこちらを参照)

Webである以上、表示には当然ブラウザが使われるので Safari が必要になる筈ですね。では、Safariの利用を禁止した端末でWebクリップを開くとどうなると思いますか？

(Safariを禁止する構成プロファイルを作成する様子。これを流し込んだ端末でWebクリップはどうなる？)

予想に反して実は、SafariがなくてもWebクリップは正しく動作します。

以下はWebクリップのみを残した状態の iPod touch ですがこれでもWebクリップは動作します。ブラウザアプリである Safari が使えない状態なのに…という点が重要です。他のブラウザアプリも一切不要で、Webクリップのみで指定のURLがブラウザ表示できます。

(監視モード化したiPod touchでは設定アプリを除いて全ての標準アプリを消すことができる)

昔のWebクリップはSafari必須だった

iOS4や5など初期の頃、Webクリップの動作にはSafariが必須でした。当時は、

「Webクリップを使いたいけど Safari が必須なのか。そうすると Safari で任意ページを見れてしまうからダメだ」

という声が現場から聞かれたものです。それもあって Safari を禁止したい企業ではWebクリップが活用されず、その代わりにブックマークやホワイトリスト機能を搭載したセキュアブラウザを導入したりしていました。

ですが、今は Safari 禁止環境でもWebクリップ単体で動作します。

実は関係者の間でも(MDMベンダーでも)この情報がアップデートされておらず『WebクリップにはSafari必須』と誤った理解のままでいることもありますので注意しましょう。Safari必須という過去仕様が理由でサードベンダーのセキュアブラウザを導入している場合は再検討をお勧めします。

是非、最新のiOSでSafari禁止にした端末上でWebクリップを試してみて下さい。

WebクリップのUserAgentはどうなるのか

ところで、Safariを禁止してWebクリップからWebサイトを開いた場合と、Safariから直接開いた場合とで何か違いはあるでしょうか？

 
(1つ目はフルスクリーンをONにしたWebClipからの表示、2つ目はSafariでURL直打ち表示)

上図のように表示に違いはありますが、サーバサイドで得られる情報に差はありません。UserAgentが一緒になります。WebClipでアクセスした時も、Safariでアクセスしたかのように

Mozilla/5.0 (iPod touch; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Mobile/15E148 Safari/604.1

というSafariのUserAgentと全く同じなのです。つまりサーバ側では、Webクリップ起動で表示されたのか SafariからURL指定で表示されたのかを識別することはできないということですね。

javascriptの documentElement.clientHeight で区別できなくもないですが、そもそも端末ごとに異なるため WebClip か Safari 直接かをこれだけで厳密に識別することは困難でしょう。

ということで、本稿ではWebクリップがSafari禁止環境でも機能することを紹介しました。

なお蛇足ですが、この仕様に変わったのがiOSのどのバージョンからか弊社では把握できていません。iOS12以降ではWebクリップ単体で動作することを確認しています。AppleがエンタープライズiOS現場の声に対応するのはとても早いので、意外にもっと早いiOSバージョンでも可能になっていたかも知れません。

前回の投稿に引き続き、Webクリップの設定項目を徹底解説します。後編の今回は、後半４つについての解説です。

• 1. ラベル
• 2. URL
• 3. 削除を許可
• 4. アイコン
• 5. 作成済みアイコン
• 6. フルスクリーン
• 7. マニフェストの範囲を無視
• 8. 対象のApp

前編をまだ見ていないかたは先に前編を見てから戻ってきて下さい。それでは順番に見ていきましょう。

5. 作成済みアイコン

このチェックは常にONにします。

OFFの場合、iOS6以前のスキューモフィズム(参考)なテイストになるようハイライトがかかる筈はずなのですが、直近のiOS14,15共に下図のように差がないことが確認されています。(理由は不明)

(shine と呼ばれる効果が自動でかかる筈。分かり易いよう黒色グラデーションのアイコンにしているが変化はない)

フラットデザインが当たり前の昨今では不要な設定項目です。このチェックは常時ONで良いでしょう。

6. フルスクリーン

文字通りの設定項目です。

このチェックをONにするとWebクリップをタップした時に全画面で表示されるようになります。下図では、左がチェックOFF、右がONです。見比べてみて下さい。

  
(左がフルスクリーンOFF、右がフルスクリーンON)

チェックがONになっている右側は、アドレスバーや画面下のツールバーも表示されずスッキリしています。

ネイティブアプリを起動しているかのように見えなくもありませんね。表示させたいURLがWebアプリのようなものである場合や、コンテンツ以外のUIを触らせたくない場合は、このチェックはONにしましょう。

ツールバーを消してしまったら「進む」「戻る」操作ができないではないか…という心配は無用です。画面左端から右方向へ、右端から左方向へスワイプすることで「進む」「戻る」ことができます。

7. マニフェストの範囲を無視

分かりにくい設定名ですが、前述の6. フルスクリーンとセットでONにすることが多い項目です。

Webクリップのデフォルト挙動では、WebクリップのURLに指定した以外のページに遷移するとツールバーやタイトルバーが表示されてしまいます。(同一サイト内でも)

少しでもページ遷移すると余計なUIが表示されるなんて興醒めですよね。この挙動を抑制するのが「マニフェスの範囲を無視」のチェックです。

下図は、Webクリップを開いたあとサイト内の別ページに遷移した直後の状態を、チェックON/OFFで見比べたものです。左がOFF、右がONです。

右側チェックONの場合は、リンクを遷移してもフルスクリーン状態が保持されていることが分かるでしょう。

リンク遷移先がどこであっても(外部サイトでも)フルスクリーン状態は保持されますので、ネイティブアプリっぽくWebクリップを使いたい場合に理想的な挙動になっています。前述の6. フルスクリーンのチェックをONにした時は、一緒にONにしておくのがお勧めです。

8. 対象のApp

この設定もWebクリップのデフォルト挙動を変更するものです。

WebクリップはタップするとSafariでURLを開いたような挙動になります。が、この設定項目を使うとSafari以外の別アプリでWebクリップを開くことができます。以下の動画を見てみて下さい。

(右側のアイコンがWebクリップ。タップするとSafariではなくChromeで開く)

Google Chrome でWebクリップが開いていますね。対応しているアプリでなければなりませんが、任意のアプリが指定可能です。

ただ残念ながら Apple Configurator の構成プロファイルエディタからは本項目を設定できません。なぜなら、この項目がMDMから配信された構成プロファイルでのみ有効だからです。ではMDMサービス側の構成プロファイルエディタを使えば良いのかというと、MDMサービスによってはこの設定値に対応していない場合があります。ではどうするのか…？

手書きします(笑)

以前の投稿で紹介した通り、構成プロファイルはしょせんXMLファイルです。テキストエディタ等で編集可能ですので、Apple Configurator で作成したあと以下のようなXML(plist)をWebクリップの定義部分に追加して保存し、その構成プロファイルをMDMにアップロードします。

<key>TargetApplicationBundleIdentifier</key>
<string>com.google.chrome.ios</string>

具体的には以下のような感じですね。

Webクリップの1つ1つは <dict> 〜 </dict> 内に定義されていますので、その中に挿入します。Webクリップごとに指定できますので、Webクリップによって起動するアプリを変えることも可能です。

設定値にある com.google.chrome.ios はiOS版Chromeアプリを意味しています。各アプリのIDはMDMの画面で確認できます。当然、指定したアプリは端末にインストールされている必要がありますので、MDMからアプリも配信するようにしましょう。

もちろん、本設定項目の指定に対応しているMDMであれば手書きの必要はありません。比較的新しい設定項目ですので、指定可能かどうかMDMベンダーに確認すると良いでしょう。

(弊社がよく利用するBizMobile Go!は、2023年7月より対応)

以上、2回に渡って Web クリップの作成方法と全8項目の設定値を徹底解説しました。

Webクリップは、HOME画面に設置できるWebブックマークに過ぎない、と言ってしまえば確かにそうです。ですが、意外に色んな制御が可能であることを感じて頂けたのではないでしょうか。

特に、Webアプリをネイティブアプリのように振る舞わせられることは、ネイティブアプリ開発の代替にできるという意味でSIer企業には朗報と言えるかも知れません。もちろん制約はありますが、活用を検討する価値はあるでしょう。

本稿ではWebクリップの作成方法と、Webクリップの設定値について紹介します。本稿を読めばWebクリップの設定項目が何を意味するか全て理解でき、Webクリップを最大限に活用できるようになります。 (長くなったので2部構成にしました。後編はこちら)

Webクリップの作り方

Webクリップは構成プロファイルに含めることのできる情報の一つですので、Webクリップを作るとはつまり構成プロファイルを作ることと同義です。

(Webクリップは構成プロファイルに含められる一要素に過ぎない)

基本的に Apple Configurator2 の専用エディタで作成することをおすすめします。MDMサービスでもWebクリップは作成できますが、新しい設定項目に対応していない場合もありWebクリップの機能を最大限に活用できないからです。

(URLとアイコン以外ほとんど何も設定できない hexnode mdm の画面。WebClipを重視していないのが分かる)

では、早速 Apple Configurator2 を使って構成プロファイルを作っていきましょう。

まずメニューから新規作成を選びます。下図のように構成プロファイルエディタが表示されますので、最初に「一般」の各項目を入力しましょう。

(Webクリップのみを含む構成プロファルとして作成する。名称で明示しておくと管理し易くなる)

一般の項目が設定できたら、画面左側のカテゴリ一覧から「Webクリップ」を選びます。

次に「構成」ボタンをクリックすると、下図のようなWebクリップの詳細入力画面が現れます。

(赤色マークは必須項目)

ここにWebクリップの設定値を入力していきます。1つの構成プロファイルに複数のWebクリップを含めることもできますので、必要な数だけ右上の+ボタンをクリックして追加して下さい。

それでは以下、Webクリップの各設定を順に見ていきましょう。2021年時点で8項目あります。Apple Configurator2のUIでは7項目しかありませんが、1つ足りない理由は後述します。(長くなったので後半4つは後編で解説しています)

• 1. ラベル
• 2. URL
• 3. 削除を許可
• 4. アイコン
• 5. 作成済みアイコン
• 6. フルスクリーン
• 7. マニフェストの範囲を無視
• 8. 対象のApp

1. ラベル

Webクリップがインストールされた時にHOME画面に表示される名称です。

ネイティブアプリでいうところのアプリ名に相当しますので、ラベルの文字列長には注意が必要です。ラベル長を変えて複数のWebクリップを作成してみた下図を見て下さい。

(左から順番にラベル長が全角6,7,8文字。一番右は半角カタカナで16文字)

上図から分かる通り、ラベル長は全角6,7文字を目安にするのが良いでしょう(1つ目2つ目のアイコン)。長過ぎると3つ目のアイコンのように末尾が…となってしまいます。

末尾…の回避策として半角カタカナも使えますが、いっきに昭和感が漂ってダサくなりますのでやめましょう。HOME画面に半角カタカナを表示するなど、iOSへの冒涜です。

2. URL

Webクリップをタップした時に表示するURLを入力します。

AppleのドキュメントではURLには http:// か https:// を指定するよう明記されています。

が、Appleの別のドキュメントには tel:// や mail: など一般表記と異なる表記(URL scheme と言います)も入力できるとあります。

(tel://06〜 というURLを指定したWebクリップをタップした直後の画面。続けて発信タップで指定番号に電話がかかる)

Appleの公式ドキュメントの記述に若干ブレがあるのが気にはなりますが、便利は便利ですので活用すると良いでしょう。

また、example:// のように他アプリを呼び出す URL Scheme も指定できます。が、iOS9から推奨されている Universal Links を使うほうがユーザ体験としては優れています。どんな URL Scheme が使えるか、Universal Links に対応しているかどうか、等はアプリ開発元に確認してみて下さい。

3. 削除を許可

このチェックをONにすると、Webクリップは削除できなくなります。

以下はHOME画面を編集しようとしている様子です。チェックON/OFFの違いが分かるでしょうか。

(HOME画面を編集しようとしても、削除許可チェックがOFFだと – マークが現れない)

Webクリップを削除されたくない場合は、このチェックをOFFにすると良いです。ただ、構成プロファイルそのものを削除されると根こそぎ消えますので注意が必要です。それも制限したい場合は、「一般」の設定で以下のように構成プロファイルの削除制限をかけて下さい。

(管理者以外は構成プロファイルを削除できなくなる。つまり従業員はWebクリップを消せなくなる)

4. アイコン

HOME画面に表示するアイコン画像ファイルを指定します。

画面上のアイコン枠にFinderから画像ファイルをドラッグ&ドロップしてもokです。

Webクリップでは、ネイティブアプリと違って大きな解像度のアイコン画像を必要としません。以下の解像度以上の画像を用意すれば十分です。

ただ、大きければ良いというわけではなく、Appleは 400 x 400 以下で1MB未満 にすることを推奨しています。対応画像フォーマットは PNG, JPEG, GIF の3種類。アニメーションGIFにしてもアニメーションはしません。また、PNG形式の透明ピクセル指定は評価されず自動で白色ピクセルに置き換わります。

なお、アイコン画像が指定されていない場合は下図のようなアイコンになります。

ここまでWebクリップの作り方と、その設定項目8つのうち4つを紹介してきました。だいぶ長くなってきましたので残り4つは後編で解説します。

(Safariで表示中のページをブックマークしようとしている様子)

ページのhtml内に適切な画像ファイル指定がされていると、その画像をアイコンにしてホーム画面上にアプリのように表示されます。

(ブックマークがアプリのように表示される。html側の公式仕様は Configuring Web Applications を参照)

もし社内ポータルやブラウザで動作する業務システムがあるなら、こういったブックマークを配布端末のホーム画面上に置けたら便利ですよね。従業員にはアプリのようにワンタップでアクセスして貰えるわけですから。

とはいえ、まさか何百何千台という数の端末で、ブックマーク登録作業を行うわけにはいきません。Appleもそこはきちんと考えていて、ブックマークの社内展開を容易にするための Webクリップ なる仕組みを用意してくれています。

本稿ではそのWebクリップの概要を紹介します。

Webクリップとは

Webクリップは、iOS4の時代から提供されているエンタープライズ向けのブックマーク配布機能です。冒頭で紹介した、Safariのブックマーク機能とは少し違っていて、業務利用で都合の良い仕組みになってます。

Webクリップを組織内で使うのに最低限必要なのは、URLとホーム画面で表示したい情報(ラベル)のみ。その2つの情報を含む構成プロファイルを作ってiOS端末に流し込むだけです。(参考 : 構成プロファイルとは)

(Apple Configurator2 を使ってWebクリップを作成している様子)

iOS端末に対しては、以下のような方法で流し込む(インストールする)ことになります。

• MDMから配信
• Apple Configurator2 でUSB転送
• メール添付で送る
• 社内WebサイトにアップロードしてそのリンクURLを配布する

管理し易さの観点で、MDM か Apple Configurator2 経由(監視モード端末) のいずれかが賢明です。なお後述するWebクリップのオプション機能を活用したいならMDM一択となります。

配布方法はどうあれ、Safari標準機能がWebサイト側に仕様に準じた記述が必要である(つまりWebサイト側に特別なhtml記述が必要である)のに対して、WebクリップはWebサイト側に一切手を加える必要がありません。

既にあるURLをどう表示したいか振る舞わせたいか、を勝手に定義するだけです。しかもネイティブアプリと同様に一方的に強制配信でき、管理側には都合の良い仕組みになっています。

Webクリップで指定できること

Webクリップは言うなれば、Webサイトをどのように表示させたいか、またどのように振る舞わさせたいか、を定義したメタ情報です。

前述の通りアイコンとラベル(ホーム画面上での名称)が必要ですが、それ以外の便利な設定項目が幾つか用意されています。

ラベルとURL以外は、必要に応じて構成プロファイルに定義していきます。上の表を見るとそれなりに細かいところまで制御できる気がしますね。特に管理部門の方にとっては、「削除を許可」は嬉しいオプションではないでしょうか。

Webクリップにもたせることのできる情報については、Apple がドキュメントを公開していますので、Device Management Profile > WebClip のページを確認すると良いでしょう。

以上、簡単ですがWebクリップについて解説しました。簡単にまとめると、

• Webサイトをブックマークとして端末のホーム画面上に配備できる機能
• 構成プロファイルとして定義して、MDMやAppleConfigurator2から端末に配布する
• Webクリップには見た目や振る舞いを制御する設定情報を付加させられる

ということでした。特定のWebサイトを業務用途で使用している場合には、Webクリップの活用を検討すると良いでしょう。

関連情報

Webクリップの作り方を以下で詳細に解説していますので併せてご覧下さい。

• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-

Webクリップを活用した業務アプリ配信については以下も参考にして下さい。

• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (前編)
• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (後編)