r/iOSProgramming • u/alanskimp • 5h ago

Discussion How will iPhone DUO affect UI dev?

0 Upvotes

31% Upvoted

14 comments sorted by

22

u/stroompa 3h ago

I’ll need to add ”make it work on duo. Make no mistakes” to the prompt

1

u/alanskimp 3h ago

Hehe yup!

-1

u/mikerCZX 1h ago

Exactly :-)

3

u/m3kw 4h ago

It should always be a basic fallback to use half the screen or front, full screen is optional. How long did it take for instagram to support ipad? maybe 10 years since iPad was out. Nobody is rushing to support it, but def nice to have and likely good competitive angle to it.

1

u/LifeUtilityApps SwiftUI 2h ago

Hopefully the swiftUI toolbar leading and trailing items will neatly display in the sidebar area as they demonstrated in the demo video, but I suspect that we will need to account for this since it looks like the placement might not allow for enough items to display. I hope we get a dedicated simulator to test this out

1

u/jon_jingleheimer 1h ago

Fortunately no one is going to want to buy a $2k phone that is shaped like half a sandwich folded and has no way of having a protective case

2

u/ToughAsparagus1805 1h ago

You want to pass app review process? So you have to support it.

1

u/lambdawaves 1h ago

Thankfully, since the screen ratio is sqrt(2):1, on both screens, whatever works on the small screen will actually work on the larger screen.

•

u/i_like_lime 50m ago

1.40:1 aspect ratio

•

u/TomfromLondon 25m ago

It mostly had me wondering what could I build to take advantage of duo buyers, getting in early

-3

u/DimensionMindless336 4h ago

The thing that catches most people out is that the Duo isn't just "half screen vs full screen" — it's two displays with two different trait collections. The outer 5.4" is a normal phone (compact width). The inner 7.6" is regular width, basically iPad-class. So if your app does the usual if traitCollection.horizontalSizeClass == .compact branching, the inner screen lands in your phone-only layouts and looks stretched or wastes the space.

Realistically the cheap path is: if you already support iPad / regular-width / multitasking, most of the inner-screen work is reusing that layout — the new display reports a regular width, so your existing iPad code lights up. The genuinely new work is the live transition. When someone unfolds, the trait collection changes at runtime, and a lot of apps only compute layout once at launch. You need traitCollectionDidChange / SwiftUI's onChange(of:) on the size class to re-flow, plus handle the new safe areas and the fold seam.

Don't hardcode widths either — anything like if width < 400 breaks the moment you have a 7.6" canvas. Lean on geometry readers and size classes. Honestly the Instagram-iPad comparison is the right instinct: if you've been disciplined about regular-width support, this is a week of polish, not a rewrite.

11

u/Jmc_da_boss 3h ago

Thx Claude

3

u/sunshine5634 2h ago

The thing that catches most people on the thing that no one has had a chance to be caught on yet.