Xcode 27.1 Beta: Your App in the iPhone Duo Simulator

Xcode 27.1 beta (27A9269) shipped on Friday, September 18, 2026 with the first iOS 27.1 SDK and an iPhone Duo device type for the simulator, four days after Xcode 27.0. The SDK carries every iPhone Duo API that Apple’s preparation guide names, the device type’s profile defines the two displays at 1398 by 2034 and 2007 by 2853 pixels at 3x, which is 466 by 678 and 669 by 951 points, and the simulator runtime is a separate download that Xcode fetches on demand. Apple’s own notes list three things the simulator cannot do yet, and a probe app linked against the 27.1 SDK and run in Device Hub’s three poses fills a 466 by 678 point display closed, with its bars down the trailing edge, and a 951 by 669 one open, regular in both size classes there, with the fold reported as a division and the camera and status column as occlusions, and with UIScreen.main still answering for the outer display while the app is on the inner one. (Corrected October 2: until then this paragraph said the probe saw no reserved regions; that probe had been linked as an iOS 27.0 app.)^1245613

TL;DR

• Dates and builds. Apple’s releases feed dates Xcode 27.1 beta (27A9269) to Friday, September 18. xcodebuild -version prints Xcode 27.1 and Build version 27A9269; the iPhoneOS and iPhoneSimulator SDKs both identify as iOS 27.1 build 24A94403; the Swift compiler reports the same swiftlang-6.4.0.34.1 version string as Xcode 27.0 and the linker the same ld-27037.1. The xip is 2,027,292,809 bytes and the expanded app is 3.6 GiB, and it installs next to Xcode 27.0 without replacing it.¹⁴ (October 11: Xcode 27.1 RC (27A9275) followed on October 5, and App Store Connect takes its builds for the App Store as well as TestFlight.¹⁴)
• The Duo APIs are in the SDK. The ten names my September 17 check could not find in the 27.0 SDK are all present in the 27.1 SDK, among them ArrangementView and reservedRegions(kind:options:layoutDirectionBehavior:) in SwiftUICore, toolbarVerticalBehavior(_:) in SwiftUI, and UIArrangementViewController, preferredVerticalBarBehavior, and verticalBarEdge in UIKit. SwiftUI marks them @available(anyAppleOS 27.1, *); UIKit’s headers mark the arrangement controller and the reserved-region methods API_AVAILABLE(ios(27.1), tvos(27.1), visionos(27.1)), two platforms more than the documentation pages list.⁴
• The simulator profile writes the display sizes down. The iPhone Duo device type (iPhone19,4, product class V68, model number A3447) defines two integrated displays: primary at 1398 by 2034 pixels, scale 3, and primary-1 at 2007 by 2853 pixels, scale 3, with a native orientation of 270. Divided by three those are 466 by 678 and 669 by 951 points, the inner figure being the number my Duo developer post inferred from App Store Connect’s screenshot size on September 10. The profile requires runtime 27.1 or later.⁵
• What the simulator does with a real app (corrected October 2). Device Hub exposes three poses, Closed, Book, and Open, plus Rotate Right. A probe linked against the 27.1 SDK gets the whole outer display when closed, 466 by 678 points, compact width, with its toolbar and tab bar standing on the trailing edge, toolbarVerticalEdge reading trailing, and two active occlusion regions, the camera and the status column. Open, it gets the whole inner display, a landscape-native 951 by 669 points, regular in both size classes, vertical bars again, and an inactive division 40 points wide down the middle that turns active in the Book pose; turned, 669 by 951 with horizontal bars. UIScreen.main.bounds keeps reporting 466 by 678 while the app is on the inner display. Until October 2 this bullet gave the display sizes, 466 by 678 and 951 by 669, with safe-area insets of 34 on each side open, a horizontal toolbar, and no reserved regions in any pose; the body gave the area the probe measured, 80 points narrower than the display (386 points closed, 803 inside 34-point insets open). All of it came from a probe that had been linked as an iOS 27.0 app by mistake: it is what the 27.0 SDK gets, and the update below has both builds.⁶¹²¹³
• What the beta cannot do yet. Apple’s notes: “Initial Simulator launch can take several minutes.” (187708500), “StandBy is unavailable in the iPhone Duo Simulator runtime.” (187708663), and “Running and debugging most app extensions is unavailable in the iPhone Duo Simulator runtime.” (187708767). Add two Mac Catalyst Known Issues for anyone whose app also ships on the Mac, and one thing Apple does not list: the runtime download failed on my first attempt with Download failed. and succeeded on retry.²³

Update, October 2: the September probe was linked as an iOS 27.0 app

The simulator results this post carried from September 21 to October 2 were measured correctly and described wrongly. They are what the iPhone Duo simulator does with an app built against the iOS 27.0 SDK. I presented them as what it does with an app built against 27.1.

What went wrong. The probe was a single Swift file compiled by calling swiftc -sdk <iPhoneSimulator27.1.sdk> directly. That flag reaches the compiler. It does not reach the link step, where the driver fell back to the macOS SDK inside the same Xcode and recorded that SDK’s version in the binary: LC_BUILD_VERSION read sdk 27.0. iOS decides which behaviors an app gets from that number. Run again on October 2, the same command prints the cause as a warning, “using sysroot for ‘macOS 27.0’ but targeting ‘arm64-apple-ios27.1.0-simulator’”; if it printed that in September, I did not read it as the cause of anything.¹³

How it surfaced. On October 2 I ran a real app, built by Xcode 27.1 beta with the same SDK, on the same simulator. Its toolbar and tab bar stood down the side of the outer display where the probe’s had lain across the top. otool -l on the two binaries showed sdk 27.1 on the app and sdk 27.0 on a probe rebuilt the September way. Rebuilt with SDKROOT set, the probe reads sdk 27.1 and behaves like the app. And a plain version of the probe compiled by Xcode 27.0 itself, against the real iOS 27.0 SDK, gets the same windows the mis-stamped one got, so the September numbers are a fair picture of a 27.0 build.¹³

The re-run. The same source, linked both ways, in each pose, on the same Xcode 27.1 beta (27A9269) and runtime (24A94401):¹³

What is withdrawn. Three statements, each of which was true of the 27.0 build and false of a build stamped 27.1: that the toolbar never drew vertically; that reservedRegions returned nothing in any pose; and that the simulator gave the app only the screen beside the status rail. A fourth was wrong about the reason: I wrote that the split arrangement “stays side by side even though the container is now taller than it is wide” when turned. The arrangement view in the probe was itself wider than tall inside that screen, and it splits by its own shape; an arrangement that fills the turned display stacks, as Apple’s guide says it will. A fifth: the TL;DR gave the display sizes, 466 by 678 and 951 by 669, where the body gave the area the probe measured, 80 points narrower (386 points closed, 803 inside 34-point insets open); the 27.0 build never had the whole display.⁷¹³

What stands. Everything outside the simulator section: the dates and builds, the SDK symbol table, the device profile and its pixel and point sizes, the runtime download, Apple’s Known Issues. Inside it: the display sizes, the size classes, the poses Device Hub offers, the screenConfig crash, and the UIScreen.main trap, which the re-run reproduced under the 27.1 stamp. The September 24 note that this update replaces guessed that the zeros came from reading the regions too early, and promised a re-run at several hinge angles. The guess was wrong: the 27.0 build returns none however long it asks. The observation it quoted from Molzahn holds: the correctly linked probe read no regions on its first six to nine evaluations and all of them after that. The hinge-angle runs were not made.¹²¹³

If you built a probe of your own from this post, check it: otool -l <app>/<binary> | grep -A4 LC_BUILD_VERSION. A project built by Xcode is stamped correctly. A file compiled by hand needs SDKROOT exported to the simulator SDK before swiftc runs. The worked example that turned this up has the three-way comparison, with an iOS 26 stamp as well.

What is in the beta?

Apple’s releases feed lists “Xcode 27.1 beta (27A9269)” on Friday, September 18 at 10:00 a.m. PT and a “TestFlight Update” the same afternoon; App Store Connect’s release notes for that day say “You can now submit apps built with Xcode 27.1 beta using the SDK for iOS 27.1 beta or iPadOS 27.1 beta for internal and external testing.”¹ The release notes’ Overview names the SDK line: “Xcode 27.1 beta includes Swift 6.4 and SDKs for iOS 27.1, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27. Xcode 27.1 beta supports on-device debugging in iOS 17 and later, tvOS 17 and later, watchOS 10 and later, and visionOS. Xcode 27.1 beta requires a Mac running macOS Tahoe 26.6 or later.”² Read that list as written: iOS is the only platform at 27.1, the SDK’s own SDKSettings.plist reports version 27.1, and App Store Connect calls the same SDK “iPadOS 27.1 beta,” a wrinkle the Xcode 27 post carries.

The download is smaller than the version number suggests. The xip is 2,027,292,809 bytes, Apple-signed under its Software Update certificate, and expands to a 3.6 GiB app, the same size as Xcode 27.0; xip --expand into a folder, a rename to /Applications/Xcode-27.1-beta.app, and DEVELOPER_DIR pointed at it is the whole install for command-line work. The first xcodebuild call under the beta then spent about two minutes installing the bundled CoreTypes.pkg and XcodeSystemResources.pkg on its own, the step xcodebuild -runFirstLaunch performs explicitly, and the second of those packages is what puts the iPhone Duo device type in place.⁴ What the app does not contain is a simulator runtime. The beta finds the iOS runtimes already on this Mac, 27.0 among them, and none for 27.1; xcodebuild -downloadPlatform iOS under the beta names the missing piece as “iOS 27.1 Simulator (24A94401)” and fetches it as a cryptex disk image through Apple’s mobile-asset service, while the developer downloads page’s own disk images stop at the iOS 18.2 Simulator Runtime.³⁴ The first attempt ended in DVTDownloadable: Download Failed with Error Domain=DVTDownloadableErrorDomain Code=41 "Download failed."; the second, with -buildVersion 24A94401, reported the runtime as 7.85 GB, finished, and simctl list runtimes then listed “iOS 27.1 (27.1 - 24A94401)”. Budget the disk for it: the runtime is four times the size of the Xcode download.³

The outer display of the iPhone Duo simulator on first boot, 1398 by 2034 pixels: the status cluster runs down the right edge, the side where Apple’s Human Interface Guidelines put the Dynamic Island and the status bar on iPhone Duo.¹⁰

How do you get the iPhone Duo simulator?

Three steps, and none of them is a download button on a web page. Apple ships the simulator only inside Xcode, and only inside the 27.1 beta: the 27.2 beta notes carry an aside that says “Download Xcode 27.1 beta to get the iOS SDK and simulator support for iPhone Duo.”⁸ (October 11: Xcode 27.1 RC (27A9275) shipped October 5, and its notes list the same iPhone Duo Simulator known issues, so the beta is no longer the only Xcode 27.1 whose notes cover the Duo simulator; I have not installed the RC.¹⁴)

1. Xcode 27.1 beta (27A9269) from the developer downloads, dated Friday, September 18 in Apple’s releases feed. Expand the xip, move the app to a versioned name such as /Applications/Xcode-27.1-beta.app beside Xcode 27.0, and point DEVELOPER_DIR at it for command-line work; the beta requires macOS Tahoe 26.6 or later.¹²
2. The iOS 27.1 runtime, which the xip does not contain. Run xcodebuild -downloadPlatform iOS with DEVELOPER_DIR set to the beta; it fetches the 27.1 runtime that makes the iPhone Duo device type bootable, and Apple’s notes warn that the first Simulator launch “can take several minutes” on top of the download. My first attempt failed and the retry worked, so retry before diagnosing.²³
3. Device Hub, where the device and its poses live. Add or select the iPhone Duo device, boot it, and use the pose buttons, Closed, Book, and Open, plus Rotate Right; simctl has no pose command. The per-pose sizes and screenshots below come from that path.⁶

There is no browser version from Apple. A page found under “iPhone Duo simulator online” is not running Apple’s iOS 27.1 runtime, so whatever it draws, it is not the source of the size classes, the reserved regions, or the outer-display behavior measured here; for a layout check without the runtime, Xcode’s Previews canvas gained a Display group in this beta for the alternative display.²

Does the 27.1 SDK have the Duo APIs?

On September 17 I searched the iOS 27.0 SDK for the names in Apple’s “Preparing your app for iPhone Duo” guide and found none of the ten that are specific to the device. The same search against the 27.1 SDK, run the same way, a plain text search of the module interfaces and headers, finds all of them. The rows are the substrings searched: seven of them carry nine of the ten names, the two reservedRegions methods and the two axisBehavior members each sharing a row, and the other three are the types behind the names, ReservedRegion, ToolbarVerticalBehavior for toolbarVerticalBehavior(_:), and UIVerticalBarBehavior for preferredVerticalBarBehavior:⁴

Two details in that table matter for how you write the code. The SwiftUI types live in SwiftUICore, the module that import SwiftUI re-exports, so an ordinary import finds them; and the availability attributes disagree with the documentation about platforms. The SwiftUICore interface declares ArrangementView, and the SwiftUI interface declares toolbarVerticalBehavior(_:), both under @available(anyAppleOS 27.1, *), which is Apple’s shorthand for every platform at that version, while UIArrangementViewController.h and the reservedRegionsOfKind: methods in UIView.h carry API_AVAILABLE(ios(27.1), tvos(27.1), visionos(27.1)) with API_UNAVAILABLE(watchos); in UIVerticalBarEdge.h the enum and the verticalBarEdge trait carry that same pair while the Leading and Trailing cases carry API_AVAILABLE(ios(27.1)) API_UNAVAILABLE(visionos) API_UNAVAILABLE(watchos, tvos). Apple’s documentation pages for all five list only iOS 27.1 and iPadOS 27.1, marked beta.⁴⁷ Write against iOS and let the compiler tell you about the rest.

The three names the guide uses that were already in the 27.0 SDK are unchanged: presentationPlacement(_:) still sits under @available(anyAppleOS 27.0, *), backgroundExtensionEffect() is still there from iOS 26, and of the two ToolbarItemPlacement cases the guide names, topBarPinnedTrailing sits under @available(iOS 27.0, visionOS 27.0, *) and cancellationAction carries no availability of its own beyond the type’s.⁴

What does the simulator profile say about the two displays?

The device type Apple installs for the beta, iPhone Duo.simdevicetype, is a plain bundle under /Library/Developer/CoreSimulator/Profiles/DeviceTypes, and its two property lists answer questions the spec sheet left open.⁵

profile.plist gives the identity: model identifier iPhone19,4, product class V68, an alias of com.apple.CoreSimulator.SimDeviceType.V68, minRuntimeVersion 27.1, and a rule to create the device by default for runtimes from 27.1 up. capabilities.plist gives the hardware: model number A3447, HomeButtonType 2, DeviceSupportsDynamicIsland true, DeviceSupportsEnhancedMultitasking false, IsLargeFormatPhone true, a CompatibleDeviceFallback of iPhone18,3, a device corner radius of 59, and a displays array with two integrated entries and three virtual ones.⁵

The first row is the outer display and matches Apple’s spec sheet pixel for pixel. The second is the inner display, and its pixel count is App Store Connect’s screenshot size, 2007 by 2853, rather than the panel’s 1878 by 2670: the simulator renders the inner display at 669 by 951 points at 3x, which is the arithmetic my Duo developer post did on September 10 and labeled an inference. Apple’s own profile now carries the number. The 270-degree native orientation says the inner display is landscape-native, 951 points wide by 669 tall when the phone is open, which matches Apple’s dimensions for the open device. The two remaining numbers are simulator values rather than hardware ones: both displays are listed at 460 pixels per inch and 60 Hz, where the spec sheet gives the inner panel 430 ppi, so treat hdpi as a placeholder.⁵

The profile also ships the shapes. Each display references a framebuffer mask, a PDF of the visible area. The outer display’s mask has asymmetric corners, the profile’s values 8 on one long edge and 59 on the other, on my reading the small radius on the side that meets the center hinge Apple’s design guide describes; the inner display’s mask is a plain rounded rectangle with the profile’s corner value 55 and no cutout for the front camera, so the camera’s occlusion comes from the reserved-region API at runtime rather than from the framebuffer shape.⁵¹⁰

What does the simulator show?

The device boots closed. On first boot the outer display shows the Home Screen and the inner display’s framebuffer is on but black, and simctl io enumerate lists both integrated screens by the profile’s names, primary at 1398 by 2034 and primary-1 at 2007 by 2853, beside the usual virtual ones.⁶ Device Hub is where the poses live. With the Duo device selected, its window exposes Rotate Right, Closed, Book, and Open as buttons the accessibility API can press, which is how everything in this section was driven; simctl has no pose command.⁶

The probe is a single-file SwiftUI app: a tab view holding a navigation stack with five toolbar items, a readout of the geometry, the size classes, the toolbarVerticalEdge environment value, the hinge, and the reserved regions of both kinds with includeInactive, and an ArrangementView in the split style. It reads the regions on every evaluation of its body and re-evaluates once a second. The numbers below are from the October 2 re-run, linked against the 27.1 SDK; the September runs, linked as 27.0 by mistake, follow under their own heading.¹³

Linked against the 27.1 SDK

Closed. The app gets the whole outer display: its window is 466 by 678 points, compact width and regular height. The toolbar and the tab bar stand on the trailing edge under the clock, toolbarVerticalEdge reads trailing, and UIKit’s verticalBarEdge trait reads raw value 2. The content inside the navigation stack measures 382 by 562 points with safe-area insets of 82 at the top, 34 at the bottom, and 84 on the trailing side, which is the rail. Two occlusion regions are reported, both active: one 37 points square where the outer camera sits, and one 84 by 170 covering the camera and the status column above the bars. No division is reported on this display. Turned on its side it is 678 by 466, compact in both size classes, with the bars still on the trailing edge.¹³

Closed, 27.1 SDK: the whole 466 by 678 point display, bars down the trailing edge.

Open. The app moves to the inner display in its landscape-native orientation: a 951 by 669 point window, regular in both size classes, bars still vertical on the trailing edge. Content measures 867 by 553 with the same three insets. Three regions come back. A division 40 points wide runs the full height at the middle of the screen, from x 455 to 495, with 20-point margins on each side, and it is inactive: the phone is flat. An inactive occlusion 58 by 37 marks the inner camera, which Apple’s guidelines say “stays hidden until the camera is active.”¹⁰ An active occlusion 84 by 120 covers the status column. The split arrangement puts its two panes side by side and divides the width evenly.¹³

Open, 27.1 SDK: 951 by 669 points, the fold reported as an inactive division down the middle.

Book. Device Hub’s Book pose reports the hinge as partly open at 127 degrees. The window does not change size. What changes is the division: same frame, now active. The split arrangement responds by moving its divider onto the fold and leaving the 40-point band empty, so the primary pane ends at x 455 and the secondary begins at 495. A sheet presented in this pose moves off-center into the leading half.¹³

Book, 27.1 SDK: the division is active, and the split arrangement leaves the fold empty.

Turned. Rotate Right with the phone open gives a 669 by 951 point window, still regular in both size classes, and the bars go back to horizontal: toolbarVerticalEdge is nil, the toolbar sits at the top beside the clock, the tab bar floats at the bottom. That matches Apple’s design guidance, which keeps “standard horizontal bars” on the inner display in portrait.¹⁰ The same three regions are reported in the turned coordinate space: the division is now a horizontal band 40 points tall across the middle, inactive when flat and active in Book. The probe’s arrangement view, which is wider than it is tall inside that screen, stays side by side.¹³

Open and turned, 27.1 SDK: horizontal bars, the fold now a horizontal band.

Two things hold across every pose. The regions arrive late: on each launch the first six to nine evaluations of the probe’s body read none, and every one after that read all of them, so a view that asks once, on its first layout pass, gets an empty answer. Sven-Eric Molzahn’s DuoProbe fixture documented exactly that on September 20 (“reservedRegions is empty on the first geometry evaluation and populated on a later one”) along with the 40-point band, and SwiftLee’s simulator guide of September 22 adds that “Holding Option ⌥ reveals a slider that you can use to control the hinge angle of the device with precision”, which I have not used.¹² And UIScreen.main.bounds answers 466 by 678 points, the outer display, while the app is on the inner one, which is the trap Apple’s guide warns about when it says to make layout calculations “based on your scene or containing view’s bounds rather than screen dimensions”: the main screen is not the screen you are on. The window scene’s own screen reports the display the app is actually on.⁷¹³

One route to the other poses does not work. simctl io screenConfig can power a screen off, and powering off the outer display while the inner one stayed on did not open the phone; it crashed the simulator’s system shell, simctl launch then failed with “The system shell probably crashed,” and a reboot was needed. Poses live in Device Hub’s window.⁶

Linked against the 27.0 SDK

These are the numbers this section carried until October 2, measured on September 19 and 20 with a probe that had a navigation stack and no tab view, and re-measured on October 2 with the current one. They describe what an app built with Xcode 27.0 gets on this simulator.⁶¹³

Closed, the window is 386 points wide on a 466-point display: the system keeps the 80-point rail for itself, draws the clock and status there on black, and the app’s toolbar lies across the top. Open, the window is 871 by 669, the same 80 points are missing on the right, and the safe-area insets are 34 on each side. Open and turned, the 80 points come off the top instead. In every pose the size classes match the 27.1 build’s, toolbarVerticalEdge is nil, verticalBarEdge reads raw value 0, and both reserved-region queries return empty arrays even with inactive regions included and however long the probe keeps asking; Book is indistinguishable from Open.

Closed, linked as 27.0: the app stops at the rail and its toolbar stays horizontal.

Open, linked as 27.0: regular in both dimensions, the rail kept by the system.

Turned, linked as 27.0: the band across the top is the system’s.

What the beta cannot do yet

Apple lists three limits under Simulator, Known Issues, in the beta’s own notes: “Initial Simulator launch can take several minutes.” (187708500), “StandBy is unavailable in the iPhone Duo Simulator runtime.” (187708663), and “Running and debugging most app extensions is unavailable in the iPhone Duo Simulator runtime.” (187708767).² The StandBy one matters for anyone with widgets or Live Activities meant for it: Apple’s announcement says the phone “enters StandBy on either the outer or inner display” and calls it a “hub for widgets”, the Duo developer post covers what appears there, and until a later beta lifts the limit, StandBy on this device is something to check on hardware.¹¹

Two more sit under Mac Catalyst, Known Issues, and they bite any app that adopts these APIs and also builds for the Mac: “Projects that use APIs specific to iOS 27.1 show compile errors when building for Mac Catalyst (“undeclared identifier”, “not found”, “has no member”, “cannot find”, etc). (185924957)”, with Apple’s workaround of #if !targetEnvironment(macCatalyst) in Swift or #if !TARGET_OS_MACCATALYST in Objective-C, and “Projects that target iOS 27.1 show no Mac Catalyst run destination available. (187046347)”, with “Add a Mac Catalyst 27.0 minimum deployment in target settings.” as the workaround.² The Xcode 27.2 beta notes add a third from the other direction: “macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly report 27.1 as a valid deployment target,” and “Mac Catalyst builds with a 27.1 or 27.2 deployment target may be unable to use newly introduced API.” (187160501).⁸

What I would do this week

1. Install the beta beside Xcode 27.0 rather than over it: expand the xip, rename the app, and point DEVELOPER_DIR at it for command-line builds; nothing in the beta’s notes changes the 27.0 toolchain, and the compiler and linker carry identical version strings.⁴
2. Start the runtime download before you need it, with xcodebuild -downloadPlatform iOS under the beta, and retry if it fails; the runtime is what makes the iPhone Duo device type bootable, and Apple warns the first launch takes minutes on top of that.²³
3. Build once against the 27.1 SDK with your Mac Catalyst target included, and read the two diagnostics Apple names before deciding whether to fence the new API with #if !targetEnvironment(macCatalyst) or to lift the Catalyst minimum to 27.0.²
4. Use the profile’s numbers as the sizes to preview and test against: 466 by 678 points closed, 669 by 951 open, with the inner display landscape-native. The beta’s Previews note adds a Display group to the canvas overrides picker “for previewing content on a device’s alternative display.” (182598534)²⁵
5. Read the reserved regions where they will be read again: in the view’s body through the geometry proxy, or on every geometry change, never once at first layout. reservedRegions(kind:options:layoutDirectionBehavior:) with .includeInactive returned nothing on the probe’s first six to nine evaluations and every region the display has on every one after (the camera and the status column closed; the fold, the inner camera, and the status column open), so a value cached from the first pass is an empty array for the life of the view. And before trusting any of it, confirm the build is stamped with the 27.1 SDK: otool -l <app>/<binary> | grep -A4 LC_BUILD_VERSION.⁷¹³

FAQ

Is the iPhone Duo simulator in Xcode 27.1 beta?

Yes. The beta installs an iPhone Duo device type, com.apple.CoreSimulator.SimDeviceType.iPhone-Duo, whose profile requires an iOS 27.1 runtime that Xcode downloads separately through xcodebuild -downloadPlatform iOS. Apple’s notes warn the first launch “can take several minutes” and that StandBy and most app extensions are unavailable in that runtime.²³⁵

How do I get the iPhone Duo simulator?

Install Xcode 27.1 beta, download the iOS 27.1 runtime with xcodebuild -downloadPlatform iOS under the beta, and pick the iPhone Duo device in Device Hub, where the poses are buttons. The 27.2 beta does not include it; Apple’s 27.2 notes point at the 27.1 beta for “the iOS SDK and simulator support for iPhone Duo.”²³⁸ (October 11: Xcode 27.1 RC (27A9275) shipped October 5, and its notes list the same iPhone Duo Simulator known issues, so the beta is no longer the only Xcode 27.1 whose notes cover the Duo simulator; I have not installed the RC.¹⁴)

Is there an online iPhone Duo simulator?

Not from Apple. The simulator shipped only inside Xcode 27.1 beta before the RC and runs Apple’s iOS 27.1 runtime; a browser page under that name is drawing something else. For a quick layout check, the beta’s Previews canvas offers a Display group for the alternative display.² (October 11: Xcode 27.1 RC (27A9275) shipped October 5, and its notes list the same iPhone Duo Simulator known issues, so the beta is no longer the only Xcode 27.1 whose notes cover the Duo simulator; I have not installed the RC.¹⁴)

How do I install Xcode 27.1 beta next to Xcode 27?

Expand the xip with xip --expand, move the resulting app to a versioned name such as /Applications/Xcode-27.1-beta.app, and set DEVELOPER_DIR to its Contents/Developer folder for xcodebuild, xcrun, and swiftc. The beta requires macOS Tahoe 26.6 or later, the same floor as Xcode 27.0.²⁴

What size is the iPhone Duo inner display in points?

669 by 951 points, per the simulator’s device profile, which defines the inner display as 2007 by 2853 pixels at scale 3 with a landscape-native orientation; the outer display is 466 by 678 points from 1398 by 2034 pixels at scale 3.⁵

Does Xcode 27.1 beta change the iOS 27.0 SDK or the Xcode 27 toolchain?

No. The Swift compiler and the linker report the same version strings as Xcode 27.0, and the beta’s release notes have three sections, Mac Catalyst, Previews, and Simulator, none of which touches the toolchain. The iOS 27.1 SDK is an addition, identified as build 24A94403 in both the device and simulator SDKs.²⁴

When does iPhone Duo ship, and on what?

October 23, on iOS 27.1, per Apple’s September 16 news post: “When iPhone Duo becomes available on October 23, it will run iOS 27.1.”⁹

Related on this site: the iPhone Duo developer post has the spec-sheet numbers and the API list this post checks against the SDK, the designing for iPhone Duo post reads Apple’s design guidance, the resizable iPhone checklist is the layout work the profile numbers feed, the Xcode 27 hub carries the dated beta sections, the Xcode 27 build failures post covers the toolchain this beta leaves unchanged, and the iOS 27 release notes post tracks the 27.x builds.

Sources