Каковы преимущества и недостатки SwiftUI для разработки iOS-приложений?

А, ну это же тот самый SwiftUI, про который все так пиздят! Ну что, разберём эту магию от Apple, которая обещает сделать из тебя фронтенд-гуру, но на деле иногда так подставляет, что волосы дыбом встают.

Смотри, суть в чём: вместо того чтобы как в старом добром UIKit — «эй, кнопка, стань сюда, а теперь подвинься на два пикселя влево, блядь» — ты просто описываешь, как всё должно выглядеть. Типа «хочу вертикальный стек, в нём тоггл и текст, который появляется, если тоггл включён». И система сама, ёпта, всё делает! Как по маслу. Ну, почти.

Вот смотри, как это выглядит, реальный пример:

struct ContentView: View {
    @State private var isOn = false

    var body: some View {
        VStack {
            Toggle("Enable Feature", isOn: $isOn)
                .padding()

            if isOn {
                Text("Feature is active")
                    .foregroundColor(.green)
            }
        }
    }
}

Видишь? Никаких делегатов, никаких «обнови вьюху». Написал условие if isOn — и текст сам появляется-исчезает. Красота, да? Это и есть их декларативный синтаксис — ты не командуешь, а заявляешь о своих хотелках.

Чем он, блядь, хорош:

1. Пишешь меньше всякой хуйни. Автоматические отступы, адаптация под размеры экрана — многое работает из коробки. Не нужно городить эти ваши констрейнты, которые вечно ломаются.
2. Живой превью — просто песня. Изменил код — и тут же, на соседней панельке, видишь результат. Не нужно каждый раз билдить проект и ждать, пока симулятор, этот тормозной ублюдок, запустится. Экономия нервов — овердохуища.
3. Один код на все платформы Apple. Ну, типа один. Для iOS, для мака, для часов этих... На практике, конечно, приходится иногда подкручивать под каждую ОС, но база-то общая!
4. Реактивность вшита в ДНК. Эти штуки @State, @Binding — они за тебя следят, когда данные меняются, и автоматически перерисовывают вьюху. Никаких reloadData() по сто раз на дню.

А теперь, сука, ложка дёгтя (и не одна):

1. Требует iOS 13 и выше. У тебя в требованиях проекта поддержка iOS 12? Ну, тогда иди нахуй со своим SwiftUI. Пока что. Придётся юзать старый добрый и проверенный UIKit.
2. Функциональность ещё не полная. Хочешь какую-нибудь специфичную, навороченную хрень из UIKit? В SwiftUI её может просто не быть. Или API будет урезанным, как говно без запаха. Приходится городить костыли.
3. Интеграция с легаси-кодом — это отдельная песня. Если у тебя проект на UIKit, а ты хочешь впихнуть туда кусочек SwiftUI (или наоборот), готовься к геморрою. Хотя мосты есть:

// Берём UIKit-компонент (например, карту) и заворачиваем в SwiftUI
struct MapView: UIViewRepresentable {
    func makeUIView(context: Context) -> MKMapView {
        MKMapView(frame: .zero) // Делаем вьюху
    }

    func updateUIView(_ uiView: MKMapView, context: Context) {
        // А тут обновляем её, если надо
    }
}

// И юзаем как обычную SwiftUI-вьюху
struct ContentView: View {
    var body: some View {
        MapView()
            .edgesIgnoringSafeArea(.all)
    }
}

Работает, но иногда чувствуешь себя сапёром, который соединяет провода от двух разных бомб.

4. Кастомизация бывает сложной. Захотел сделать не «как у всех», а что-то своё, уникальное — и тут ты понимаешь, что стандартные компоненты не всегда к этому готовы. Приходится копать глубоко, а иногда и вовсе писать свою реализацию с нуля.

Так что в итоге, ёпта?

• Запускаешь новый проект с таргетом на iOS 13+? Смело бери SwiftUI, особенно если архитектуру закладываешь типа MVVM. Это будущее, хоть и слегка сыроватое.
• Работаешь со старым проектом или нужен специфичный контрол из UIKit? Сиди на UIKit, не выёбывайся. Или комбинируй осторожно.
• В целом, учить SwiftUI надо. Потому что Apple его активно пихает везде, где можно, и со временем он, скорее всего, всё захватит. Но и про UIKit забывать нельзя — иначе окажешься в ситуации «и вашим, и нашим», а по факту — ни хуя не шарящим в основах.

Вот такая, блядь, история. Инструмент мощный, но требующий сноровки и понимания, где его применять, а где не соваться.