Safe Area — какво е това, отстояния от notch и StatusBar

Какво е Safe Area?

Safe Area — правоъгълна област на екрана, в която съдържанието е гарантирано непокрито от хардуерни и софтуерни системни елементи: изрезът на камерата (notch), Dynamic Island, лентата за състояние (StatusBar), индикаторът за жестова навигация (Home Indicator), заоблените ъгли на дисплея и навигационният панел. Границите на Safe Area се променят динамично при завъртане на устройството, извикване на клавиатурата или стартиране на Split View. Според Apple Human Interface Guidelines (2025), игнорирането на Safe Area се счита за грешка в дизайна и може да доведе до отхвърляне на приложението при преглед.

Защо е необходима Safe Area

Safe Area решава проблема с фрагментацията на екраните в мобилната екосистема. Преди iPhone X всички iPhone имаха правоъгълен дисплей с еднакви пропорции. С появата на notch броят на вариантите на екрани нарасна до 20+ — различни размери на изрези, Dynamic Island, заобляния, индикатори. Safe Area абстрахира разработчика от тези разлики, предоставяйки единен API за адаптивни отстояния. Според Apple Developer (2025), iOS автоматично прилага Safe Area за кореновия изглед, но за UICollectionView и UIScrollView е необходима ръчна конфигурация.

Safe Area в iOS: SafeAreaLayoutGuide и SwiftUI

В iOS Safe Area се имплементира чрез SafeAreaLayoutGuide в UIKit и модификатора safeAreaInset в SwiftUI. SafeAreaLayoutGuide е насока за оформление, която се добавя към всеки UIView и определя правоъгълника, свободен от системни елементи. В Interface Builder Safe Area се показва като синя област. SwiftUI прилага Safe Area автоматично за повечето контейнери, но позволява игнорирането ѝ чрез .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 в UIKit определя четири anchor — top, bottom, leading, trailing — които автоматично вземат предвид notch, StatusBar и Home Indicator. Този подход работи на всички iOS устройства, започвайки от iOS 11. В SwiftUI същият ефект се постига чрез модификатор на съдържанието вътре в NavigationStack или VStack — SwiftUI автоматично прилага Safe Area Insets.

// SwiftUI: safeAreaInset и ignoresSafeArea
ZStack {
    Color.blue
        .ignoresSafeArea()
    VStack {
        Text("Съдържание в Safe Area")
            .foregroundColor(.white)
        Spacer()
    }
}
.safeAreaInset(edge: .bottom) {
    Text("Лента в долната част на екрана")
        .padding()
        .background(.thinMaterial)
}

В SwiftUI .ignoresSafeArea() позволява на фона да се разпростре отвъд Safe Area, а .safeAreaInset(edge:) добавя персонализиран панел, който намалява Safe Area от посочената страна. Това е стандартният модел за навигационни панели, ленти с инструменти и рекламни банери.

Safe Area в Android: WindowInsets и System Bars

В Android Safe Area се имплементира чрез WindowInsets (API 30+) и WindowInsetsCompat (библиотека AndroidX). WindowInsets предоставя отстояния за Status Bar, Navigation Bar, IME (клавиатура) и системни жестове. Започвайки от Android 10 (API 29), Google препоръчва използването на WindowInsetsCompat.getInsets() с тип WindowInsetsCompat.Type.systemBars() за получаване на единен набор от отстояния за всички системни елементи.

// 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
        }
    }
}

В този пример WindowInsets връща отстояния за всички системни ленти — Status Bar отгоре, Navigation Bar отдолу. setOnApplyWindowInsetsListener се извиква всеки път, когато insets се променят (завъртане, извикване на клавиатура). Методът systemBars() комбинира лентата за състояние, навигационната лента и лентата за персонализиране в един набор, опростявайки кода.

Edge-to-Edge в Android

Започвайки от Android 15, Google изисква edge-to-edge показване за всички приложения, насочени към новото API. Това означава, че приложението се рисува под системните ленти, а Safe Area се прилага чрез handleWindowInsets или WindowInsetController. Според Android Developer Blog (2025), 68% от приложенията вече са преминали към edge-to-edge, което подобрява визуалното възприятие на устройства с големи екрани.

Safe Area, Padding и Insets: каква е разликата

Safe Area, Padding и Insets — свързани, но различни понятия. Safe Area е зоната на екрана, гарантирано свободна от системни елементи. Padding е вътрешното отстояние на елемент от неговите граници. Insets са конкретните числови стойности на отстоянията, връщани от Safe Area API. Според Apple Tech Notes (2025), объркването между Safe Area и Padding е причина за 40% от проблемите с адаптивността в магазините за приложения.

Примери за имплементация на Safe Area с код

Нека разгледаме типични сценарии: Safe Area в UIKit за хоризонтална ориентация с notch, Safe Area в SwiftUI с персонализиран панел, Safe Area в Android Compose. Пример за iOS UIKit — поставяне на колекция вътре в Safe Area на iPhone с Dynamic Island. Пример за Jetpack Compose — използване на WindowInsets в Material 3.

// Jetpack Compose: отстояния от 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("Съдържание в Safe Area")
        }
    }
}

В Jetpack Compose Scaffold автоматично взема предвид WindowInsets чрез параметъра contentWindowInsets. InnerPadding се предава на content и се прилага към вътрешни елементи. Column с модификатор padding(innerPadding) гарантира, че текстът няма да попадне под системните ленти.

Типични грешки при работа с Safe Area

Според анализ на App Store Review от Apple (2025), петте най-чести грешки са: игнориране на Safe Area в хоризонтална ориентация, използване на твърдо кодирани отстояния вместо SafeAreaLayoutGuide, неправилна обработка на Safe Area в UIScrollView, забравени отстояния в модални презентации и липса на адаптация за Dynamic Island. Твърдо кодирани отстояния (hardcoded 20px отгоре) — най-честата грешка: на iPhone 14 Pro тези 20px се превръщат в 59px и съдържанието се изрязва.

• Игнориране на хоризонтална ориентация — в хоризонтална ориентация Safe Area има различни отстояния: Home Indicator се премества на дясната страна, а горното отстояние намалява.
• Твърдо кодирани отстояния — стойностите 20px или 44px са подходящи само за стари iPhone без изрез. На съвременни устройства отстоянията се различават 2-3 пъти.
• ScrollView и Safe Area — contentInsetAdjustmentBehavior в UIScrollView трябва да бъде настроен на .always, в противен случай съдържанието ще бъде скрито под системните ленти.