Your iPhone Duo Apps Still Show Black Bars. Laziness Is Not the Reason.

After the iPhone Duo went on sale, the first controversy came from the screen, not the price and not the crease. Unfold the 7.6-inch inner display and many common apps still sit in the center with wide black bars on both sides. QQ, some photo editors, and note apps do not turn into large-screen apps. They place a traditional iPhone interface in the middle of a foldable display. In testing, nearly 80 percent of apps do not support a foldable large-screen layout. That number looks like software vendors ignoring the device. The black bars have a narrower cause.

Black bars come from compatibility mode

Many apps show a centered interface because they are still built with an older Xcode version. Apple keeps a compatibility path for apps that have not been recompiled. The app runs in compatibility mode, and the system frames the traditional iPhone layout in the center of the large screen. The app does not fill the inner display. For those apps, removing the bars is not hard. Migrate to Xcode 27.1 or later and recompile. The app can then fill the inner screen.

The bars mostly show a toolchain delay. They do not prove that every app needs a foldable layout written from scratch. Filling the screen is step one. The slower work comes after that: checking whether the interface makes sense, whether navigation feels right, whether state survives a fold, and whether the crease and cameras are avoided. The black bars are the visible symptom.

The timeline leaves little room

Vendors did not adapt early, and they did not all choose to wait out of indifference. Foldable support has three gates. WWDC in June updated the iOS 27 development rules, and developers got the documentation. Apple's foldable developer kit became public in early October. Real devices arrived in the last couple of days. The first two stages can run in the Xcode simulator, but simulator results can differ from device results. An app can run in the simulator and fail on the device. Many teams wait for hardware before they start.

That explains the apparent contradiction. The device costs more than ten thousand yuan, so why not adapt before launch? Documentation alone does not finish the job. Foldable layout, hinges, reserved regions, and multi-window behavior need device testing. With a short window, the result will not match years of work on slab phones.

Android stretches the layout; Apple makes you build it

Android and Apple take different approaches to foldable layout. The Android developer documentation says that by default Android resizes the app layout to fit the current screen. The system helps stretch the interface. Apple asks developers to use container-relative layout and standard navigation APIs. The system will not rescue every interface on its own.

Neither approach is clean. Android-style resizing can stretch images or make them blurry. Many developers decide that a working app is enough and skip high-precision layout work. Apple does not count that as adaptation. It counts as automatic system resizing. If enough apps do this, the platform looks uneven. Apple's approach puts more work on developers. If you want the large screen and the new interactions to work well, you write the layout yourself.

Layout decisions move from orientation to size class

Older iPhone apps often read UIScreen.main.bounds or switch layout on device orientation. Portrait gets one column, landscape gets two. That logic fails on the Duo. The inner screen does not follow the app's orientation setting. The system reports a size class change, not an orientation change. Code that says "portrait means one column, landscape means two" will not work.

iOS also asks for container-relative layout. View sizes come from the parent container, not hard-coded screen dimensions. Apps with hard-coded sizes will not be rescued by the system. They stretch, misalign, or leave usable space empty. Adaptation is not a spacing pass. The layout decision changes from device orientation to the size class of available space. That change touches the app's base layout logic.

UIScene migration is a hard gate

The iOS 27 SDK requires a scene-based lifecycle. An app that still uses the old app-delegate lifecycle will crash at launch when built with the new SDK. There is no gradual path around this. Many production apps have customized the app delegate for push, deep links, analytics, or native code. Moving to UIScene takes manual work. It is not a switch.

This is why some feature-heavy apps respond more slowly. The team may want to adapt. The lifecycle migration blocks the build first. Recompiling can remove the black bars, but the app still needs the lifecycle migration before it can pass a new SDK build.

Foldable state is about continuity

When the Duo opens, closes, or half-folds, the system expects the app to keep the user's progress and login state. It should not reload or jump to the home screen. The app has to treat inner and outer screen changes as size class and trait changes, not as a scene disconnect or app restart.

State continuity does not happen by default. If a LazyVGrid changes column count during a fold, the scroll position may need scrollPosition(id:) or similar work to stay in place. Navigation hierarchy, form input, and media playback can all be rebuilt in a half-folded posture. These are state management problems, not spacing problems.

Hinges, reserved regions, and multi-window add new rules

Slab phones do not have a crease or hinge in the middle of the screen. The Duo adds several variables. The crease, the inner camera, and the outer camera create reserved regions that the app must avoid. System containers handle some of this. Custom views must query those regions. If they do not, buttons or content can land under the crease or camera. In some folded states, the hinge angle changes continuously and can drive sound or animation. It is a poor input for manual control coordinates. A small shake can make the interface jitter.

The Duo also runs two apps side by side and can open a second window of the same app. Apps must handle non-full-screen windows with changing aspect ratios. Many apps still assume they own the whole screen. These rules stack. Adaptation is not a wider version of the slab layout. It is a new set of layout and interaction rules for half-folded, split-screen, and windowed states.

Vendors ship what works first

The business order is practical. Apple users spend money, the user base is large, and the app market is stable. Vendors want to support the iPhone Duo. Wanting to support it does not make the work immediate. Tencent's emergency update in the past two days is rough, but it is better than the old black bars. The likely path for many vendors is to remove the bars first, then refactor. Migrate the SDK so the app fills the screen. Then handle side navigation, reserved regions, and state continuity.

Apple recommends standard navigation and toolbar APIs. In SwiftUI, add the toolbar modifier to NavigationStack or NavigationSplitView. The Duo screen is wider and shorter. The navigation bar moves to the side, and the app's bottom action bar has to move to the right and stack vertically. The right-side under-display camera also needs space. None of this comes from overtime. Teams make architecture decisions first, then migrate modules.

Apple's review timeline shows the scale of the job

The review process asks for screenshots in two forms: the 5.4-inch outer screen and the unfolded 7.6-inch screen. Old apps are not affected yet. Future updates will need those screenshots. Apple set the deadline for mandatory foldable screenshots at April 2027. That date shows the company expects this work to take months across the app market.

So is the iPhone Duo adaptation problem mostly workload or mostly technical limits? Both. The workload is large: every app must migrate its toolchain, refactor layout, keep state, and handle new interactions. The technical limits sit underneath. UIScene migration, hard-coded dimensions, and orientation-driven layout all touch the base architecture. The black bars and centered interfaces are signs that the migration is not finished. They are not proof that developers sat still.

Foldable adaptation has never been a matter of stretching a slab-phone interface wider. Developers have to answer three questions again. What decides layout? How does state continue across form changes? How do interactions stay coherent across creases and windows? The iPhone Duo black bars are the first problem. The adaptation work starts after they disappear.