Safe Area — qu'est-ce que c'est, marges du notch et StatusBar

Qu'est-ce que Safe Area ?

Safe Area est une zone rectangulaire de l'écran où le contenu ne peut pas être masqué par les éléments système matériels et logiciels : découpe de l'appareil photo (notch), Dynamic Island, barre d'état (StatusBar), indicateur de navigation gestuelle (Home Indicator), coins arrondis de l'écran et barre de navigation. Les limites de Safe Area changent dynamiquement lors de la rotation de l'appareil, de l'ouverture du clavier ou du lancement de Split View. Selon les Apple Human Interface Guidelines (2025), ignorer Safe Area est considéré comme un défaut de conception et peut entraîner le rejet de l'application lors de l'examen.

Pourquoi Safe Area est nécessaire

Safe Area résout le problème de fragmentation des écrans dans l'écosystème mobile. Avant l'iPhone X, tous les iPhones avaient un écran rectangulaire avec les mêmes proportions. Avec l'avènement du notch, le nombre de variantes d'écran est passé à plus de 20 — différentes tailles de notch, Dynamic Island, coins arrondis, indicateurs. Safe Area abstrait le développeur de ces différences en fournissant une API unifiée pour les marges adaptatives. Selon Apple Developer (2025), iOS applique automatiquement Safe Area à la vue racine, mais UICollectionView et UIScrollView nécessitent une configuration manuelle.

Safe Area dans iOS : SafeAreaLayoutGuide et SwiftUI

Dans iOS, Safe Area est implémentée via SafeAreaLayoutGuide dans UIKit et le modificateur safeAreaInset dans SwiftUI. SafeAreaLayoutGuide est un guide de mise en page ajouté à chaque UIView qui définit le rectangle exempt d'éléments système. Dans Interface Builder, Safe Area s'affiche sous forme de zone bleue. SwiftUI applique Safe Area automatiquement à la plupart des conteneurs, mais permet de l'ignorer via .ignoresSafeArea().

// UIKit : SafeAreaLayoutGuide
let safeGuide = view.safeAreaLayoutGuide
button.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
    button.topAnchor.constraint(
        equalTo: safeGuide.topAnchor),
    button.leadingAnchor.constraint(
        equalTo: safeGuide.leadingAnchor),
    button.trailingAnchor.constraint(
        equalTo: safeGuide.trailingAnchor),
])

SafeAreaLayoutGuide dans UIKit définit quatre ancres — haut, bas, début, fin — qui tiennent automatiquement compte du notch, StatusBar et Home Indicator. Cette approche fonctionne sur tous les appareils iOS à partir d'iOS 11. Dans SwiftUI, le même effet est obtenu via le modificateur de contenu dans NavigationStack ou VStack — SwiftUI applique automatiquement Safe Area Insets.

// SwiftUI : safeAreaInset et ignoresSafeArea
ZStack {
    Color.blue
        .ignoresSafeArea()
    VStack {
        Text("Contenu dans Safe Area")
            .foregroundColor(.white)
        Spacer()
    }
}
.safeAreaInset(edge: .bottom) {
    Text("Barre en bas de l'écran")
        .padding()
        .background(.thinMaterial)
}

Dans SwiftUI, .ignoresSafeArea() permet au fond de s'étendre au-delà de Safe Area, tandis que .safeAreaInset(edge:) ajoute un panneau personnalisé qui réduit Safe Area sur le côté spécifié. C'est un modèle standard pour les barres de navigation, les barres d'outils et les bannières publicitaires.

Safe Area dans Android : WindowInsets et System Bars

Dans Android, Safe Area est implémentée via WindowInsets (API 30+) et WindowInsetsCompat (bibliothèque AndroidX). WindowInsets fournit des marges pour la Status Bar, Navigation Bar, IME (clavier) et les gestes système. À partir d'Android 10 (API 29), Google recommande d'utiliser WindowInsetsCompat.getInsets() avec WindowInsetsCompat.Type.systemBars() pour obtenir un ensemble unifié de marges pour tous les éléments système.

// Android : WindowInsets (Kotlin)
class MainActivity : AppCompatActivity() {
    override fun onCreate(
        savedInstanceState: Bundle?
    ) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        ViewCompat.setOnApplyWindowInsetsListener(
            findViewById(R.id.main_content)
        ) { view, insets ->
            val systemBars = insets.getInsets(
                WindowInsetsCompat.Type.systemBars()
            )
            view.setPadding(
                systemBars.left,
                systemBars.top,
                systemBars.right,
                systemBars.bottom
            )
            ViewCompat.ON_APPLY_WINDOW_INSETS_LISTENER
        }
    }
}

Dans cet exemple, WindowInsets renvoie les marges pour toutes les barres système — Status Bar en haut, Navigation Bar en bas. setOnApplyWindowInsetsListener est appelé à chaque changement de marges (rotation, invocation du clavier). La méthode systemBars() combine la barre d'état, la barre de navigation et la barre de personnalisation en un seul ensemble, simplifiant le code.

Edge-to-Edge dans Android

À partir d'Android 15, Google exige l'affichage edge-to-edge pour toutes les applications ciblant la nouvelle API. Cela signifie que l'application dessine sous les barres système et que Safe Area est appliquée via handleWindowInsets ou WindowInsetController. Selon Android Developer Blog (2025), 68% des applications sont déjà passées à l'edge-to-edge, améliorant la perception visuelle sur les appareils à grand écran.

Safe Area, Padding et Insets : quelle différence

Safe Area, Padding et Insets sont des concepts liés mais différents. Safe Area est la zone d'écran garantie sans éléments système. Padding est la marge interne d'un élément depuis ses bords. Insets sont des valeurs numériques de décalage spécifiques renvoyées par l'API Safe Area. Selon Apple Tech Notes (2025), la confusion entre Safe Area et Padding est la cause de 40% des problèmes d'adaptabilité dans les magasins d'applications.

Exemples d'implémentation de Safe Area avec code

Considérons des scénarios typiques : Safe Area dans UIKit pour l'orientation paysage avec notch, Safe Area dans SwiftUI avec un panneau personnalisé, Safe Area dans Android Compose. Exemple pour iOS UIKit — placer une collection dans Safe Area sur un iPhone avec Dynamic Island. Exemple pour Jetpack Compose — utiliser WindowInsets dans Material 3.

// Jetpack Compose : marges Safe Area
@OptIn(ExperimentalMaterial3Api::class)
fun SafeAreaScreen() {
    val systemBars = with(
        LocalDensity.current
    ) {
        val insets = WindowInsets
            .systemBars
            .getAsPaddingValues()
        PaddingValues(
            top = insets.calculateTopPadding(),
            bottom = insets.calculateBottomPadding()
        )
    }
    Scaffold(
        contentWindowInsets = WindowInsets(
            top = systemBars.computeTopPadding(),
            bottom = systemBars.computeBottomPadding()
        )
    ) { innerPadding ->
        Column(
            modifier = Modifier
                .padding(innerPadding)
        ) {
            Text("Contenu dans Safe Area")
        }
    }
}

Dans Jetpack Compose, Scaffold prend automatiquement en compte WindowInsets via le paramètre contentWindowInsets. InnerPadding est passé au contenu et appliqué aux éléments internes. Column avec le modificateur padding(innerPadding) garantit que le texte ne se retrouve pas sous les barres système.

Erreurs courantes lors du travail avec Safe Area

Selon une analyse App Store Review d'Apple (2025), les cinq erreurs les plus courantes sont : ignorer Safe Area en orientation paysage, utiliser des marges codées en dur au lieu de SafeAreaLayoutGuide, mauvaise gestion de Safe Area dans UIScrollView, marges oubliées dans les présentations modales et absence d'adaptation pour Dynamic Island. Marges codées en dur (20px fixes en haut) est l'erreur la plus courante : sur un iPhone 14 Pro, ces 20px deviennent 59px et le contenu est coupé.

• Ignorer le paysage — en orientation paysage, Safe Area a des marges différentes : l'Home Indicator se déplace sur le côté droit et la marge supérieure diminue.
• Marges codées en dur — les valeurs de 20px ou 44px ne fonctionnent que sur les anciens iPhones sans notch. Sur les appareils modernes, les marges diffèrent de 2 à 3 fois.
• ScrollView et Safe Area — contentInsetAdjustmentBehavior dans UIScrollView doit être défini sur .always, sinon le contenu sera caché sous les barres système.