Сборка и публикация в мобильной разработке: что это, какие форматы и как работает

Форматы сборок: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — традиционный формат сборки и публикации мобильных приложений на Android. APK содержит весь код, ресурсы и манифест приложения. AAB (Android App Bundle) — формат, введённый Google в 2018 году и ставший обязательным для новых приложений с августа 2021. AAB не устанавливается напрямую — Google Play динамически генерирует оптимизированный APK для каждого устройства из AAB.

Преимущества AAB: размер загрузки в среднем на 15% меньше (за счёт доставки только нужных ресурсов: правильные плотности экрана, языки, архитектуры процессора). AAB также поддерживает modular delivery — вы можете загружать модули по требованию (Play Feature Delivery) или отложенно (Play On-Demand). Для разработчиков AAB обязателен, для распространения вне Google Play (сайди, маркетплейсы) — только APK.

IPA

IPA (iOS App Store Package) — установочный файл iOS, который представляет собой ZIP-архив с подписанным приложением. IPA содержитPayload/ папку с .app-бандлом, Provisioning Profile и подпись. IPA собирается только на macOS через Xcode, который создаёт архив (.xcarchive) и экспортирует IPA. Для распространения через App Store IPA подписывается Apple Distribution Certificate, для Ad Hoc или Enterprise — соответствующими сертификатами.

Компиляция и оптимизация: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — компиляция кода во время выполнения приложения, влияющая на скорость сборки и публикации. На Android до версии 5.0 (Lollipop) использовался Dalvik VM с JIT-компиляцией. При каждом запуске приложения байткод DEX преобразовывался в машинный код «на лету». Недостаток: замедление при первом запуске и дополнительное потребление энергии. AOT (Ahead-Of-Time) — компиляция кода до запуска приложения, во время установки. Начиная с Android 7.0 (Nougat), ART (Android Runtime) компилирует приложение полностью при установке.

ART (Android Runtime) — среда выполнения, заменившая Dalvik в Android 5.0. ART использует гибридный подход: AOT-компиляция при установке + JIT для часто выполняемых методов. Это сочетает скорость AOT (быстрый запуск) с гибкостью JIT (адаптивная оптимизация). Результат: производительность Android-приложений выросла на 20–30% по сравнению с Dalvik. Для разработчиков переход на ART прозрачен — код не требует изменений.

Bitcode и App Thinning

Bitcode — промежуточное представление кода (IR), которое Apple использует для перекомпиляции IPA под разные архитектуры процессоров. Bitcode опционален: для iOS-приложений он включён по умолчанию, для watchOS и tvOS — обязателен. Apple может перекомпилировать Bitcode при выходе новых процессоров без участия разработчика. App Thinning — технология Apple, включающая Slicing (доставка только нужных ресурсов для устройства) и On-Demand Resources (загрузка ресурсов по требованию). App Thinning сокращает размер загрузки из App Store на 30–50%.

DEX — формат байткода для Android, исполняемый ART/Dalvik. Исходный код Kotlin/Java компилируется в class-файлы, затем в DEX через dx или d8 (современный и более быстрый инструмент). Multidex — механизм для приложений, которые превышают лимит в 65 536 методов в одном DEX-файле. В современных проектах multidex включается автоматически, если targetSdkVersion >= 21.

Подпись кода: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — файл, содержащий приватный ключ и сертификат для подписи Android-приложения при сборке. Keystore создаётся через keytool (ключ -genkey) или Android Studio. Важно: Keystore нельзя терять — без него вы не сможете обновить приложение в Google Play. Параметры для подписи: keyAlias, keyPassword, storePassword и storeFile. Формат: JKS (Java KeyStore) или PEPK (Play Encrypted Private Key) для AAB.

App Bundle ID (Android) — уникальный идентификатор приложения в пакетной нотации (com.example.app). Version Code — целое число для внутренней нумерации версий (каждая новая сборка увеличивает его). Version Name — строка, отображаемая пользователю (1.2.3). Эти параметры задаются в build.gradle уровня app.

iOS: Apple Certificate и Provisioning Profile

Apple Certificate — цифровой сертификат, удостоверяющий личность разработчика. Типы: Development (для отладки), Distribution (для App Store), Ad Hoc (для ограниченного распространения). Сертификаты создаются в Apple Developer Account и скачиваются в Keychain. Provisioning Profile — файл, связывающий сертификат, App ID (Bundle Identifier) и список разрешённых устройств. Без Provisioning Profile приложение не запустится на устройстве.

Bundle ID (iOS) — уникальный идентификатор приложения (com.example.app). Build Number — версия сборки, увеличивается с каждым билдом. Marketing Version — версия, показываемая пользователю. Управление версиями: для iOS параметры задаются в Info.plist и Project Settings, для Android — в build.gradle. В IT Sectr мы автоматизируем обновление версий через Fastlane — это исключает человеческие ошибки при релизе.

Процесс публикации в магазинах

Google Play Console

Google Play Console — инструмент для публикации Android-приложений. Процесс: регистрация аккаунта разработчика ($25 разово), создание приложения, заполнение метаданных (название, описание, скриншоты, категория), загрузка AAB, настройка цен и распространения, ревью. Google проверяет приложение автоматически (на вирусы, несоответствие политикам) и вручную для некоторых категорий. Ревью занимает от нескольких часов до 2–3 дней.

App Store Connect

App Store Connect — платформа Apple для публикации iOS-приложений. Процесс: аккаунт разработчика Apple ($99/год), создание приложения в App Store Connect, подготовка IPA в Xcode (Archive → Distribute App → App Store Connect), загрузка через Transporter или Xcode, заполнение метаданных, отправка на ревью. App Review — ручная проверка Apple может занять от 24 часов до 7 дней. Типичные причины отказа: неработающие кнопки, неполный контент, запрос разрешений без объяснения.

Бета-тестирование: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — официальный инструмент Apple для бета-тестирования iOS-приложений. TestFlight поддерживает Internal Testing (до 100 тестировщиков по email, без ревью) и External Testing (до 10 000 тестировщиков, с ревью Apple). Сборки доступны 90 дней, после чего нужно загрузить новую. TestFlight автоматически обновляет приложение у тестировщиков при загрузке новой сборки.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — до 100 тестировщиков, без ревью Google, сборка доступна сразу. Closed Beta — до 1000 тестировщиков по email или Google Groups, без ревью. Open Beta — неограниченное количество тестировщиков через публичную ссылку, с ревью Google. Staged Rollout — постепенное увеличение процента пользователей, получающих обновление (5% → 20% → 50% → 100%). Это самый безопасный способ релиза.

App Thinning (iOS) — автоматическое уменьшение размера загружаемого IPA: Slicing (только нужные ресурсы для устройства), Bitcode (оптимизация под процессор), On-Demand Resources (загрузка по требованию). В IT Sectr мы используем TestFlight для бета-тестов iOS и Internal Testing для Android — это позволяет отловить проблемы до массового релиза.