Apple maakt bij iPhone Duo een duidelijk onderscheid tussen een app die start en een app die het opvouwbare scherm goed benut. Bestaande apps kunnen volgens Apple werken zonder de iOS 27 SDK, maar oudere layouts kunnen zwarte balken, ongebruikte ruimte en een beperkte weergave opleveren. Voor gebruikers betekent dat: compatibiliteit is niet hetzelfde als optimalisatie.
Wat betekent appcompatibiliteit op iPhone Duo?
Appcompatibiliteit betekent hier dat een bestaande iPhone-app op iPhone Duo kan worden geopend en gebruikt. De kwaliteit van die ervaring hangt vervolgens af van de manier waarop de app met verschillende schermformaten, veilige gebieden en de centrale vouw omgaat.
Een app die voor één vaste schermmaat is ontworpen, weet minder goed raad met het compacte buitenscherm en het brede binnenscherm. Een flexibele app kan de inhoud herschikken zodra de beschikbare ruimte verandert. Dat verschil merk je vooral wanneer kaarten, knoppen of navigatie niet simpelweg worden uitgerekt, maar opnieuw moeten worden geplaatst.
De drie compatibiliteitslagen volgens de SDK-versie
De beschreven indeling onderscheidt drie groepen. De belangrijkste grens loopt niet tussen “werkt” en “werkt niet”, maar tussen basisgebruik en een interface die echt voor iPhone Duo is ingericht.
| SDK-versie van de app | Gebruik van het scherm | Gedrag dat voor iPhone Duo wordt beschreven |
| Voor iOS 27 | Beperkt gebruik van de beschikbare ruimte | De app werkt in een compatibiliteitsweergave; zwarte balken, een beperkt veilig gebied of ongebruikte ruimte zijn mogelijk. |
| iOS 27 | Meer gebruik van het beschikbare scherm | De app kan meer schermruimte benutten, maar er kan nog ongebruikte ruimte overblijven. |
| iOS 27.1 | De uitgebreidste beschreven compatibiliteitsmodus | Apps uit deze generatie worden gekoppeld aan nieuwere Duo-specifieke interfacecomponenten en een vollediger gebruik van het scherm. |
Daarmee is het antwoord op de praktische vraag eenvoudig: nee, niet elke app hoeft te worden bijgewerkt om te starten. Wel kan een update nodig zijn om de binnenruimte goed te benutten. Welke Duo-specifieke componenten precies aan iOS 27.1 zijn gekoppeld, vormt geen volledige lijst in de beschikbare ontwikkelaarsuitleg.
Waarom de vouw het ontwerp verandert
Een opvouwbaar scherm is geen gewone tabletweergave die toevallig kleiner kan worden gemaakt. De app krijgt te maken met meerdere standen, een compact buitenscherm, een breder binnenscherm en een centrale zone die niet altijd geschikt is voor tekst of bediening.
Apple adviseert daarom size classes: breedteklassen die aangeven hoeveel ruimte de interface daadwerkelijk heeft. Voor het buitenscherm ligt de nadruk op compact width; het binnenscherm kan regular width bieden. Ontwikkelaars kunnen daarmee bepalen hoe elementen zich gedragen zonder vaste pixels, schermmaten of simpele oriëntatiecontroles als uitgangspunt te nemen.
Ook de veilige gebieden zijn asymmetrisch. Content en bediening moeten uit de buurt blijven van de centrale vouw en andere zones waarin hardware of systeemonderdelen de interface kunnen hinderen. Op het buitenscherm kunnen bedieningselementen naar de zijkant verhuizen, zodat er verticaal meer ruimte overblijft voor de app zelf.
Voor SwiftUI presenteert Apple ReservedRegion; voor UIKit is UIViewReservedRegion bedoeld. Deze API's helpen gebieden vrij te houden die niet door gewone content moeten worden gevuld. Dat klinkt technisch, maar het resultaat is heel concreet: minder tekst onder een vouw, minder knoppen op een onhandige plek en minder kans dat een belangrijk element tegen een hardwarezone botst.
Wat merkt een gebruiker in de praktijk?
Bij een oudere app kan de inhoud in een kleiner kader blijven staan terwijl er rondom lege ruimte ontstaat. Zwarte balken zijn daarbij een mogelijke uitkomst van de beperkte compatibiliteitsweergave. De app start dan wel, maar gebruikt niet automatisch het volledige binnenscherm.
Bij een app die voor iOS 27 is gebouwd, kan de interface meer van de beschikbare ruimte benutten. De overgang naar iOS 27.1 wordt daarnaast gekoppeld aan de uitgebreidste beschreven compatibiliteitsmodus en nieuwere interfacecomponenten voor iPhone Duo.
Voor games is dat verschil extra zichtbaar. Een spel dat uitgaat van één vaste beeldverhouding kan lege randen of een minder passende plaatsing van bedieningselementen krijgen. Dat betekent niet dat ieder spel hetzelfde probleem heeft, maar wel dat rigide layouts minder goed passen bij een toestel dat voortdurend van beschikbare ruimte verandert.
Wat moeten ontwikkelaars aanpassen?
Apple’s ontwikkelaarsaanpak komt neer op een paar concrete ontwerpkeuzes:
- gebruik compact en regular width als uitgangspunt voor de layout;
- vermijd vaste schermmaten en vaste breedtebreekpunten;
- ontwerp voor meerdere standen van iPhone Duo;
- houd rekening met asymmetrische veilige gebieden en de centrale vouw;
- gebruik ReservedRegion in SwiftUI en UIViewReservedRegion in UIKit wanneer een gebied vrij moet blijven;
- test open, gesloten en gevouwen standen met de iPhone Duo-simulator in Xcode 27.1.
De kern is niet alleen opnieuw compileren. De app moet ook logisch blijven aanvoelen wanneer de beschikbare ruimte verandert. Een ontwikkelaar kan een interface technisch laten passen en toch eindigen met knoppen die te ver weg staan, kaarten die onnodig smal blijven of content die tegen de vouw aanligt. Juist dat laatste stuk maakt het werk groter dan een simpele SDK-wijziging.
En hoe zit het met iPad-apps in iOS 28?
Voor iOS 28 wordt een mogelijke compatibiliteitsmodus voor iPad-apps als terugvaloptie genoemd. Het gaat daarbij niet om een aangekondigde functie waarop gebruikers of ontwikkelaars nu al kunnen rekenen. De actuele compatibiliteitsaanpak draait om bestaande iPhone-apps, hun SDK-versie en hun vermogen om zich aan verschillende schermstanden aan te passen.
