Я создал Android-приложение на Swift: главное о новом SDK в Swift 6.3

Около 10 лет я пишу на Swift исключительно для закрытой экосистемы Apple. Поэтому, когда я прочитал, что в Swift 6.3 наконец появился официальный SDK для Android… я буквально рассмеялся. А потом всё-таки решил нормально попробовать его за выходные.

Кратко: нет, я не запустил SwiftUI-приложение на своём Pixel. Зато получил кое-что намного интереснее — и гораздо более применимое к моей реальной работе.

Подождите, Swift теперь работает на Android?

Ответ: да — Swift 6.3 добавляет первый официальный SDK Swift для Android, разработанный Swift Android Workgroup по состоянию на март 2026 года. Инструменты сообщества существуют ещё с 2015 года, но впервые основная команда Swift взяла на себя официальную поддержку, версионирование и развитие такого SDK.

Но вот важный момент, на котором многие спотыкаются: это не SwiftUI на Android. Никакого import SwiftUI и никакой иерархии представлений. Вместо этого вы получаете:

• Поддержку кросс-компиляции для цели (aarch64-unknown-linux-android28), так что swift build собирает нативную библиотеку .so/ELF-бинарник
• Swift Java/JNI Core — базовый механизм для вызова Swift-кода из Kotlin или Java
• Возможность делиться слоем бизнес-логики между iOS и Android — сетью, разбором данных, валидацией, доменными моделями, условно вашими view model в архитектуре MVVM

Интерфейс всё равно нужно писать на Kotlin/Jetpack Compose. Либо использовать что-то вроде Skip — сторонний проект, который преобразует SwiftUI в Compose.

Почему это важно: реальный сценарий

Когда вы в последний раз выпускали только iOS-приложение на UIKit или SwiftUI? Почти наверняка у вашей команды есть и Android-приложение, в котором те же правила валидации, тот же API-клиент и те же доменные модели заново переписаны на Kotlin.

То есть вы вдвое увеличиваете объём поддержки, а со временем реализации на двух платформах всё сильнее расходятся.

Именно эту проблему и решает Android SDK в Swift 6.3: один пакет, две сборки, общая логика и нативная производительность на обеих платформах. Если архитектура вашего iOS-приложения уже хорошо разделена по ответственности — привет, MVVM — то половина работы у вас уже сделана.

Подключаем Swift Package к Android

Устанавливаем SDK и добавляем Android-цель.

# Install the official Swift SDK for Android
swift sdk install swift-6.3-android-sdk.artifactbundle.tar.gz

# Cross-compile your package for a real device/emulator target
swift build --swift-sdk aarch64-unknown-linux-android28

Даже общий слой логики выглядит как обычный Swift — конкурентность Swift и async/await работают привычным образом:

// SharedKit/UserRepository.swift
// Runs identically on iOS and Android via the Swift Android SDK
import Foundation
public struct User: Codable, Sendable {
    public let id: String
    public let name: String
}
public actor UserRepository {
    // async/await Swift — no platform-specific networking code needed
    public func fetchUser(id: String) async throws -> User {
        let url = URL(string: "https://api.example.com/users/\(id)")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(User.self, from: data)
    }
}

На стороне Android Kotlin вызывает скомпилированный Swift-код через бридж Swift Java JNI, а интерфейс на Compose просто отображает полученный результат — никакого дублирования логики разбора данных и никаких одинаковых багов в двух реализациях.

Чем это пока не является

Перед тем как предлагать такое решение своей команде, стоит очень чётко понимать ограничения:

1. Нативного рендеринга SwiftUI на Android нет — интерфейс явно не входит в область задач рабочей группы.
2. Инструменты пока молодые — не стоит ожидать отладки уровня Xcode или профилирования Instruments для Android.
3. Skip — отдельный проект, который закрывает проблему интерфейса, но он не является официальной частью Swift. Его нужно оценивать отдельно.

Так что если вы мечтаете уже завтра выпускать SwiftUI-экраны на Android вообще без Kotlin — пока нет. А вот если вы хотите перестать поддерживать две копии одной и той же бизнес-логики, тогда всё становится действительно интересно.

Главный вывод

Swift 6.3 не превращает Swift в новый кроссплатформенный UI-фреймворк — Flutter и Kotlin Multiplatform никуда не исчезают. Зато теперь iOS-команды наконец могут перестать каждый релиз заново переписывать «мозг» приложения на Kotlin.

Для команд со зрелой архитектурой на Swift это уже не забавный эксперимент, а вполне реальный инженерный выигрыш: общий код, немного возни с отладкой — и никакой полной переписки.