iPhone Duo Flutter guide: honest advice for Apple's first foldable

Summary. Flutter apps run on iPhone Duo, but Flutter has no built-in fold awareness on iOS yet: MediaQuery.displayFeatures is populated only on Android, and the proposal to change that (flutter/flutter#192515) is open at P2 with no implementation pull request. How much of the 7.6-inch inner display your app gets depends on the iOS SDK it was built with, and the iOS 27.1 SDK that unlocks the full screen has not shipped. The practical move today is width-driven responsive layout plus a UIScene migration, with a native hinge bridge only if your product needs one.

Apple's first foldable iPhone is real, it has a name, and it goes on sale next month. If you write Flutter, the honest starting point is the gap, before any feature list. Native iOS developers have a documented, first-party path for building on this device. Flutter developers do not yet have an equivalent built into the framework. This guide covers what exists, what is missing, where Apple's own guidance overturns the usual advice, and what a Flutter team should do this month.

iPhone Duo specs and dates Flutter developers need

Apple announced iPhone Duo, which it calls the first foldable iPhone, on 9 September 2026, alongside iPhone 18 Pro and iPhone 18 Pro Max. Pre-orders open on Friday 16 October, and the device goes on sale on Friday 23 October in more than 70 countries and regions, with 28 more following on 30 October. It starts at $1,999 in the US and ships with iOS 27.1.

The device folds like a book. Closed, you use a 5.4-inch outer display; open, you get a 7.6-inch inner display, the largest display Apple has put on an iPhone. Apple rounds both figures: measured as rectangles, they are 5.36 and 7.58 inches. Both displays share the same aspect ratio, and Apple's developer talks show the open inner display used in both portrait and landscape, so an app should never assume the open device is held one way. For how Apple's published figures compare with early spec sheets, see our iPhone Duo spec sheet breakdown.

This is a shipping product with dedicated SDK support on the way, so Flutter teams can start planning now.

What Apple shipped for iPhone Duo developers

On 9 September Apple published a structured developer programme for the device, which now lists six tech talks, Group Labs and Q&As on the Apple Developer Forums. It is worth knowing its shape even if you never write Swift, because it is the surface any Flutter bridge will eventually target.

The iPhone Duo toolchain has not shipped yet

The toolchain is Xcode 27.1 with the iOS 27.1 SDK, and as of 18 September neither is available, not even as a beta. On 16 September Apple said Xcode 27.1 will add iPhone Duo support, including updated SDKs and a simulator with the new poses, and that a beta will arrive later in September.

The tools you can download today, Xcode 27 and the Xcode 27.2 beta, include neither the iPhone Duo SDK nor its simulator, and Apple's documentation marks every Duo-specific API as iOS 27.1 Beta. Nobody outside Apple can compile against these APIs yet, and that includes every Flutter plugin author.

Hinge APIs are for effects, not layout

SwiftUI's onHingeChange modifier and UIKit's UIHingeInteraction report the same information: a discrete status (closed, partially open or fully open, with an extra unknown case in UIKit) plus continuous angle updates as the device folds. UIKit reports the angle in radians, Apple treats the update rate and precision as system policy, and the hinge value is nil on a device without a hinge or, in UIKit, when the view leaves a hierarchy that provides hinge updates.

A common assumption is that the hinge angle is how apps reflow content through the fold. Apple says the opposite. Hinge data is meant for interactions and effects (Apple's example is a guitar whammy bar driven by the angle), and layout should come from the arrangement and reserved-region APIs. That distinction decides what a Flutter team should bridge first.

Reserved regions, arrangements and safe areas

The layout side of Apple's guidance rests on size classes, standard containers, safe areas and two new tools.

• Reserved regions come in two kinds. A division region splits content, as the fold does; it is active only when the device is folded and has zero width when the device lies flat. An occlusion region marks an area covered by the Dynamic Island, a camera or window controls; on iPhone Duo the inner FaceTime camera is one, active only while the camera is on. SwiftUI exposes ReservedRegion through GeometryProxy.reservedRegions(kind:options:layoutDirectionBehavior:), and UIKit exposes UIView.ReservedRegion (UIViewReservedRegion in Objective-C) through UIView.reservedRegions(kind:options:). Apple suggests adopting them only where needed: for your highest-priority hand-positioned controls, custom bars or edge-to-edge UI. Standard containers handle the fold for free.

• Arrangements structure two-view layouts. SwiftUI has ArrangementView, and UIKit has a counterpart, UIArrangementViewController. There are two built-in arrangements: split (for example .split.axes(.horizontal)), which is the default, and overlay, which layers views and can turn side by side when the device folds. Apple warns against putting navigation containers inside an ArrangementView, or an ArrangementView inside a List or ScrollView.

• Safe areas get no new API, but they are often asymmetric on iPhone Duo: vertical bars can sit on the left in landscape and in Split View, and the outer display's camera is always present. Handle each inset on its own and never assume opposite sides match.

Our ArrangementView and reserved regions deep dive covers the native side in more detail.

Two smaller points matter for Flutter plugin code. Apple says UIScreen.main is ambiguous on a two-display device and will be deprecated, so native code should read the trait collection, scene bounds or windowScene.screen instead. And system bars go vertical only when a navigation container manages them; custom-built bars stay where they are. Flutter draws its own AppBar and navigation bars, so they will not get the native vertical layout, and handling asymmetric safe areas correctly becomes your job.

Device Hub and the iPhone Duo simulator

Device Hub is the Xcode 27 window where simulators and physical devices are managed and where a running simulator's screen appears. Folding itself is simulated by the iPhone Duo simulator in Xcode 27.1, which runs inside Device Hub with on-screen controls to open, close, rotate or fold the device. That simulator ships with the Xcode 27.1 beta, which is not out yet.

The iPhone Duo layout rule: size class, not orientation

If one instruction from Apple's guidance is worth absorbing first, it is this: adapt by size class, not by orientation. The inner display does not honour an app's supported interface orientations, so any code that branches on portrait versus landscape to decide layout is using the wrong signal on this device. The inner display is regular in both width and height, while the outer display behaves like any other iPhone: compact width and regular height in portrait, compact in both in landscape.

Apple adds a nuance in the same talk, saying iPhone Duo respects your supported orientations but your app will scale on the inner display, including in Split View. Either way, orientation is not a layout signal here.

The payoff for native apps is real. Apple says NavigationSplitView and UISplitViewController, and TabView and UITabBarController, adapt across every pose without extra layout code: columns collapse when the device is closed and tile or overlay when it is open. Tabs can opt into a sidebar on the inner display, sheets, popovers, menus and alerts adapt, and when the device is folded the system keeps both split-view columns visible in an even 50/50 split.

Two more rules widen this beyond folding. Every app takes part in multitasking on iPhone Duo: two apps can sit side by side on the inner display, there is a stacked video-plus-app layout, and apps cannot opt out. And iPhone Duo honours UIRequiresFullScreen, but the app still resizes when someone opens or closes the device. So a Flutter app will receive half-width and odd-shaped windows even if your team never thinks about the fold. Our note on iOS 27.1 Split View and UI changes covers what users will see.

Flutter's own guidance already points the same way. Its adaptive-design best practices say not to lock orientation, to avoid orientation-based layouts, and to read size with MediaQuery.sizeOf(context) or local constraints with LayoutBuilder.

Which iOS SDK your Flutter app is built with decides how much screen it gets

This is the point most early coverage misses. An existing Flutter binary runs on iPhone Duo, because Apple says apps work even if they were not built with the iOS 27 SDK. What changes is how much of the screen they get, and that depends on the SDK the app was built with.

For a Flutter team, the consequence is that the stretched single-column layout on a 7.6-inch screen is a problem you meet in full only after rebuilding with Xcode 27.1. Until then, an app built with today's toolchain runs in a smaller presentation. flutter build ios uses whichever Xcode is selected, so run xcode-select -p and xcrun --sdk iphoneos --show-sdk-version before assuming which tier a build lands in. For the native checklist, see our iOS 27.1 SDK readiness checklist.

Rebuilding with Xcode 27 means adopting UIScene

"Runs without modification" stops being true the moment you rebuild. With the iOS 27 SDK, Apple requires the scene-based life cycle, and apps that have not adopted it fail to launch. Flutter's migration guide says the same of Flutter apps built with Xcode 27. The iOS 27 SDK also requires a launch screen, and Xcode 27 raises the minimum deployment target to iOS 15. Standard Flutter templates already include a launch storyboard, but custom setups should check.

Flutter's migration path depends on how far your iOS project has drifted from the template:

• Flutter 3.38 added UIScene support. From 3.41, UIScene is the default, and flutter run or flutter build ios migrates an unmodified AppDelegate automatically and reports when the migration has finished.

• A customised AppDelegate needs the manual steps: conform it to FlutterImplicitEngineDelegate, move GeneratedPluginRegistrant.register (plus any method channels or platform views) into didInitializeImplicitFlutterEngine, and add a UIApplicationSceneManifest entry to Info.plist whose UISceneDelegateClassName is FlutterSceneDelegate.

• Plugins adopt FlutterSceneLifeCycleDelegate and call registrar.addSceneDelegate(instance), which needs Flutter 3.38 or later.

Stay on the current stable release, Flutter 3.47.4 (11 September 2026, Dart 3.13.3). Flutter 3.47.0 added Device Hub simulator support and fixed Xcode 27 lipo verification, and the 3.47.2 hotfix fixed Xcode 27 Swift Package Manager builds for add-to-app projects.

There is also a hard deadline: from April 2027, App Store uploads of iOS apps must be built with the iOS 27 SDK or later. If debugging on the new toolchain misbehaves, our fix for mprotect failed: 13 on iOS 26 and 27 may save you an afternoon.

Does Flutter support iPhone Duo?

Flutter apps run on iPhone Duo, but the framework cannot tell that the device is folding. It has no built-in way to read fold posture, crease position or hinge angle on iOS, no official iPhone Duo package, and no committed date for either. Everything fold-aware today comes from custom native code or unvalidated community plugins.

Flutter's fold awareness runs through displayFeatures, a property of MediaQueryData in the widgets library that you read with MediaQuery.displayFeaturesOf(context). The data underneath comes from dart:ui, through FlutterView.displayFeatures and the DisplayFeature class. The API documentation is blunt: "This list is populated only on Android."

On iOS, including iPhone Duo, the list stays empty however the device is folded. No retail device has shipped yet, so this has not been observed on hardware, but nothing in the framework would populate it.

The open proposal: flutter/flutter#192515

A proposal to change this exists as issue #192515 in the flutter/flutter repository, titled "Proposal: populate MediaQuery.displayFeatures on iOS for iPhone Duo (foldable)". It was filed on 9 September at 22:05 UTC, within hours of the announcement. The Flutter engine now lives inside the flutter/flutter monorepo, so the issue carries the engine label; the old standalone engine repository is archived.

As of 18 September the issue is open and triaged, labelled platform-ios, engine, c: proposal, P2, fyi-framework and team-ios. It has one comment and no linked implementation pull request. It is a community proposal from an external contributor. The Flutter team has made no roadmap commitment to it.

Its author was explicit about why it is a proposal and not code: they could not build or test the engine change and did not want to submit changes they could not verify. They also noted that the iOS API signatures came from Apple's tech talks rather than shipped headers and had not been checked against the SDK.

The only comment so far matters for anyone planning a bridge. Its author tested what the framework would do if iOS did populate displayFeatures: Flutter's DisplayFeatureSubScreen would confine every AlertDialog, bottom sheet and date picker to roughly 47% of the inner display. The comment also found that the proposed mapping of the camera occlusion to a cutout with a half-opened posture would trip a dart:ui assert, and that none of the new iOS names exist in the iOS 26.1 SDK headers.

A related bug, flutter/flutter#192667, shows MediaQuery.sizeOf reporting the whole screen inside a dialog confined to one half of a foldable. A broader proposal for built-in split-view support, #189554, is open at P3.

None of this is a criticism of the Flutter team or the community. A proposal filed within a day of a brand-new device's announcement, still open with no implementation PR nine days later and with the SDK it depends on unreleased, is a normal timeline. It is the accurate state of things, and worth stating plainly.

Flutter packages for iPhone Duo compared

No package is production-validated yet. These are the main options as of 18 September 2026:

Microsoft's dual_screen was built for Surface Duo. Its pure-Dart TwoPane widget runs on any platform, but it relies on display features that only Android populates, so its fold awareness was Android-only in practice. Its repository is not archived, though recent activity is CI housekeeping.

The foldable package, which Berkay Çatak introduced in a Medium post on 14 September, deliberately leaves its MediaQuery.displayFeatures bridge off by default to avoid the half-screen dialog problem described above. iphone_duo_layout is unusually candid about its state, and notes that Xcode 26.4 cannot compile the APIs it references.

What Flutter developers can use on iPhone Duo today

Given that gap, here is what a Flutter team can rely on when the device reaches customers, from safest to riskiest:

For most apps the second row is the right answer this month. It helps on iPhone Duo, Android foldables and tablets, and none of it is wasted if Flutter later adds fold support. The Android payoff is immediate, because Flutter's foldable support already works on Android, where devices report display features today.

How to adapt a Flutter layout for iPhone Duo

Translated out of Apple's native vocabulary, "adapt your app" means three concrete things for a Flutter team.

First, stop making layout decisions from orientation or fixed aspect ratios. Build against available width and height, with LayoutBuilder for local constraints or MediaQuery.sizeOf(context) for the whole window. Flutter's large-screen guidance adds a warning worth taking seriously: locking orientation can leave an app letterboxed on Android foldables, because MediaQuery never receives the larger window size. Because the inner display does not honour supported orientations, do not rely on SystemChrome.setPreferredOrientations to hold a layout steady there either.

Second, design the large layout as two panes where the content suits it, such as list and detail or sidebar and content, rather than a single column stretched across 7.6 inches. That is the failure Apple's multi-column containers exist to prevent.

Third, treat the fold as a physical constraint, on Apple's terms. Apple does not recommend a permanent gap down the middle. The fold's division region is active only when the device is folded, and has zero width when flat. Apple's advice is to move content away from the fold only when folded, never to displace scrolling content such as articles, feeds and lists, and to prefer even column counts in grids.

Without a native bridge, a Flutter app cannot know when the device is folded, so the cheapest approximation is structural: split wide layouts into two equal panes so the boundary between them sits on the vertical centre line, and keep interactive controls away from that boundary. That line matches the fold only when the device is held like a book; propped up on a table, the fold runs across the middle, and Apple suggests the top region for viewing and the bottom for controls.

            import 'package:flutter/material.dart';

/// One pane on narrow windows, two equal panes on wide ones.
/// Equal widths keep the pane boundary near the vertical centre line,
/// where the fold sits when the open iPhone Duo is held like a book.
class AdaptiveTwoPane extends StatelessWidget {
  const AdaptiveTwoPane({
    super.key,
    required this.primary,
    required this.secondary,
    this.breakpoint = 600, // tune to your content
    this.gutter = 24,
  });

  final Widget primary;
  final Widget secondary;
  final double breakpoint;
  final double gutter;

  @override
  Widget build(BuildContext context) {
    return SafeArea(
      child: LayoutBuilder(
        builder: (context, constraints) {
          if (constraints.maxWidth < breakpoint) {
            return primary; // outer display, Split View pane, narrow window
          }
          return Row(
            children: [
              Expanded(child: primary),
              SizedBox(width: gutter), // keeps controls off the centre line
              Expanded(child: secondary),
            ],
          );
        },
      ),
    );
  }
}
          

SafeArea applies each inset separately, which is what asymmetric safe areas need. If you pad by hand, read MediaQuery.paddingOf(context) and use each edge on its own; EdgeInsets.symmetric built from one side goes wrong when a vertical bar or camera sits on only one side. Read sizes in build rather than caching them in State, because the window changes size when the device opens, closes or enters Split View.

Three quick searches find most of the risky code:

            grep -rni "orientation" lib/
grep -rn "EdgeInsets.symmetric" lib/
grep -rn "UIScreen.main" ios/
          

The first command finds orientation-driven layout and orientation locks, the second finds insets that assume left equals right, and the third finds native code reading the ambiguous main screen. Run the third against the native code of any plugins you maintain as well.

How to read the iPhone Duo hinge angle in Flutter

Start with Apple's rule: use the hinge for interactions and effects, and take layout from reserved regions and arrangements. If your product has a genuine hinge-driven interaction, in the spirit of Apple's whammy-bar example, a custom bridge is the documented route. Flutter documents platform channels, with MethodChannel for calls, and the Pigeon package for type-safe generated bindings. For continuous streams such as hinge updates, use an EventChannel.

The Dart side is small:

            import 'package:flutter/services.dart';

/// Dart side of a custom hinge bridge. The channel name is yours;
/// the native side sends maps like {'status': 'partiallyOpen', 'angle': 1.2}.
class HingeUpdate {
  const HingeUpdate(this.status, this.angleRadians);

  final String status; // closed, partiallyOpen, fullyOpen or unknown
  final double? angleRadians; // null when the device has no hinge
}

const EventChannel _hingeChannel = EventChannel('com.example.app/hinge');

Stream<HingeUpdate> hingeUpdates() {
  return _hingeChannel.receiveBroadcastStream().map((dynamic event) {
    final data = Map<String, Object?>.from(event as Map);
    return HingeUpdate(
      data['status'] as String? ?? 'unknown',
      (data['angle'] as num?)?.toDouble(),
    );
  });
}
          

On the native side, register an event channel with the same name (inside didInitializeImplicitFlutterEngine once you have migrated to UIScene), attach a UIHingeInteraction to the Flutter view, and forward each status change and angle as a map. Base decisions on the status rather than the angle, and throttle angle updates, because Apple does not guarantee their rate or precision.

For fold-aware layout, bridge UIView.reservedRegions(kind: .division) instead, which returns the fold's frame, and expose the occlusion kind as well so the inner camera region is covered. onHingeChange is a SwiftUI modifier and a poor fit for Flutter's UIKit-hosted engine.

Two cautions apply. The native half cannot compile against these APIs until the Xcode 27.1 beta ships; the foldable package works around that with Objective-C runtime lookups. And do not feed your bridge's fold data into MediaQuery.displayFeatures, because that triggers the DisplayFeatureSubScreen behaviour that squeezes dialogs, sheets and pickers into half the screen. Publish it through your own inherited widget or state object instead, which is the approach foldable takes by default.

How to test a Flutter app for iPhone Duo before you have the device

You can cover most of the risk before the hardware or the Duo simulator arrives. Start with widget tests at several window sizes. tester.view.physicalSize and tester.view.devicePixelRatio render a test at any size, and tester.view.displayFeatures can simulate a fold, which is how the #192667 bug report reproduces the half-screen dialog behaviour. Cover a narrow width, a wide width and a half-width Split View pane.

            import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
// import 'package:your_app/adaptive_two_pane.dart';

void main() {
  testWidgets('one pane when narrow, two when wide', (tester) async {
    tester.view.devicePixelRatio = 1.0;
    addTearDown(tester.view.reset);

    for (final width in <double>[400, 900]) { // illustrative widths
      tester.view.physicalSize = Size(width, 800);
      await tester.pumpWidget(const MaterialApp(
        home: AdaptiveTwoPane(
          primary: Text('list'),
          secondary: Text('detail'),
        ),
      ));
      expect(find.text('detail'), width >= 600 ? findsOneWidget : findsNothing);
    }
  });
}
          

Then move up to Xcode:

1. Device Hub resize mode in Xcode 27. It resizes a running app today, but Apple lists it as unsupported for apps linked against the iOS 26 SDK or earlier, so build with the iOS 27 SDK first.

1. The iPhone Duo simulator, once the Xcode 27.1 beta lands. Choose the iPhone Duo simulator in Device Hub and use its controls to open, close, rotate and fold the device. Flutter needs no tool of its own here, because Flutter 3.47.0 launches Device Hub for the iOS simulator on Xcode 27 and later. Teams on older Flutter versions can hit a bug where flutter devices does not list simulators on Xcode 27.

1. Split View checks. Put the app beside another app and in the stacked layout, and confirm nothing depends on the window being full width.

Nobody has publicly confirmed flutter run against the iPhone Duo simulator yet, because the simulator is not available.

A Flutter team's iPhone Duo readiness plan

For most teams, the sensible sequence looks like this:

1. Update the toolchain. Move to the current Flutter stable (3.47.4) and Xcode 27, and adopt the UIScene life cycle using Flutter's migration guide. Check the launch screen and the iOS 15 deployment target.

1. Audit layout code. Remove orientation checks, fixed-width and fixed-aspect assumptions, sizes cached in State and symmetric insets. This improves your app on Android foldables and tablets too, not only on iPhone Duo.

1. Build two-pane layouts where content suits them, driven by LayoutBuilder breakpoints and covered by widget tests at several sizes.

1. Audit native plugin code for UIScreen.main, and check that any plugin opening new scenes handles failure on the outer display, where new windows cannot be created.

1. Rebuild with the iOS 27.1 SDK when Xcode 27.1 ships, then test every pose in the iPhone Duo simulator. This is the build where your app first fills the inner display.

1. Decide whether fold awareness earns its cost. Treat the hinge as an effects feature. Try the community plugins in a throwaway branch to learn the likely API shape, but keep them out of user-facing production until they have compilation and device validation behind them.

1. Track flutter/flutter#192515 directly rather than secondhand summaries, since its status is the clearest signal of when built-in support will land.

If you need to budget this work, our guide to iPhone Duo app support costs covers how that work is scoped and priced.

What to watch next for Flutter on iPhone Duo

Four things are worth checking over the coming weeks:

• whether #192515 picks up an implementation pull request now that the hardware is close to shipping;

• when the Xcode 27.1 beta, and then the final iOS 27.1 SDK, arrive, which fixes the native API surface any Flutter bridge must target;

• whether a community plugin moves from syntax checks and runtime lookups to real compilation and device validation;

• whether anyone confirms flutter run against the iPhone Duo simulator.

Any one of these moving meaningfully changes what Flutter guidance for iPhone Duo should say next.

The bottom line

The honest state of iPhone Duo for Flutter developers is day one of a new hardware category, with the framework still catching up. Cross-platform frameworks usually start behind a platform vendor's own tooling on brand-new hardware, and Flutter is no exception. The teams that get ahead will treat responsive, size-driven layout as table stakes today, and build the fold-specific bridge themselves only if their product needs it before Flutter does.

For the native side of the same device, including every new SwiftUI, UIKit and camera API Apple has documented, see our iPhone Duo SDK guide.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. For Flutter teams preparing for iPhone Duo, we run responsive layout audits that remove orientation logic and asymmetric-inset bugs, rebuild apps against the iOS 27 SDK with the UIScene migration, and, once the iOS 27.1 SDK ships, move apps onto it and build and validate native hinge and reserved-region bridges. You can hire Flutter developers for a focused sprint or work with our foldable and large-screen app development team. Talk to us at /contact-us/.

Last updated: 18 September 2026.

References

1. Apple unveils iPhone Duo — Apple Newsroom

1. Raise the bar with iPhone Duo — Apple Developer

1. Latest News — Apple Developer

1. Multiple displays and scenes on iPhone Duo (tech talk 111464) — Apple Developer

1. Strike a pose with adaptive layouts on iPhone Duo — Apple Developer

1. Prepare your app for iPhone Duo — Apple Developer

1. Best practices for adaptive design — Flutter documentation

1. iOS & iPadOS 27 Release Notes — Apple Developer Documentation

1. UIScene adoption — Flutter documentation

1. Flutter 3.47.0 release notes — Flutter documentation

1. displayFeatures property, MediaQueryData class — Flutter API reference

1. Proposal: populate MediaQuery.displayFeatures on iOS for iPhone Duo (foldable), issue #192515 — GitHub, flutter/flutter

1. dual_screen — pub.dev

1. berkaycatak/foldable — GitHub

1. samchancanada1/iphone_duo_layout — GitHub

1. Large screen devices — Flutter documentation

1. Writing custom platform-specific code — Flutter documentation

1. Xcode 27 Release Notes — Apple Developer Documentation