Перейти к содержанию

Технологии нативных мобильных приложений

Требования применяются к нативным приложениям iOS и Android. Уровни обязательности определены в корневом README.md.

MOB-TECH-001. UI framework нативных приложений

Уровень: MUST

Применяется к: исходному коду пользовательского интерфейса

iOS-приложение должно реализовывать новый UI на SwiftUI, Android-приложение — на Jetpack Compose. Использование UIKit или Android Views для нового экрана запрещено.

Обоснование

Единый декларативный стек ограничивает число параллельных моделей UI.

Проверка

  • статический анализ импортов и UI-компонентов;
  • сборка и запуск нового экрана.

Исключения

Адаптер системного или стороннего компонента без SwiftUI/Compose API требует ADR и должен быть изолирован от прикладного UI.

MOB-TECH-005. Базовая минимальная версия ОС

Уровень: SHOULD

Применяется к: выбору минимальной поддерживаемой версии нового приложения

Для нового iOS-приложения следует использовать deployment target iOS 16.0 или выше. Для нового Android-приложения следует использовать minSdk 26 или выше. Проекту следует зафиксировать выбранное значение как продуктовое ограничение и проверять сборку и запуск на этой версии.

Обоснование

Единая начальная граница уменьшает матрицу совместимости, но доля поддерживаемых устройств и обязательства перед пользователями остаются решением продукта.

Проверка

  • проверка deployment target и minSdk;
  • сборка и запуск на минимальной версии;
  • review продуктового решения при выборе более ранней версии.

Исключения

Более ранняя версия MAY использоваться при зафиксированной потребности пользователей и проверяемой матрице совместимости.

MOB-TECH-002. Языки и поддерживаемый синтаксис

Уровень: MUST

Применяется к: production-коду приложения

iOS-код должен быть написан на Swift, Android-код — на Kotlin. Проект должен фиксировать версии Swift/Xcode, Kotlin, Android Gradle Plugin, Gradle и Compose в машинно-читаемых файлах. Код должен использовать только синтаксис и API, доступные зафиксированным версиям и минимальной версии платформы.

Обоснование

Зафиксированный toolchain делает сборку и доступность API воспроизводимыми.

Проверка

  • компиляция зафиксированным toolchain;
  • platform availability и lint checks;
  • проверка фактических версий в CI.

Исключения

Более новый API платформы допускается только под runtime availability check с проверенным поведением на минимальной версии.

MOB-TECH-003. Изменение минимальной версии ОС

Уровень: MUST

Применяется к: повышению минимальной поддерживаемой версии iOS или Android

Повышение минимальной версии ОС является несовместимым изменением. Оно должно выполняться отдельным управляемым изменением с оценкой доли активных устройств, которые потеряют поддержку, и планом прекращения поддержки для этих пользователей.

Обоснование

Повышение минимальной версии платформы может исключить действующих пользователей.

Проверка

  • отчёт распределения версий ОС;
  • review изменения deployment target или minSdk.

Исключения

Экстренное прекращение поддержки небезопасной версии выполняется по процедуре инцидента.

MOB-TECH-004. Раздельность платформенного кода

Уровень: MUST

Применяется к: общему бизнес-контракту iOS и Android

Платформы должны реализовывать одинаковый публичный backend-контракт, но не должны совместно использовать скомпилированный UI или скрытую кроссплатформенную runtime-зависимость. Различия поведения должны быть явно зафиксированы контрактом продукта.

Обоснование

Нативный профиль требует независимой проверяемости каждой платформы.

Проверка

  • review dependency graph;
  • contract-тесты обеих платформ;
  • сопоставление пользовательских сценариев.

Исключения

Общая схема, fixture и сгенерированная модель контракта допускаются без общей runtime-логики.