Развертывание приложений React Native в App Stores: полный контрольный список

Реальность развертывания мобильных приложений

Развертывание приложения React Native в Apple App Store и Google Play Store является важной вехой, с которой сталкивается каждый мобильный разработчик. В то время как React Native дает вам возможность ориентироваться на обе платформы из одной кодовой базы, путь к успешному запуску производства включает в себя строгие руководящие принципы, сложную инструментальную поддержку сборки и тщательное тестирование. Один надзор - отсутствующая строка разрешения, неправильно настроенный магазин ключей или недостижимая конечная точка API - может задержать запуск на несколько дней или недель.

Это руководство предоставляет закаленный контрольный список для развертывания приложений React Native. Независимо от того, отправляете ли вы простое приложение или сложную платформу, основанную на контенте, на основе Directus, эти шаги помогут вам уверенно ориентироваться в процессе подачи. Цель состоит в том, чтобы устранить сюрпризы и обеспечить стабильный опыт для ваших пользователей в первый день.

Укрепление перед развертыванием

Тестирование полноты

Прежде чем вы даже подумаете о создании артефакта релиза, ваше приложение должно быть тщательно проверено. Это выходит за рамки прохождения единичных тестов. Вы должны выполнять сквозное тестирование на физических устройствах, охватывая весь спектр размеров экрана iOS и Android и версий ОС. Если ваше приложение React Native опирается на бэкэнд Directus, интеграционное тестирование становится необходимым. Убедитесь, что ваши вызовы API обрабатывают сетевые тайм-ауты изящно, что запросы Directus SDK возвращают данные в ожидаемом формате и что ваше приложение отображает значимые ошибки, если бэкэнд недостижим.

Окончательная доработка активов

Оба магазина приложений предъявляют строгие требования к визуальным активам. Не ждите до последней минуты, чтобы сгенерировать эти файлы.

• iOS: Подготовьте значки приложений всех требуемых размеров (@1x, @2x, @3x). Предоставьте скриншоты для каждого необходимого размера устройства (6,5-дюймовый, 5,5-дюймовый, iPad Pro и т. д.).
• Android: Создавайте адаптивные значки (на переднем и заднем плане слоев). Создавайте графические функции и скриншоты для телефона и планшета.
• Splash Screen: Используйте библиотеки, такие как react-native-bootsplash, чтобы ваш брызг экран соответствовал вашему бренду и плавно переходил в приложение.

Permissions & Конфиденциальность

Это один из самых распространенных камней преткновения во время просмотра. Каждое разрешение, которое запрашивает ваше приложение, должно быть оправдано для пользователя.

• iOS Info.plist: Для каждого разрешения (камера, библиотека фотографий, местоположение, микрофон) вы должны предоставить целевую строку. Если ваше приложение использует Directus для загрузки мультимедиа, ваша строка должна быть конкретной: «Нам нужен доступ к вашей камере для загрузки вашей фотографии профиля».
• Android Manifest: Удалите ненужные разрешения. Google Play строго относится к приложениям, которые запрашивают разрешения, такие как READ CONTACTS или CALL PHONE без четкого требования к функции.
• Тестирование: Пройдите через каждый поток разрешений в сборке релиза. Что произойдет, если пользователь нажмет «Отрицать»? Сбой вашего приложения или изящно вернется к опции ручного ввода?

Backend Lockdown (фактор Directus)

Общий надзор - это оставить бэкэнд доступным после запуска приложения. Если ваше приложение React Native полагается на Directus как безголовую CMS, предварительное развертывание - это время для правильной настройки вашей производственной среды.

• Роли и разрешения: Отключить публичный доступ к панели администратора. Создать выделенную роль API, которая имеет именно те разрешения, которые необходимы для вашего приложения. Используйте систему разрешений Directus, чтобы ограничить операции чтения, создания, обновления и удаления на основе сбора данных.
• Конфигурация CORS: Заблокируйте совместное использование ресурсов с перекрестным происхождением, чтобы принимать только запросы из домена или пользовательской схемы вашего приложения.
• Ограничение ставок: Защитите свой Directus API от злоупотреблений, включив ограничение скорости.
• Статические токены против динамического аута: Решите заранее, будет ли ваше приложение использовать статический токен API для общедоступных данных или полный поток аутентификации для пользовательских данных.Статические токены проще для общедоступного контента, но аутентификации пользователей (через встроенную систему аута Directus) требуется для персонализированного опыта.

Ссылка: Передача документов по прямому разрешению

Конфигурация окружающей среды и усилие; Управление секретами

Жесткое кодирование API-ключей или URL-адреса проекта Directus в исходный код является критическим риском для безопасности. Это также делает поддержание различных сред (постановка, производство) излишне болезненным.

.env Экосистема

Используйте библиотеки, такие как react-native-dotenv (для простого React Native) или expo-constants (для проектов Expo) для управления переменными среды.

• Создайте отдельные файлы: .env.staging и .env.production.
• Храните URL-адрес экземпляра Directus, статический токен (если применимо) и любые сторонние ключи API здесь.
• Никогда не передавайте эти файлы в систему управления версиями. Добавьте их в свой .gitignore.

Безопасное хранение пользовательских токенов

Когда пользователь аутентифицируется против вашего бэкэнда Directus, возвращенный токен доступа никогда не должен храниться в обычном тексте или в AsyncStorage в течение длительных периодов времени. Используйте react-native-keychain (iOS) или react-native-encrypted-storage (Android) для безопасного хранения конфиденциальных учетных данных. Это защищает ваших пользователей в случае компрометации физического устройства.

Здание для освобождения

Запуск npx-реактивного run-ios или run-android не является достаточным для производства. сборки релизов требуют подписи кода, оптимизации и конкретных форматов распространения.

Android: подписанный AAB

Google Play теперь требует Android App Bundle (AAB) для новых приложений.

• Создайте магазин ключей для производства с помощью команды Android Studio или команды keytool.
• Поместите файл хранилища ключей в каталог и Android/app.
• Создайте файл key.properties , ссылающийся на путь вашего хранилища ключей, пароль, псевдоним ключа и пароль ключа.
• Настройте свой android/app/build.gradle, чтобы читать key.properties для конфигурации подписи.
• Запустите cd android &&./gradlew bundleRelease для создания файла AAB.
• Примечание: Никогда не теряйте файл хранилища ключей. Без него вы не можете выпускать обновления для своего приложения.

iOS: архив и экспорт

Для дистрибутива iOS требуется активное членство в программе Apple Developer Program.

• Создайте сертификат дистрибуции и профиль предоставления на портале разработчиков Apple.
• В Xcode выберите цель для своего приложения и перейдите к Signing & Capabilities. Убедитесь, что вы используете профиль распределения продукции.
• Установите схему сборки на «Выпустить».
• Перейдите в Product > Archive. После того, как архив будет построен, откроется окно Организатора. Нажмите «Распространить приложение» и выберите «Подключить магазин приложений».

EAS Build (Экспо)

Если вы используете Expo, EAS Build - это рекомендуемый способ создания сборок производства. Он обрабатывает подписание, генерацию ключей и облачную компиляцию.

• Установите eas-cli и войдите в свою учетную запись Expo.
• Run eas build — Platform all —profile production.
• EAS будет автоматически управлять вашим Android-клавиатурой и сертификатами iOS, надежно сохраняя их на серверах Expo.
• Этот подход легко интегрируется с EAS Submit для загрузки в магазины.

Ссылка: EAS Build Documentation

Предварительная гарантия качества

Загрузка сборки для выпуска в TestFlight (iOS) или Internal App Sharing (Android) должна быть обязательным шагом перед нажатием «Отправить на просмотр».

TestFlight (iOS)

После загрузки архива в App Store Connect включите TestFlight. Вы можете пригласить внутренних тестеров (до 100 членов вашей команды) без необходимости бета-обзора. Для внешних тестеров вы должны представить сборку для Beta App Review, которая следует аналогичным рекомендациям к полному обзору App Store. Используйте это, чтобы рано улавливать проблемы.

Внутренний обмен приложениями (Android)

Консоль Google Play позволяет загружать AAB и генерировать общую ссылку для распространения тестировщикам. Это быстрее, чем управление полным бета-треком и идеально подходит для окончательной проверки.

QA Checklist для проверки строительства

• Глубокие ссылки: Тестирование универсальных ссылок (iOS) и ссылок приложений (Android). Убедитесь, что они правильно направляют пользователей к нужному контенту, особенно если вы используете Directus для управления динамическими направлениями глубоких ссылок.
• Поддержка в автономном режиме: Обрабатывает ли ваше приложение потерю сетевого подключения? Отображает ли оно кэшированные данные? Если ваше приложение полагается на данные Directus, которые не часто меняются, рассмотрите возможность кэширования ответов локально с использованием react-native-mmkv или AsyncStorage.
• Push-уведомления: Убедитесь, что push-уведомления настроены на сертификат производства (iOS) и ключ обмена сообщениями Firebase Cloud (Android).Проверьте полный поток уведомлений, включая нажатие на уведомление, чтобы открыть конкретный элемент контента Directus.
• Аналитика и отчетность о крушении: Проверьте, что Firebase или Sentry инициализированы с производственной конфигурацией. Сделайте преднамеренный сбой в тесте, чтобы отчет о сбое появился на панели мониторинга.

Процесс представления и рассмотрения

Рекомендации по обзору App Store, как известно, строги, в то время как Google Play в значительной степени полагается на автоматизированные проверки, хотя человеческие обзоры становятся все более распространенными для соблюдения политики.

Оптимизация метаданных

• Магазин приложений: Выбирайте ключевые слова тщательно. Они являются одним из основных способов, с помощью которых пользователи находят ваше приложение за пределами прямого поиска.
• Google Play: Напишите убедительное, богатое ключевыми словами описание. Первые несколько строк являются наиболее важными для ранжирования в поиске.
• Скриншоты: Убедитесь, что ваши скриншоты отражают последнюю версию вашего приложения. Если вы обновили пользовательский интерфейс после альфа-тестирования, сделайте новые скриншоты. Устаревшие визуальные эффекты являются распространенной причиной отказа.

Соблюдение и законность

• Удаление учетной записи: Оба магазина теперь требуют, чтобы приложения, поддерживающие создание учетной записи, также позволяли удаление учетной записи непосредственно в приложении. Если вы используете управление пользователем Directus, убедитесь, что в вашем приложении есть кнопка, которая запускает конечную точку DELETE /users/me через SDK. Пользователи должны иметь возможность очищать свои данные без необходимости отправлять по электронной почте администратору.
• Политика конфиденциальности: Вы должны предоставить URL-адрес политики конфиденциальности. Это относится как к iOS, так и к Android. Если вы собираете какие-либо личные данные (имена, адреса электронной почты, данные об использовании с помощью аналитики), ваша политика должна отражать это.
• Прозрачность отслеживания приложений (iOS): Если ваше приложение использует Firebase Analytics, Mixpanel или аналогичные SDK, вы должны запросить разрешение пользователя через запрос ATT.

Ссылка: Руководство по обзору Apple App Store

Обработка отклонения

Отказ является общей частью процесса. Ключ в том, чтобы реагировать быстро и профессионально.

• Внимательно прочитайте причину отказа. Это проблема с метаданными (текст заполнителя оставлен на скриншоте)? Неработающая ссылка (ваш экземпляр Directus был отключен во время обзора)?
• Если вашему приложению требуется вход в систему, убедитесь, что вы предоставили демо-счет для рецензента. Включите четкие инструкции: «Войти с [email protected] / password123. Эта учетная запись имеет доступ только для чтения к бэкэнду Directus».
• Обжалуйте отказ напрямую, если вы считаете, что ваше приложение соответствует рекомендациям. Если вам нужно исправить проблему, решить ее, загрузить новую сборку и отправить новый запрос на обзор.

Послезапускные операции

Поздравляем, вы в прямом эфире. Процесс развертывания не останавливается на "Готовы к продаже". Долгосрочный успех зависит от мониторинга и итерации.

Мониторинг производственного здоровья

• Настройте оповещения о производительности в Sentry или Firebase Crashlytics. Следите за сбоями, которые коррелируют с конкретными устройствами или версиями ОС.
• Контролируйте нагрузку на сервер Directus. Оптимизированы ли ваши запросы API? Используйте встроенные поля Directus и фильтры в ваших запросах SDK, чтобы уменьшить размер полезной нагрузки и избежать получения ненужных данных.
• Если вы обслуживаете пользователей по всему миру, рассмотрите возможность развертывания Directus в регионе, близком к вашей пользовательской базе, или использования CDN перед вашими активами.