Публикуване на приложение в App Store — подготовка преди прегледа

Публикуване на приложение в App Store започва с една цифра: над 40% от нерешените проблеми при прегледа са по правило 2.1, „пълнота на приложението“ (RevenueCat, Expo). Това са сривове, текст-заместител, счупени връзки и липсващ работещ вход за рецензента. Повечето от тези откази се предотвратяват с два-три часа подготовка преди изпращането.

Ръководството е за собственик на малък бизнес или начинаещ разработчик, който вече има работеща версия. Ако още не сте я пуснали на тестери, първо прочетете как се ползва TestFlight за тестване преди App Store.

Технически изисквания към билда през 2026 г.

Apple променя минималните версии на инструментите приблизително веднъж годишно, затова проверявайте страницата с предстоящите изисквания преди всяко качване. Към ноември 2026 г. важат следните срокове.

Източник: Apple Developer, „Upcoming Requirements“ (Apple Developer)

Практичният извод е, че билд, направен със стар Xcode на чужд лаптоп, ще бъде отхвърлен още при качването, преди да стигне до рецензент. Проверете версията на Xcode на машината, от която качвате, още в първия ден на подготовката.

Какво проверява прегледът първо

Правило 2.1 изисква подаването да е окончателна версия с пълни метаданни и работещи адреси, без текст-заместител и празни сайтове (Apple Developer). Ако приложението има вход, трябва да дадете данни за демо акаунт и да включите сървъра си.

Втората честа спънка са метаданните. Описанието, снимките на екрана и информацията за поверителност трябва да съответстват на приложението (Apple Developer, Expo). Всяка нова функция се описва конкретно в полето „Notes for Review“, а общи формулировки водят до отказ.

Подробен преглед на всички раздели има в правилата на App Store.

Демо акаунт и бекенд при рецензента

Рецензентът няма да създава акаунт с Вашия имейл и няма да чака код по SMS. Подгответе акаунт с реалистични данни, който достига до всяка функция, и не разчитайте на вход през VPN или еднократен код (Expo).

Проверката е проста: инсталирайте release билда на чисто устройство и влезте точно с данните, които ще пишете в бележките (Expo). Ако за някоя функция трябва първо да се създаде запис, кажете го в бележките, защото рецензентът не може да го отгатне.

Наше правило от практиката: не изключвайте тестовия сървър през уикенда преди подаването. Ако бекендът не отговаря в момента на прегледа, отказът е сигурен.

Поверителност, акаунти и вход през трети страни

Всички приложения трябва да имат връзка към политиката за поверителност в App Store Connect и в самото приложение, на лесно достъпно място (Apple Developer). Липсата на работеща връзка е сред най-честите причини за отказ (RevenueCat). Как се пише такава политика, е обяснено в нашия материал за бисквитки и съгласие.

Ако приложението позволява регистрация, трябва да предлага и изтриване на акаунта от самото приложение (Apple Developer). Изтриването трябва да започва в приложението и да работи реално на сървъра (Expo).

Вход през Google или друга социална мрежа като основен начин изисква равностойна алтернатива. Тя ограничава събираните данни до име и имейл, позволява скриване на имейл адреса и не следи действията за реклама без съгласие (Apple Developer). За проследяване на потребителите е нужно изрично разрешение през рамката App Tracking Transparency. Не може да изисквате включване на известия или местоположение, за да се ползва приложението.

Плащания и функционалност, която не минава

Отключването на функции, абонаменти и платено съдържание става само през покупки в приложението, а лицензни ключове и QR кодове не са допустими (Apple Developer). Покупките трябва да са завършени, видими за рецензента и работещи. Тествайте и отказа от абонамент, и възстановяването на покупка (Expo).

Приложение, което е просто опакован сайт, рискува отказ по правило 4.2 (Apple Developer, RevenueCat). Тук е и ориентирът за решението между сайт и приложение: ако Вашият „мобилен продукт“ е каталог от връзки към страници, адаптивният сайт е по-добрият избор. Сравнението е в статията за приложение или адаптивен сайт.

Правило 1.2 засяга приложенията със съдържание от потребители. Те трябва да имат филтър за неприемливо съдържание, начин за докладване, блокиране на злоупотребяващи потребители и публикуван контакт (Apple Developer).

График на подаването и отговор при отказ

Подайте нови приложения поне една седмица преди планираната дата за пускане, за да остане време за поправки (RevenueCat). Всяка платформа се подава и преглежда отделно, а подадените неща не се разглеждат непременно по реда на изпращане [Apple, S1 не го съдържа].

Ако получите отказ, прочетете точния номер на правилото в Resolution Center и поправете само него, като отговорите с конкретни промени. Приложения, отхвърляни многократно по едно и също правило, може да чакат по-дълго за преглед (Expo). По апелация е позволена само една жалба на отхвърлено подаване.

Контролен списък за деня преди изпращане

• Билд с Xcode 26 или по-нов и цел iOS 13+ (Apple Developer).
• Чисто устройство, release билд, вход с демо акаунта (Expo).
• Политика за поверителност в метаданните и в приложението (Apple Developer).
• Изтриване на акаунт в приложението, ако има регистрация.
• Екранни снимки и описание, които съответстват на билда.
• Бележки за рецензента с конкретно описание на новото.

Сравнение с Google Play за наблюдение

Android има различен праг: личен акаунт в Google Play, създаден след 13.11.2023, изисква затворен тест с поне 12 тестери, останали включени най-малко 14 дни (Google Play Console Help). Подробности са в статията за публикуване в Google Play. За iOS следете как се мести прагът на Xcode: от Xcode 15 през април 2024 г. до Xcode 26 през април 2026 г. (Apple Developer).