Едно приложение или две? Какво промени ИИ в избора на мобилния ви канал

Представете си комитета, който одобрява новото приложение за клиентите ви. На масата има две предложения. Първото казва: «Една-единствена кодова база за iPhone и Android; изгражда се веднъж и се спестява почти половината». Второто казва: «Две нативни приложения, по едно за платформа; това е сериозното решение за банка или застрахователна компания». Всяко предложение носи своя известен пример. Едното цитира Shopify, които изградиха приложенията си с една кодова база и им проработи. Другото цитира Airbnb, които изоставиха същата технология през 2018 г.

Доскоро комитетът щеше да избере според примера, който му звучи по-убедително. Но през септември 2026 г. Shopify, примерът от първото предложение, обяви, че се връща към нативно [3]. Не си тръгна по същата причина като Airbnb: контекстът му беше друг, а причината му е свързана с изкуствения интелект.

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

Първо, три думи

Преди да сравнявате, добре е всички на масата да разбират едно и също.

• Нативно: изгражда се едно приложение за iPhone, с езика и инструментите на Apple (Swift), и друго за Android, обикновено на Kotlin, езика, който Google препоръчва за Android. Това са два кода и известно дублиране. В замяна всяко приложение възприема директно възможностите на телефона, когато те са налични.
• Крос-платформено: пише се едно-единствено приложение, а междинен слой го кара да работи и в двете системи. Най-известните примери са React Native (роден във Facebook, програмира се с JavaScript, езика на уеб) и Flutter (на Google). Една кодова база, един екип, но един слой повече между приложението ви и телефона.
• Споделена логика, нативни екрани: междинната точка. Споделя се онова, което не се вижда (бизнес правила, изчисления, връзка с вашите системи), а всяка платформа рисува собствените си екрани. Най-видимият пример е Kotlin Multiplatform, на JetBrains, който Google поддържа официално за споделяне на логика между Android и iOS [5].

И четири термина, които ще се срещнат. Framework (фреймуърк): платформата за разработка, върху която се изгражда приложението. Зависимости: компоненти на трети страни, които приложението ползва и които трябва да се обновяват и следят. Мост или слой: кодът, който превежда между споделената част и функциите на телефона. Новата архитектура (New Architecture): преработеният начин, по който React Native прави този превод.

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

Airbnb, 2018: не им проработи

Airbnb вградиха React Native в нативните си приложения, които вече бяха големи и продължаваха да растат. През юни 2018 г. публикуваха, че спират да го ползват [1]. Причините им, на езика на бизнеса:

• Не споделиха толкова, колкото очакваха. Само малка част от приложението беше на React Native, а свързването ѝ с останалото изискваше много инфраструктура за моста. В крайна сметка, казва статията, поддържаха код за три платформи вместо за две [1].
• Отстраняването на грешки стана по-трудно. Компилирането беше по-бързо; дебъгването, много по-лошо [1].
• Липсваха експертни ръце, вътре и извън компанията, за да се решават техническите проблеми, които срещнаха [1].

Нюансът, който почти никой не цитира: самата статия казва, че много от тези трудности идват от хибридния модел, който са избрали, и че 63 % от инженерите им биха избрали отново React Native (с пристрастие, което самите те отбелязват: анкетирани са само онези, които са го ползвали) [1]. А днес статията носи предупреждение в началото: отразява технологията от края на 2017 г. и моли: «Ако тези статии се цитират единствено като причина да не се използва React Native, моля, направете собствено по-задълбочено проучване, преди да вземете решение» [1].

Airbnb не казаха «React Native не става». Казаха: «в нашия начин на ползване, с нашия екип и нашето приложение, не постигнахме това, което търсехме».

Shopify, 2020–2025: проработи им

Shopify решиха през 2020 г., че новите им мобилни приложения ще бъдат на React Native. През януари 2025 г. един директор по инженерството в Shopify публикува равносметката от пет години [2]: «Това, че не се налага да изграждаме едни и същи функции два пъти, ни даде скок в производителността». Съобщи за екрани, които зареждат за по-малко от половин секунда, и за над 999 от всеки 1 000 сесии без сривове, както и че нативно не означава автоматично бързо, а React Native не означава автоматично бавно [2].

Същата статия съдържа предупрежденията, които един директор трябва да прочете [2]:

• Ползването на React Native на 100 % трябваше да бъде антицел: продължаваха да се нуждаят от нативен код за най-новото в хардуера (2D и 3D сканиране, ИИ модели, които работят в телефона), за уиджетите на началния екран, часовника и гласовите команди, и за дълги задачи на заден план, като синхронизацията, която позволява на касовата им система да таксува без връзка.
• Обновяването на приложението до всяка нова версия на фреймуърка струва значителна работа, а зависимостите трябва да се поддържат актуални.
• Дебъгването оставаше нестабилно.

Тоест: проработи им, с екип, който освен това допринасяше активно за екосистемата на React Native.

Shopify, 2026: проработи им и въпреки това се връщат

На 10 септември 2026 г. същият автор публикува «Native is now the future of mobile at Shopify» [3]. Основната причина се побира в едно изречение: «LLM промениха едно от основните допускания зад решението ни от 2020 г.» [3]. LLM е езиков модел, технологията зад ИИ асистентите, които днес пишат код.

Допускането беше, че изграждането на всяка функция два пъти, на Swift и на Kotlin, е твърде скъпо. Shopify казват, че когато ИИ агентите (асистенти, които изпълняват програмистки задачи по поръчка) вършат работата по реализация, превод, тестване и преглед, тази цена престана да бъде решаващият фактор [3]. Остават предимствата на нативното: по-близо до възможностите на всяка платформа и до инструментите на производителя, с по-малко слоеве от фреймуъркове и зависимости по средата [3]. И уточняват: не си тръгват, защото React Native е бавен; техните приложения, казват, са бързи [3].

Резултатът, който съобщават: приложението им за пазаруване (Shop) мина от доказателство на концепцията до публикувано в нативна версия за 12 седмици; това за търговци щяло да излезе преди края на 2026 г. [3].

Поуката не е «да минем на нативно»

Сложете двата случая един до друг:

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

Какво промени ИИ и какво не

Shopify заявяват, че за техните приложения и техния екип ИИ намали цената да се пише една и съща функция два пъти, и уточняват, че поддържането на две платформи продължава да струва [3]. Във вашата компания това се проверява с ограничена по обхват проба, преди да се приеме за даденост. И дори там, където цената пада, всичко останало не пада или пада много по-малко:

• Проектирането на изживяването, решението какво прави приложението и какво не.
• Тестването върху десетки модели телефони и версии на операционната система.
• Прегледът дали генерираното е поддържаемо. Shopify го казват без заобикалки: насочването на езиков модел към целия им код, за да го «преведе», е давало огромно количество код, който не може да се поддържа [3]. За да го избегнат, изградиха собствена система на етапи, с тестове, визуален преглед, двама автоматични рецензенти и човешко одобрение [3].
• Публикуването в магазините на Apple и Google и спазването на техните правила.
• Свързването на приложението със системите, които наистина обслужват клиента. За това ще говорим по-долу, защото обикновено е най-скъпото.

С други думи: ИИ не направи безплатно да имате две приложения. Той направи така, че цената да се пише два пъти да престане да бъде, за Shopify, решаващият фактор. Дали ще бъде такъв и при вас, зависи от това колко контрол на качеството можете да поставите върху генерирания код.

Няма и универсален победител по производителност. Едно изследване, публикувано през септември 2026 г. (препринт, т.е. още без рецензия от колеги), изгради едно и също приложение пет пъти: нативно за iOS, нативно за Android, Flutter, React Native и Kotlin Multiplatform, и измери всеки вариант 2 000 пъти [4]. Нативното отчете най-ниските времена в частта, която не е интерфейс; Kotlin Multiplatform беше най-близката споделена опция; при тези реализации споделените имаха по-малко код от двете нативни, взети заедно, което не е равно на усилието за произволен продукт. Изводът му: няма технология, по-добра във всичко; предимството зависи от това кой атрибут се измерва, от натоварването и от платформата [4].

Пет критерия за решението

1. Какво от пътната ви карта засяга телефона отвътре?

Направете списък с онова, което приложението ви ще прави през следващите две или три години, и отбележете какво зависи от хардуера или от операционната система:

• Биометрия: отпечатък или лице, за да влезете или да разрешите операция.
• NFC: плащане чрез доближаване на телефона или четене на карта или документ за самоличност.
• Усъвършенствана камера: четене на лични документи, документи или кодове; сканиране на повреда за застрахователно събитие.
• Работа на заден план: синхронизиране, таксуване без връзка, проследяване на доставка.
• Уиджети, часовник, гласови команди, обогатени известия.

Ако списъкът е кратък, едно крос-платформено приложение го решава добре и ползва точкови нативни части там, където е нужно. Ако списъкът е дълъг и е сърцевината на вашето ценностно предложение, нативното ви позволява да възприемате всяка нова функция на Apple или Google с по-малко слоеве. Shopify, дори в най-добрите си години с React Native, поддържаха нативен код именно за това [2].

2. Какъв екип имате и какъв екип можете да задържите?

Екип, силен в уеб разработката, се движи бързо в React Native. Екип със специалисти за iPhone и Android използва по-добре нативното. Airbnb посочиха липсата на експертни ръце като част от проблема си [1]; Shopify, със зрял екип, накараха да работят и двете възможности. Въпросът не е коя технология е по-добра, а коя може да поддържа вашият екип в продължение на пет години, включително свободните позиции, които ще му се наложи да попълни.

3. Какво поставя на първо място клиентът ви?

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

4. Колко струва поддържането, а не изграждането?

Цената на изграждането се вижда в предложението; тази на поддържането се появява по-късно. С крос-платформеното трябва да следвате темпото на фреймуърка и на неговите зависимости. Скорошен пример: React Native направи Новата си архитектура стандартна във версия 0.76, през 2024 г., а от 0.82, през октомври 2025 г., вече не може да се изключи [6]. Приложение, което се обновява до 0.82, без да я е валидирало, може да изисква работа по съвместимостта и тестове: заложете я в бюджета. С нативното трябва да поддържате два кода и да ги държите еднакви. ИИ променя тежестта на тази втора цена; не премахва първата.

5. На какъв интервал преглеждате решението?

Shopify взеха добро решение през 2020 г. и друго добро решение, различно, през 2026 г., защото се промени едно допускане. Сложете дата в протокола: кое допускане поддържа избора (например «изграждането два пъти струва почти двойно»), как се измерва и кога ще се прегледа отново.

Междинната точка: да се споделя логиката, не екраните

Между «едно приложение» и «две приложения» има трети път, който често подхожда на регулирани компании: да се споделя онова, което не се вижда, и да се изгражда нативно онова, което се вижда.

Помислете какво трябва да е идентично в iPhone и в Android: как се изчислява премия или комисиона, какви проверки се прилагат при паричен превод, как се съхранява и криптира информацията, как се говори с вашите системи. Ако тези правила живеят в два кода, расте рискът да казват различни неща. С Kotlin Multiplatform, например, тези правила се пишат веднъж, а всяка платформа рисува екраните си със собствените си инструменти. Google го поддържа официално за споделяне на бизнес логика между Android и iOS и позволява да се избере колко да се споделя: от само логиката до цялото приложение [5]. В цитираното изследване това беше споделената опция, най-близка до нативното по производителност [4].

Цената му: екипът трябва да владее и двете платформи и, освен това, споделения слой. Не е най-евтината опция; тя е онази, която обикновено дава паритет на правилата, без да се отказвате от нативното изживяване.

Ситуация и опция, която обикновено подхожда

Насока за разговор, не рецепта.

Сценарий (илюстративни цифри, без клиент). Една застрахователна компания планира приложението си за три години: 24 функции. Като ги отбелязва, установява, че 5 зависят от телефона отвътре (камера за щетите, биометрия, обогатени известия, работа без връзка на оценителя и уиджет за полицата). Останалите 19 са екрани за справки и обслужване, които извикват системите ѝ. 5 от 24 е опис, не присъда: всяка от петте се претегля по критичност, зависимост от SDK (комплекта на трета страна, например антиизмамен), регулаторно задължение и производителност. Една-единствена критична функция може да реши: ако работата без връзка на оценителя е залогът на бизнеса, тя тежи повече от 19-те и везната се накланя към нативно или към споделена логика. Във всеки случай 19-те екрана зависят от това системите зад тях да отговарят: там е по-голямата част от риска.

Рисковете, на езика на бизнеса

Всяка от трите опции има рискове. Пет за масата.

• «Фреймуъркът се промени и трябва да мигрираме». Крос-платформеното приложение зависи от темпото на трета страна и от много зависимости. Shopify описват обновяването до всяка версия като значителна работа [2], а Новата архитектура изисква работа по съвместимостта от онзи, който обновява, без да я е валидирал [6]. Заложете в бюджета поддържането, не само изграждането.
• «Не знаем защо се проваля». Повече слоеве между кода ви и телефона означават по-трудно откриваеми грешки. Airbnb го изпитаха [1], а Shopify продължаваха да го съобщават през 2025 г. [2]. При приложение, което движи пари, времето за намиране на грешка е време с недоволни клиенти.
• «ИИ го написа и никой не го прегледа». Да генерирате две приложения с ИИ е по-евтино; да генерирате две приложения, които не могат да се поддържат, също е по-евтино. Връщането на Shopify дойде с контрол на всеки етап [3]. Ако вашият доставчик предложи «две нативни приложения, защото ИИ ги прави», попитайте го как контролира качеството на онова, което ИИ пише.
• «В Android прави едно, а в iPhone друго». При две нативни приложения паритетът не е автоматичен: расте рискът едно правило да се промени в едното и не в другото. Решете какво трябва да е идентично (правила, суми, правни съобщения), кой е източникът, който има последната дума, и подкрепете го с договори и тестове за паритет между двете приложения. Оставяйте в телефона само онова, което изживяването или работата без връзка изискват.
• «Приложението е готово, но основната система не е». Най-честият и най-малко обсъждан риск. Разглеждаме го отделно.

Приложението е лицето; трудното е зад него

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

Безупречно приложение, нативно или крос-платформено, което пита бавна основна система или което получава само «получено», когато клиентът очаква «готово», се възприема като лошо приложение. Затова решението за мобилния канал върви заедно с други:

• Какво прави приложението и какво правят системите му. Правилата, които трябва да са идентични във всички канали (приложение, уеб, клон, консултант), е добре да имат своята версия, която има последната дума, зад приложението, само веднъж; в приложението, само необходимото.
• Как се интегрира с основната система. Кои заявки вървят онлайн и кои операции вървят с референтен номер и проследяване. Това е темата на статията «Онлайн или асинхронно? Как да изберете начина за интегриране на системите си».
• Какво става, когато системата отзад не отговаря. Какво вижда клиентът, какво се запазва в телефона и как се повтаря опитът, без да се дублира плащане.

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

Пет въпроса за следващия ви комитет

1. Какъв процент от нашата мобилна пътна карта зависи от телефона отвътре (биометрия, NFC, камера, заден план, уиджети) и колко е екран, който пита нашите системи?
2. Какъв екип можем да поддържаме пет години, включително свободните позиции, за опцията, която изберем?
3. Кое икономическо допускане поддържа сегашното ни решение и кога за последно го измерихме?
4. Ако ползваме ИИ за изграждането, как контролираме качеството на онова, което генерира, преди да стигне до продукция?
5. Къде живее единствената версия на правилата, които трябва да са идентични в iPhone, Android и останалите канали?

Ако при два или повече от тях отговорът е «не знам», там може да е вашият риск.

Откъде да започнете тази седмица

Вземете пътната карта на приложението си и отбележете всяка функция с един от два етикета: «засяга телефона отвътре» или «е екран върху нашите системи». Пребройте колко има от всяка и посочете критичните. Този опис, заедно с екипа, който имате, ви казва повече за опцията, която подхожда, отколкото всеки известен случай.

Какво прави Hábil

Hábil е мексиканска инженерна консултантска компания, основана през 2006 г., която проектира и изгражда дигитални канали (уеб, мобилни и настолни приложения), свързани със системите, които компанията вече има. Не идваме с предварително избрана технология: помагаме да се реши между нативно, крос-платформено или споделена логика според пътната ви карта, екипа и системите ви, и изграждаме с опцията, която подхожда. Вижте страницата Дигитални канали, които клиентите наистина ползват.

Първият разговор е безплатен: тръгва от вашата мобилна пътна карта и от начина, по който ще се свързва със сегашните ви системи. Пишете ни в WhatsApp.

Твърденията за компаниите отразяват техните публикации към 13 октомври 2026 г.; това са твърдения на всяка компания, не наши измервания. Цитатите са преведени от английски.