Acasă/Metode

Aplicații · iOS

Cum construim o aplicație de iPhone

Testăm cererea cu propriul scanner de App Store înainte să scriem cod, ținem motorul într-un pachet care se poate verifica fără Xcode și tratăm o instalare curată pe simulator drept primul recenzent. Exemplul nostru, Null Field, e construit și gata de trimis, dar nu a fost trimis.

Actualizat 2026-10-11

Ce acoperă metoda și unde se află Null Field

Așa ducem o aplicație de iPhone de la idee la un build pe care îl putem trimite la Apple. Exemplul este Null Field, o aplicație de divertisment din zona paranormalului care transformă variațiile mici ale magnetometrului în cuvinte și spune deschis că acestea vin din variația măsurată a senzorului.

Starea, spusă direct: Null Field nu este în App Store. Avem o arhivă Release validată, o suită de 92 de verificări care trece, interfață în două limbi, textul de listare cu notele pentru recenzent, răspunsurile de confidențialitate, 8 capturi la 1320×2868 și paginile de confidențialitate și suport publicate. Lipsește abonamentul plătit la Apple Developer Program, pe care l-am amânat intenționat. Până atunci aplicația rulează pe telefonul nostru cu un profil de semnare gratuit care expiră după 7 zile, așa că un script o reinstalează în fiecare săptămână.

Și numele a ieșit din proces. Titlul de lucru era marca înregistrată, activă, a unei aplicații existente, iar Apple respinge imitațiile pe Guideline 4.1. Am ales un nume care descrie ce face motorul, o linie de bază și abaterile de la ea, și care nu promite nimic din ce nu măsurăm.

Pasul unu: un test de cerere care măsoară fluxul, nu stocul

Înainte de orice linie de cod, scanăm singuri App Store-ul. Scannerul nostru folosește endpoint-urile publice ale Apple, fără autentificare: API-urile de căutare și lookup pentru metadate, fluxul de recenzii pe țară pentru textul datat al recenziilor și pagina produsului pentru prețurile achizițiilor in-app, pe care API-ul nu le întoarce.

Regula care contează e fluxul înaintea stocului. Numărul total de note doar crește, deci arată cât de mare a fost cândva o nișă. Noi calculăm o rată lunară din recenziile datate. Într-o nișă, liderul avea 3.774 de note și părea ușor de ajuns din urmă, dar toate aplicațiile din nișă la un loc primeau 10 recenzii pe lună. Nișa era moartă.

Căutarea Apple potrivește larg și sortează după popularitate, așa că o interogare pentru o unealtă de nișă scoate aplicații generale cu peste un milion de note; o aplicație intră în calcul doar dacă fiecare cuvânt al interogării apare în nume sau în descriere. Iar volumul de plângeri nu înseamnă cerere: în toate cele 34 de nișe analizate, plângerea dominantă a fost prețul, cu 25% până la 49% din recenziile negative în fiecare. Cei care se plâng cel mai tare sunt, disproporționat, cei care nu plătesc.

Trei lucruri descalifică o nișă pentru noi: o unealtă canonică gratuită, preinstalată sau finanțată de o universitate ori de o comunitate; o plângere principală care nu se poate repara, ca la detectoarele de metale, unde magnetometrul nu vede aurul, argintul sau cuprul; și Guideline 4.3, care respinge aplicațiile aproape identice ale aceluiași dezvoltator. Dintre nișele clasificate, paranormalul a avut cel mai mare flux măsurat, 8.539 de recenzii pe lună.

Pasul doi: un motor pe care îl verifici fără Xcode

Mașina de la care am pornit avea doar uneltele de linie de comandă, fără Xcode. Motorul stă într-un pachet Swift care depinde doar de Foundation și CryptoKit, fără UIKit și fără CoreMotion. Se compilează și rulează pe un Mac fără Xcode, iar aplicația iOS e doar stratul subțire care îi dă datele senzorilor.

Fără XCTest și fără Swift Testing în aceste unelte, testele sunt un executabil care tipărește un tabel comparativ. Rezultatul se poate citi, nu e doar o bifă. Am verificat estimatorii de aleatoriu pe exemplele rezolvate din NIST SP 800-90B, care se reproduc exact, iar suita a prins 4 bug-uri reale pe care citirea codului le ratase, între ele un estimator care dădea nota 0 unei surse tocmai fiindcă era prea bună.

Viteza se judecă doar pe build-uri release: o evaluare a durat 1.266 ms în debug și 10 ms în release.

Pasul trei: build pentru telefon, apoi verifici artefactul

„BUILD SUCCEEDED” nu înseamnă că aplicația se poate instala. Cu un Info.plist scris de mână, Xcode nu mai adaugă identificatorul de pachet, numele executabilului și alte câteva chei. Build-ul e curat, iar aplicația nu se instalează. Un script mic verifică acum aceste chei în pachetul construit, înaintea oricărui alt pas.

Primul build pentru telefon a cuprins 5.203 linii care nu fuseseră compilate niciodată pentru iOS și a dat 3 erori, toate în afara motorului verificat. Tot ce acoperea suita a mers din prima, ceea ce justifică separarea în pachet.

Când un bloc de cod trebuie să existe doar în build-urile de simulator, demonstrăm că e exclus cu un test de otravă: o eroare de compilare deliberată în bloc trebuie să strice build-ul de simulator și să lase neatins build-ul pentru telefon. Căutarea de șiruri în binar nu dovedește nimic, fiindcă tot codul stă într-un framework.

Pasul patru: o instalare curată pe simulator e primul recenzent

Simulatorul de iPhone 16 Pro Max produce nativ capturi de 1320×2868, formatul de 6,9 inci cerut de App Store Connect, deci aranjarea la rezoluția finală se verifică fără telefon.

Simulatorul a găsit un bug pe care telefonul nu-l putea arăta. Aplicația cerea microfonul la pornire, pe un ecran care nu înregistrează nimic. Pe telefonul nostru permisiunea fusese dată cu luni în urmă, deci cererea nu mai apărea. Pe o instalare curată a apărut și ar fi picat pe Guideline 5.1.1, care cere ca permisiunea să fie solicitată în momentul folosirii. Acum cererea stă pe butonul de înregistrare.

Simulatorul nu are magnetometru, deci aplicația ar fi așteptat calibrarea la nesfârșit. Nu am inventat date. Aplicația poate reda o înregistrare făcută pe telefonul nostru real, la 100 Hz, așa că și cuvintele din capturi vin din motorul real, hrănit cu o măsurătoare reală. Se schimbă doar transportul.

Un audit de pregătire a confirmat apoi 7 din 36 de probleme semnalate. Modul englez era incomplet, cu 3 din 5 taburi rămase în română, iar aplicația pornea mereu în română, deci un recenzent vorbitor de engleză ar fi citit disclaimerul nostru într-o limbă pe care nu o vorbește. Modul de înregistrare capta și vocea sintetică a aplicației. Fiecare reparație are acum o verificare permanentă, iar înainte de trimitere urmează o analiză de lansare: securitate, manifest de confidențialitate, experiență de utilizare, distribuție.

Pasul cinci: măsori pe hardware înainte să crezi un prag

Toate pragurile de declanșare au fost puse întâi pe simulare. Așa că am construit în aplicație o sondă de câmp: lași telefonul pe masă 10 minute și îți spune rata reală de eșantionare, zgomotul și câte declanșări false ar fi fost. Pe telefonul nostru magnetometrul a mers la 100,7 Hz, cu zgomot de 0,148 µT, față de 0,15 presupus. Simularea a rezistat.

Ce nu putea prinde simularea: giroscopul brut are în repaus o deviație de 0,0168 rad/s, peste pragul din manual pentru un telefon nemișcat. O poartă de mișcare construită pe date brute nu s-ar fi deschis niciodată. Reparația e rata de rotație corectată de deviație.

Sonda a lămurit și o întrebare de listare. Un uscător de păr de 1600 W se vedea doar cu telefonul lipit de el; la 2–3 cm efectul dispărea în zgomot. Așa că listarea nu scrie „EMF”.

Unde am greșit

Primul declanșator pornea doar pe un scor statistic. Pe un telefon simulat, lăsat nemișcat, a produs 166 de cuvinte în 5 minute, mai multe decât cele 151 produse când chiar se întâmpla ceva. Un z-score împarte la împrăștierea pe care tocmai a măsurat-o, deci senzorul vorbea cu el însuși. Detectorul are acum nevoie de trei lucruri: o limită absolută în unități fizice, un prag derivat dintr-un buget de alarme false, nu ales de mână, și persistență pe 5 eșantioane consecutive.

Într-o singură sesiune am raportat de mai multe ori „64/64 de verificări trec”. Una dintre ele avea plafonul la 250, iar scenariul producea între 249 și 256, deci pica în aproximativ 6 rulări din 10, fiindcă suita folosea un generator fără sămânță. Acum toate generatoarele au sămânță, iar verificările rulează pe mai multe semințe fixe și își tipăresc împrăștierea.

Banca de cuvinte în română fusese scrisă fără diacritice și livra alte cuvinte: fără accente, „față” se citea „fata”, iar „râu” și „rău” deveneau același cuvânt. Am corectat 528 de intrări.

Ce nu garantează metoda

Nu ne spune că Null Field va trece de recenzie sau că se va vinde. N-a fost trimisă niciodată, deci nu avem niciun rezultat de recenzie de raportat. Scannerul nu vede venituri sau descărcări, fiindcă Apple nu le publică, iar recenziile reprezintă undeva între 0,3% și 5% din instalări, deci orice estimare de instalări acoperă o bandă de circa 16 ori. Avem implementați 5 din cei 10 estimatori NIST, așa că valoarea de entropie afișată e o limită superioară, iar aplicația o spune.

Lista de verificare

Înainte de cod. Scanezi fluxul lunar, nu notele totale; filtrezi rezultatele căutării după apartenență; nu iei plângerile despre preț drept cerere; elimini nișele cu unealtă canonică gratuită și cu plângeri imposibil de reparat; verifici numele față de mărcile existente și de Guideline 4.1.

În timpul construcției. Motorul stă într-un pachet cu o suită de verificare lizibilă și cu sămânță fixă; viteza se judecă pe release; verifici pachetul construit, nu codul de ieșire.

Înainte de trimitere. Instalare curată pe simulator; capturi din date reale redate; pornești aplicația în fiecare limbă și te uiți; permisiunile se cer în momentul folosirii; pragurile se confirmă pe hardware; paginile de confidențialitate și suport rămân publicate și la aceeași adresă; rulezi analiza de lansare.

Întrebări și răspunsuri

Cum testez cererea pentru o idee de aplicație de iPhone înainte să o construiesc?

Cererea pentru o aplicație de iPhone se testează scanând App Store-ul prin endpoint-urile publice ale Apple și calculând o rată lunară din recenziile datate, nu din numărul total de note. Într-o nișă, liderul avea 3.774 de note, dar toate aplicațiile la un loc primeau 10 recenzii pe lună, deci nișa era moartă. O aplicație intră în calcul doar dacă fiecare cuvânt al interogării apare în nume sau descriere, iar plângerile despre preț nu înseamnă cerere.

Ce face ca o nișă din App Store să nu merite intrarea?

O nișă din App Store nu merită când există deja o unealtă canonică gratuită, preinstalată sau finanțată de o universitate ori de o comunitate. Nișa cade și când plângerea principală nu se poate repara, ca la detectoarele de metale, unde magnetometrul nu vede aurul, argintul sau cuprul. A treia barieră e Guideline 4.3, prin care Apple respinge aplicațiile aproape identice ale aceluiași dezvoltator. Numele aplicației se verifică și față de mărcile existente și de Guideline 4.1.

Cum pot testa logica unei aplicații iOS fără Xcode?

Logica unei aplicații iOS se poate testa fără Xcode dacă motorul stă într-un pachet Swift care depinde doar de Foundation și CryptoKit, fără UIKit și fără CoreMotion. Uneltele de linie de comandă nu includ XCTest sau Swift Testing, așa că testele pot fi un executabil care tipărește un tabel comparativ lizibil. Într-un proiect, această suită a prins 4 bug-uri reale pe care citirea codului le ratase. Viteza se judecă doar pe build-uri release.

De ce să testez o aplicație de iPhone pe o instalare curată în simulator înainte de trimitere?

O instalare curată în simulator arată aplicația de iPhone așa cum o va vedea recenzentul App Store. Într-un caz, aplicația cerea microfonul la pornire, dar pe telefonul echipei permisiunea fusese dată cu luni în urmă, deci cererea nu mai apărea. Pe instalarea curată a apărut și ar fi picat pe Guideline 5.1.1, care cere permisiunea în momentul folosirii. Simulatorul de iPhone 16 Pro Max produce și capturi native de 1320×2868.

De ce trebuie măsurate pragurile senzorilor pe un telefon real?

Pragurile senzorilor stabilite pe simulare trebuie confirmate pe hardware real, fiindcă unele efecte apar doar acolo. O sondă de câmp lăsată pe masă 10 minute raportează rata reală de eșantionare, zgomotul și numărul de declanșări false. Într-un test, zgomotul magnetometrului a confirmat simularea, dar giroscopul brut avea în repaus o deviație de 0,0168 rad/s, peste pragul din manual, deci o poartă de mișcare pe date brute nu s-ar fi deschis. Soluția a fost rata de rotație corectată.

E gata o aplicație de iPhone pentru App Store dacă build-ul și verificările trec?

Un build reușit și verificări trecute nu înseamnă că aplicația de iPhone e în App Store sau că va trece de recenzie. În exemplul prezentat, aplicația are o arhivă Release validată și o suită de 92 de verificări care trece, dar nu a fost trimisă, fiindcă abonamentul plătit la Apple Developer Program a fost amânat intenționat. Fără trimitere nu există niciun rezultat de recenzie, iar metoda nu poate spune dacă aplicația va trece sau se va vinde.

Toate metodele