LaunchLint Academy
La risposta breve
- React Native ed Expo non sono motivi di rifiuto. Il rischio nasce tra JavaScript, configurazione nativa, backend, metadata e percorso che il reviewer può davvero provare.
- I gruppi più comuni sono app incompleta (2.1), metadata inesatti (2.3), pagamenti (3.1), valore insufficiente (4.2) e privacy o cancellazione account (5.1).
- Riproduci il percorso nel build inviato, correggi la causa e rispondi con prove verificabile invece di una rassicurazione generica.
1. Perché React Native raramente è la causa
Apple valuta il prodotto distribuito, i metadata e il comportamento osservabile. SwiftUI, React Native o Expo non cambiano i requisiti. Il framework conta quando l’astrazione nasconde un dettaglio nativo: plugin che aggiunge permessi, SDK che trasmette dati, configurazione release diversa o aggiornamento OTA non allineato al binario.
Assegna prima il rifiuto a un livello. Un crash di login riguarda build o backend; un acquisto assente può dipendere da prodotto o accesso; una risposta privacy vive nella console anche se nasce da uno SDK. Separare i livelli evita fix nel posto sbagliato.
| Livello | prove | Domanda |
|---|---|---|
| file del progetto/build | Plugin, permessi, SDK, ID | È nell’artefatto inviato? |
| App | Crash, login, acquisto, cancellazione | Un nuovo utente lo riproduce? |
| Store | Screenshot, privacy, note | Descrive questo build? |
2. Guideline 2.1: build incompleto o accesso bloccato
La 2.1 copre più dei crash. Apple richiede binario finale, metadata completi, URL funzionanti e accesso alle funzioni essenziali. App stabili falliscono per account demo scaduti, backend inattivo, codici monouso o feature flag disabilitati per la review.
Prova su un altro dispositivo:
- Primo avvio senza sessione
- Credenziali review esatte
- Backend e media accessibili
- Funzione principale senza invito
- Acquisti visibili e aggiornati
- Rifiuto permessi senza blocco
- URL supporto e privacy pubblici
3. Guideline 2.3: la promessa Store contraddice l’app
Descrizione, screenshot, preview e privacy devono riflettere l’esperienza principale. Il conflitto nasce quando le immagini provengono da un branch più nuovo o mostrano un flusso premium irraggiungibile dal reviewer.
Collega ogni claim forte a un percorso. Anonima, offline, senza tracking o con IA richiede verifica di SDK e chiamate di rete. Elimina menu debug, placeholder, prezzi test e loghi di altre piattaforme.
- Screenshot di UI raggiungibile
- Nome senza funzioni assenti
- Acquisti extra spiegati
- What’s New specifico
- Età coerente con contenuti e UGC
- informativa sulla privacy e label descrivono la stessa release
4. Guideline 3.1: acquisti digitali e ripristino
Il percorso di pagamento è decisivo per sbloccare funzioni, contenuti o abbonamenti digitali. Stripe nel file del progetto non è automaticamente vietato; il rischio è usarlo per unlock digitali iOS o link esterni non consentiti. Le eccezioni regionali richiedono analisi precisa.
Anche StoreKit corretto fallisce se i prodotti non sono inviati, visibili o testabili. Prova caricamento, annullamento, successo, restore, abbonamento attivo e reinstallazione. Spiega nelle indicazioni per il team di verifica quando appare ogni prodotto.
- Stato e accordi prodotti
- Paywall accessibile
- Restore visibile
- Prezzo e durata chiari
- Nessun segreto nel codice o nelle note
- Disponibilità regionale documentata
5. Guideline 4.2: valore duraturo insufficiente
La 4.2 riguarda wrapper di siti, raccolte di link, materiale marketing o app con utilità minima. WebView e template sono esposti. Qualche pulsante nativo non basta: contano funzione reale e beneficio specifico.
Descrivi il lavoro ricorrente risolto e perché il mobile aggiunge valore. Offline, fotocamera, posizione, notifiche o acquisizione aiutano solo se funzionano davvero. Non inventare feature decorative o incomplete.
6. Guideline 5.1: privacy, permessi e cancellazione
I problemi nascono dalle differenze: SDK omessi dall’informativa sulla privacy, purpose string vaghi o dichiarazioni senza raccolta nonostante una trasmissione. Il provider risponde anche del codice terzo.
Se l’app crea account, Apple richiede di avviare la cancellazione nell’app. Logout o disattivazione non bastano. Spiega conservazione, gestisci abbonamenti e prova conferma, riautenticazione ed errori.
- Purpose string concreti
- Inventario SDK e dati
- informativa sulla privacy pubblica con conservazione
- Percorso in-app di cancellazione
- Dichiarazioni confrontate con trasmissioni
- Nuovo binario dopo modifiche native
7. Dal rifiuto a un nuovo invio verificabile
Leggi guideline, percorso e allegati. Riproduci con il build rifiutato prima di modificare codice. Poi decidi se serve un nuovo binario o se un problema di metadata consente lo stesso build.
La risposta deve indicare causa, modifica e punto di verifica: build, menu e account. Evita di discutere il framework o dire che tutto funziona senza prove. Conserva anche screenshot, log di test e commit del fix per distinguere una nuova segnalazione da una regressione.
- Annotare i passi del reviewer
- Riprodurre nel build rifiutato
- Scegliere il livello
- Documentare fix e regressione
- Indicare build e navigazione
- Verificare account e backend da rete esterna
- Aggiornare screenshot e privacy se coinvolti
- Rispondere brevemente
- Fare appeal solo su interpretazioni davvero contestate
Domande frequenti
Le app React Native vengono rifiutate più spesso?
Apple non pubblica un tasso affidabile per framework. Contano stabilità, configurazione nativa, metadata, pagamenti, privacy, accesso completo, SDK incorporati, comportamento reale del backend e riproducibilità del percorso sul build inviato da un dispositivo pulito e una rete esterna.
Serve sempre un nuovo build?
No per alcuni problemi di metadata. Sì dopo modifiche a codice, SDK, permessi o configurazione nativa.
LaunchLint garantisce l’approvazione?
No. Rileva segnali riproducibili e crea task con prove, ma non sostituisce backend o decisione umana.
Come rispondo a un rifiuto ambiguo?
Chiedi il percorso esatto, riproducilo e rispondi con build, navigazione ed prove. Usa appeal se l’interpretazione resta realmente contestata.