Apple shipped a foldable. Your app has six weeks.

On 9 September Apple announced the iPhone Duo — its first foldable. It opens to a 7.6-inch display, has a 5.4-inch screen on the outside, and costs $1,999. Pre-orders open on 16 October and it reaches customers on 23 October. Apple Pencil support follows later in the year.

Most of the coverage is about whether the crease is visible. That is the least interesting question in the room. The interesting one, if you own an app, is this: for eighteen years every iPhone has been a rectangle of roughly known proportions that never changed shape while your app was running. That is over. And you have about six weeks.

What actually changed

Not the screen size. Apps have coped with new screen sizes since the iPhone 5, and mostly they cope automatically.

What changed is that the screen size is now a runtime event. The device can be 5.4 inches, then 7.6 inches, then 5.4 again, while your app stays in the foreground. Apple’s own description is that content “reacts as it folds, reorients when turned to the side, and switches to the appropriate display when flipped over” — which means the system will hand your app a new set of dimensions mid-session and expect it to keep its composure.

There’s a second change hiding inside that one. iOS 27 brings Split View to the iPhone: two apps side by side, for the first time. So your app is no longer guaranteed the whole screen even when the device is open and nobody is folding anything.

That is a different class of problem from supporting a new model. Supporting a new model is a build setting. Surviving a size change while running is an architecture question, and it’s the kind of question that gets answered badly by code written in a hurry three years ago.

The three ways apps break

I’ve seen all of these in production code, on projects I inherited rather than wrote.

Hardcoded dimensions

Someone needed a layout finished by Friday and wrote width * 0.42, or worse, a literal point value measured off a specific device. It looked right on the phone on their desk. It has looked right ever since, because every phone since has been close enough in shape.

Unfold the device and the multiplier that meant “just under half the screen” now means something else entirely. Nothing crashes. It just looks wrong, and it looks wrong in the screenshot the customer posts.

Layout computed once

Plenty of apps calculate their layout when a view loads and never revisit it. On a phone that never changed shape, that was indistinguishable from correct. On a device that unfolds mid-session, it’s a bug that was always there and never fired.

This is the one that produces the ugliest result: content sized for the small screen, marooned in the middle of a 7.6-inch display with dead space around it.

State that doesn’t survive the transition

A size change can mean view controllers are rebuilt. If your app holds important state in the view layer — a half-typed message, a scroll position, an in-progress upload, an unsaved form — you find out about it here. The customer unfolds the phone to read something more comfortably and loses what they were doing.

That is the failure that generates one-star reviews, because from the outside it’s indistinguishable from the app losing their work for no reason.

What this is really about

A foldable doesn’t introduce these bugs. It reveals them. Every one of the three above has been latent in a lot of shipped code for years, harmless only because no device ever exercised the path.

This is the recurring shape of iOS maintenance, and it’s why “the app is finished” is never quite true. The app is finished with respect to the devices that exist. Apple then ships a device that asks a question the code was never asked before — the notch, Dynamic Island, iPad multitasking, StandBy, now a hinge — and the answer arrives as a support email.

The apps that handle this well are not the ones written by the cleverest developers. They’re the ones where somebody was still paying attention when the hardware changed.

What to do about it, in order

Work out whether you care. The Duo is $1,999 and ships on 23 October. This is not a volume device in 2026. If your users are warehouse staff on company-issued handsets, you can note this and move on. If you sell to people who buy the expensive thing on day one — and if you’re a consumer product, some of your best customers are exactly those people — you care.

Open your app in the simulator and resize it. Before any code changes. This costs an afternoon and turns an abstract worry into a specific list. Most of what you find will be cosmetic. Some of it won’t be.

Fix the state loss first, cosmetics second. A stretched layout is embarrassing. Losing a customer’s half-written message is a refund. These are not the same priority, and under time pressure people reliably fix the visible one.

Separately: check your minimum iOS version. iOS 27 is out. There is no standard iPhone 18 until spring 2027, so this year’s lineup is unusually top-heavy — the buyers are people on new hardware running the newest OS. Worth confirming your build is actually tested there, which is a different thing from it compiling.

The honest version

For most apps this is a week of work, largely unglamorous, and it produces nothing you can put in a release note beyond “improved support for foldable displays.”

It’s also exactly the work nobody does, because there’s no launch attached to it and no one asked for it. Then eighteen months later the app has accumulated six of these, feels subtly broken everywhere, and someone decides it needs rewriting from scratch — which costs thirty times what keeping up would have.

I’d rather do the week.

Announced at Apple’s 9 September event, alongside the iPhone 18 Pro and Pro Max ($1,199 and $1,299, on sale 18 September), Apple Watch Series 12 and Ultra 4, and a new AirPods line. The Duo is the one that changes how apps are built.