Вопросы на собеседовании: Мобильный разработчик

iOS и Android дают приложениям похожие возможности, но используют разные SDK, инструменты и платформенные соглашения.

• Для iOS обычно используют Swift, Xcode и фреймворки Apple, например UIKit или SwiftUI.
• Для Android обычно используют Kotlin, Android Studio и библиотеки AndroidX, например Jetpack Compose.
• У каждой платформы свои правила навигации, разрешений, фоновой работы и проверки в магазине, поэтому даже общий дизайн требует отдельных решений.

Жизненный цикл приложения описывает платформенные изменения видимости, интерактивности, фонового состояния и завершения приложения или его компонента.

• Приложение должно запускать работу, связанную с интерфейсом, когда экран активен, и приостанавливать камеру при уходе в фон.
• Операционная система может завершить фоновый процесс ради освобождения памяти, поэтому важное состояние нельзя хранить только в RAM.
• iOS сообщает фазы приложения и сцен, а Android предоставляет колбэки жизненного цикла Activity и других компонентов, поэтому общей state machine у платформ нет.
• Колбэки жизненного цикла не гарантируют, что перед завершением процесса обязательно вызовется каждый метод очистки.

Я бы выбрал нативную разработку, если интеграция с платформой и её особое поведение важнее общего кода интерфейса.

• Swift и Kotlin дают прямой доступ к новым API iOS и Android без ожидания кроссплатформенной обёртки.
• React Native или Flutter позволяют разделить между платформами значительную часть продуктовой логики и UI, что помогает небольшой команде выпустить оба приложения.
• Кроссплатформенному коду всё равно нужна нативная часть для неподдерживаемых SDK, виджетов, фоновых режимов и необычных аппаратных функций.
• Выбор зависит от навыков команды, нужных API устройства и требуемого соответствия правилам каждой платформы.

Junior iOS-разработчик должен уверенно работать с константами, опциональными значениями, функциями, коллекциями, структурами и классами Swift.

• Используйте let для неизменяемой привязки, а var только когда значение действительно должно меняться.
• Обрабатывайте optional через if let, guard let, optional chaining или значение по умолчанию вместо принудительного извлечения.
• Выбирайте struct для простых моделей-значений, например Profile; class нужен, когда важна общая идентичность экземпляра или наследование.
• Протоколы описывают поведение, которое могут реализовать разные типы без общего суперкласса.

Kotlin делает Android-код безопаснее и короче благодаря null safety, data class, extension-функциям и корутинам.

• Nullable-тип обозначается знаком ?, а safe call и оператор Elvis позволяют явно обработать отсутствие значения.
• Data class генерирует методы equals, hashCode, copy и понятный toString для работы с данными.
• Extension-функции добавляют удобные операции существующему типу без его изменения или наследования.
• Корутины позволяют последовательно описывать асинхронную работу, а структурированные coroutine scopes управляют её жизненным циклом.

Dart поддерживает строгую null safety, изменяемые переменные и неизменяемые привязки.

• Переменной final присваивается значение один раз во время выполнения, а const создаёт константу времени компиляции.
• Тип с ? может содержать null, а обычный String не может.
• Именованные параметры делают конструкторы виджетов читаемыми, а required отмечает обязательный именованный аргумент.
• Функция с async возвращает Future, а await получает будущий результат без блокировки UI-потока.

TypeScript находит многие ошибки в структуре данных и работе с null до запуска React Native-приложения.

• Интерфейсы и псевдонимы типов могут описывать ответы API, свойства компонентов и параметры навигации.
• Union-типы моделируют состояния загрузки, успеха и ошибки безопаснее, чем набор несвязанных булевых флагов.
• Сужение типа проверяет значение перед обращением к свойствам, доступным только одному варианту union.
• Типы TypeScript исчезают во время выполнения, поэтому внешний JSON всё равно нужно проверять.

Nullable-значения нужно обозначать явно и проверять перед обычным использованием; конкретный синтаксис зависит от выбранного стека.

• Swift использует optional-типы вроде String? и требует извлечь значение перед обычным использованием.
• Kotlin и Dart тоже отмечают nullable-типы знаком ?, а safe call и явные проверки сужают их до non-null.
• TypeScript проверяет null только при включённом strictNullChecks, и эти проверки не валидируют JSON во время выполнения.
• Операторы Swift !, Kotlin !! и Dart ! обходят защиту, поэтому подходят только для заранее доказанных инвариантов.

Значение копируется как независимые данные, а ссылка позволяет нескольким переменным указывать на один объект.

• Структуры Swift имеют семантику значения, поэтому изменение копии Settings не меняет оригинал.
• Классы Swift, экземпляры классов Kotlin и объекты Dart имеют ссылочную идентичность, поэтому мутация видна через все ссылки.
• Data class в Kotlin предоставляет удобный copy, но его экземпляры остаются ссылками, а вложенные изменяемые объекты могут быть общими.
• Неизменяемые модели в стиле значений упрощают состояние UI, потому что обновление заменяет данные, а не скрытно меняет их.

Асинхронная работа не даёт сетевым и дисковым операциям заморозить главный UI-поток.

• Swift async и await, корутины Kotlin и Future в Dart приостанавливают задачу на время ожидания вместо блокировки интерфейса.
• В React Native асинхронные результаты обычно представлены Promise и обрабатываются через async и await.
• UI нужно обновлять в главном контексте платформы, даже если данные загружались в другом месте.
• Ошибки и отмену надо обрабатывать явно, потому что экран может закрыться до завершения операции.

Экран на UIKit обычно состоит из UIViewController и иерархии объектов UIView.

• UILabel, UIButton и UITableView создаются в коде или подключаются из storyboard.
• Auto Layout constraints задают положение и размеры относительно guides, соседних элементов или родительского view.
• Контроллер обрабатывает события жизненного цикла и действия пользователя, а затем императивно обновляет view.
• Данные и бизнес-правила лучше держать вне view controller, чтобы он не превратился в огромный универсальный класс.

SwiftUI описывает view как функцию текущего состояния и пересчитывает body при изменении наблюдаемого состояния.

• VStack, HStack и ZStack располагают дочерние view вертикально, горизонтально или слоями.
• Простое состояние, принадлежащее view, можно хранить в @State, а общие данные модели должны приходить из наблюдаемого источника.
• Модификаторы возвращают новые описания view, поэтому их порядок может менять компоновку и внешний вид.
• Body может вычисляться много раз, поэтому он должен описывать UI, а не запускать неконтролируемые побочные эффекты.

Compose повторно вызывает composable-функции, которые прочитали изменившееся состояние.

• remember сохраняет значение между recomposition, а rememberSaveable умеет также восстанавливать поддерживаемые значения после пересоздания Activity.
• Mutable state нужно менять через его holder, чтобы Compose заметил обновление.
• Compose может пропустить неизменившиеся composable, если их входные данные остались стабильными.
• Дорогие вычисления стоит вынести из часто выполняемого кода или мемоизировать по используемым входным данным.

React Native рендерит платформенные view из React-компонентов, а не обычный HTML в браузере.

• View, Text и Pressable соответствуют нативным примитивам интерфейса, а не элементам div, span и button.
• Компоновка использует Flexbox-модель Yoga с отличающимися от браузерного CSS значениями по умолчанию, например вертикальной главной осью.
• TypeScript или JavaScript отвечает за React-логику, а native modules открывают API устройства, которых нет в самом фреймворке.
• WebView служит отдельным компонентом для веб-контента и не участвует в обычном рендеринге React Native-экрана.

Widget во Flutter представляет собой неизменяемое описание части пользовательского интерфейса.

• У StatelessWidget нет собственного изменяемого объекта State, но он может зависеть от inherited context, например Theme или MediaQuery.
• Widgets образуют дерево конфигурации, из которого Flutter создаёт структуры элементов и render objects для обновления и layout.
• Для композиции часто используются Row, Column, Stack, Padding и ListView.
• Небольшие widgets с явными параметрами конструктора упрощают понимание rebuild и повторное использование.

Декларативный UI описывает, как интерфейс должен выглядеть при текущем состоянии, вместо последовательности ручных изменений view.

• В состоянии загрузки описание возвращает индикатор, а после успешной загрузки возвращает контент, поэтому видимую ветку определяет модель состояния.
• Фреймворк сравнивает или повторно вычисляет описания и применяет нужные изменения к отрисованному интерфейсу.
• У состояния должен быть понятный владелец, иначе несколько копий одного значения превращаются в конфликтующие источники истины.
• Код рендеринга не должен содержать неконтролируемых побочных эффектов, потому что он может выполняться многократно.

Мобильная компоновка задаёт связи и гибкое пространство вместо фиксированных координат в пикселях.

• UIKit использует Auto Layout constraints, а SwiftUI и Compose строят компоновку из стеков, размеров и гибких модификаторов.
• React Native использует Flexbox, а во Flutter constraints идут вниз по дереву, после чего размеры передаются вверх.
• Фиксированный размер подходит иконкам, но области контента должны расширяться, переноситься или прокручиваться.
• Проверяйте узкие и большие телефоны, landscape и увеличенный текст, потому что одной ширины экрана недостаточно для всех ограничений.

Логические единицы сохраняют похожий воспринимаемый размер элементов на экранах с разной плотностью пикселей.

• iOS строит layout в points, Android использует dp для геометрии и sp для текста, а Flutter использует логические пиксели.
• Операционная система переводит эти единицы в подходящее конкретному устройству число физических пикселей.
• Изображению могут понадобиться варианты для разных плотностей, чтобы оно оставалось чётким при неизменном размере в layout.
• Текст должен учитывать выбранный пользователем масштаб шрифта, а не помещаться в фиксированную физическую высоту.

Safe areas и insets описывают области экрана, перекрытые системным UI или аппаратными элементами устройства.

• Status bar, вырез камеры, navigation bar и home indicator могут перекрывать контент, нарисованный от края до края.
• iOS предоставляет safe-area guides, а Android предоставляет window insets для системных панелей и вырезов экрана.
• Flutter SafeArea и аналогичные API фреймворков добавляют нужные отступы вокруг важного контента.
• Фон может заходить под системный UI, но элементы управления и важный текст должны оставаться доступными и видимыми.

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

• Временное состояние элемента, например открыто ли меню, храните внутри компонента-владельца этого меню.
• Общее состояние формы или выбора поднимайте в родителя или модель экрана, а вниз передавайте значения и события.
• Фильтрованное количество вычисляйте из исходного состояния, а не храните второй экземпляр, который может устареть.
• Recomposition или rebuild после изменения состояния нормальны, поэтому обычный рендеринг не должен напрямую запускать дорогой I/O.