Изработка на мобилно приложение: цена, срокове и такси в магазините

Изработката на мобилно приложение с няколко екрана и без профили струва в България от около 1000 до 8000 € според цените, които публикуват студиата. С профили, собствен сървър и админ панел цената е между 4000 и 25 000 €, а маркетплейсите и приложенията с чат в реално време или геолокация започват от 25 000 €.

Долната граница идва от пакет с дизайн, разработка и публикуване: 999 € за една платформа и 1789 € за iOS и Android, с ДДС. Софийската агенция слага каталозите и простите клиентски зони между 3000 и 8000 €, магазините, резервациите и членствата между 8000 и 25 000 €, а маркетплейсите и чата в реално време над 25 000 €. Студиото с цените без ДДС ги разделя по технология: за Flutter или React Native, с плащания и връзка към сървър, 4000 – 13 000 €, а за нативно приложение от 10 000 до над 30 000 €.

В рамките на един ред от таблицата най-скъпо излиза вторият вид потребител. Приложение за записване на час при фризьор има клиенти, но ако салонът иска в него и служителите да виждат графика си, екраните стават двойно повече, а правилото кой какво вижда и кой какво може да променя се превръща в отделна задача. Плащанията за дигитално съдържание носят абонаменти, подновявания, покупки, които трябва да се възстановят на нов телефон, и комисиона за магазина. Работата без интернет, при която приложението пази промените и ги качва по-късно, иска синхронизация и правило какво става, когато двама са променили едно и също нещо. Връзката с Econt, със склад или със счетоводна програма струва толкова, колкото е подредено API-то от другата страна.

Броят на екраните идва чак след тези неща.

За бизнес приложение с профили избирам Flutter: един код за iOS и Android, а една поправка важи и за двете платформи. PWA, тоест сайт, който се инсталира на телефона, стига, когато клиентите идват от сайта ви и магазините не ви трябват. Нативно приложение, на Swift за iPhone и на Kotlin за Android, има смисъл, когато всичко зависи от хардуера на телефона.

PWA

PWA не минава през App Store и Google Play: няма такса за акаунт и комисиона, няма чакане за преглед, а новата версия стига до всички при следващото отваряне. Цената за това се плаща на iPhone. Push известия там работят едва от iOS 16.4 и само след като потребителят добави приложението към началния екран (WebKit), а тази стъпка трябва да му я обясните. Едно българско студио иска за PWA 1300 – 2500 € без ДДС.

Сайт, опакован като приложение, е най-евтиният път до App Store, но рискува отказ: правило 4.2 на Apple иска от приложението повече от преопакован уебсайт (App Review Guidelines).

Flutter или React Native

И двете технологии дават един код за iOS и Android. Между тях избирам Flutter, защото рисува интерфейса си сам и екраните изглеждат еднакво на нов iPhone и на евтин Android. Към септември 2026 г. текущата версия е 3.47 (документация на Flutter). React Native е по-добрият избор, когато сайтът ви вече е писан на React и едни и същи хора ще поддържат и двете.

Твърд отговор нямам само за един случай: първата версия стои върху функция, която Apple или Google са пуснали току-що. Flutter използва такава функция през пакет, а за нещо ново пакет може още да няма и тогава някой пише мост към нативния код. Малък мост не променя избора. Ако мостът стане половината приложение, започвам нативно.

Нативно: Swift и Kotlin

Нативно за двете платформи значи два кода, на практика две приложения. Двойната цена се оправдава, когато приложението работи повече с хардуера, отколкото с екрана: връзка с Bluetooth устройство, видео от камерата, обработено в реално време, дълга работа във фонов режим, уиджети на началния екран и приложение за смарт часовник.

Flutter компилира и за Windows, но ако служителите ще работят на компютър в офиса с файлове, скенер и принтер, прочетете първо как се прави програма за Windows по поръчка.

Apple иска 99 долара годишно за акаунт на разработчик, а Google – 25 долара (около 21 €) веднъж. От продажбите на дигитално съдържание в приложението малкият бизнес дава по 15% и на двата магазина. Поръчка на храна, час при зъболекар или билет за концерт се плащат с карта през собствен доставчик на плащания и магазинът не взима нищо от тях.

При Apple тези 15% не са автоматични. Трябва да се запишете в програмата за малък бизнес, отворена за нови разработчици и за тези с до 1 млн. долара постъпления от App Store през предходната календарна година. Извън нея стандартната комисиона е 30% (Apple). От 1 октомври 2026 г. в ЕС влизат в сила единни условия: 26% за продажбите през In-App Purchase и 15% за участниците в програмата и за абонаментите след първата им година (съобщение на Apple от 18 август 2026 г.).

Google смени таксите за потребителите в Европейското икономическо пространство на 30 юни 2026 г. Върху първия 1 млн. долара годишен приход взима 10% такса за услугата и още 5% за плащането, ако то минава през системата за плащания на Google Play (Service fees). Абонаментите се таксуват по същия начин при всякакъв оборот. За малко приложение това са пак 15%, само че на два реда.

Apple изисква физическите стоки и услуги, които се ползват извън приложението, да се плащат без In-App Purchase (правило 3.1.3(e)), а Google изрично изважда доставката на храна, транспорта, фитнес картите и билетите за събития от своята система за плащания (Payments policy). Приложение с платени видео тренировки, уроци или рецепти обаче трябва да предвиди 15% в бизнес плана.

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

Телефонът е видимата част. Зад него стоят база данни, вход, известия и админ панел, през който някой в офиса добавя съдържание и вижда потребителите. Готовите услуги за сървърната част като Firebase свалят цената на старта: push известията през Cloud Messaging там са без такса (ценоразпис на Firebase).

Акаунтите в двата магазина регистрирайте на фирмата, а не на човека, който пише кода. За фирмен акаунт и Apple, и Google искат D-U-N-S номер, международния идентификационен номер на фирмата. Номерът е безплатен. Издава се до пет работни дни, а Apple го вижда след още до два (Apple). Google предупреждава, че процесът може да продължи до 30 дни (Google Play). Затова заявката за номера се пуска в първата седмица на проекта. Фирменият акаунт в Google Play спестява и затворения тест, задължителен за личните акаунти, създадени след 13 ноември 2023 г.: поне 12 тестери, включени непрекъснато 14 дни (изискванията за тестване).

Данните на потребителите носят още четири задължения:

• Apple не приема ново приложение или обновление без попълнени данни за поверителността, включително какво събират чуждите библиотеки за аналитика и реклама (App privacy details).
• Google иска формата Data safety дори от приложение, което не събира нищо, заедно с линк към политика за поверителност (Data safety).
• Щом в приложението има регистрация, профилът трябва да може да се изтрие от самото приложение: при Apple това е правило 5.1.1(v), а Google иска и уеб страница, от която се подава заявка за изтриване (Google Play).
• Ако приложението обработва данни на деца под 14 години въз основа на съгласие, съгласието дава родителят или настойникът (чл. 25в от Закона за защита на личните данни).

За приложение на Flutter с профили и админ панел залагам три до шест месеца до двата магазина: около месец за дизайн, два до четири месеца за разработка и тестове и една-две седмици за прегледа в магазините. В един български ценоразпис сроковете са 3 – 5 месеца за Flutter или React Native, 6 – 12 месеца за нативно приложение и 4 – 8 седмици за PWA.

Самият преглед е кратък. Apple съобщава, че девет от десет подавания получават решение в рамките на денонощие (App Review), а Google Play предупреждава, че при някои акаунти проверката трае до седмица, понякога и повече (Publish your app).

Предвидете време и за подготовката извън програмирането.

Първото подаване е отделна работа: снимки на екрана в нужните за всеки магазин размери, описание на приложението, данни за поверителност и тестов профил, с който рецензентът на Apple да влезе в приложението (правило 2.1). Предвиждам поне едно връщане с бележки. Всеки екран, сменен след началото на програмирането, мести срока, защото се пренаписва и тества отново на двете платформи.

Годишната поддръжка на мобилно приложение струва 10 – 20% от цената на изработката по оценка на едно софийско студио, а при друга българска фирма месечните пакети за поддръжка започват от 100 € без ДДС. Отгоре се добавят таксата на Apple, сървърът и комисионите от продажбите. Поддръжката не може да чака, защото Apple и Google вдигат изискванията си всяка година.

Тази година сроковете бяха два. От 28 април 2026 г. Apple приема само приложения, компилирани с Xcode 26 или по-нов и SDK за iOS 26 (Upcoming requirements). От 31 август 2026 г. Google Play приема нови приложения и обновления само с целево ниво Android 16 (API 36), а приложенията с целево ниво под Android 15 (API 35) вече не се показват на нови потребители с по-нов Android. Отсрочка до 1 ноември 2026 г. се иска отделно (Target API level). Apple вече обяви и следващия срок: от април 2027 г. ще иска SDK за iOS 27 (съобщение от 9 септември 2026 г.).

Приложение, което никой не е пипал година, продължава да работи, но вече не се поправя бързо: първата спешна поправка след такава пауза минава през нови версии на библиотеките, нова компилация и тестове на новите iOS и Android.

Пример с приложение от средния ред, изработено за 15 000 €: поддръжка за 1500 – 3000 € на година, 99 долара за Apple, сървър за 5 – 50 € на месец според същото софийско студио и 15% от продажбите на дигитално съдържание. Без комисионите това са около 1650 – 3700 € годишно.

Цената на първата версия пада най-много, когато махнете функциите, при които хората общуват помежду си или приложението следи къде са: чат, публични профили, коментари, геолокация. Всяка от тях добавя екрани, правила и редове във формите за поверителност. Започнете с един вид потребител и едно действие, което той прави всяка седмица. Чатът може да почака.

Когато правихме Versetio, го затворихме нарочно в кръга на семейството: в приложението дете между 6 и 14 години и родителят му вършат занимания заедно и други потребители няма. Няма и съобщения, местоположението не се следи, а при първото отваряне се попълват само възрастова група и първо име или прякор. Всяко от липсващите неща е цял модул: съобщенията искат сървър в реално време и правила кой на кого може да пише, а местоположението – разрешение на телефона и редове в двете форми за поверителност, които трябва да остават верни при всяко обновление.

За записване на час или карта за лоялност има и готови платформи с месечен абонамент. Колко излизат абонаментът и собствената разработка за пет години, съм сметнал в софтуер по поръчка или готово решение. Мобилните приложения правим като част от софтуера по поръчка, заедно със сървъра и админ панела.

Втората версия се проектира по данните от първата: кои екрани хората отварят всяка седмица и къде се отказват.