Промты для мобильной разработки редко пишут так, как для бэкенда: React Native живёт на стыке двух платформ, и половина боли — не в бизнес-логике, а в навигации, ре-рендерах списков и релизной возне с сертификатами. Универсальный «напиши мне код» здесь работает плохо: модель уверенно выдаёт FlatList без keyExtractor и советует ScrollView там, где 5000 элементов.
Ниже — 10 рецептов, которые я собрал под реальные задачи мобильного разработчика: от структуры навигации в React Navigation до отладки краша на устройстве и подготовки билда. Формат один: задача → промт → пример результата. Промты — не магия, а способ сжать контекст: чем точнее вы опишете версию, платформу и ограничения, тем меньше модель фантазирует.
Базовый уровень: навигация и списки
1. Каркас навигации под реальный сценарий
Задача: собрать стек + табы так, чтобы не переделывать через месяц. Модель без контекста лепит вложенные навигаторы наугад.
Промт:
Ты — React Native-разработчик. Спроектируй навигацию для приложения
«доставка еды» на React Navigation v7 (native-stack + bottom-tabs).
Сценарии: авторизация → главный таб (каталог) → карточка блюда → корзина →
оформление → экран успеха (не должен возвращаться назад).
Требования: типобезопасные параметры экранов, deep link на карточку блюда,
сохранение состояния табов при переключении. Покажи дерево навигаторов,
типы ParamList и где ставить initialRouteName. Не пиши UI-код.
Пример результата: модель вернёт дерево `RootStack (Auth
| Main | Success), гдеMain— таб-навигатор, аSuccessлежит в корневом стеке сpresentation: 'modal'иheaderBackVisible: false, плюсRootStackParamListс{ Dish: { id: string } }и конфигlinkingдля путиdish/:id`.
2. Оптимизация FlatList, а не переписывание с нуля
Задача: список лагает на Android при 1000+ элементах. Просить «оптимизируй» бесполезно — нужен диагноз.
Промт:
FlatList с карточками товаров (изображение + текст) дёргается при скролле
на Android. Вот компонент: [код]. Найди причины ре-рендеров и предложи
3 уровня правок: (1) обязательные props, (2) memo-обёртки, (3) вынос
тяжёлой логики. Для каждой правки объясни механизм — почему это влияет
на кадры. Не предлагай FlashList, пока не исчерпаны правки FlatList.
Пример результата: модель укажет на отсутствие keyExtractor, инлайн-стрелку в renderItem (новый референс каждый рендер), ListHeaderComponent как JSX-элемент вместо мемоизированного компонента и отсутствие getItemLayout при фиксированной высоте карточки.
Здесь важна честность модели: getItemLayout работает только при одинаковой высоте элементов. Если карточки разной высоты — это не оптимизация, а источник съехавшего скролла.
3. Экран с формой и валидацией
Задача: быстро получить рабочий экран логина с обработкой ошибок.
Промт:
Экран логина на React Native + TypeScript. Поля email и пароль, валидация
на blur, состояния: idle/validating/error/submitting. Покажи KeyboardAvoidingView
с правильным behavior для iOS (padding) и Android (height),
отключение submit во время запроса, accessibilityLabel на кнопке.
Пример результата: готовый компонент с useState для каждого поля и отдельным errors-объектом; модель напомнит, что keyboardType="email-address" и autoCapitalize="none" обязательны для email.
Продвинутый уровень: Expo, отладка, хранилище
4. Миграция на Expo или отказ от него
Задача: решить, тянуть ли проект в Expo. Это trade-off, а не «всегда да».
Промт:
Сравни bare React Native и Expo (managed + dev builds) для приложения с
камерой, push-уведомлениями и нативным SDK банка, который требует
ручной интеграции .aar. Дай таблицу: что работает из коробки, что требует
config plugin, что блокирует. Назови конкретный режим отказа каждой опции.
Пример результата: модель объяснит, что Expo-модули и config plugins покрывают камеру и push, но сторонний .aar без плагина потребует перехода на dev build с нативным кодом — иначе сборка упадёт на этапе линковки.
| Критерий | Bare RN | Expo (dev build) |
|---|---|---|
| Камера, push | вручную | модули из коробки |
| Сторонний .aar | напрямую | через config plugin |
| EAS Build | настраивать самому | готовый пайплайн |
| Контроль нативного кода | полный | ограничен плагинами |
5. Отладка краша на устройстве
Задача: приложение падает только на реальном iPhone, в симуляторе — тишина.
Промт:
Приложение падает на физическом iOS-устройстве при открытии экрана с
камерой. Симулятор работает. Вот лог из Xcode Organizer: [лог].
Составь пошаговый план: какие permissions в Info.plist проверить,
как воспроизвести через Console.app, что смотреть в crash log
(exception type, thread). Не придумывай причину — перечисли гипотезы
по убыванию вероятности.
Пример результата: модель предложит проверить NSCameraUsageDescription (без него iOS убивает приложение при первом обращении), затем — гонку на инициализации нативного модуля и EXC_BAD_ACCESS в crash log.
6. Локальное хранилище без иллюзий
Задача: выбрать между AsyncStorage, MMKV и SQLite.
Промт:
Выбери хранилище для: (а) токен авторизации, (б) кэш 2000 товаров
с фильтрами, (в) черновик формы. Ограничения: iOS Keychain для секретов,
скорость чтения на старте, размер данных. Дай таблицу и предупреди
о типичных ошибках (синхронность, шифрование, миграции).
Пример результата: токен — Keychain через expo-secure-store или react-native-keychain, кэш — SQLite с индексами по фильтрам, черновик — AsyncStorage. Модель предупредит: AsyncStorage асинхронный и не шифрует данные, а MMKV синхронный и быстрее на частых записях.
Экспертный уровень: производительность и релиз
7. Профилирование ре-рендеров
Задача: экран тормозит, но непонятно, какой компонент виноват.
Промт:
Экран профиля ре-рендерится при каждом вводе в поле поиска в шапке.
Вот дерево компонентов: [код]. Объясни, как React Native DevTools
(React Profiler) покажет лишние рендеры, и предложи правки:
React.memo, useCallback, вынос контекста. Покажи, как проверить
результат до/после.
Пример результата: модель укажет, что контекст поиска обёрнут вокруг всего экрана — при вводе перерисовывается всё дерево. Решение: вынести провайдер ниже или разделить контекст на два (query и setQuery), чтобы компоненты, читающие только сеттер, не ре-рендерились.
8. Сборка Android: подпись и версии
Задача: собрать релизный AAB без сюрпризов.
Промт:
Проведи чек-лист релизной сборки Android для React Native:
versionCode/versionName, подпись через keystore, .gitignore для keystore,
build.gradle signingConfigs, команда сборки AAB. Покажи пример
signingConfigs и объясни, что будет, если versionCode не увеличить.
Пример результата: модель даст signingConfigs { release { storeFile, storePassword, keyAlias, keyPassword } }, напомнит про cd android && ./gradlew bundleRelease и предупредит: без роста versionCode Google Play отклонит загрузку — новый билд не примут.
9. iOS и App Store: сертификаты и TestFlight
Задача: провести билд до TestFlight и не застрять на подписи.
Промт:
Пошаговый план публикации React Native-приложения в App Store:
Apple Developer Program, App ID, provisioning profile, архив в Xcode,
загрузка через Transporter, TestFlight. Для каждого шага — типичная
ошибка. Отдельно: что делать при «Missing Compliance» и как
заполнить App Privacy.
Пример результата: последовательность от создания App ID до внутреннего тестирования, с пометкой, что Missing Compliance снимается ответом на вопрос об экспортном шифровании в App Store Connect, а App Privacy требует перечислить собираемые типы данных.
10. Автоматизация релиза в CI
Задача: убрать ручную сборку.
Промт:
Опиши CI-пайплайн (GitHub Actions) для React Native: сборка Android AAB
и iOS через EAS Build, версионирование, кэш зависимостей. Покажи
workflow-файл и объясни, какие секреты хранить (keystore, Apple API key)
и как не светить их в логах.
Пример результата: YAML с шагами setup-node, кэшем yarn, вызовом eas build --platform all --non-interactive и секретами из GitHub Secrets. Модель напомнит: --non-interactive требует заранее заданных переменных окружения, иначе сборка повиснет.
Как не превратить LLM в генератор багов
Три правила, которые экономят нервы. Первое: всегда указывайте версию React Native, React Navigation и Expo — API между мажорами ломается, и совет под v5 развалит проект на v7. Второе: просите модель перечислять режимы отказа, а не только решение — так вы ловите getItemLayout на разных высотах и permission-краши до запуска. Третье: код от модели — черновик, а не истина; прогоняйте через линтер и на реальном устройстве.
Если хотите глубже — в блоге есть разбор промтов для код-ревью и промтов для Data Science, а основы работы с версиями пригодятся из материала про Git и GitHub.
Начните с одного промта сегодня: возьмите свой самый лагающий экран и попросите у модели не «оптимизировать», а поставить диагноз по коду. Разница в ответе будет заметна сразу.
