0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

iOSのUIガイドライン Human Interface Guidelines を読んでみる part4

Last updated at Posted at 2020-09-21

バー

ナビゲーションバー

ナビゲーションバーは、アプリ画面の上部、ステータスバーの下に表示され、一連の階層画面をナビゲートできます。
新しい画面が表示されると、前の画面のタイトルが付けられた戻るボタンがバーの左側に表示されます。
場合によっては、ナビゲーションバーの右側に、
アクティブなビュー内のコンテンツを管理するための[編集]ボタンや[完了]ボタンなどのコントロールが含まれています。
分割ビューでは、分割バーの1つのペインにナビゲーションバーが表示される場合があります。
ナビゲーションバーは半透明で、背景の色合いがあり、キーボードが画面上にあるとき、ジェスチャーが発生したとき、またはビューのサイズが変更されたときに非表示になるように構成できます。

全画面コンテンツを表示するときは、ナビゲーションバーを一時的に非表示にすることを検討する

コンテンツに集中したい場合、ナビゲーションバーが邪魔になることがあります。
バーを一時的に非表示にして、より没入型のエクスペリエンスを提供します。
写真は、フルスクリーンの写真を表示するときに、ナビゲーションバーやその他のインターフェイス要素を非表示にします。
このタイプの動作を実装する場合、タップなどの簡単なジェスチャーでナビゲーションバーを復元できるようにします。

開発者向けガイダンスについては、UINavigationBarを参照してください。

ナビゲーションバーのタイトル

ナビゲーションバーに現在のビューのタイトルを表示することを検討してください。
ほとんどの場合、タイトルは人々が自分が見ているものを理解するのに役立ちます。
ただし、ナビゲーションバーにタイトルを付けるのが冗長に思われる場合は、タイトルを空白のままにすることができます。
たとえば、コンテンツの最初の行は必要なすべてのコンテキストを提供するため、メモアプリは現在のノートにタイトルを付けません。

■標準タイトル

■大きなタイトル

コンテキストを特に強調したい場合は、大きなタイトルを使用

大きなタイトルはコンテンツと競合するべきではありませんが、
一部のアプリでは、大きなタイトルの大きくて太字のテキストが、ユーザーが閲覧および検索する際の方向付けに役立ちます。
たとえば、タブ付きレイアウトでは、大きなタイトルはアクティブなタブを明確にし、
ユーザーがいつ一番上までスクロールしたかを示すのに役立ちます。
電話アプリはこのアプローチを使用していますが、
ミュージックは大きなタイトルを使用して、アルバム、アーティスト、プレイリスト、ラジオなどのコンテンツ領域を区別しています。
iOS 13以降では、大きなタイトルナビゲーションバーには、デフォルトで背景素材や影が含まれていません。
また、大きなタイトルは、コンテンツをスクロールし始めると標準のタイトルに変わります。
開発者向けガイダンスについては、prefersLargeTitlesを参照してください。

大きなタイトルのナビゲーションバーの境界線を非表示にする

iOS 13以降では、バーの影を取り除くことで、ナビゲーションバーの下の境界線を非表示にできます。
(ユーザーがコンテンツ領域をスクロールすると、境界線は自動的に再表示されます)。
ボーダレススタイルは、タイトルとコンテンツのつながりを強化するため、大きなタイトルのナビゲーションバーでうまく機能します。
ただし、標準のタイトルのナビゲーションバーでは、ボーダーレススタイルはうまく機能しない可能性があります。
バーのタイトルとボタンを区別するのが難しい場合があるためです。
これの例外は、iPadの分割ビューです。
両方でボーダーレススタイルを使用して、プライマリビューとセカンダリビューの一貫性を維持することができます。

ナビゲーションバーコントロール

コントロールの数が多すぎるナビゲーションバーを混雑させないようにします。
一般に、ナビゲーションバーには、ビューの現在のタイトル、戻るボタン、およびビューのコンテンツを管理する1つで十分です。
ナビゲーションバーでセグメント化されたコントロールを使用する場合、
バーにはタイトルやセグメント化されたコントロール以外のコントロールを含めないでください。

標準の戻るボタン

標準の戻るボタンを使用すると、情報の階層をたどってステップをたどることができます。
ただし、カスタムの戻るボタンを実装する場合は、

  • 戻るボタンのように見え
  • 直感的に動作し
  • 他のインターフェースと一致し
  • アプリ全体に一貫して実装されていること

を確認してください。
システム提供の戻るボタンシェブロンをカスタムイメージに置き換える場合は、カスタムマスクイメージも指定してください。
iOSはこのマスクを使用して、遷移中にボタンのタイトルをアニメーション化します。

複数セグメントのパンくずリストを含めないでください。

戻るボタンは常に単一のアクションを実行し、前の画面に戻ります。
現在の画面への完全なパスがないと人々が迷子になる可能性があると思われる場合は、
アプリの階層をフラット化することを検討してください。

テキスト付きのボタンに十分なスペースを与えます。

ナビゲーションバーに複数のテキストボタンが含まれている場合、
間隔がないとボタンが区別しにくくなることがあります。
ボタンの間に固定スペースアイテムを挿入して、分離を追加します。
開発者のガイダンスについては、参照UIBarButtonSystemItemFixedSpaceのではUIBarButtonItemを参照してください。

ナビゲーションバーでセグメント化されたコントロールを使用して、アプリの情報階層を平坦化することを検討してください。

ナビゲーションバーでセグメント化されたコントロールを使用する場合は、階層の最上位レベルでのみ使用し、
下位レベルで正確な戻るボタンのタイトルを選択してください。
追加のガイダンスについては、「セグメント化されたコントロール」を参照してください。

※こちらはあまり最近のアプリで利用されていることを見ない気がします。
基本的にはタイトルや戻るボタンのあるナビゲーションバーが最上位にあるイメージです。
タブで階層が深くない場合はこういうのも良いのでしょうか。

検索バー

検索バーを使用すると、フィールドにテキストを入力して、値の大きなコレクションを検索できます。
検索バーは、単独で、またはナビゲーションバーやコンテンツビューに表示できます。

検索を実装するには、テキストフィールドの代わりに検索バーを使用

テキストフィールドには、ユーザーが期待する標準の検索バーの外観がありません。

[クリア]ボタンを有効に

ほとんどの検索バーには、フィールドの内容を消去する[クリア]ボタンが含まれています。

必要に応じて[キャンセル]ボタンを有効に

ほとんどの専用検索バーには、検索をすぐに終了する[キャンセル]ボタンがあります。

必要に応じて、検索バーにヒントを

検索バーのフィールドには、検索対象を思い出させるために、
「衣類、靴、アクセサリーの検索」または単に「検索」などのプレースホルダーテキストを含めることができます。

検索バーの下に便利なショートカットやその他のコンテンツを提供することを検討

検索バーの下の領域を使用すると、コンテンツにすばやくアクセスできます。
たとえばSafariでは、検索フィールドをタップするとすぐにブックマークが表示されます。
いずれかを選択すると、検索語句を入力せずにその場所に移動します。

いわゆる絞り込みであったり良くあるものを素早くアクセスさせてUXを良くするってことですよね。
開発者向けガイダンスについては、UISearchControllerおよびUISearchBarを参照してください。

自分UISearchController使ったことないので勉強してみよう。

スコープバー

スコープバーを検索バーに追加すると、検索の範囲を絞り込むことができます。

サイドバー

サイドバーは、アプリレベルのナビゲーションと、アプリ内のコンテンツのトップレベルコレクションへのクイックアクセスを提供します。
サイドバーの項目を選択すると、特定のコンテンツに移動できます。

サイドバーに正しい外観を適用する

サイドバーを作成するには、コレクションビューリストレイアウトのサイドバーの外観を使用します。
開発者向けガイダンスについては、UICollectionLayoutListConfiguration.Appearanceを参照してください。

サイドバーを隠せるようにしてください

ユーザーがサイドバーを非表示にしてコンテンツのスペースを増やし、組み込みのエッジスワイプジェスチャーを使用して
サイドバーを再度表示できるようにします。
デフォルトでサイドバーを非表示にしないでください。

サイドバーのタイトルは明確かつ簡潔にしてください。

不要で冗長な単語は省略します。

一般に、サイドバー内で2レベルを超える階層を公開しない

データ階層が2レベルよりも深い場合は、分割ビューインターフェイスの補足列でリストビューを使用します。
開発者向けガイダンスについては、UICollectionLayoutListConfigurationを参照してください。

ステータスバー

ステータスバーは画面の上端に沿って表示され、時間、携帯通信会社、バッテリーレベルなど、
デバイスの現在の状態に関する有用な情報を表示します。
ステータスバーに表示される実際の情報は、デバイスとシステム構成によって異なります。

システム提供のステータスバーを使用します。
ステータスバーがシステム全体で一貫していることを期待しています。
カスタムステータスバーに置き換えないでください。

ステータスバーの下にある不明瞭なコンテンツ

デフォルトでは、ステータスバーの背景は透明で、下のコンテンツが透けて見えます。
ステータスバーを読みやすくし、その背後にあるコンテンツがインタラクティブであることを示唆しないでください。
これを行うには、いくつかの一般的な手法があります。

  • アプリのナビゲーションバーを使用すると、ステータスバーの背景が自動的に表示され、
    コンテンツがステータスバーの下に表示されなくなります。

  • ステータスバーの背後に、グラデーションや単色などのカスタム画像を表示します。

  • ステータスバーの後ろにぼかしたビューを配置します。

開発者向けガイダンスについては、UIBlurEffectを参照してください。

フルスクリーンメディアを表示するときは、ステータスバーを一時的に非表示にすることを検討してください。

ユーザーがメディアに集中しようとすると、ステータスバーが邪魔になることがあります。
これらの要素を一時的に非表示にして、より没入型のエクスペリエンスを提供します。
たとえば、写真アプリでは、ユーザーが全画面の写真を閲覧すると、ステータスバーやその他のインターフェイス要素が非表示になります。

タブバー

アプリ画面の下部にタブバーが表示され、アプリのさまざまなセクションをすばやく切り替えることができます。
タブバーは半透明で、背景の色合いがあり、すべての画面方向で同じ高さを維持し、キーボードが表示されているときは非表示になっています。
タブバーには任意の数のタブを含めることができますが、表示されるタブの数はデバイスのサイズと向きによって異なります。
水平方向のスペースが限られているために一部のタブを表示できない場合、最後に表示されるタブは[追加]タブになり、別の画面のリストに追加のタブが表示されます。

タブバーを使用して、アクセスを容易に

タブバーは、情報階層を平坦化し、複数のピア情報カテゴリまたはモードへのアクセスを一度に提供するための良い方法です。

ナビゲーションを目的としてタブバーを使用する

アクションを実行するためにタブバーボタンを使用しないでください。
現在のビューの要素に作用するコントロールを提供する必要がある場合は、代わりにツールバーを使用してください。

タブが多すぎないように

タブを追加するたびに、タブを選択するためのタップ可能な領域が減り、アプリの複雑さが増し、情報の検索が難しくなります。
[その他]タブでは追加のタブを表示できますが、これにはタップの回数が増え、スペースの使用率が低くなります。
必須のタブのみを含め、情報階層に必要な最小限のタブを使用してください。
タブが少なすぎると、インターフェースが切断されたように見えるため、問題になる可能性があります。
一般的に、iPhoneでは3〜5個のタブを使用します。iPadでは、さらにいくつかを使用できます。

アプリ内の別の領域に移動するときにタブバーを非表示にしないでください。

タブバーはアプリのグローバルナビゲーションを有効にするため、どこにでも表示されたままにする必要があります。
これの例外は、モーダルビューです。
モーダルビューは、終了時にユーザーが閉じる別のエクスペリエンスを提供するため、アプリの全体的なナビゲーションの一部ではありません。

機能が利用できないときは、タブを削除したり無効にしたりしないでください

タブが使用可能な場合とそうでない場合がある場合、アプリのインターフェースは不安定になり、予測できなくなります。
すべてのタブが常に有効になっていることを確認し、タブのコンテンツが使用できない理由を説明します。

※例えばコンテンツが使えない場合は「データがありません」などの使用できない理由のラベルがのったビューを表示させるなど。

バッジを使用する

新しい情報がそのビューまたはモードに関連付けられていることを示すために、
バッジ(白いテキストと数字または感嘆符のいずれかを含む赤い楕円)をタブに表示できます。

ツールバー

ツールバーはアプリ画面の下部に表示され、
現在のビューまたはその中のコンテンツに関連するアクションを実行するためのボタンが含まれています。
ツールバーは半透明で、背景の色合いがあり、多くの場合、ユーザーが必要としない場合は非表示になります。
たとえば、Safariでは、ページをスクロールし始めると、読んでいる可能性が高いため、ツールバーが非表示になります。

アイコンまたはテキストタイトルのボタンがアプリに適しているかどうか

4つ以上のツールバーボタンが必要な場合、アイコンは適切に機能します。
ボタンが3つ以下の場合、テキストがより鮮明になることがあります。

テキスト付きのボタンに十分なスペースを持たせる

ツールバーに複数のボタンが含まれている場合、
それらのボタンのテキストが一緒に実行されているように見えて、ボタンを区別できなくなる場合があります。
ボタン間に固定スペースを挿入して、分離を追加します。
開発者のガイダンスについては、UIBarButtonSystemItemFixedSpaceを参照してください。

アクションシート

アクションシートは、コントロールまたはアクションに応答して表示される特定のスタイルのアラートであり、
現在のコンテキストに関連する2つ以上の選択肢のセットを提示します。
アクションシートを使用して、タスクを開始したり、キャンセルのような操作を実行する前に確認を要求したりできます。
小さい画面では、アクションシートが画面の下から上にスライドします。
大きな画面では、アクションシートがポップオーバーとして一度に表示されます。

わかりやすくする場合は、[キャンセル]ボタンを提供する

[キャンセル]ボタンは、ユーザーがタスクを放棄しているときに自信を与えます。
キャンセルボタンは、常に画面下部のアクションシートに含める必要があります。

破壊的な選択を目立たせます。

破壊的または危険なアクションを実行するボタンには赤を使用し、アクションシートの上部にこれらのボタンを表示します。

アクションシートでスクロールを有効にしない

アクションシートのオプションが多すぎる場合、人々はスクロールしてすべての選択肢を見る必要があります。
スクロールは、選択を行うために余分な時間を必要とし、不注意でボタンをタップしてしまうかもしれないので有効にしないでください。

アラート

アラートは、重要な情報を伝え、多くの場合フィードバックを要求します。
アラートは、タイトル、メッセージ、1つ以上のボタン、および入力を収集するためのオプションのテキストフィールドで構成されます。
これらの構成可能な要素を除いて、アラートの視覚的な外観は静的であり、カスタマイズできません。

アラートを最小限に抑える

アラートはユーザーエクスペリエンスを混乱させるため、購入の確認や破壊的なアクション(削除など)、
または問題の通知などの重要な状況でのみ使用する必要があります。
頻度の低いアラートは、人々がアラートを真剣に受け止めるのに役立ちます。

両方の方向でアラートの外観をテスト

アラートは、横長モードと縦長モードで異なって表示される場合があります。
アラートテキストを最適化して、スクロールせずにどの方向でも読みやすくします。

開発者向けガイダンスについては、UIAlertControllerを参照してください。

アラートのタイトルとメッセージ

短く説明的なマルチワードのアラートタイトルを作成します。

画面上で読む必要があるテキストが少なければ少ないほど良いです。
質問するか短い文章を使用することを検討してください。
タイトルは可能な限り1行にしてください。
タイトルが完全な文である場合は、文スタイルの大文字と適切な末尾の句読点を使用します。
タイトルが文の断片である場合は、タイトルスタイルの大文字を使用し、末尾に句読点を追加しないでください。

メッセージを提供する必要がある場合は、短く

スクロールしないように、メッセージを1行または2行に収まるように短くしてください。

非難、批判的、または侮辱的な発言は避ける

アラートは問題や危険な状況について通知することを知っています。
親しみのある口調を使うよりネガティブでダイレクトな方がいいです。
ただし、あなた、あなた、私、私のような代名詞は避けてください。

警告ボタン

最大2つのボタンのアラートを使用する

2ボタンのアラートにより、2つの選択肢から簡単に選択できます。
ボタン1つでアラートが通知されますが、状況を制御できません。
3つ以上のボタンを持つアラートは複雑になり、スクロールが必要になる場合があります。
これはユーザーエクスペリエンスの低下です。
3つ以上の選択肢が必要な場合は、代わりにアクションシートの使用を検討してください。

警告ボタンに簡潔なタイトルを

最適なボタンのタイトルは、ボタンを選択した結果を説明する単語で構成されます。
すべてのボタンタイトルと同様に、タイトルスタイルの大文字を使用し、句読点を使わないでください。
可能な限り、アラートのタイトルとメッセージに直接関連する動詞と動詞句を使用します(たとえば、すべて表示、返信、または無視)。
OKを使用して単純に受け入れます。
はいといいえの使用は避けてください。

人々が期待する場所にボタンを配置します。

一般的に、人々がタップする可能性が最も高いボタンは右側にある必要があります。
キャンセルボタンは常に左側にある必要があります。
キャンセルボタンに適切にラベルを付けます。
アラートのアクションをキャンセルするボタンには、常に「キャンセル」というラベルを付ける必要があります。

破壊的なボタンを定義する

アラートボタンの結果、コンテンツの削除などの破壊的なアクションが発生する場合は、
ボタンのスタイルをDestructiveに設定して、システムが適切なフォーマットを取得できるようにします。
開発者のガイダンスについては、UIAlertActionStyleDestructiveの定数UIAlertActionを参照してください。

ホーム画面に戻って、アラートをキャンセルできるようにします。アラートが表示されているときにホーム画面にアクセスすると、アプリが終了します。また、[キャンセル]ボタンをタップするのと同じ効果が得られるはずです。つまり、アラートはアクションを実行せずに閉じられます。アラートに[キャンセル]ボタンがない場合は、誰かがアプリを終了したときに実行されるキャンセルアクションをコードに実装することを検討してください。

コレクション(ビュー)

コレクションは、一連の写真などのコンテンツの順序付けされたセットを管理し、
カスタマイズ可能な高度に視覚的なレイアウトで表示します。
コレクションは厳密な線形形式を強制しないため、サイズの異なるアイテムを表示するのに特に適しています。
一般的に言えば、コレクションは画像ベースのコンテンツを表示するために理想的です。
オプションで背景やその他の装飾ビューを実装して、アイテムのサブセットを視覚的に区別できます。

コレクション(ビュー)は対話性とアニメーションの両方をサポートする

デフォルトでは、タップして選択したり、押し続けて編集したり、スワイプしてスクロールしたりできます。
アプリで必要な場合は、カスタムアクションを実行するためのジェスチャーをさらに追加できます。
コレクション内では、アイテムが挿入、削除、または並べ替えられるたびにアニメーションを有効にできます。

標準の行またはグリッドレイアウトで十分な場合は、根本的な新しいデザインを作成しない

コレクションはユーザーエクスペリエンスを向上させるものであり、注目の的になるものではありません。
アイテムを選択しやすくします。
コレクション内のアイテムをタップするのが難しい場合、ユーザーは不満をもち、目的のコンテンツに到達する前に興味を失います。
コンテンツの周りに適切なパディングを使用して、レイアウトをきれいに保ち、コンテンツの重複を防ぎます。

テキストのコレクションではなくテーブルの使用を検討する

スクロール可能なリストに表示されている場合、テキスト情報を表示して要約する方が一般的には簡単で効率的です。

動的なレイアウト変更を行うときは注意

コレクションのレイアウトはいつでも変更できます。
人々がそれを表示して操作しているときにレイアウトを動的に変更する場合は、変更が意味をなし、追跡が容易であることを確認してください。

ページ

ページビューコントローラーは、ドキュメント、ブック、メモ帳、カレンダーなど
コンテンツのページ間の線形ナビゲーションを実装する方法を提供します。
ページビューコントローラーは、2つのスタイルの1つを使用して、
ナビゲーション中のページ間の遷移(スクロールまたはページカール)を管理します。
スクロール遷移には特定の外観はありません。
ページは次から次へとスムーズにスクロールします。
ページカールの遷移により、画面をスワイプすると、ページがカールして、物理的な本のページのようにめくります。

■ページカール

ポップオーバー

ポップオーバーは、コントロールまたは領域をタップしたときに画面上の他のコンテンツの上に表示される一時的なビューです。
通常、ポップオーバーには、それが出現した場所を指す矢印が含まれています。
ポップオーバーは非モーダルまたはモーダルにすることができます。
非モーダルポップオーバーは、画面の別の部分またはポップオーバーのボタンをタップすることによって閉じられます。
モーダルポップオーバーは、ポップオーバーの[キャンセル]または他のボタンをタップすることによって閉じられます。

iPhoneでは使用しない

通常、ポップオーバーはiPadアプリで使用するために予約する必要があります。
iPhoneアプリでは、ポップオーバーではなく全画面のモーダルビューで情報を表示することにより、
利用可能なすべての画面スペースを利用します。

スクロールビュー

スクロールビューを使用すると、ドキュメント内のテキストや画像のコレクションなど、
表示領域よりも大きなコンテンツを閲覧できます。
人々がスワイプ、フリック、ドラッグ、タップ、ピンチすると、スクロールビューがジェスチャーに追従し、
自然な方法でコンテンツを表示またはズームします。
スクロールビュー自体には外観はありませんが、ユーザーが操作するときに一時的なスクロールインジケーターが表示されます。
スクロールビューは、ページングモードで動作するように構成することもできます。
スクロールすると、現在のページを移動するのではなく、コンテンツのまったく新しいページが表示されます。

スクロールビューを別のスクロールビュー内に配置しない

これを行うと、制御が困難な予測不可能なインターフェースが作成されます。

一度に1つのスクロールビューを表示

人々はスクロール時に大きなスワイプジェスチャーを行うことが多く、
同じ画面上の隣接するスクロールビューとの対話を避けるのが難しい場合があります。
1つの画面に2つのスクロールビューを配置する必要がある場合は、1つのジェスチャーが両方のビューに影響する可能性が低くなるように、
スクロールビューを異なる方向にスクロールできるようにすることを検討してください。

テーブル(ビュー)

テーブル(ビュー)は、セクションまたはグループに分割できる、スクロールする単一列リストです。
一般的に、テーブルはテキストベースのコンテンツに最適であり、関連するコンテンツが反対側に表示された状態で、
分割ビューの片側にナビゲーション手段として表示されることがよくあります。

iOSは

  • プレーン
  • グループ化
  • インセットグループ化

の3つのスタイルのテーブルを提供します。

プレーン

行はラベル付きセクションに分割でき、
セクションの最初の項目の前にヘッダーを表示でき、最後の項目の後にフッターを表示できます。

グループ化

行はグループで表示され、ヘッダーの前にフッターを付けることができます。
このスタイルのテーブルには常に少なくとも1つのグループが含まれ、各グループには常に少なくとも1つの行が含まれます。

インセットグループ

行は、角が丸く、親ビューの端からはめ込まれたグループで表示されます。
構成はグループ化と同じ特性を持ち合わせています。
インセットのグループ化されたスタイルは、通常の幅の環境で最適に機能します。

テーブルのコンテンツが素早く表示される

画面上の行にテキストデータをすぐに入力し、画像などのより複雑なデータが利用可能になったら表示します。
これによって人々にすぐに役立つ情報を提供し、アプリの知覚される応答性を高めます。

コンテンツの読み込み時に進行状況を伝えます。テーブルのデータの読み込みに時間がかかる場合は、進行状況バーまたは回転アクティビティインジケーターを表示して、アプリがまだ実行中であることをユーザーに知らせます。

コンテンツを最新の状態に

新しいデータを反映するために、テーブルのコンテンツを定期的に更新することを検討してください。
スクロール位置は勝手に変更してはいけないです。
代わりに、コンテンツをテーブルの最初または最後に追加し、準備ができたらスクロールできるようにします。

テーブルセル

基本的に4種類のスタイルが用意されています。

  • Basic (Default)
  • Subtitle
  • Right Detail (Value 1)
  • Left Detail (Value 2)

詳しくはhttps://developer.apple.com/design/human-interface-guidelines/ios/views/tables/

選択時のフィードバック

コンテンツがタップされたときに、行が短時間ハイライト表示されることを期待しています。
次に、選択が行われたことを示すチェックマークが表示されるなど、新しいビューが表示されるか何かが変更されることを期待します。

Webビュー

Webビューは、埋め込みHTMLやWebサイトなどのリッチWebコンテンツをアプリ内に直接ロードして表示します。
例えば、メールアプリはWebビューを使用して、メッセージにHTMLコンテンツを表示します。

Webビューのみでアプリを構築しない

Webビューを使用して、アプリのコンテキストを離れることなくWebサイトに簡単にアクセスできるようにすることは問題ありませんが、
iOSでWebを閲覧する主な方法はSafariです。
Safariの機能をアプリに複製することは不要であり、お勧めできません。

最後に

part5へ続く...

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?