Разработка мобильных приложений
в США

Делаем нативные (Swift/Kotlin) и кросс-платформенные (React Native, Flutter) приложения. Выбор зависит от вашей аудитории и бюджета — обсудим на первой встрече.

Да, работаем по инвойсу в USD (wire/Payoneer). График платежей — 50/50 или по вехам для крупных проектов.

Да, сопровождаем весь процесс публикации: создание аккаунтов разработчика, скриншоты, описания (RU/EN), submission и ответ на замечания ревьюеров.

На русском. При необходимости переписку и документацию дублируем на английском.

Назначаем созвоны в удобное для вас время — перекрытие с ET и PT доступно. Асинхронная коммуникация через трекер, ответ по рабочим вопросам в течение нескольких часов.

App Store Review Guidelines одинаковы для всех регионов. Придирок на практике больше к трём вещам — заполненным App Privacy details, работающему удалению аккаунта и понятному назначению пуш-уведомлений. Google Play отдельно смотрит на декларацию Data safety, и расхождение декларации с кодом ревьюер видит. Эти данные готовим до отправки, а ревьюеру заранее заводим демо-вход.

Публиковать можно с любого юрлица. Страна аккаунта меняет только налоговые формы в App Store Connect, доступность приложения в US-сторе от неё не зависит. Для organization-аккаунта Apple спросит номер D-U-N-S — он бесплатный, но выдают его не за один день. Если юрлица нет вовсе, подойдёт individual-аккаунт, правда в сторе тогда будет видно имя человека.

С iOS 14.5 приложение обязано спросить разрешение, прежде чем читать IDFA для трекинга между сервисами. Отказывается заметная часть аудитории. Значит атрибуция рекламы в США держится на SKAdNetwork, собственных событиях и агрегированных отчётах, а сквозной путь «клик — установка — покупка» по конкретному человеку собрать уже нельзя. Закладываем это в схему аналитики на проектировании: переделывать воронку после запуска дороже.

Да, если в приложении есть регистрация. Apple требует, чтобы удаление запускалось из самого приложения, и письма в поддержку для этого недостаточно. Google Play просит того же плюс веб-страницу для удаления данных. На экране удаление аккаунта должно читаться отдельно от выхода из него — формулировку проверяем до сабмита.

Цифровой контент и подписки внутри приложения идут через In-App Purchase: ставка 30 %, для участников Small Business Program 15 %. Физические товары и услуги можно принимать своим платёжным провайдером. Граница проходит по типу товара, и в спорных случаях её лучше выяснить до выбора биллинга. Переписать оплату после отказа ревью — это отдельный спринт.

Закон Калифорнии даёт жителю штата право узнать состав собранных данных и потребовать удаления, а порог применимости считается по выручке компании и объёму этих данных. В интерфейсе это экран приватности, ссылка на политику и работающий запрос на удаление. Похожие законы приняли Вирджиния, Колорадо, Техас и ещё несколько штатов. Один такой экран закрывает их все.

Да. По мобильным приложениям в США идут иски о доступности по Title III ADA, и суды берут WCAG за ориентир, хотя отдельного техрегламента для приложений в законе нет. Технически это подписи для скринридера, Dynamic Type, контраст и размер зон нажатия. Заложенное на этапе вёрстки стоит дёшево, прикрученное потом переписывает половину экранов.

Дата в формате MM/DD/YYYY, номер вида +1 (212) 555-0123, ZIP из пяти цифр, дюймы и фунты. Поле «отчество» убираем, штат в адресе выносим отдельным списком. Меняется и тон системных сообщений — американский интерфейс говорит короче и обходится без извинений. Правится это в макетах и строковых файлах, пока экраны ещё не собраны.

Apple требует описывать, какие данные собирает приложение и зачем оно обращается к чувствительным системным интерфейсам. Манифест идёт внутри сборки. Для части интерфейсов причину использования выбирают из закрытого списка, свободный текст там не принимается. Сторонние библиотеки обязаны приносить свои манифесты и подписи. Отсутствие манифеста у одной зависимости останавливает загрузку всей сборки в стор. Из-за этого состав библиотек мы проверяем до сборки релиза. Отказ стора обходится неделей ожидания.

Форма в App Store Connect перечисляет типы данных и цели их сбора. Заполняется она под ответственность разработчика. Расхождение с фактическим поведением приложения ведёт к снятию с публикации, и жалоба пользователя такую проверку запускает. Ответы собираем вместе с вашей командой. Причина простая: данные собирает не только ваш код. Их тянет подключённый SDK аналитики или рекламной сети, о котором в брифе никто не вспомнил. Карту данных приложения держим одним документом.

Ответ зависит от того, как приложение выглядит. Текст описания тут не решает. Закон о защите детей в интернете смотрит на аудиторию по факту. Яркая графика, персонажи и простая механика делают продукт привлекательным для детей независимо от заявленного возраста. Если такой риск есть, безопаснее закрыть рекламу с таргетингом и сократить сбор данных через возрастные настройки. Проверку делаем на этапе дизайна: переделка механики после релиза выходит дороже.

Системный запрос показывается один раз. Отказ пользователь отменяет редко, и повторно спросить нельзя. Значит запрос ставим после того, как человек увидел пользу. На первом экране его не показываем. Маркетинговые и транзакционные уведомления разделяем: часть аудитории готова получать статус заказа и не готова получать акции. Настройки выносим внутрь приложения, чтобы отключение одного канала не убивало все. Такой порядок поднимает долю согласий и снижает удаления в первую неделю.

Экран обязан показать цену, период, условия автопродления и длину пробного периода одним блоком до нажатия кнопки. Ссылки на условия и политику приватности обязательны. Рецензенты отклоняют экраны, где цена спрятана мелким шрифтом или период подписки не назван. Ещё одно требование забывают: приложение должно оставаться работоспособным, если человек подписку не купил. Экран собираем по гайдлайну и проверяем оба сценария — с покупкой и с отказом от неё.

Это своя форма со своей структурой: типы данных, шифрование при передаче, возможность удаления по запросу пользователя. Ответы в двух сторах обязаны совпадать по смыслу. Расхождение видно любому проверяющему за пять минут и читается как небрежность. Обе формы заполняем из одного источника — карты данных приложения. По памяти их не заполняют: через полгода никто не помнит, какие поля уходят в аналитику, а какие остаются на устройстве.

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

Через TestFlight на iOS и внутренний трек в Google Play. Вы получаете ссылку и ставите сборку на своё устройство. Каждая сборка идёт с описанием, что именно в ней проверять. Замечания собираем в трекере. Переписка в мессенджере для этого не годится: через две недели никто не найдёт, на каком экране была проблема. Такой порядок снимает вопрос «это уже исправлено» и даёт историю по каждому дефекту от первого сообщения до релиза.

В большинстве случаев нет. Одно приложение с локализациями и региональными настройками закрывает задачу. Вторая сборка нужна под названную причину: разные юридические требования, разная платёжная схема, разный состав функций. Каждая дополнительная сборка удваивает работу по релизам, ревью и поддержке версий. Из-за этого мы предлагаем её только когда причина названа и посчитана. Регион в одной сборке переключается настройкой, и это дешевле на всём сроке жизни продукта.

Будут. Приложения про здоровье, финансы и данные детей проходят более пристальное ревью. Часть категорий требует подтверждения, что за продуктом стоит зарегистрированная организация с соответствующей лицензией. Сроки растут. Отказ по документам возможен на любом круге. Эти сроки закладываем в календарный план, а документы готовим до подачи первой сборки. Порядок обратный — сначала сборка, потом документы — растягивает релиз на месяцы и ломает даты запуска маркетинга.

Частично. Правила изменились после судебных разбирательств, и в США теперь допускается сообщать пользователю о внешних способах оплаты со ссылкой наружу, с оговорками по оформлению экрана. Цифровой контент внутри приложения по-прежнему идёт через встроенные покупки. Комиссия магазина остаётся весомой частью экономики. Разбираем вашу модель и считаем два варианта в деньгах: через встроенные покупки и через внешнюю оплату с учётом потерь на переходе.

Проверочный код относится к транзакционным сообщениям. Правила по звонкам и рассылкам в США строгие, и согласие нужно фиксировать в момент его получения. В форме ставим явный чекбокс, храним отметку времени и текст, под которым человек подписался. Маркетинговые SMS отделяем от кодов и даём работающую отписку. Отправку ведём через провайдера с регистрацией отправителя: без регистрации операторы режут доставку, и код просто не приходит.

Google Play считает долю сессий с падениями и сравнивает её с порогом по категории. Превышение снижает видимость в каталоге. Apple такую метрику публично не выставляет, но отказ по нестабильности возможен на ревью. Сбор падений подключаем с первого релиза, до выхода в открытый доступ. Разбор регрессий держим в регламенте поддержки: падение, которое видит один процент пользователей, накапливает отзывы с одной звездой быстрее, чем команда успевает их прочитать.

Американская база обновляется быстрее среднего по миру. Свежие версии занимают её большую часть уже в первые месяцы после выхода. Поддержка старых версий требует денег на каждом релизе: свои ветки кода, свои прогоны тестов, свои дефекты. Смотрим фактическое распределение по вашей аудитории в консолях сторов и отсекаем хвост, который не оправдывает затрат. Решение фиксируем в договоре. Иначе список поддерживаемых версий ползёт вниз от релиза к релизу.