LASSIC Media らしくメディア
iPad業務アプリのマルチタスク・ドラッグ&ドロップ対応
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- iPadOS 26では、フルスクリーン・ウィンドウ・Stage Managerという3つのモードでアプリを利用できるようになりました。
- 複数ウィンドウ対応にはUIScene/UIWindowSceneベースのアプリアーキテクチャが前提になります。
- ドラッグ&ドロップはUIDragInteraction・UIDropInteractionという専用APIで実装し、他アプリとの連携まで見据えて設計します。
目次
iPad業務アプリのマルチタスク対応とは、生産性機能に合わせて改修する実装を指す
iPad業務アプリのマルチタスク対応とは、Split View世代のシングルウィンドウ設計を、複数ウィンドウやドラッグ&ドロップ、Stage Managerといった生産性機能に合わせて作り直す実装を指します*1。iPadのHuman Interface Guidelines（HIG。Appleが公開するデザイン指針）は2025年6月9日付でこの領域のガイダンスを再編し、iPadOS向けの複数ウィンドウ対応の指針を新設しました*1。
これまで「今のままでも使えている」という理由で改修を先送りにしてきた業務アプリでも、複数ウィンドウやドラッグ&ドロップへの対応状況は現場の作業効率に直結します。iPadを持ち歩いて使う営業・現場・医療といった業種ほど、1台の画面で複数の業務を並行させる場面が多いためです。
本稿ではAppleの公式ドキュメントに基づき、iPadOS 26時点のマルチタスクの全体像、複数ウィンドウ対応（UIScene）とドラッグ&ドロップ（UIDragInteraction・UIDropInteraction）の実装の要点、そして改修を内製と外注のどちらで進めるかの判断軸を整理します。
フルスクリーン・ウィンドウ・Stage Manager——iPadOS 26の3モード
Appleの現行HIGでは、iPadのマルチタスクを大きく2つの表示形態で説明しています。1つはアプリが画面全体を占有する「フルスクリーンモード」で、ユーザーはApp Switcherでアプリごとのウィンドウを切り替えます*1。もう1つが「ウィンドウモード」で、アプリのウィンドウはサイズ変更が可能になり、macOSに近い感覚でウィンドウを自由に配置できます*1。
ウィンドウモードでは、タイル状に並べる定型配置や全画面化、最小化、ウィンドウを閉じる操作までシステム側の標準コントロールが用意されています*1。最前面のウィンドウは、ウィンドウコントロールの色や背後への影の付き方で区別される仕組みです*1。加えてPicture in Pictureは、アプリがフルスクリーンかウィンドウ表示かにかかわらず、動画やFaceTime通話を他のコンテンツの上に重ねて表示できます*1。
Stage Managerは、この複数ウィンドウ環境をさらに拡張する機能として2022年のWWDCで発表されました。Appleは「Stage Managerを使うことで、1つのビューで複数アプリを扱えるようになる」と説明しています*8。同時にiPadOS 16では拡張ディスプレイのサポートやディスプレイズーム機能も導入され、より大きな解像度を活かせるようになりました*8。
重要なのは、アプリ自身が「今どのモードで表示されているか」を判定したり制御したりできない点です*1。HIGは「アプリはマルチタスクの構成を制御できず、ユーザーが選んだ構成についての通知も受け取らない」と明記しており、アプリ側は画面サイズの変化に自動で適応するレイアウト設計が前提になります*1。
整理すると、3つの表示のされ方は次のように特徴が異なります。
| 表示形態 | 画面の使い方 | アプリ側で必要な対応 |
|---|---|---|
| フルスクリーン | 1アプリが全画面を占有*1 | 画面回転・サイズクラスへの追随 |
| ウィンドウ | 複数アプリのウィンドウをリサイズ・配置*1 | ウィンドウサイズの上限・下限の指定*2 |
| Stage Manager | 複数アプリを1つのビューにまとめて操作*8 | ウィンドウリサイズ時のツールバー調整*8 |
複数ウィンドウ対応の要——UIScene・UIWindowSceneによるアプリ側の実装
複数ウィンドウ対応の土台になるのが、UIKitのシーンベースのアーキテクチャです。UIWindowSceneは「アプリのUIを1つ管理するシーン」であり、ウィンドウの表示やユーザー操作に応じたライフサイクルを扱います*4。UIWindowSceneはiOS/iPadOS 13.0以降で利用できます*4。
アプリを複数ウィンドウ対応にするには、Info.plistにUIApplicationSceneManifestを追加し、UIApplicationSupportsMultipleScenesをtrueに設定します*3。この設定は、アプリが2つ以上のシーンを同時に扱えることを示すものです*3。あわせてUISceneDelegateを実装し、scene(_:willConnectTo:options:)でウィンドウの初期設定や状態復元を行います*3。
新規ウィンドウをプログラムから開く場合は、UIApplication.requestSceneSessionActivation(_:userActivity:options:errorHandler:)を呼び出します*3。既存のシーンセッションがあれば前面に呼び出し、なければNSUserActivityを渡して新しいシーンを作成する、という2系統の呼び出し方が用意されています*3。ドラッグ操作で画面端に項目を運んだ際に新規ウィンドウを開く実装も、この仕組みの応用です*3。
ウィンドウサイズへの追随は、UISceneSizeRestrictionsでリサイズ可能なウィンドウの上限・下限のサイズを定義することから始まります*2。ウィンドウのジオメトリが変化したときはUIWindowSceneDelegateのwindowScene(_:didUpdateEffectiveGeometry:)で検知し、geometryのcoordinateSpace.boundsを比較して差分を確認します*2。isInteractivelyResizingプロパティを見れば、ユーザーが今まさにリサイズ中かどうかも判定できます*2。
画面回転についても考慮が必要です。UIViewController側でsetNeedsUpdateOfPrefersInterfaceOrientationLockedを呼び、prefersInterfaceOrientationLockedをtrueで返すと、そのシーンの向きを固定できます*2。ただしシステムがロックの意図と異なる向きに変更する場合もあるため、windowScene(_:didUpdateEffectiveGeometry:)側での監視もあわせて実装します*2。
UITraitCollectionによる環境の把握とAuto Layoutの組み合わせが、この一連の対応の前提になります*2。既存アプリがUIApplicationDelegateだけで画面遷移を管理している場合、UISceneDelegateへのロジック移行そのものが対応工程の中心になることが少なくありません。
アプリ間の情報連携を担うドラッグ&ドロップ——UIDragInteraction・UIDropInteractionの仕組み
iPadのドラッグ&ドロップとは、ユーザーが1つの連続したジェスチャーで、画面上のある場所から別の場所へ項目を移動させる操作を指します*5。同じアプリ内で完結する場合もあれば、片方のアプリで始まり別のアプリで終わる場合もあります*5。iPad向けのアプリ間ドラッグ&ドロップはiOS/iPadOS 11.0から利用でき、iPhoneでアプリをまたぐ操作に対応したのはiOS 15以降です*5。
ビューをドラッグの起点にするにはUIDragInteractionを、ドロップ先にするにはUIDropInteractionを、それぞれ対象のビューに追加します*6*7。UIDragInteractionは「ビューから項目をドラッグできるようにするインタラクションで、ドラッグ項目の提供とドラッグセッションからの呼び出しへの応答をデリゲートに委ねる」と定義されています*6。UIDropInteraction側も同様に、デリゲートを介してオブジェクトの生成とドロップセッションへの応答を担います*7。両クラスともiOS/iPadOS 11.0以降で利用できます*6*7。
実際にやり取りするデータは、UIDragItemとNSItemProvider(受け渡すデータを遅延生成込みで表現する仕組み)の組み合わせで表現します*5。テキストビューやテキストフィールドは標準でドラッグ&ドロップに対応しており、コレクションビューやテーブルビューにも専用のAPIが用意されています*5。特別なエンタイトルメントやInfo.plistの設定は不要で、アプリ間のセキュリティはシステム側が担う設計です*5。
業務アプリでの活用は幅広く考えられます。案件情報を管理するアプリから写真や添付ファイルを別の申請書アプリへドラッグする、あるいは表計算アプリの一部の行を報告書アプリへ直接ドロップする、といった連携です。ドラッグ元のアプリとドロップ先のアプリが両方Split View状態で並んでいる場合はもちろん、ドロップ先のアプリが起動していない状態からでも操作が成立する点も特徴です*5。
ここで注意したいのは、標準UIコンポーネントを使わず独自に描画したカスタムビューでは、ドラッグ&ドロップは自動で有効になりません*6*7。UIDragInteractionDelegate・UIDropInteractionDelegateの実装が必須になるため、対象範囲の広い業務アプリほど改修規模も比例して大きくなります。
現場・営業・医療の業務アプリで見落としやすい落とし穴
マルチタスク対応を軽視すると、業務そのものが止まりかねません。既存アプリがUIApplicationDelegateに画面制御ロジックを集中させている構成では、UISceneDelegateへ移行する過程でシングルトンや共有プロパティへの依存が表面化しやすく、あるウィンドウでの変更が別のウィンドウに反映されない不整合が起こり得ます*3。
現場・営業・医療のように、iPadを片手に複数のアプリを行き来しながら使う業種ほど、この不整合の影響は大きくなります。たとえば点検記録アプリと写真管理アプリを並行して開いている状態で、一方の入力内容が他方の表示に反映されないと、記録の抜け漏れや二重入力につながるおそれがあります。
この作業を内製で担うには、複数領域の知識が要ります。UIKitのシーンベースのライフサイクル、Auto Layoutとサイズクラスへの対応、UIDragInteraction/UIDropInteractionのデリゲート実装、そしてウィンドウごとの状態管理の設計です*2*3*6*7。既存のUIApplicationDelegate中心の実装が古いほど、移行に伴う影響範囲の洗い出しに時間がかかります。
外部ディスプレイやポインタ・キーボード操作への対応も、業務端末としての使い勝手を左右します。Stage Manager導入時にAppleが案内したように、ウィンドウを縮小した際はツールバーの項目が自動でオーバーフローメニューに収まる設計が求められます*8。ボタンやアイコンを固定サイズ・固定位置で作り込んだ画面ほど、ウィンドウリサイズへの追随に手間がかかる傾向があります。
内製と外注の分かれ目——マルチタスク改修をどう判断するか
マルチタスク対応そのものの手順はAppleが公式ドキュメントとして公開しているため、画面数が少なく依存関係が単純なアプリであれば、自社の開発体制で対応できる場合もあります*2*3。判断が分かれるのは、対象画面が多い基幹的な業務アプリや、複数のアプリ間でドラッグ&ドロップ連携を新設するケースです。
専門パートナーに委託する場合は、依頼範囲の広さが選定の分かれ目になります。UISceneへの移行方針の設計からドラッグ&ドロップの実装、Stage Managerやウィンドウモードでの表示検証までを一括して依頼できるかどうかを確認します*1*3。内製で進める場合は、既存の運用担当者が通常業務と並行して対応することになり、複数モードでの検証に割ける時間が限られる場合があります。
。対象画面数やドラッグ&ドロップで連携させたいアプリの範囲によって、必要な工数は変わってきます。現状のアプリ構成を診断したうえで、内製・外注の切り分けを検討することが実務的です。
まとめ：iPadマルチタスク・ドラッグ&ドロップ対応で押さえる3つの判断軸
本稿ではiPad業務アプリのマルチタスク・ドラッグ&ドロップ対応について、Apple公式情報をもとに整理しました。要点は3つに集約できます。第一に、iPadOS 26のマルチタスクはフルスクリーン・ウィンドウ・Stage Managerという3つの表示形態で構成され、アプリ側は自らモードを制御できません*1。第二に、複数ウィンドウ対応はUIScene・UIWindowSceneベースのアーキテクチャが前提で、ドラッグ&ドロップはUIDragInteraction・UIDropInteractionという専用のデリゲート実装が必要です*3*6*7。第三に、既存アプリの画面数や依存関係の複雑さによって改修工数は変わり、内製と外注の判断材料になります。
よくある質問
既存のiPad業務アプリを複数ウィンドウ対応にするには、大規模な作り直しが必要ですか。
画面遷移の管理をUIApplicationDelegateに集中させている構成では、UISceneDelegateへのロジック移行が発生します*3。移行範囲は画面数や共有状態への依存度によって変わるため、まず現状のアーキテクチャを棚卸しすることが最初の一歩になります。
ドラッグ&ドロップは自社アプリと純正アプリの間でも機能しますか。
iPadのドラッグ&ドロップは同じアプリ内だけでなく、別のアプリとの間でも機能する仕組みです*5。ドロップ先のアプリが起動していない状態からでも操作が成立しますが、両アプリともUIDragInteraction・UIDropInteractionを実装している必要があります*6*7。
Stage Managerとウィンドウモードは同時に対応させる必要がありますか。
アプリはどちらのモードで表示されているかを自ら判定・制御できないため、両方の表示形態に自動で追随できるレイアウト設計が前提になります*1。ウィンドウのリサイズに応じてツールバーなどのUIが調整される作りにしておくことが実務上の対応方針になります*8。
外部ディスプレイやキーボードショートカットへの対応も一緒に進めるべきですか。
iPadOS 16以降、拡張ディスプレイのサポートやディスプレイズームによって大きな解像度を活かせるようになりました*8。マルチタスク対応と合わせて検討すると改修範囲が明確になりやすいものの、まずは複数ウィンドウとドラッグ&ドロップへの対応を優先し、段階的に拡張する進め方も選べます。
マルチタスク対応の改修を外部に委託する場合、何を確認すればよいですか。
UISceneへの移行方針の設計からドラッグ&ドロップの実装、複数モードでの表示検証までをどの範囲まで一括して依頼できるかを確認します*3。あわせて、検証環境でフルスクリーン・ウィンドウ・Stage Managerの各モードをどこまで確認してもらえるかを契約前にすり合わせておくと、リリース後のトラブルを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple「Multitasking」（Human Interface Guidelines）（https://developer.apple.com/design/human-interface-guidelines/multitasking）
- *2 出典：Apple「Multitasking on iPad, Mac, and Apple Vision Pro」（Apple Developer Documentation）（https://developer.apple.com/documentation/uikit/multitasking-on-ipad-mac-and-apple-vision-pro）
- *3 出典：Apple「Supporting multiple windows on iPad」（Apple Developer Documentation）（https://developer.apple.com/documentation/UIKit/supporting-multiple-windows-on-ipad）
- *4 出典：Apple「UIWindowScene」（Apple Developer Documentation）（https://developer.apple.com/documentation/uikit/uiwindowscene）
- *5 出典：Apple「Drag and drop」（Apple Developer Documentation）（https://developer.apple.com/documentation/uikit/drag-and-drop）
- *6 出典：Apple「UIDragInteraction」（Apple Developer Documentation）（https://developer.apple.com/documentation/uikit/uidraginteraction）
- *7 出典：Apple「UIDropInteraction」（Apple Developer Documentation）（https://developer.apple.com/documentation/uikit/uidropinteraction）
- *8 出典：Apple「What’s new in iPad app design」（WWDC22セッション）（https://developer.apple.com/videos/play/wwdc2022/10009/）
