Puoi richiedere la commissione di revisione per esaminare il reclamo.
Tuttavia, vorrei chiedere loro quale schermata ha causato il bug: ho sentito parlare di volte in cui un tester ha provato a utilizzare PassBook su un iPad quando tale funzionalità viene caricata solo su un iPhone. Chiedendo cortesemente, capirai meglio quale codice tagliare da questa sottomissione anziché doverlo fare alla cieca e ripresentarlo. Puoi anche inviare nuovamente la build esatta a TestFlight e chiedere di averla approvata in modo da poter avere una copertura per quella build di quel dispositivo dal tuo pool di test.
Senza vedere il testo del rifiuto, è difficile sapere cosa o perché hai ottenuto il no. Assolutamente, crea una nuova build e inviala per la revisione. Anche se occorrono una settimana o due a causa della cotta delle nuove app per Apple Watch, puoi sempre presentare un ricorso se il rifiuto non ha più senso in 48 ore dopo averlo esaminato e / o raggiunto ad altri sviluppatori per ottenere il loro parere sulla situazione.
Personalmente, li ringrazierei per il rifiuto. Offri una build fissa per risolvere i loro reclami specifici e ripristina un ricorso solo dopo 6 settimane di tentativi non riusciti di ottenere la versione iniziale approvata.
Non dici se questa app è mai stata approvata, quindi concedere parecchi mesi è realistico se l'app non è chiaramente qualcosa che ha avuto una significativa ingegneria.
Inoltre, trovo che mettere l'app in TestFlight per beta ti consenta di scoprire prima quello che Apple considera problematico con la tua app senza che si tratti di uno scenario "go live" o "die in a fire".
TL; DR - trova un modo per dare al revisore quello che chiedono in tutto o in parte e cerca di evitare di portarlo alla bacheca finché non sei sicuro che non ci siano altre opzioni.