Почему платежные приложения, созданные на основе «вайб-кодинга», отклоняются в App Store

Платежные приложения, созданные на основе вайб-кодинга, отклоняются из App Store чаще, чем практически любые другие приложения в очереди на модерацию, и причины обычно никак не связаны с качеством кода. Приложение, созданное методом вайб-кодинга — то есть собранное путем описания ваших пожеланий ИИ-ассистенту и отправленное в том виде, в каком он его написал, — внешне может быть неотличимо от профессиональной работы. Но модерация Apple не оценивает код. Она проверяет, кто отправил приложение, какой платежный механизм обрабатывает тот или иной тип товаров, были ли отдельно одобрены аппаратные разрешения и может ли модератор совершить реальную транзакцию. Это именно те вещи, которые ИИ-ассистент сгенерировать не может.

Это стена, в которую упираются все после создания индивидуальной POS-системы с помощью ИИ-модели: код пишется за один день, но перенос его на iPhone в качестве реального платежного приложения — это процесс соблюдения требований, а не задача по программированию.

Направил ли ваш ИИ платежи через неверную систему?

Самая частая причина отклонения — использование неверного платежного механизма для продаваемых товаров, и ИИ-ассистенты на удивление часто ошибаются именно в этом. Руководство по модерации App Store проводит жесткую границу. Цифровой контент и услуги, потребляемые внутри приложения, должны использовать встроенные покупки Apple в соответствии с пунктом 3.1.1. Физические товары и услуги в реальном мире — кофе, стрижка, доставка заказа — должны делать прямо противоположное согласно пункту 3.1.5(a): они вообще не могут использовать встроенные покупки и требуют внешнего метода оплаты.

Модель для написания кода воспроизводит тот шаблон платежей, который преобладал в ее обучающих данных — шаблонный код встроенных покупок из руководств по подпискам или SDK для веб-оплаты из примеров электронной коммерции, — даже не спрашивая, что именно вы продаете. Попросите ее создать «приложение, которое принимает платежи», и вы получите один из двух вариантов, выбранный на основе статистики, а не правил Apple. Правила также различаются в зависимости от региона: после решения по делу Epic в 2025 году приложения в магазине США могут ссылаться на внешние варианты покупки цифровых товаров, но это исключение действует только в Соединенных Штатах. Приложение, распространяемое по всему миру, по-прежнему должно соответствовать более строгому правилу во всех остальных странах.

Имеете ли вы вообще право отправлять платежное приложение?

Apple требует, чтобы приложения, связанные с управлением деньгами или финансовыми услугами, отправлялись организацией, которая фактически оказывает эти услуги, при наличии необходимых лицензий в каждом регионе, где доступно приложение — это пункт 3.2.1. Индивидуальный разработчик, выпускающий созданное ИИ платежное приложение, не является лицензированной финансовой организацией, как и агентство, отправляющее его для клиента. Предложение приложения в стране, где отсутствует лицензия на перевод денежных средств, приведет к отклонению по той же причине, но с другой формулировкой.

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

Почему для Tap to Pay требуется отдельный процесс одобрения?

Прием бесконтактных карт на iPhone требует разрешения Tap to Pay on iPhone — это отдельная заявка в Apple, не зависящая от модерации приложения, которая предоставляется юридическому лицу, а не кодовой базе. Разрешение на разработку обычно одобряется за день-два. Разрешение на публикацию проходит через операционную команду Apple, обычно занимает от одной до двух недель и требует работы с поддерживаемым провайдером платежных услуг. ИИ-ассистент с радостью напишет код для Tap to Pay, не упомянув ни слова об этом; отправьте приложение до получения разрешения, и оно будет отклонено.

Прием физических карт также влечет за собой требования, которые не контролируются Apple: сертифицированное терминальное оборудование, правила EMV и соответствие стандарту PCI для всего, что касается данных карт. Ничего из этого не появится само по себе из модели, пишущей на Swift.

Может ли модератор действительно завершить транзакцию?

Пункт 2.1 «Полнота приложения» незаметно губит больше платежных приложений, чем сами правила платежей. Модераторы должны иметь возможность протестировать приложение полностью, включая процесс оплаты. Платежное приложение обычно требует наличия учетной записи продавца, подтверждения личности, а иногда и банковского счета — вещей, которые модератор не может оформить во время проверки. Работы, созданные методом вайб-кодинга, постоянно срезаются на этом этапе, потому что разработчик часто сам никогда не настраивал реальный аккаунт продавца; приложение тестировалось только на макетных данных, которые ИИ сгенерировал вместе с ним. Без работающего демо-аккаунта и возможности провести тестовую транзакцию приложение отклоняется как незавершенное, а каждая повторная отправка стоит еще одного цикла проверки.

Что же в итоге попадает в релиз?

Сложной частью никогда не был код. ИИ-ассистент может создать работающий интерфейс оформления заказа за один день, но дистрибуция в App Store — это полоса препятствий из разрешений, лицензирования и политик модерации, которые находятся полностью за пределами возможностей текстового запроса. Демо-версия работает, но инфраструктуры для нее не существует.

Для продавца, реализующего физические товары, практический вывод проще: не вставайте в эту очередь. Вашему бизнесу нужна работающая касса, а не собственное приложение в App Store — лицензирование, сертификация оборудования и накладные расходы на модерацию имеют смысл только для компаний, чьим продуктом является само платежное программное обеспечение. Работайте за прилавком на POS-платформе, которая уже взяла на себя эти расходы (Final построена именно так — платежи через Final Pay с сертифицированным терминальным оборудованием, без необходимости публиковать собственное приложение), а деньги, сэкономленные на циклах модерации, направьте на то, что увеличивает выручку, например на ускорение процесса оформления заказа и снижение эффективных комиссий по картам.

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