Acasă/Metode

Aplicații · Shopify

Cum construim o aplicație Shopify

Construim fiecare aplicație Shopify pe același șasiu comun, ținem logica ce o face diferită într-un modul pur pe care îl testăm gratuit și considerăm plata nedovedită până când un clic real ajunge pe pagina de aprobare a Shopify. Metoda e mai ales o listă de verificări adăugate după ce ceva s-a stricat.

Actualizat 2026-10-11

La ce folosește

Aceasta e procedura prin care ducem o aplicație Shopify de la idee până la listarea în App Store. E scrisă pornind de la aplicațiile pe care chiar le-am construit și trimis la review, inclusiv cele respinse, suspendate sau care n-au găsit niciun cumpărător. Cea mai mare parte consemnează verificări pe care prima dată nu le aveam.

Înainte de cod: un veto pe cerere, apoi trei cercetări

1. Verificăm dacă plătește cineva. Înainte de orice specificație rulăm scanerul nostru de marketplace pe nișă: câte aplicații sunt, câte recenzii au, cât de repede le adună liderul. O nișă moartă sau goală oprește ideea acolo. Când am măsurat, 52% dintre aplicațiile din magazin aveau zero recenzii, iar 81% aveau sub zece. Lipsa clienților e rezultatul obișnuit.

2. Vedem ce există deja. Profilăm principalii concurenți după listările și videoclipurile lor reale și le împărțim funcțiile în obligatorii, diferențiatoare și goluri ale noastre. Nu desenăm nicio arhitectură până nu putem spune într-un paragraf unde câștigăm. O variantă onestă, cu un nivel gratuit care ajută cu adevărat, e un avantaj pe care îl putem păstra.

3. Facem trei cercetări aprofundate și le contopim. Același prompt merge la trei motoare: ce livrează cei mai buni concurenți, ce fac unelte din domenii vecine și n-a copiat încă nicio aplicație Shopify, ce ar include o versiune de 10× mai bună și cum se ordonează fiecare idee după valoarea pentru comerciant și efortul de construcție. Fiecare motor găsește lucruri pe care celelalte le ratează. Eliminăm dublurile, criticăm rezultatul din poziție adversă (ce e exagerat, ce ne-ar strica nivelul de protecție a datelor) și scriem o singură foaie de parcurs, pe etape care se pot lansa separat. Repetăm totul după v1 și înaintea fiecărei versiuni mari.

Șasiul și motorul pur

Fiecare aplicație pornește ca o copie a unei aplicații de referință, șasiul: React Router 7, Polaris, App Bridge, Prisma peste Postgres, workeri BullMQ peste Redis, numai GraphQL și modele Anthropic în spatele unui limitator de cost, acolo unde aplicația generează text. Șasiul are deja sesiunile, verificarea webhook-urilor, webhook-urile de confidențialitate obligatorii și facturarea. O aplicație nouă schimbă doar ce îi e propriu: nume, permisiuni, modele de date, servicii.

Logica ce face aplicația diferită stă într-un modul fără importuri de bază de date, coadă sau SDK. Modulul primește teste unitare simple, care nu costă nimic la rulare; așa au fost verificate toate cele 15 motoare din primul val.

Prețul unui șasiu e deriva copiilor: o reparație făcută în aplicația de referință după copiere nu ajunge niciodată în copie. Când găsim o eroare de șasiu într-o aplicație, presupunem că e în toate până o măsurăm, în producție, nu citind cod. Într-o singură trecere, patru astfel de erori erau prezente în 19 din 20 de copii.

Metoda de depanare și clasele de erori cu care o pregătim

Înainte de trimiterea la review sau când un comerciant raportează multe erori, rulăm un audit advers cu mai mulți agenți. Câțiva agenți de căutare iau fiecare câte un subsistem, pregătiți cu clasele de erori pe care le cunoaștem și instruiți să raporteze doar erori la care ajunge un utilizator, cu un mod concret de reproducere. Fiecare constatare trece apoi pe la un verificator care pornește de la ideea că eroarea nu e reală. La prima aplicație auditată astfel au intrat 50 de constatări, 8 au fost infirmate și 42 confirmate.

La o aplicație de mărime medie împărțim pe preocupări: ecranele din admin; drumul cumpărătorului; facturare, autentificare, webhook-uri și confidențialitate; onestitatea serviciilor de bază. Ultima direcție prinde funcția accesibilă care raportează succes pentru o muncă pe care n-a făcut-o.

Clasele cu care pregătim auditul vin toate din codul nostru: un credit consumat înainte de validarea răspunsului modelului; rezultatul unui formular citit din hook-ul greșit, așa că mesajele lui nu apar niciodată; un id determinist de job care face din al doilea clic o operație fără efect și fără eroare; un link nativ spre o rută internă, care rupe sesiunea integrată și afișează un simplu null; un callback OAuth validat printr-un cookie în loc de un state semnat HMAC.

Facturarea: singura dovadă e un clic real

Funcția de facturare a Shopify semnalează succesul aruncând o redirecționare. Dintr-un formular trimis din aplicație ea sosește ca un 401 cu un antet de reautorizare, pe care o cerere de date nu-l poate urma în afara iframe-ului. Șasiul nostru o trata greșit și, când am verificat prima dată, butonul de upgrade era mort în 14 din 17 aplicații. Reparația care a rezistat: acțiunea extrage URL-ul de confirmare și îl întoarce, iar pagina trimite cadrul de sus acolo.

Clasa asta e periculoasă fiindcă toate verificările la nivel de API trec pe versiunea stricată: apelul direct de abonament întoarce un URL de confirmare valid, iar build-ul e verde. Singura dovadă pe care o acceptăm e un clic într-un browser real care ajunge pe pagina de aprobare a Shopify, urmat de activarea planului și de o retrogradare care funcționează. După valul de respingeri am verificat astfel 14 aplicații.

Din același drum au ieșit încă două reguli. Comutatorul pentru facturare de test trebuie să cadă spre facturare reală, ca o variabilă nesetată să nu pună niciodată producția în modul de test. Iar o reparație la webhook-ul de facturare primește un al doilea evaluator, pentru că o eroare care oprește activarea nu arată ca o funcție stricată. Nu arată ca nimic.

Review-ul și trecerea la distribuție publică

Distribuția publică e un pas fără întoarcere, care pornește verificări invizibile până atunci. API-ul de facturare refuză orice apel până când aplicația e publică, așa că facem trecerea devreme. Aplicațiile publice create începând cu 1 aprilie 2026 trebuie să folosească tokenuri offline care expiră; fără opțiunea asta tot API-ul Admin răspunde 403, iar workerii au nevoie de propriul mecanism de reînnoire.

Datele protejate ale clienților se declară câmp cu câmp. Multe dintre aplicațiile noastre nu citesc date despre clienți și declară nivelul 0. O aplicație care păstrează numele, emailul, telefonul sau adresa destinatarului e la nivelul 2, iar un „Nu” la criptarea datelor stocate înseamnă că aplicația nu e aprobată. N-am reformulat răspunsul. Am criptat în aplicație coloanele care identifică persoana, am adăugat indecși orbi cu cheie ca să meargă în continuare căutarea după telefon și email, am criptat copiile de siguranță, am scris procedura de răspuns la incidente și abia apoi am răspuns.

Înainte de fiecare trimitere rulăm poarta de onestitate, care verifică dacă fiecare afirmație de pe pagina de planuri, din listare și din paginile publice are în spate cod accesibil; are un articol separat. Demonstrația e un parcurs real de configurare, cu upgrade-ul arătat pe ecran, fiindcă un tur al titlurilor pică review-ul.

Unde am greșit

Am construit primul val înainte să existe vetoul pe cerere. Rulat retroactiv, el a arătat că zece dintre acele aplicații erau live fără nicio instalare între ele și că cele mai multe stăteau în nișe moarte, goale sau blocate de un singur lider.

Apoi am citit lipsa instalărilor ca pe o problemă de produs sau de marketing. Cauza erau două comutatoare. Paisprezece aplicații aprobate erau publicate ca nelistate, așa că directorul public arăta 6 din 20, iar 9 aplicații nu aveau niciun plan de preț public, deci cardurile lor arătau „Free” și nimeni nu putea cumpăra nimic. Amândouă s-au reparat în cam o oră.

Propriile noastre reparații au provocat respingeri. O gardă adăugată pe ruta de autentificare a lăsat ruta fără componentă, așa că afișa un simplu null; era live în toate cele 20 de aplicații, iar o aplicație a fost suspendată 14 zile. În alta, instrucțiunea din prompt de a nu inventa stocul n-a oprit un număr de stoc fabricat, ajuns pe pagină prin editări manuale, și a urmat o nouă suspendare. Controlul stă acum pe drumul de scriere, pe textul final, chiar înainte de modificarea din magazin.

Funcția de bază a TermForge nu capturase niciodată niciun rând: sosiseră 72 de webhook-uri de comandă și toate fuseseră ignorate, pentru că codul se baza pe conținutul webhook-ului în loc să interogheze comanda. Și încasarea pica de fiecare dată, pentru că cheia de idempotență avea 40 de caractere față de o limită de 32, iar testul unitar verifica tocmai 40. Doar fluxul de bani rulat pe un magazin real a scos la iveală ambele probleme.

În septembrie, o căutare a următoarei aplicații, făcută de patruzeci și unu de agenți, n-a găsit niciuna care să merite construită. Ne-am apucat în schimb să măsurăm pâlnia aplicațiilor pe care le aveam deja.

Limite

Metoda face o aplicație mai corectă și mai onestă. Nu face pe nimeni s-o instaleze, iar niciuna dintre verificări nu atinge descoperirea în magazin. La sfârșitul lui august 2026, aplicațiile Shopify descrise aici nu aveau niciun comerciant plătitor; instalările din afară pe care le vedeam erau testeri de aplicații care treceau prin planuri în modul de test.

Și auditul ratează lucruri: o a doua trecere de onestitate, peste aplicații aflate deja în review, a găsit șase erori reale scăpate de prima. O poartă verde arată că lipsesc clasele cunoscute, nu că aplicația funcționează.

Lista de verificare

Nișa are cumpărători și ne putem numi avantajul. Trei cercetări sunt contopite într-o singură foaie de parcurs pe etape. Aplicația e copiată din șasiul actual, iar motorul ei e pur și testat unitar. Build-ul complet e verde și fiecare flux a fost parcurs în browser. Auditul a rulat cu un verificator care încearcă să infirme fiecare constatare.

Upgrade-ul ajunge pe pagina de aprobare a Shopify printr-un clic real, iar retrogradarea funcționează. Tokenurile care expiră sunt activate, iar declarația de date corespunde cu ce se stochează. Poarta de onestitate e curată, iar după aprobare listarea e vizibilă și are planurile publicate.

Întrebări și răspunsuri

Cum decid dacă merită construită o idee de aplicație Shopify?

Decizia dacă merită construită o aplicație Shopify începe cu verificarea că plătește cineva în nișă. Numeri aplicațiile, recenziile lor și cât de repede le adună liderul; o nișă moartă sau goală oprește ideea. Apoi profilezi principalii concurenți după listările și videoclipurile lor reale și nu desenezi nicio arhitectură până nu poți spune într-un paragraf unde câștigă aplicația nouă.

De ce nu face nimic butonul de upgrade din aplicația mea Shopify integrată?

Butonul de upgrade dintr-o aplicație Shopify integrată poate să nu facă nimic pentru că funcția de facturare a Shopify semnalează succesul aruncând o redirecționare. Dintr-un formular trimis din aplicație, redirecționarea sosește ca un 401 cu antet de reautorizare, pe care o cerere de date nu-l poate urma în afara iframe-ului. Reparația care ține: acțiunea întoarce URL-ul de confirmare, iar pagina trimite cadrul de sus acolo.

Cum testez facturarea unei aplicații Shopify înainte de trimiterea în App Store?

Facturarea unei aplicații Shopify se testează printr-un clic real, nu prin verificări la nivel de API. Un drum de upgrade stricat poate întoarce totuși un URL de confirmare valid la un apel direct de abonament, iar build-ul rămâne verde. Dovada acceptată e un clic într-un browser real care ajunge pe pagina de aprobare a Shopify, urmat de activarea planului și de o retrogradare care funcționează.

Ce trebuie să știu înainte să fac publică o aplicație Shopify?

Trecerea unei aplicații Shopify la distribuție publică e un pas fără întoarcere, care pornește verificări invizibile până atunci. API-ul de facturare refuză orice apel până când aplicația e publică, așa că trecerea se face devreme. Aplicațiile publice noi trebuie să folosească tokenuri offline care expiră, altfel API-ul Admin răspunde 403, iar workerii au nevoie de propriul mecanism de reînnoire a tokenului.

Cum obțin aprobarea pentru o aplicație Shopify care stochează date de clienți?

O aplicație Shopify care stochează date de clienți se aprobă îndeplinind cerințele pentru datele protejate, nu reformulând răspunsurile. O aplicație care păstrează numele, emailul, telefonul sau adresa destinatarului e la nivelul 2, iar un „Nu” la criptarea datelor stocate înseamnă respingere. O soluție care a mers: criptarea coloanelor care identifică persoana, indecși orbi cu cheie pentru căutări, copii de siguranță criptate și o procedură de răspuns la incidente.

De ce nu are instalări o aplicație Shopify aprobată?

O aplicație Shopify aprobată poate să nu aibă instalări din motive care nu țin de produs. Aplicațiile aprobate, dar publicate ca nelistate, nu apar în directorul public, iar cele fără planuri de preț publice apar drept „Free”, deci nimeni nu poate cumpăra nimic. Ambele comutatoare se repară repede. Dincolo de ele, o aplicație corectă și onestă are nevoie de o nișă cu cumpărători, fiindcă verificările de construcție nu ating descoperirea.

Toate metodele