Dezvoltare aplicații mobile: ce rămâne după ce AI scrie codul

Răspunsul scurt: AI a ieftinit partea de scris cod, dar nu a atins nimic din ce face ca o aplicație mobilă să funcționeze ca produs. Aplicația ta rulează pe telefoanele altor oameni, în versiuni pe care nu le controlezi, într-un magazin care își schimbă regulile în fiecare an. Google Play a impus termenul de 31 august 2026 pentru aplicațiile care nu țintesc Android 16, iar Apple cere din 28 aprilie 2026 ca orice încărcare să fie construită cu Xcode 26. Niciuna dintre problemele astea nu se rezolvă scriind mai mult cod, mai repede.

Articolul ăsta e despre cele cinci lucruri care rămân aceleași indiferent dacă linia de cod e scrisă de un om sau generată. Dacă alegi o firmă de dezvoltare aplicații mobile, astea sunt lucrurile despre care merită să întrebi, pentru că despre ele nu vorbește aproape nimeni în ofertă.

Și poți începe întrebându-ne pe noi. Digital U construiește aplicații mobile de la 5.000 $ (pagina de prețuri), cu toate cele cinci incluse în scop, nu vândute separat mai târziu. Pune-ne cele cinci întrebări într-o discuție gratuită de 30 de minute și compară răspunsurile cu ale celorlalți care îți fac ofertă.

De ce „merge pe telefonul meu” nu mai înseamnă nimic după lansare

Un site îl repari și gata: toată lumea vede versiunea nouă la următorul refresh. O aplicație mobilă nu funcționează așa. Fiecare utilizator are instalată o versiune, actualizează când vrea el sau niciodată, iar între tine și telefonul lui stau două magazine cu reguli proprii.

Asta schimbă complet lista de probleme. Nu mai e „cât durează să construim”, ci „ce facem în ziua în care ceva nu merge și jumătate dintre oameni sunt pe o versiune de acum patru luni”. Am detaliat partea de buget în cât costă o aplicație mobilă în 2026. Aici vorbim despre ce cumperi de fapt când cumperi „dezvoltare aplicații mobile”.

1. Să știi ce fac oamenii în aplicație

Fără măsurare, fiecare decizie de produs e o presupunere, iar presupunerile se plătesc în funcționalități pe care nu le folosește nimeni. Două instrumente diferite, amândouă necesare: unul care îți arată comportamentul (ce ecrane, ce pași, unde abandonează) și unul care îți arată erorile în producție, cu telefon, versiune de OS și versiune de aplicație.

Combinația pe care o folosim și o recomandăm e PostHog plus Sentry, pentru că răspund la întrebări diferite. Sentry îți spune că o funcționalitate crapă. PostHog îți spune câți oameni o ating de fapt. Împreună îți spun dacă merită reparată azi sau săptămâna viitoare, ceea ce niciunul dintre ele nu poate spune singur.

Partea care se uită des: datele de test nu au ce căuta în aceleași conturi de analytics ca datele reale. Dacă mediile de development și producție împart aceeași cheie, rapoartele arată frumos și sunt false, iar deciziile luate pe baza lor costă bani reali.

2. Să controlezi ce versiune rulează lumea

Întrebarea care apare în fiecare produs mobil, mai devreme sau mai târziu: de ce raportează oamenii un bug pe care l-am reparat luna trecută? Pentru că nu și-au actualizat aplicația.

Mecanismul care rezolvă asta se numește force update și e simplu ca idee: ții undeva, în afara aplicației, două numere (versiunea minimă acceptată și versiunea curentă), iar aplicația le verifică la pornire. Sub minim, blochezi accesul și ceri actualizarea. Peste minim dar sub curent, arăți un banner opțional.

Ce contează e să nu tratezi toate actualizările la fel. Update obligatoriu pentru probleme de securitate, schimbări incompatibile de backend, migrări de date și cerințe legale. Update opțional pentru îmbunătățiri de interfață și reparații care nu dor. Iar momentul potrivit să construiești mecanismul e la început, nu când ai deja mii de oameni blocați pe o versiune stricată: partea tehnică e mică, dar nu poate fi adăugată retroactiv în versiunile deja instalate.

Ai deja o aplicație în magazine și nu știi pe ce versiuni sunt oamenii? Hai să ne uităm împreună într-un call gratuit de 30 de minute sau scrie-ne în două rânduri. Îți spunem ce lipsește din ce ai deja, chiar dacă nu lucrăm împreună.

3. Să poți schimba ce se afișează fără să treci prin store

Asta e partea pe care cei mai mulți proprietari de aplicații o descoperă târziu: o bună parte din ce vede utilizatorul nu trebuie să fie în cod. Poate fi controlată din afară, în timp real.

Firebase Remote Config, ca exemplu documentat public, îți permite să schimbi comportamentul și aspectul aplicației fără ca utilizatorii să descarce o versiune nouă. Documentația oficială descrie și livrarea graduală către un procent din utilizatori, și targetarea pe segmente după versiunea aplicației, limbă sau audiență.

Ce cumperi concret cu asta:

• Pornești o funcționalitate nouă pentru 5% dintre utilizatori și o oprești în cinci minute dacă strică ceva, fără să aștepți o nouă versiune în magazin.
• Afișezi un banner de mentenanță când backend-ul tău e în lucru, în loc să lași aplicația să dea erori.
• Ascunzi o funcționalitate care nu mai e validă, fără release.
• Ții textele și conținutul într-un CMS, ca să poți schimba o ofertă sau o descriere fără programator.

Un comutator care oprește o funcționalitate stricată în cinci minute valorează, în ziua în care ai nevoie de el, mai mult decât funcționalitatea în sine.

4. Să poți repara ceva critic în aceeași zi

Actualizările over-the-air rezolvă problema „am un bug critic în producție și trebuie să aștept reviewul din magazin”. Cu EAS Update, documentația Expo e explicită despre ce intră și ce nu intră: poți actualiza partea non-nativă a aplicației, adică JavaScript, stiluri și imagini, fără o versiune nouă în store.

Și, la fel de important, ce nu poți actualiza așa: cod nativ sau dependențe native, permisiunile aplicației (cameră, locație), versiunea de SDK Expo, deci orice necesită un binar nou. Documentația mai precizează un lucru pe care unii îl trec cu vederea: actualizările tot trebuie să respecte regulile App Store și Play Store, inclusiv la conținut, iar schimbările de comportament ale aplicației trebuie, de regulă, trecute prin review.

Tradus în termeni de afacere: OTA e plasa ta de siguranță pentru reparații urgente și ajustări de conținut, nu o portiță prin care ocolești magazinele. Cine ți-o vinde ca pe a doua variantă îți vinde o problemă viitoare.

5. Să ții pasul cu regulile magazinelor, an de an

Asta e partea care surprinde cel mai mult proprietarii de aplicații, pentru că e un cost care apare chiar dacă nu schimbi nimic în produs.

Google Play cere, de la 31 august 2026, ca aplicațiile noi și actualizările să țintească Android 16 (API level 36) sau mai nou. Aplicațiile existente trebuie să țintească cel puțin Android 15 (API level 35) ca să rămână disponibile pentru utilizatori noi pe dispozitive cu versiuni de Android mai mari decât ținta aplicației. Cine are nevoie de timp suplimentar poate cere o prelungire până la 1 noiembrie 2026.

Apple cere, din 28 aprilie 2026, ca aplicațiile încărcate în App Store Connect să fie construite cu Xcode 26 sau mai nou, folosind un SDK pentru iOS 26.

Asta înseamnă, în practică, că o aplicație care „merge bine și nu are nevoie de nimic” tot are nevoie de cel puțin o rundă de lucru pe an, făcută de cineva care urmărește termenele astea. Nu e mentenanță opțională, e condiția de a rămâne în magazin.

6. Să existe un loc unde ajunge omul când ceva nu merge

Ultimul lucru pe care AI nu îl scrie: drumul dintre un utilizator nemulțumit și tine. Dacă singura lui opțiune e o recenzie de o stea, acolo va ajunge, iar recenziile rămân publice mult după ce repari problema.

Un canal de suport în aplicație, legat de aceleași date pe care le colectezi la punctul 1, transformă o recenzie proastă într-un tichet pe care îl poți rezolva. Iar când tichetul vine însoțit de versiunea aplicației și de ce a făcut omul înainte să se blocheze, îl rezolvi în minute, nu în zile de reprodus bug-ul pe orbește.

Ce înseamnă asta când ceri o ofertă

Aproape toate ofertele de dezvoltare aplicații mobile descriu ce se construiește. Foarte puține descriu ce se întâmplă după. Cinci întrebări care separă două oferte care arată identic:

Întrebarea	De ce contează
1. Ce se măsoară și unde văd datele?	Fără analytics și crash reporting, deciziile de după lansare sunt presupuneri.
2. Există mecanism de force update?	Altfel rămâi cu utilizatori blocați pe versiuni cu buguri deja reparate.
3. Pot opri o funcționalitate fără release nou?	Un comutator remote e diferența dintre cinci minute și două săptămâni.
4. Ce pot repara fără să trec prin store?	Răspunsul corect e „JS, stiluri, conținut”, nu „orice”.
5. Cine urmărește termenele Google și Apple?	Sunt anuale și obligatorii. Dacă nu le urmărește nimeni, le afli când aplicația dispare.

Dacă răspunsul la oricare dintre ele e „vedem după lansare”, ai aflat că lansarea e considerată finalul proiectului. Pentru un produs mobil, lansarea e ziua în care încep problemele interesante.

Deci AI chiar nu ajută cu nimic?

Ba da, și încă mult. Scrie cod mai repede, ajută la teste, la documentație, la refactorizări plictisitoare. Partea care s-a schimbat real e că distanța de la idee la un ecran funcțional s-a scurtat enorm.

Ce nu s-a schimbat e ce urmează după ecranul funcțional: cineva trebuie să decidă ce se măsoară, ce se dă drumul și cui, ce se repară azi și ce poate aștepta, și cine răspunde când cade ceva la ora 9 dimineața. Astea sunt decizii de produs și de proces, iar ele rămân aceleași indiferent cine a tastat.

Rezultatul practic: dacă evaluezi o ofertă doar după cât de repede se scrie codul, compari partea care s-a ieftinit. Diferența dintre o aplicație care trăiește și una care moare în șase luni stă în restul.

Întrebări frecvente

Poate AI să scrie o aplicație mobilă completă? Poate genera o parte semnificativă din cod, dar o aplicație mobilă ca produs are nevoie de lucruri care nu sunt cod: analytics și crash reporting configurate, mecanism de force update, feature flags pentru a controla ce se afișează, un canal de suport și respectarea termenelor anuale impuse de Google Play și Apple.

Ce înseamnă mentenanța unei aplicații mobile? Înseamnă, în principal, actualizări impuse de platforme (Google Play cere Android 16, API level 36, pentru aplicații noi și actualizări de la 31 august 2026, iar Apple cere Xcode 26 pentru orice încărcare din 28 aprilie 2026), reparații de buguri, actualizări de dependențe și monitorizarea erorilor în producție. Apare și dacă nu schimbi nimic în produs.

Poți actualiza o aplicație fără să treci prin App Store? Parțial, da. Conform documentației EAS Update, poți actualiza over-the-air partea non-nativă: JavaScript, stiluri și imagini. Nu poți actualiza astfel cod nativ, dependențe native, permisiunile aplicației sau versiunea de SDK, iar actualizările trebuie să respecte în continuare regulile magazinelor.

Ce sunt feature flags și de ce contează pentru afacerea ta? Sunt comutatoare care pornesc sau opresc funcționalități din afara aplicației, fără o versiune nouă în magazin. Firebase Remote Config permite schimbarea comportamentului și aspectului aplicației fără ca utilizatorii să descarce un update, inclusiv livrare graduală către un procent din utilizatori și targetare pe versiune sau segment. Practic, poți opri o funcționalitate stricată în minute.

Ce este un force update și când e justificat? E mecanismul prin care aplicația verifică la pornire versiunea minimă acceptată și blochează accesul dacă utilizatorul e sub ea. E justificat pentru probleme de securitate, schimbări incompatibile de backend, migrări de date și cerințe legale. Pentru îmbunătățiri de interfață și reparații minore se folosește un banner opțional, nu blocarea.

De ce trebuie actualizată aplicația chiar dacă merge bine? Pentru că magazinele impun termene anuale. Google Play cere aplicațiilor existente să țintească cel puțin Android 15 (API level 35) ca să rămână disponibile utilizatorilor noi pe dispozitive mai noi, cu prelungire posibilă până la 1 noiembrie 2026, iar Apple cere construirea cu Xcode 26 din 28 aprilie 2026.

Cât costă să pui o aplicație pe Magazin Play? 25 $, taxă unică de înregistrare a contului de developer, conform paginii oficiale Google. La Apple sunt 99 $ pe an, prin Apple Developer Program. Am detaliat toate costurile de lansare și pe cele anuale în cât costă o aplicație mobilă în 2026.

Cât costă dezvoltarea unei aplicații mobile? Ofertele publicate în România merg de la câteva mii de dolari pentru o aplicație simplă până la peste 110.000 $ pentru platforme complexe, iar mentenanța anuală se ofertează frecvent ca procent din costul de dezvoltare. Intervalele complete, cu surse, sunt în cât costă o aplicație mobilă în 2026.

Ai o aplicație în magazine sau ești pe punctul să începi una? Scrie-ne în două rânduri sau rezervă un call de 30 de minute: trecem prin cele cinci întrebări de mai sus pentru produsul tău și îți spunem onest ce lipsește. Dacă ai și un site, poți cere în schimb un audit gratuit.