.NET MAUIでiPadシミュレーターがスマホ解像度になる原因と対処法

.NET MAUI で作った画面を iPad シミュレーターで動かしたら、「巨大な iPad の中にスマホ画面だけポンと出る」ような状態になって困っていませんか。Android の実機(Pixel 7 など)では問題ないのに、iOS 側だけスマホ相当の狭い解像度でレターボックス表示になってしまう……という現象は、主にアプリ設定とレイアウト設計の二つが原因です。本記事では、Info.plist の具体的な設定から、Grid/FlexLayout を使った“iPad でも伸びるレイアウト”への改善方法まで、実務レベルで踏み込んで解説します。

.NET MAUI アプリを iPad シミュレーターにデプロイするとスマホ解像度になるときの原因と対処法

目次

現象の整理:iPad シミュレーターでだけ「スマホ解像度」になる

まずは問題を整理しておきます。典型的には次のような状態になっています。

  • Android 実機(例:Pixel 7)では、画面いっぱいに UI が表示される
  • iPad シミュレーターにデプロイすると、左右に黒帯(または余白)が出て、スマホ相当の“細長い”画面として表示される
  • クリーン/リビルド、Visual Studio や Mac ビルドホスト、シミュレーターの再起動をしても改善しない

イメージとしては、iPad 上で「iPhone アプリだけを中央に拡大して動かしている」ような表示です。これは iPad 側で iPhone 互換モード(いわゆる“iPhone only”アプリとして起動)になっているか、レイアウトが端末サイズに応じて伸び縮みしない設計になっているときに起こります。

結論:原因は「iPad 非対応設定」か「固定レイアウト」

結論から言うと、原因は大きく次の二つに分かれます。

  • アプリ設定が iPad をサポートしていない
    → iPad では iPhone 互換モードで起動し、画面サイズがスマホ相当になる
  • レイアウトが固定サイズ前提で設計されている
    → iPad として起動していても、UI が「広がってくれない」

多くの場合、両方に問題が混在しています。まずは設定を直して「iPad として正しく起動する」ようにした上で、レイアウトを Grid / FlexLayout / StackLayout ベースの可変設計に切り替えていく、という二段構えで対処していくのが近道です。

iPad をサポートする Info.plist の設定を確認する

iPad が iPhone 互換モードで起動している場合、アプリは「iPhone 専用アプリ」として扱われ、iPad 上でもスマホの解像度を前提としたサイズで表示されます。これは .NET MAUI 特有の現象ではなく、ネイティブ iOS アプリでも同じです。

.NET MAUI プロジェクトでは、iOS / iPadOS 向けの設定は Platforms/iOS/Info.plist にまとまっています。ここに誤りや不足があると、iPad での表示がスマホ解像度になってしまいます。

UIDeviceFamily に iPad を含める

最優先で確認するのが UIDeviceFamily の設定です。

<key>UIDeviceFamily</key>
<array>
  <integer>1</integer> <!-- iPhone / iPod touch -->
  <integer>2</integer> <!-- iPad -->
</array>

ここで <integer>2</integer>(iPad)が抜けていると、「iPhone 向けのアプリ」と判断され、iPad では iPhone 互換モードで起動します。もし 1 のみになっていたら、必ず 2 を追加します。

値対象デバイス結果
1 のみiPhone / iPod touchiPad では iPhone 互換モードで起動(スマホ解像度)
1, 2iPhone / iPad 両対応iPad ネイティブ解像度で起動

UISupportedInterfaceOrientations~ipad を設定する

次に、iPad 用の対応回転方向を明示しておきます。iPhone 向けの UISupportedInterfaceOrientations と別に、UISupportedInterfaceOrientations~ipad を設定するのがポイントです。

&lt;key&gt;UISupportedInterfaceOrientations~ipad&lt;/key&gt;
&lt;array&gt;
  &lt;string&gt;UIInterfaceOrientationPortrait&lt;/string&gt;
  &lt;string&gt;UIInterfaceOrientationLandscapeLeft&lt;/string&gt;
  &lt;string&gt;UIInterfaceOrientationLandscapeRight&lt;/string&gt;
&lt;/array&gt;

少なくとも、iPad で許可したい向き(縦・横)をここで宣言しておくと、「iPad としてのレイアウト」を iOS が正しく判断してくれるようになります。

UIRequiresFullScreen は通常 false にする

UIRequiresFullScreen は「フルスクリーン専用アプリかどうか」を指定するキーです。通常の業務アプリや一般的なアプリでは false で問題ありません。

&lt;key&gt;UIRequiresFullScreen&lt;/key&gt;
&lt;false/&gt;

true にすると、Split View や Slide Over など、iPad 特有のマルチタスク機能が制限される場合があります。直接「スマホ解像度」問題の原因ではないことも多いですが、iPad での挙動トラブルを避けるためにも false を基本としておくのがおすすめです。

テンプレートからの新規 MAUI プロジェクトと比較する

新規に .NET MAUI プロジェクトをテンプレートから作成した場合、通常は iPhone / iPad 両対応の設定が最初から含まれています。したがって、もし既存プロジェクトで iPad の設定が抜けているなら、次のような可能性があります。

  • Info.plist を手動で編集した際に UIDeviceFamily などを削除してしまった
  • 別のサンプルプロジェクトの Info.plist を上書きしてしまった
  • ソース管理のマージミスで一部のキーが失われた

もっとも手っ取り早い確認方法は、

  1. 新規に空の MAUI プロジェクトを作成する
  2. そのプロジェクトの Platforms/iOS/Info.plist を開く
  3. 既存プロジェクトの Info.plist と比較し、UIDeviceFamily などの差分を戻す

という手順です。設定起因なのか、レイアウト起因なのかを切り分けるためにも、新規プロジェクトとの比較は非常に有効です。

レイアウトが iPad で広がらない理由と改善パターン

Info.plist を修正して iPad ネイティブ解像度で起動するようになっても、UI が中央に小さく固まったままだったり、左右に無駄な余白が残るケースがあります。これは、レイアウトが「固定サイズ前提」で組まれている場合に起こりがちです。

AbsoluteLayout / 固定ピクセル指定の問題点

次のような書き方を多用していると、画面サイズが変わっても UI が追従せず、iPad ではスカスカな画面になりやすくなります。

  • AbsoluteLayout を使い、座標(X, Y)や幅・高さをピクセルで固定している
  • WidthRequest / HeightRequest で幅・高さを固定している
  • Grid の列幅・行高をすべて固定ピクセル(例:100 など)で指定している

例として、次のような AbsoluteLayout ベースの設計を考えてみます。

&lt;AbsoluteLayout&gt;
  &lt;Button Text="ログイン"
          WidthRequest="200"
          HeightRequest="50"
          AbsoluteLayout.LayoutBounds="50,400,200,50"
          AbsoluteLayout.LayoutFlags="None" /&gt;
&lt;/AbsoluteLayout&gt;

スマホ画面前提の座標(50, 400)でボタンを配置しているため、画面サイズが変わってもボタンの位置は変わらず、iPad では画面の一部分だけが使われているように見えてしまいます。

Grid / FlexLayout / StackLayout を基本にする

.NET MAUI では、Grid / FlexLayout / StackLayout を基本として、端末サイズに応じて伸び縮みするレイアウトを組むのが定石です。Grid を例にとると、次のようにスターサイズ(*)や Auto サイズを組み合わせていきます。

&lt;Grid
    RowDefinitions="Auto,*"
    ColumnDefinitions="*,*"&gt;

  &lt;Label Text="タイトル"
         Grid.Row="0"
         Grid.ColumnSpan="2"
         HorizontalOptions="Center"
         Margin="0,16,0,8" /&gt;

  &lt;VerticalStackLayout Grid.Row="1" Grid.Column="0"
                       Padding="16"
                       Spacing="12"&gt;
    &lt;Entry Placeholder="メールアドレス" /&gt;
    &lt;Entry Placeholder="パスワード"
           IsPassword="True" /&gt;
    &lt;Button Text="ログイン"
            HorizontalOptions="FillAndExpand" /&gt;
  &lt;/VerticalStackLayout&gt;

  &lt;Image Grid.Row="1" Grid.Column="1"
         Aspect="AspectFit"
         Margin="16"
         Source="login_illustration.png" /&gt;

&lt;/Grid&gt;

スターサイズや Auto サイズを駆使することで、iPad のように画面が広くなったときにも、コントロールが自然に拡大・再配置されます。

OnIdiom / DeviceInfo.Idiom で Phone / Tablet を出し分ける

Phone と Tablet で同じレイアウトを使うと、どちらかに無理が出ることがあります。その場合は、OnIdiom / DeviceInfo.Idiom を使って、Phone と Tablet でパディングや列数を切り替える設計が有効です。

XAML 側での出し分け例:

&lt;VerticalStackLayout
    Padding="{OnIdiom Phone='16,12', Tablet='32,24'}"
    Spacing="16"&gt;

  &lt;Grid RowDefinitions="Auto,*"
        ColumnDefinitions="{OnIdiom Phone='*', Tablet='*,*'}"&gt;
    &lt;Label Text="ダッシュボード"
           Grid.Row="0"
           Grid.ColumnSpan="2"
           FontSize="24"
           Margin="0,0,0,8" /&gt;

    &lt;CollectionView Grid.Row="1"
                    Grid.Column="0"
                    ItemsLayout="{OnIdiom Phone='VerticalList', Tablet='VerticalGrid, 2'}"&gt;
      &lt;!-- ... --&gt;
    &lt;/CollectionView&gt;

    &lt;Border Grid.Row="1" Grid.Column="1"
            IsVisible="{OnIdiom Phone=false, Tablet=true}"&gt;
      &lt;!-- サイドバー的な情報パネル --&gt;
    &lt;/Border&gt;
  &lt;/Grid&gt;

&lt;/VerticalStackLayout&gt;

C# 側での判定例:

using Microsoft.Maui.Devices;

if (DeviceInfo.Idiom == DeviceIdiom.Tablet)
{
    // iPad 向けにアイテムサイズや列数を調整
    collectionView.ItemsLayout = new GridItemsLayout(2, ItemsLayoutOrientation.Vertical);
}
else
{
    // Phone 向け
    collectionView.ItemsLayout = LinearItemsLayout.Vertical;
}

こうした分岐を入れておくと、「Phone では 1 カラム」「Tablet では 2 カラム」「余白も Tablet のほうを広めに」といったチューニングが簡単になります。

OnPlatform で iOS / Android の見た目差を吸収する

同じ XAML でも、iOS と Android では微妙に表示が異なる場合があります。その差を吸収したいときには OnPlatform を使います。

&lt;Label Text="合計金額"
       FontSize="18"
       Margin="{OnPlatform iOS='16,8', Android='12,4'}"
       HorizontalOptions="Center" /&gt;

細かい見た目差はスタイルや OnPlatform で吸収し、基本設計としては「Grid / FlexLayout / StackLayout + OnIdiom」で Phone / Tablet の差分に対応していくのが、メンテナンス性の面でもおすすめです。

原因切り分けの手順:設定かレイアウトかを素早く見極める

「設定がおかしいのか」「UI 設計の問題なのか」をごちゃ混ぜにして考えると、調査が長引きがちです。効率よく切り分けるには、次の手順をおすすめします。

1. 新規“空の” MAUI プロジェクトを iPad シミュレーターで起動する

  1. Visual Studio から新規 .NET MAUI アプリ(空のテンプレート)を作成
  2. iPad シミュレーターを選択してデバッグ実行
テンプレートアプリの挙動疑うべき原因
画面が iPad 全体に広がる既存アプリ側のレイアウト設計の問題が濃厚
テンプレートでもスマホ解像度相当になるプロジェクト全体の設定、またはビルド/シミュレーターのキャッシュ問題

テンプレートが正常に広がるなら、「あなたのアプリ固有の問題」と切り分けられるので、レイアウトや Info.plist の差分に集中できます。

2. Info.plist を新規プロジェクトと比較する

テンプレートの Info.plist を開いて、既存プロジェクトの Info.plist と見比べてください。特に次のキーを重点的に確認します。

  • UIDeviceFamily に 2(iPad)が含まれているか
  • UISupportedInterfaceOrientations~ipad が存在するか
  • UIRequiresFullScreen の値が意図通りか

差分があれば、新規プロジェクト側の内容をベースに修正してから再ビルドします。

3. それでも改善しない場合はキャッシュを疑う

設定を直しても挙動が変わらない場合、ビルドキャッシュやシミュレーターのキャッシュが悪さをしていることがあります。代表的な対処は次のとおりです。

  • プロジェクトの bin/obj フォルダを削除し、リビルド
  • iOS シミュレーターで「Erase All Content and Settings」 を実行
  • Mac の Xcode の DerivedData を削除
    (Xcode を開き、Preferences > Locations から DerivedData のパスを確認して削除)

キャッシュをクリアした上で再ビルド・再デプロイすると、Info.plist の変更が正しく反映され、iPad ネイティブ解像度で起動するようになるケースが多くあります。

よくある落とし穴とアンチパターン

iPad 対応でハマりやすいポイントを、現象と対策を含めて整理します。

落とし穴典型的な現象対策
UIDeviceFamily に iPad が含まれていないiPad でスマホ解像度のウィンドウとして表示UIDeviceFamily に 2 を追加し、iPhone / iPad 両対応にする
AbsoluteLayout で座標を固定iPad で画面の一部だけに UI が密集し、周囲がスカスカGrid / FlexLayout / StackLayout に置き換え、相対的な配置にする
WidthRequest / HeightRequest の多用画面が広くなってもコントロールのサイズが変わらない必要最低限にとどめ、可能なら Minimum/Maximum と組み合わせる
Phone 前提の 1 カラム UIiPad で横幅が余り、可読性が下がるOnIdiom で Tablet の場合は 2 カラム構成にするなど再配置する
余白のハードコーディングPhone と Tablet で余白のバランスが不自然OnIdiom で端末種別に応じた Padding / Margin を出し分ける

最小構成サンプル:Phone と iPad でレイアウトを変える

ここまでの内容を踏まえて、「Phone では 1 カラム、Tablet(iPad)では 2 カラム」になる最小例を紹介します。

XAML 側の例

&lt;ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="SampleApp.Views.DashboardPage"&gt;

  &lt;Grid
      RowDefinitions="Auto,*"
      ColumnDefinitions="{OnIdiom Phone='*', Tablet='*,*'}"
      Padding="{OnIdiom Phone='16,12', Tablet='32,24'}"&gt;

    &lt;Label Text="ダッシュボード"
           Grid.Row="0"
           Grid.ColumnSpan="2"
           FontSize="24"
           HorizontalOptions="Center"
           Margin="0,0,0,16" /&gt;

    &lt;CollectionView Grid.Row="1"
                    Grid.Column="0"
                    x:Name="MainList"&gt;
      &lt;!-- メインの一覧 --&gt;
    &lt;/CollectionView&gt;

    &lt;Border Grid.Row="1"
            Grid.Column="1"
            IsVisible="{OnIdiom Phone=false, Tablet=true}"&gt;
      &lt;VerticalStackLayout Spacing="12"&gt;
        &lt;Label Text="詳細情報" FontAttributes="Bold" /&gt;
        &lt;Label Text="ここに iPad のみで表示するサイド情報を配置" /&gt;
      &lt;/VerticalStackLayout&gt;
    &lt;/Border&gt;

  &lt;/Grid&gt;

&lt;/ContentPage&gt;

C# 側の例(アイテムサイズや列数の調整)

using Microsoft.Maui.Controls;
using Microsoft.Maui.Devices;

public partial class DashboardPage : ContentPage
{
    public DashboardPage()
    {
        InitializeComponent();

        if (DeviceInfo.Idiom == DeviceIdiom.Tablet)
        {
            // iPad では 2 カラム表示(グリッド)
            MainList.ItemsLayout = new GridItemsLayout(2, ItemsLayoutOrientation.Vertical)
            {
                HorizontalItemSpacing = 16,
                VerticalItemSpacing = 16
            };
        }
        else
        {
            // Phone では縦 1 列スクロール
            MainList.ItemsLayout = LinearItemsLayout.Vertical;
        }
    }
}

このような構成にしておくと、

  • Phone(iPhone / Android Phone)では 1 カラム・余白少なめ
  • Tablet(iPad / Android Tablet)では 2 カラム・余白多め・サイド情報付き

という、端末に応じて最適化された UI を簡単に実現できます。

Shell を使う場合の iPad 向けポイント

.NET MAUI の Shell を使っている場合は、iPad でのサイド分割も意識する必要があります。例えば、ナビゲーション周りの設定として FlyoutBehavior を適切に設定しておくと、iPad では「常時サイドにメニューを出す」といった UI にできます。

&lt;Shell
    x:Class="SampleApp.AppShell"
    xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    FlyoutBehavior="Split"&gt;

  &lt;FlyoutItem Title="ホーム" Icon="home.png"&gt;
    &lt;ShellContent ContentTemplate="{DataTemplate local:HomePage}" /&gt;
  &lt;/FlyoutItem&gt;

  &lt;FlyoutItem Title="設定" Icon="settings.png"&gt;
    &lt;ShellContent ContentTemplate="{DataTemplate local:SettingsPage}" /&gt;
  &lt;/FlyoutItem&gt;

&lt;/Shell&gt;

FlyoutBehavior="Split" にしておくと、

  • Phone では通常どおりハンバーガーメニューからの Flyout
  • Tablet では画面左にナビゲーションを固定表示

という、タブレットらしい UI を比較的簡単に実現できます。

実案件での iPad 対応設計の考え方

業務アプリや BtoB 系アプリで iPad をターゲットにする場合、「単に画面を引き伸ばす」のではなく、iPad の画面サイズを活かした設計が重要です。いくつかの考え方を挙げておきます。

  • マスター・詳細(Master-Detail)レイアウトにする
    一覧を左、詳細を右に配置し、Phone では別ページとして表示する構成が典型です。
  • 頻繁に操作するボタンは Thumb(親指)の位置を意識する
    iPad でも片手操作するケースを想定しつつ、Phone よりも広い範囲を考慮してボタン位置を調整します。
  • 入力フォームは複数カラム化を検討する
    Phone では縦に長いフォームでも、iPad では 2 カラム化してスクロール量を減らすなど、体験を変えると使いやすくなります。
  • グラフやチャートを積極的に活用する
    スペースが広がった分、数値一覧よりも視覚的な要素を増やしても良い場面が増えます。

これらはすべて、「OnIdiom で Phone と Tablet を切り替える」「ItemsLayout を変える」など、この記事で紹介したテクニックで実現できます。最初から「Phone と Tablet の両方をサポートする」前提で画面設計を行っておくと、後から iPad 対応をする際の手戻りが少なくなります。

まとめ:iPad 対応は「設定+レイアウト」の両輪で考える

最後に、本記事のポイントを整理します。

  • iPad シミュレーターで“スマホ解像度”になる主因は、iPhone 互換モードで起動していることが多い
  • まずは Platforms/iOS/Info.plist を確認し、UIDeviceFamily に 2(iPad)を含める
  • UISupportedInterfaceOrientations~ipad で iPad 用の回転方向を設定し、UIRequiresFullScreen は通常 false にする
  • レイアウトは AbsoluteLayout ではなく Grid / FlexLayout / StackLayout を基本とし、* や Auto サイズを活用して可変レイアウトにする
  • OnIdiom や DeviceInfo.Idiom を使って、Phone と Tablet でパディングや列数を切り替える
  • 新規 MAUI プロジェクトとの比較とキャッシュクリア(bin/obj、シミュレーター、DerivedData)の実施で、「設定起因か UI 起因か」を素早く切り分ける

この二つ(アプリ設定の見直しと、レイアウトのレスポンシブ化)を押さえておけば、.NET MAUI アプリを iPad でネイティブかつ快適な解像度で表示させることができます。すでにスマホ向けとして完成している画面でも、Grid と OnIdiom を組み合わせて少しずつ改善していけば、iPad 用 UI への移行コストを抑えつつ、ユーザーにとって使いやすいアプリへと育てていくことができます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次