Apple unveiled its first foldable iPhone, but the developer frameworks for building truly adaptive foldable apps are conspicuously incomplete. Here's what's missing, what's provided, and why the gap matters.
Apple's iPhone Duo announcement introduced a device with two distinct display contexts: a 7.6-inch inner screen and a 5.4-inch outer screen sharing the same aspect ratio. Both displays use a 1:1.4 ratio, and Apple emphasized that content "scales proportionally, ensuring visual continuity." That's a clean pitch for consumers. For developers, it raises a harder question: what APIs actually exist to handle the transition between those two screens, and what happens at the hinge?
The answer, right now, is less than you'd expect from a company shipping a $1,999 device (Apple).
What Apple Shipped for Developers: Bezels and Not Much Else
Within hours of the announcement, Apple updated its Design Resources portal with product bezels for the iPhone Duo in Photoshop and PNG formats, 9to5Mac reported. These assets show the device in open and closed configurations and in both color options. That's useful for marketing mockups and pitch decks. It's not useful for solving the core engineering challenges of foldable API design.
What's notably absent from that update: Figma or Sketch templates with interactive fold states, SwiftUI preview configurations for dual-screen layouts, or any documentation on how apps should behave during the fold transition itself. The Design Resources portal includes assets for Figma, Sketch, Photoshop, PDF, PNG, and SVG across Apple's product line, but the iPhone Duo additions were limited to static image formats.
This is a pattern Apple has followed before. New hardware ships, and the deeper SDK support arrives in subsequent Xcode and iOS point releases. But the iPhone Duo represents a more fundamental interface shift than a new screen size or notch shape. A foldable device has fold states that existing UIKit and SwiftUI layout systems weren't designed to express.
The API Gaps: What SwiftUI and UIKit Can't Do Today
iOS developers have long relied on size classes, trait collections, and adaptive layout to handle different screen dimensions. SwiftUI's GeometryReader and layout containers can respond to width and height changes. But foldable devices introduce a category of context that these tools don't currently model: hinge position, fold state, and the physical discontinuity of a screen that bends.
Consider what a productivity app needs to know on a foldable device. None of these questions have first-party API answers in the current public iOS SDK:
- Is the device fully open, partially folded (tent mode, laptop mode), or closed?
- Is the user interacting with the inner display or the outer display?
- Should content span the hinge or treat it as a divider between two logical panes?
SwiftUI's @Environment property wrappers track things like color scheme, size class, and dynamic type. There's no \.foldState or \.hingeAngle equivalent. UIKit's UIScreen API reports a single main screen. There's no public interface for querying whether the device is in a folded or unfolded configuration, much less the angle of the hinge.
Apple's announcement mentioned that iOS 27 is "reimagined, remaining familiar and intuitive while adapting to the versatile ways users can interact with iPhone Duo" (Apple). That language suggests the OS handles transitions internally. But for third-party developers, the question is whether they can hook into those transitions or are left guessing.
How Android Solved This (Years Ago)
Android's foldable ecosystem offers a useful contrast. Google introduced Jetpack WindowManager in 2021, giving developers explicit access to fold state, hinge orientation, and display features (Android Developers). The FoldingFeature class reports whether a fold is flat, half-opened, or fully open, and whether the hinge runs horizontally or vertically (Android Developers). Apps can register listeners for fold state changes and adapt their layouts in real time.
Samsung went further with its Flex Mode APIs, which let apps detect specific hinge angles and present split interfaces that treat the top and bottom halves of a folded screen as separate interaction zones (Samsung Developer). Google's large-screen guidelines also established patterns for canonical layouts: list-detail, feed, and supporting panel configurations that adapt to foldable form factors.
Android developers building for the Galaxy Z Fold series or the Pixel Fold have had years to iterate on these patterns. Libraries exist. Design patterns are documented. Testing tools like the Android Emulator support fold simulation.
Apple developers, as of this week, have PNG bezels.
That gap isn't permanent, but it's real—and it matters most for the app categories where the iPhone Duo's dual functionality is supposed to shine.
The Apps That Need It Most
Apple's own announcement highlighted multitasking, content viewing, and camera use as key scenarios for the iPhone Duo. Apple prefaced its reveal with a critique, noted by Ars Technica, of square-ratio foldables that stretch single apps awkwardly and leave videos with oversized black bars. The 1:1.4 aspect ratio is Apple's answer to that problem (Apple).
But the most demanding use cases for foldable API patterns come from third-party apps, not Apple's own. Productivity apps like spreadsheets, document editors, and project management tools benefit enormously from hinge-aware layouts that can split a workspace across two logical panes. Media apps need to know whether to letterbox, fill, or reflow content when the fold state changes. Communication apps could use the outer screen for quick replies while keeping a full conversation visible on the inner display.
Without foldable-specific APIs, developers in these categories face a choice: treat the iPhone Duo as a large-screen iPhone and ignore the fold entirely, or build custom heuristics based on screen size changes and hope they correctly infer fold state. Neither option is great. The first leaves the device's signature feature underutilized. The second is fragile and likely to break when Apple does ship proper APIs.
The Timeline Problem
Apple typically previews major SDK changes at WWDC in June and ships them alongside new hardware in the fall. The iPhone Duo was announced at the September "Surprise and Shine" event; Apple's newsroom confirms the device is powered by the A20 Pro with iOS 27. If foldable APIs are part of iOS 27, they haven't been publicly documented yet. If they're coming in a point release, developers won't have them at launch.
This creates a familiar but frustrating dynamic. Early adopters spending $1,999 on an iPhone Duo will find that most third-party apps simply treat it as a bigger iPhone (Apple). The transformative foldable experiences Apple demoed on stage will initially be limited to first-party apps that had internal access to APIs the rest of the ecosystem doesn't (Apple).
The design-to-code pipeline adds another layer. As we explored in our earlier reporting on Figma-GitHub AI integration, bidirectional design workflows are becoming standard for teams building adaptive interfaces. But those workflows depend on having accurate device specifications and layout constraints in design tools. Static PNG bezels don't feed into Figma's component system or SwiftUI's preview canvas in a meaningful way.
What Comes Next
Apple almost certainly has foldable-aware APIs in development. The company doesn't ship hardware without internal frameworks to support it, and iOS 27's "reimagined" interface for the Duo implies significant layout system work under the hood. The question is when those tools become public and how complete they'll be at launch.
Developers should watch for several signals: updated Human Interface Guidelines with foldable-specific patterns, new SwiftUI environment values for fold state, Xcode Simulator support for fold transitions, and expanded Design Resources with interactive templates rather than static images.
Until then, the iPhone Duo is a device whose most interesting software possibilities are locked behind a foldable API that doesn't yet exist for the people who'd build it. Apple has shipped the hardware. The developer story is still unfolding.
