Почему приложение для доски объявлений для взрослых никогда не пройдёт проверку сторов, и что строить вместо него
Рано или поздно тот, кто ведёт каталог объявлений, задаёт себе тот же вопрос, что и любой основатель мобильного сервиса в первые месяцы: нужно ли это приложение. Кажется, что это очевидный следующий шаг. Значок на главном экране, push-уведомления о новом сообщении или проверенном объявлении, что-то, что выглядит серьёзнее, чем сайт. Кто-то в команде оборачивает сайт в приложение, отправляет его на проверку, и через несколько дней приходит отказ, никак не связанный с багом или отсутствующей политикой конфиденциальности. Его отклоняют за то, чем является бизнес, а не за то, что можно исправить и отправить заново.
Это стоит понять до того, как в это вложено время разработки. Apple и Google не решают для каждого приложения отдельно, хорошо ли управляется именно ваш каталог, хорошо ли он модерируется или полностью ли соответствует закону вашей страны. Они решили много лет назад, письменно, что этой категории бизнеса нет места на их платформах, и точка. Дальше речь о том, что на самом деле говорят правила, почему не существует конфигурации чистого, легального, с проверкой возраста маркетплейса, которая их обойдёт, и как выглядит мобильное присутствие, не зависящее от того, передумает ли одна из этих двух компаний.
Что на самом деле говорят правила
Правила проверки App Store компании Apple рассматривают это напрямую в разделе Objectionable Content, пункт 1.1.4. Формулировка не расплывчата: приложения не могут содержать "откровенно сексуальные или порнографические материалы", и далее правило уточняет, что это "включает приложения для 'хукапов' и другие приложения, которые могут содержать порнографию или использоваться для содействия проституции, торговле людьми и эксплуатации". Обратите внимание, что делает эта фраза. Она не запрещает откровенные изображения, которые каталогу объявлений в любом случае не нужно показывать. Она запрещает приложения, которые содействуют проституции как функции, независимо от того, как сформулированы или обрезаны объявления. Каталог со сдержанными, полностью одетыми фотографиями профиля и формой бронирования остаётся приложением, которое содействует именно тому, что названо в правиле.
Политика Google Play, пожалуй, ещё более явно называет эту категорию. Её правило о сексуальном контенте гласит, что Google не разрешает приложения или контент приложений, которые "продвигают или предлагают сексуальный акт в обмен на вознаграждение", и политика перечисляет в качестве конкретного примера приложения, которые "продвигают развлечения сексуального характера, услуги эскорта или другие услуги, которые можно истолковать как предложение или предоставление сексуальных актов в обмен на вознаграждение". Услуги эскорта названы напрямую, а не подразумеваются. Google идёт ещё дальше и отдельно запрещает "договорённости об оплачиваемых свиданиях или сексуальные договорённости, при которых от одного участника ожидается или подразумевается предоставление денег, подарков или финансовой поддержки другому участнику", то есть договорённость, обычно называемую sugar dating. Этот дополнительный пункт существует потому, что операторы пытались описывать тот же бизнес более мягким языком, и Google целенаправленно закрыл эту лазейку, а не оставил её на усмотрение толкования.
Стоит понять, почему обычные приложения для знакомств этим не затронуты. Tinder, Bumble и похожие приложения остаются в обоих сторах, потому что ничто в их заявленной функции не подразумевает вознаграждения за сексуальную договорённость. Это граница, которую проводят обе платформы, и это функциональная граница, а не граница тона. Приложение для знакомств может быть настолько провокационным в своём маркетинге, насколько захочет, а каталог объявлений может быть настолько сдержанным и деловым, насколько захотят его основатели, и результат не меняется, потому что задаваемый вопрос не "выглядит ли это респектабельно", а "содействует ли это оплачиваемым сексуальным договорённостям". Каталог отвечает на этот вопрос "да" по самой своей конструкции, и это весь продукт целиком.
Почему нет хитрого способа это обойти
Новые операторы обычно пробуют одно из двух, прежде чем это принять. Первое: описать приложение расплывчатым, нейтральным по отношению к категории языком в карточке стора, назвав его приложением "социальных знакомств" или "премиальной компании", в то время как реальный функционал по-прежнему соответствует запрещённому паттерну, как только проверяющий его открывает. Это не работает, потому что команды проверки обоих сторов открывают приложение, проходят по всем сценариям и в неоднозначных категориях обычно создают тестовый аккаунт и просматривают объявления так, как это сделал бы реальный пользователь. Отточенное описание не меняет того, что проверяющий увидит на экране через тридцать секунд.
Вторая попытка, разделение: "чистое" приложение, которое позволяет только просматривать профили, в паре с веб-оплатой или внешней ссылкой, где на самом деле происходит бронирование или оплата, из расчёта, что вынесение вознаграждения за пределы приложения обходит правило. Это неверно трактует то, что на самом деле проверяют обе политики. Правило Apple о приложениях с пользовательским контентом написано достаточно широко, чтобы охватывать приложения, существующие в первую очередь для направления пользователей к ограниченной деятельности, даже если сама транзакция завершается в другом месте, а исходящие ссылки отслеживаются при проверке именно потому, что этот паттерн распространён во многих ограниченных категориях, а не только в этой. Приложение, которое существует для просмотра перечня объявлений об оплачиваемой компании, и есть проверяемое приложение, а не шаг оплаты в конце.
Есть вторая цена за попытку любого из этих двух обходных путей, которая весит больше, чем простой отказ. Прямой отказ, при котором приложение честно категоризировано и просто подпадает под правило о контенте, обе платформы трактуют именно так: как отказ. Описание приложения одним образом в метаданных, тогда как после установки оно функционирует иначе, читается для команды проверки по-другому, ближе к попытке ввести их в заблуждение, чем к добросовестной ошибке категоризации. Соглашение разработчика Apple даёт широкие основания для действий против аккаунта за нечестные или вводящие в заблуждение отправки, отдельно от обычного отказа по контенту и серьёзнее его, а паттерн повторной отправки замаскированной версии того же отклонённого приложения, и именно такой паттерн заставляет ситуацию обостряться. Реальный риск не в том, что исчезнет одно отклонённое приложение. Риск в том, что аккаунт разработчика, привязанный к названию компании, банковскому счёту и всем другим зарегистрированным под ним приложениям, снесут разом, из-за приложения, которое всё равно никогда бы не одобрили, как бы его ни описывали.
Ничто из этого не является суждением о самом бизнесе, который может быть полностью легальным, хорошо модерируемым и с корректной проверкой возраста в своей юрисдикции и всё же не пройти эту проверку, потому что проверка не имеет никакого отношения к законности или качеству модерации. Это продуктовая политика частной компании, и написана она так, чтобы исключить категорию целиком, а не оценивать отдельных операторов внутри неё.
Что строить вместо этого
Альтернатива не является урезанным вариантом, выбранным из-за нехватки бюджета. Это единственное мобильное присутствие, которое каталог этой категории реально может сохранить в долгосрочной перспективе, потому что оно не арендовано у компании, которая уже письменно заявила, что не примет вас. Мобильное веб-приложение, построенное с веб-манифестом и service worker, можно добавить на главный экран телефона с собственным значком, оно открывается на весь экран без интерфейса браузера и с точки зрения пользователя ведёт себя как установленное приложение. Ничто из этого не проходит через проверку сторов Apple или Google, потому что не распространяется ни через один из них. Правила о контенте, применяемые к приложениям в их маркетплейсах, попросту не применяются к веб-сайту, который на обеих платформах регулируется куда более лёгкими и общими правилами просмотра.
Push-уведомления закрывают большую часть оставшегося разрыва с нативным приложением. Веб-push на Android зрелая технология и работает так же, как нативное уведомление. На iOS веб-приложения на главном экране могут получать push-уведомления начиная с версии 16.4, что на сегодняшний день охватывает практически весь активный парк iPhone. Пользователь, добавивший каталог на главный экран, может получить уведомление о новом сообщении, одобрении объявления или завершённом шаге верификации точно так же, как от скачанного приложения, при этом ни одной из двух компаний не нужно его проверять, одобрять или получать возможность его удалить.
Это также устраняет зависимость, структурно идентичную проблеме, с которой операторы уже сталкиваются с поставщиками инфраструктуры: платформу, чьи условия публичны, чей ответ уже известен заранее и которая может прекратить отношения по собственному графику независимо от того, как ведёт себя бизнес. Карточка в сторе для этой категории не представляет собой медленно тлеющий риск, который может материализоваться после проверки политик. Это гарантированный отказ с проверяемым и цитируемым правилом за ним, что делает его одним из тех инфраструктурных рисков, которые проще всего просто избежать, а не управлять ими.
Что операторам действительно нужно решить
Первое решение не техническое. Оно в том, решило бы приложение вообще ту проблему, которую должно было решить. Основатели обычно хотят одного из двух: способа чувствовать себя так же обнаруживаемыми, как мейнстрим-приложения, или способа отправлять push-уведомления, не спрашивая разрешения у браузера. Поиск в сторах не является реалистичным каналом обнаружения для этой категории независимо от одобрения, поскольку столь специфичная карточка была бы удалена раньше, чем успела бы хоть за что-то ранжироваться, так что аргумент про видимость не работает даже в лучшем случае. Стратегии органического и прямого трафика, которые уже работают для каталога объявлений, никак не зависят от наличия нативного приложения, потому что ни одна из них не проходит через поиск в сторе.
Есть более узкая категория, о которой стоит знать, поскольку она реально отличается от публичного приложения-маркетплейса и иногда жизнеспособна: рабочий инструмент для проверенных рекламодателей, позволяющий управлять собственным объявлением, сообщениями и аккаунтом, не открытый для публичного поиска и не показывающий сам по себе просматриваемый каталог оплачиваемой компании пользователям стора. Это ближе к обычному деловому программному обеспечению, и хотя такое решение тоже требует внимательного изучения актуальных правил перед подачей, поскольку граница зависит именно от того, что приложение показывает и кому, оно не подпадает автоматически под то же правило, что блокирует публично ориентированное приложение-каталог.
Для всех остальных ответ: перестать относиться к отсутствующей иконке приложения как к чему-то, за что нужно извиняться или что рано или поздно нужно исправить. Вместо этого стоит как следует выстроить мобильный веб-опыт: быстрый, устанавливаемый сайт с настоящим манифестом, приглашение добавить на главный экран, показываемое в подходящий момент, а не при загрузке страницы, и push-уведомления, на которые пользователь действительно подписывается сам. Это здесь не запасной вариант. Это единственная мобильная стратегия, которая не заканчивается письмом об отказе и, при достаточном упорстве, уведомлением о закрытии аккаунта за бизнес, который в любом случае никогда бы туда не пустили.
