Share via

Xamarin.iOS の Web ビュー

  • [アーティクル]

iOS が登場して以降、Apple は、アプリ開発者がアプリに Web ビュー機能を組み込むための多数の方法をリリースしました。 ほとんどのユーザーは、iOS デバイス上で組み込みの Safari Web ブラウザーを使用するため、他のアプリの Web ビュー機能がこのエクスペリエンスと一致することを期待しています。 同じジェスチャが機能し、パフォーマンスが同程度で、機能が同じである必要があります。

iOS 11は、WKWebView と SFSafariViewController の両方に新しい変更が加えられました. これらの詳細については、iOS 11 の「Web 変更ガイド」ガイドを参照してください。

WKWebView

WKWebView は iOS 8 で導入され、アプリ開発者はモバイル Safari と同様の Web 閲覧インターフェイスを実装できるようになりました。 これは、部分的には、WKWebView がモバイル Safari で使用されるのと同じ Nitro Javascript エンジンを使用するという事実によるものです。 WKWebView は、パフォーマンスの向上、ユーザーフレンドリなジェスチャの組み込み、Web ページとアプリ間の操作の容易さの点から、可能な限り常に UIWebView 経由で使用する必要があります。

WKWebView は UIWebView とほぼ同じ方法でアプリに追加できますが、開発者は UI/UX と機能をより詳細に制御できます。 Web ビュー オブジェクトを作成して表示すると、要求されたページが表示されますが、ビューの表示方法、ユーザーの移動方法、およびユーザーがビューを終了する方法を制御できます。

次のコードを使用して、Xamarin.iOS アプリで WKWebView を起動できます。

WKWebView webView = new WKWebView(View.Frame, new WKWebViewConfiguration());
View.AddSubview(webView);

var url = new NSUrl("https://learn.microsoft.com");
var request = new NSUrlRequest(url);
webView.LoadRequest(request);

WKWebView は WebKit 名前空間に含まれているため、これをクラスの先頭にディレクティブを使用して追加する必要があることに注意してください。

WKWebView は Xamarin.Mac アプリでも使用できます。また、クロスプラットフォーム Mac/iOS アプリを作成する場合はこれを使用する必要があります。

「JavaScript アラートの処理」レシピでは、Javascript での WKWebView の使用に関する情報も提供します。

SFSafariViewController

SFSafariViewController は、アプリから Web コンテンツを提供する最新の方法であり、iOS 9 以降で利用できます。 UIWebView や WKWebViewとは異なり、SFSafariViewController はビュー コントローラーであるため、他のビューでは使用できません。 ビュー コントローラーを提示するのと同じ方法で、SFSafariViewController を新しいビュー コントローラーとして提示する必要があります。

SFSafariViewController は基本的に、アプリに埋め込むことができる "ミニ サファリ" です。 WKWebView と同様に、同じ Nitro Javascript エンジンを使用しますが、オートフィル、リーダー、モバイル Safari と Cookie やデータを共有する機能など、さまざまな Safari 機能も提供します。 ユーザーと SFSafariViewController の間の対話は、アプリからアクセスできません。 アプリは、既定の Safari 機能にアクセスできません。

また、既定では、[完了] ボタンが実装されているため、ユーザーはアプリに簡単に戻ることができます。また、前後のナビゲーション ボタンも実装されているため、ユーザーは複数 Web ページの間を移動できます。 さらに、ユーザーに対しアドレス バーも提供されるため、想定される Web ページ上にあることを確認して安心できます。 このアドレス バーでは、ユーザーが URL を変更することはできません。

これらの実装は変更できないため、カスタマイズなしで Web ページを表示する場合は、SFSafariViewController を既定のブラウザーとして使用することをお勧めします。

次のコードを使用して、Xamarin.iOS アプリで SFSafariViewController を起動できます。

var sfViewController = new SFSafariViewController(url);

PresentViewController(sfViewController, true, null);

これにより、次の Web ビューが生成されます。

SFSafariViewController を使用する Web ビューの例

Safari

次のコードを使用して、アプリ内からモバイル Safari アプリを開くこともできます。

var url = new NSUrl("https://learn.microsoft.com");

UIApplication.SharedApplication.OpenUrl(url);

これにより、次の Web ビューが生成されます。

Safari で表示された Web ページ

ユーザーをアプリから Safari に移動することは、通常は避けるべきです。 ほとんどのユーザーは、アプリケーションの外部へのナビゲーションを予期していないため、ナビゲーションでアプリから離れた場合、ユーザーはアプリに戻らない可能性があり、実質的にエンゲージメントを妨げます。

iOS 9 の機能強化により、ユーザーは Safari ページの左上隅にある [戻る] ボタンを使用してアプリに簡単に戻れるようにします。

アプリケーション トランスポート セキュリティ

App Transport Security (または ATS) は、すべてのインターネット通信がセキュリティで保護された接続のベスト プラクティスに準拠していることを確認するために、Apple によって iOS 9 で導入されました。

アプリで ATS を実装する方法など、ATS の詳細については、「アプリのトランスポート セキュリティ」ガイドを参照してください。

UIWebView の廃止

UIWebView は、Apple の従来の方法でアプリに Web コンテンツを提供します。 iOS 2.0 でリリースされ、8.0 の時点で非推奨となりました。

重要

UIWebView は非推奨とされます。 このコントロールを使用する新しいアプリは、2020 年 4 月の時点で App Store に受け入れられなくなりました。また、このコントロールを使用したアプリの更新プログラムは 2020 年 12 月までに受け入れられなくなります。

Apple の UIWebView ドキュメントでは、アプリでは代わりに WKWebView を使用すべきと提案しています。

Xamarin.Forms の使用時に UIWebView の非推奨の警告 (ITMS-90809) についてリソースを探している場合は、Xamarin.Forms WebView のドキュメントを参照してください。

過去 6 か月間に iOS アプリケーションを提出した開発者は、UIWebView 非推奨に関する警告を App Store から受け取った可能性があります。

API の廃止は一般的なことです。 Xamarin.iOS では、カスタム属性を使用して、これらの API について開発者に通知します (使用可能な場合は代替を提案)。 今回が異なっていてはるかに一般的でない点は、この廃止が提出時に Apple の App Store によって強制適用されることです。

残念ながら、Xamarin.iOS.dll から UIWebView 型を削除することは、バイナリの破壊的変更です。 既存のサード パーティ製ライブラリは、この変更により壊れます。これには、サポートされていない場合や、あるいは、既に再コンパイル不可能な場合もあるライブラリ (クローズド ソースなど) も含まれています。 これは、単に、開発者には余分な問題を発生させるものです。 したがって、この型は "まだ" 削除されていません。

Xamarin.iOS 13.16 以降では、UIWebView からの移行に役立つ新しい検出とツール使用できます。

検出

iOS アプリケーションを Apple App Store に最近提出していない場合は、この状況が自分アプリケーションに該当するかどうか疑問に思うかもしれません。

調べるには、プロジェクトの [追加の mtouch 引数]に --warn-on-type-ref=UIKit.UIWebViewを追加します。これにより、アプリケーション内の 非推奨 UIWebView への参照 (およびそのすべての依存関係) がすべて警告されます。 マネージド リンカーが実行される前と後における型の種類を報告するために、さまざまな警告が使用されます。

これらの警告は、他のものと同様に、-warnaserror: を使用してエラーに変えることができます。 これは、検証後に UIWebView への新しい依存関係が追加されないようにしたい場合に便利です。 次に例を示します。

  • -warnaserror:1502 は、事前にリンクされたアセンブリで参照が見つかった場合にエラーを報告します。
  • -warnaserror:1503 は、リンク後のアセンブリで参照が見つかった場合にエラーを報告します。

リンク前/後での結果が役に立たない場合は、警告を無音にすることもできます。 次に例を示します。

  • -nowarn:1502 は、事前にリンクされたアセンブリで参照が見つかった場合、警告を報告しません。
  • -nowarn:1503 は、リンク後のアセンブリで参照が見つかった場合、警告を報告しません。

削除

すべてのアプリケーションは一意です。 アプリケーションから UIWebView を削除するには、使用する方法と場所に応じて異なる手順が必要な場合があります。 最も一般的なシナリオは次のとおりです。

  • アプリケーション内で UIWebView は使用されていません。 すべて順調。 AppStore に送信する際には、警告は表示されないはずです。 他に何もする必要はありません。
  • アプリケーションによる UIWebView の直接使用。 まず、UIWebView の使用を削除します。たとえば、新しい WKWebView (iOS 8) または SFSafariViewController (iOS 9) の種類に置き換えます。 これが完了すると、マネージド リンカーには UIWebView への参照が示されず、最終的なアプリ バイナリにはその痕跡はありません。
  • 間接使用。 UIWebView は、アプリケーションで使用されている一部のサード パーティ製ライブラリ (マネージドまたはネイティブ) に存在する場合があります。 この状況は、より新しいリリースで既に解決されている可能性があるため、まず外部依存関係を最新バージョンに更新します。 そうでない場合は、ライブラリの保守担当者に連絡し、更新計画について質問します。

または、次の方法を試すことができます。

  1. Xamarin.Forms 使用している場合は、このブログ記事を参照してください。
  2. 参照されていない場合には削除されてもよいように、マネージド リンカーを (プロジェクト全体、または少なくとも、UIWebView を使用した依存関係に対し) 有効にします。 これで問題は解決しますが、コード リンカーを安全に加えるために追加の作業が必要になる場合があります。
  3. マネージド リンカーの設定を変更できない場合は、次の特殊なケースを参照してください。

アプリケーションでリンカーを使用できない (または設定を変更できない)

何らかの理由で、マネージド リンカーを使用しない場合 (たとえば、[リンクしない]の場合)、UIWebView シンボルは Apple に送信したバイナリ アプリに残るため、アプリが拒否される可能性があります。

"強制的な" ソリューションは、プロジェクトの[追加の mtouch 引数]に --optimize=force-rejected-types-removal を追加することです。 これにより、アプリケーションから UIWebView の痕跡が削除されます。 ただし、この型を参照するコードはいずれも正しく機能しません (例外やクラッシュが予想されます)。 この方法は、実行時にコードに到達できないことが確実である場合にのみ使用する必要があります (静的分析によって到達可能であった場合でも)。

iOS 7.x (またはそれ以前) のサポート

v2.0 以降、UIWebView は iOS の一部となっています。 最も一般的な代替品は、WKWebView (iOS 8) と SFSafariViewController (iOS 9) です。 アプリケーションで引き続き古い iOS バージョンがサポートされている場合は、次のオプションを検討する必要があります。

  • iOS 8 を最小ターゲット バージョンにします (ビルド時の決定)。
  • アプリが iOS 8 以降 (実行時の決定) で実行されている場合にのみ、WKWebView を使用します。

Apple に送信されていないアプリケーション

アプリケーションが Apple に送信されていない場合は、非推奨の API は今後の iOS リリースで削除されるため、これらを使わないような計画を立てるべきです。 ただし、この切り替えは、独自のスケジュールで行うことができます。