Изграждане и публикуване в мобилната разработка: какво е, какви формати и как работи

Формати за изграждане: APK, AAB, IPA

APK срещу AAB

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

Предимства на AAB: размерът на изтегляне е средно с 15% по-малък (чрез доставяне само на необходимите ресурси: правилни плътности на екрана, езици, архитектури на процесора). AAB също поддържа модулна доставка — можете да зареждате модули при поискване (Play Feature Delivery) или отложено (Play On-Demand). За разработчиците AAB е задължителен; за разпространение извън Google Play (sideloading, пазари) — само 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 срещу 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 на ниво приложение.

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 — номер на изграждане, увеличава се с всяко build. 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 тестери по имейл, без преглед) и External Testing (до 10 000 тестери, с преглед от Apple). Изгражданията са достъпни за 90 дни, след което трябва да се качи ново изграждане. TestFlight автоматично актуализира приложението при тестерите при качване на ново изграждане.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — до 100 тестери, без преглед от Google, изграждането е достъпно веднага. Closed Beta — до 1000 тестери по имейл или 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 — това ни позволява да открием проблеми преди масово пускане.