App Store and Google Play review: what actually gets an app rejected

Ο έλεγχος των stores έχει τη φήμη ότι είναι αυθαίρετος. Σχεδόν όλη αυτή η φήμη προέρχεται από την πρώτη υποβολή ομάδων που δεν το έχουν ξανακάνει. Στην πράξη, οι λόγοι απόρριψης ενός app είναι λίγοι, γραμμένοι και επαναλαμβάνονται. Σπάνια αφορούν το ίδιο το προϊόν. Αφορούν έναν ελεγκτή που δεν μπορεί να το δει, χαρτιά που διαφωνούν με τον κώδικα, ή χρήματα που περνούν από λάθος κανάλι. Για όλους μπορείτε να προετοιμαστείτε πριν ανεβάσετε το build. Και ο καθένας κοστίζει μέρες όταν δεν το κάνετε.

Ξεκινήστε από την πρόσβαση, γιατί είναι ο πιο συχνός λόγος και αυτός που αποφεύγεται πιο εύκολα. Αν οποιοδήποτε κομμάτι του app θέλει σύνδεση, η Apple και η Google περιμένουν στοιχεία σύνδεσης που δουλεύουν μαζί με την υποβολή. Η Apple στο App Review Information, η Google στη δήλωση App access του Play Console. Ο λογαριασμός πρέπει να δουλεύει τη μέρα που θα τον ανοίξει ο ελεγκτής, που δεν είναι απαραίτητα η μέρα της υποβολής. Ένας δοκιμαστικός λογαριασμός που διαγράφηκε, κλειδώθηκε, έληξε ή άδειασε από μια αυτόματη εκκαθάριση σημαίνει απόρριψη. Και η απόρριψη επαναλαμβάνεται και στις επόμενες εκδόσεις, γιατί κάθε ενημέρωση ελέγχεται ξανά. Αντιμετωπίστε τον λογαριασμό ελέγχου ως κομμάτι του ζωντανού συστήματος: με υπεύθυνο, τεκμηριωμένο, εξαιρεμένο από τις εκκαθαρίσεις και ελεγμένο πριν από κάθε υποβολή.

Το ίδιο ισχύει για ό,τι χρειάζεται ο ελεγκτής για να φτάσει στο ενδιαφέρον κομμάτι. Μια σύνδεση με κωδικό μίας χρήσης χρειάζεται τρόπο να λάβει ο ελεγκτής τον κωδικό. Μια διαδικασία κράτησης χρειάζεται κάτι διαθέσιμο για κράτηση. Μια λειτουργία μόνο για την Ελλάδα χρειάζεται μια σημείωση που την εξηγεί σε έναν ελεγκτή που ίσως δεν είναι στην Ελλάδα και ίσως δεν διαβάζει ελληνικά. Το πεδίο των σημειώσεων υπάρχει ακριβώς γι' αυτό. Μια σύντομη, απλή παράγραφος εκεί αποτρέπει περισσότερες απορρίψεις από οποιαδήποτε βελτίωση στην εμφάνιση.

Μετά, η πληρότητα. Η Apple θα απορρίψει ένα app που κρασάρει, δείχνει προσωρινό περιεχόμενο (placeholder), έχει συνδέσμους σε σελίδες που δεν υπάρχουν ή περιγράφει στη σελίδα του στο store λειτουργίες που δεν υπάρχουν στο build. Τα στιγμιότυπα πρέπει να δείχνουν το app όπως είναι. Και ένα app που δεν είναι πολύ περισσότερο από ένα website μέσα σε κέλυφος app απορρίπτεται βάσει της οδηγίας για την ελάχιστη λειτουργικότητα. Είναι το ίδιο συμπέρασμα στο οποίο καταλήγει αυτό το journal για εμπορικούς λόγους, μόνο που εδώ το βγάζει ένας ελεγκτής με μια λίστα.

Στην ιδιωτικότητα πρέπει να συμφωνούν τα χαρτιά και ο κώδικας. Η Apple ζητά privacy labels που περιγράφουν τι συλλέγει το app και γιατί, και απαιτεί privacy manifest για ορισμένα API του συστήματος. Η Google ζητά την ενότητα Data safety στο Play Console. Και τα δύο είναι δηλώσεις που κάνετε εσείς. Και τα δύο κρίνονται σε σχέση με ό,τι κάνει πραγματικά το app, και με ό,τι κάνει για λογαριασμό σας κάθε SDK τρίτου μέσα σε αυτό. Μια βιβλιοθήκη analytics, ένα εργαλείο αναφοράς crashes ή ένα διαφημιστικό SDK που προστέθηκε αργά στο έργο αλλάζει το τι πρέπει να δηλώσετε. Ο πρακτικός κανόνας: κρατήστε μια λίστα με κάθε SDK και τι συλλέγει, και ενημερώνετε τις δηλώσεις κάθε φορά που αλλάζει η λίστα, όχι όταν σας το επισημάνει ένας ελεγκτής.

Η διαγραφή λογαριασμού είναι πλέον υποχρεωτική και στις δύο πλατφόρμες, και είναι πιο συγκεκριμένη απ' ό,τι νομίζουν πολλές ομάδες. Αν οι χρήστες μπορούν να δημιουργήσουν λογαριασμό μέσα στο app, η Apple περιμένει να μπορούν να ξεκινήσουν και τη διαγραφή του μέσα από το app, όχι μόνο με email στην υποστήριξη. Το Google Play ζητά επιπλέον μια διεύθυνση στο web όπου ζητείται η διαγραφή χωρίς να ξαναεγκατασταθεί το app, δηλωμένη στην ενότητα Data safety. Διαγραφή λογαριασμού σημαίνει διαγραφή ή ανωνυμοποίηση των δεδομένων πίσω του, μέσα στους κανόνες που ήδη ακολουθεί η επιχείρηση για τιμολόγια και κρατήσεις. Είναι λειτουργία του backend όσο και μια οθόνη, και ανήκει στην πρώτη έκδοση.

Η σύνδεση έχει δικό της κανόνα στο iOS. Ένα app που προσφέρει σύνδεση μέσω τρίτου, όπως η Google, πρέπει να προσφέρει και μια αντίστοιχη επιλογή που περιορίζει τη συλλογή δεδομένων και επιτρέπει στον χρήστη να κρατήσει ιδιωτικό το email του. Ο συνηθισμένος τρόπος είναι το Sign in with Apple. Αν το προσθέσετε μετά από απόρριψη, είναι λίγες μέρες δουλειάς σε app και API. Αν το σχεδιάσετε από την αρχή, είναι ένα απόγευμα.

Οι πληρωμές είναι ο κανόνας που παρεξηγείται πιο συχνά. Ψηφιακά αγαθά και υπηρεσίες που χρησιμοποιούνται μέσα στο app, όπως συνδρομές, premium λειτουργίες και νομίσματα μέσα στο app, πρέπει να πωλούνται μέσω της χρέωσης του ίδιου του store στο iOS, και κατά κανόνα και στο Google Play, με την προμήθεια του store. Τα φυσικά προϊόντα και οι υπηρεσίες που καταναλώνονται έξω από το app είναι άλλη κατηγορία. Μια παραγγελία λιανικής, μια διαμονή σε ξενοδοχείο ή μια κράτηση τραπεζιού πληρώνονται μέσω ενός κανονικού παρόχου πληρωμών. Το να τα περάσετε από in-app purchase είναι από μόνο του λάθος. Μάθετε σε ποια πλευρά της γραμμής βρίσκεται κάθε προϊόν του app πριν σχεδιαστούν οι οθόνες πληρωμής.

Τα wallets προσθέτουν ένα δικό τους βήμα. Το Apple Pay χρειάζεται ταυτότητα εμπόρου ρυθμισμένη με την Apple και τον πάροχο πληρωμών. Το Google Pay σε app Android δουλεύει σε δοκιμαστικό περιβάλλον κατά την ανάπτυξη. Για πραγματικές πληρωμές όμως, η επιχείρηση πρέπει να ζητήσει πρόσβαση παραγωγής στο Google Pay and Wallet Console και να εγκριθεί η σύνδεση. Είναι χωριστή διαδικασία από τον έλεγχο του Play, με δικό της χρονοδιάγραμμα. Ένα app μπορεί να περάσει τον έλεγχο, να βγει ζωντανό και να αποτυγχάνει ακόμη στο κουμπί του Google Pay, επειδή αυτή η έγκριση δεν ζητήθηκε ποτέ.

Οι νέοι λογαριασμοί developer στο Google Play έχουν ένα ακόμη εμπόδιο. Οι προσωπικοί λογαριασμοί που δημιουργήθηκαν από τα τέλη του 2023 πρέπει να τρέξουν κλειστή δοκιμή με έναν ελάχιστο αριθμό δοκιμαστών για ορισμένο διάστημα, πριν μπορέσουν να ζητήσουν πρόσβαση παραγωγής. Οι λογαριασμοί οργανισμών, επαληθευμένοι ως επιχειρήσεις, δεν υπάγονται σε αυτόν τον κανόνα. Είναι ένας λόγος ακόμη να ανοίξετε τον λογαριασμό developer στο όνομα της εταιρείας από την αρχή.

Τίποτα από αυτά δεν είναι δύσκολο, και όλα είναι πιο εύκολα με μια λίστα ελέγχου παρά με το πάθημα. Πριν από κάθε υποβολή: ο λογαριασμός ελέγχου συνδέεται, οι σημειώσεις εξηγούν ό,τι δεν θα καταλάβαινε ένας άγνωστος, οι δηλώσεις ιδιωτικότητας συμφωνούν με την τρέχουσα λίστα SDK, η διαγραφή δουλεύει από την αρχή ως το τέλος, οι πληρωμές βρίσκονται στη σωστή πλευρά της γραμμής, και οι εγκρίσεις των wallets είναι στη θέση τους. Περνάμε αυτή τη λίστα σε κάθε έκδοση των apps που φτιάχνουμε και συντηρούμε, και στο TRVL AIR στο App Store και στο Google Play. Η ανταμοιβή είναι βαρετή: έλεγχοι που περνούν με την πρώτη, χωρίς καμία ιστορία να διηγηθεί κανείς.