Checklist Mobile App για Startups: 34 Στοιχεία από MVP έως Έγκριση App Store (2026)

Checklist Mobile App για Startups: 34 Στοιχεία από MVP έως Έγκριση App Store (2026)

Η Κατευθυντήρια Γραμμή 5.1.1(v) του App Store Review της Apple έχει σκοτώσει περισσότερες ημερομηνίες κυκλοφορίας startups από οποιοδήποτε bug που έχουμε στείλει εμείς. Ένα κουμπί διαγραφής λογαριασμού που λείπει, υποβλήθηκε το βράδυ πριν από ένα demo day, και ολόκληρο το χρονοδιάγραμμα μετατοπίζεται κατά μία εβδομάδα. Αυτό το checklist mobile app για startups υπάρχει επειδή αυτό το λάθος αποφεύγεται πλήρως, και σχεδόν κανείς δεν σημειώνει τον αριθμό της κατευθυντήριας γραμμής που το προκαλεί.

Βασικά συμπεράσματα:

• Η Apple απορρίπτει εφαρμογές για ροές διαγραφής λογαριασμού και συνδέσμους πολιτικής απορρήτου που λείπουν: οι Κατευθυντήριες Γραμμές 5.1.1 και 1.5 το ονομάζουν ακριβώς.
• Το Google Play απαιτεί τόσο μια διαδρομή διαγραφής λογαριασμού εντός εφαρμογής όσο και μια δημόσια διαδρομή web, με την επιβολή να ακολουθεί την προθεσμία παράτασης της 31ης Μαΐου 2024.
• Τα checklists υποβολής για iOS και Android διαφέρουν. Η αντιμετώπισή τους ως μία ενιαία λίστα είναι η νούμερο 1 αιτία καθυστερήσεων κυκλοφορίας της τελευταίας στιγμής.

Πριν Γράψεις Κώδικα

Πριν σχεδιαστεί έστω και μία οθόνη, τρία πράγματα πρέπει να κλειδώσουν: τι είναι πραγματικά το MVP σου, αν χρειάζεσαι πολιτική απορρήτου (χρειάζεσαι), και αν το GDPR ή ο KVKK της Τουρκίας ισχύει για τους χρήστες σου. Το να παραλείψεις αυτό το στάδιο είναι ο λόγος που οι ιδρυτές καταλήγουν να γράφουν έντρομοι νομικές σελίδες την εβδομάδα που ήθελαν να υποβάλουν.

Ένα MVP, με μία πρόταση, είναι η μικρότερη εκδοχή του προϊόντος σου που δοκιμάζει την κεντρική σου υπόθεση με πραγματικούς χρήστες. Δεν είναι μια κουρεμένη εκδοχή του πλήρους οράματός σου. Αν ακόμα αμφιταλαντεύεσαι για το πεδίο, το σωστό scoping του project σου πριν γράψεις μια γραμμή κώδικα σε γλιτώνει από το να κόβεις λειτουργίες στη μέση της ανάπτυξης αντί πριν από αυτήν.

Οι ίδιες οι κατευθυντήριες γραμμές της Apple είναι ωμές για την απαίτηση πολιτικής απορρήτου: η Κατευθυντήρια Γραμμή 5.1.1(i) ορίζει ότι οι εφαρμογές "πρέπει να περιλαμβάνουν σύνδεσμο προς την πολιτική απορρήτου τους" στα μεταδεδομένα του App Store Connect και, σε πολλές περιπτώσεις, μέσα στην ίδια την εφαρμογή. Αυτό δεν είναι πρόταση. Είναι εμπόδιο υποβολής αν λείπει.

• Όρισε το πεδίο του MVP σου σε μία πρόταση
• Επιβεβαίωσε ότι χρειάζεσαι πολιτική απορρήτου (σχεδόν πάντα χρειάζεται)
• Σχεδίασε ένα Support URL (η Κατευθυντήρια Γραμμή 1.5 της Apple το απαιτεί)
• Έλεγξε την εφαρμοσιμότητα GDPR/KVKK αν έχεις χρήστες στην ΕΕ ή την Τουρκία
• Αποφάσισε native ή cross-platform stack

Η Εβδομάδα Ανάπτυξης του MVP

Η εβδομάδα ανάπτυξης του MVP είναι όπου αποφασίζεις τι πραγματικά κυκλοφορεί έναντι τι κόβεται, και η ειλικρινής απάντηση είναι: περισσότερα από όσα περιμένουν οι ιδρυτές. Τα analytics και η αναφορά σφαλμάτων μπαίνουν κατά την ανάπτυξη, όχι μετά. Η εκ των υστέρων προσθήκη τους σημαίνει ότι χάνεις ακριβώς τα δεδομένα που χρειαζόσουν για να επικυρώσεις την πρώτη σου υπόθεση.

Αυτό που πραγματικά κόβουμε από το πεδίο μιας v1, τις περισσότερες φορές, είναι οτιδήποτε δεν είναι το ένα πράγμα που δοκιμάζεται. Push notifications, social login, μια οθόνη ρυθμίσεων με έξι διακόπτες, όλα αυτά μπορούν να περιμένουν. Οι ιδρυτές αντιστέκονται σε αυτό, κατανοητά. Νιώθει σαν να κυκλοφορείς κάτι ημιτελές. Είναι ημιτελές. Αυτό είναι το νόημα.

Όπως το έθεσε ένας ιδρυτής που έχει κυκλοφορήσει αρκετές εφαρμογές σε μια ανάρτηση checklist στο dev.to, η παράλειψη ενός μηχανισμού ανατροφοδότησης νωρίς είναι λάθος που "το μετάνιωσε κάθε φορά". Ενσωμάτωσέ το τώρα, όχι μετά την πρώτη σου κριτική. Αν θέλεις να επιταχύνεις την ίδια τη συζήτηση scoping, η χρήση AI για γρηγορότερο scoping αξίζει μια ματιά πριν ξεκινήσει η ανάπτυξη.

• Ενόργανα analytics πριν το πρώτο TestFlight/εσωτερικό build
• Συνδύασε αναφορά σφαλμάτων (Sentry ή Firebase Crashlytics)
• Ενσωμάτωσε έναν μηχανισμό ανατροφοδότησης στην εφαρμογή
• Κόψε κάθε λειτουργία που δεν είναι κεντρική για το ένα πράγμα που δοκιμάζεις
• Γράψε το πρώτο σου version string (δες versioning παρακάτω)

Η Εβδομάδα Πριν την Υποβολή

Αυτό είναι το στάδιο που κάθε ανταγωνιστικό checklist παραλείπει εντελώς, και είναι όπου συμβαίνουν οι πιο αποτρέψιμες καθυστερήσεις. Το semantic versioning για εφαρμογές ακολουθεί το μοτίβο MAJOR.MINOR.BUILD (1.0.0, μετά 1.0.1 για patch, 1.1.0 για feature bump). Διάλεξε ένα σχήμα τώρα, επειδή οι ασυνεπείς αριθμοί έκδοσης μπερδεύουν τόσο τα app stores όσο και την ίδια σου την ομάδα.

Η σταδιακή κυκλοφορία (staged rollout) απελευθερώνει την ενημέρωσή σου πρώτα σε ένα μικρό ποσοστό χρηστών (συχνά 1%, μετά 10%, μετά 50%) πριν πάει σε όλους. Μόνο ένα από τα τρία ανταγωνιστικά checklists που εξετάσαμε το αναφέρει, και ακόμα τότε εν παρόδω. Αν ένα σφάλμα ξεφύγει, η σταδιακή κυκλοφορία περιορίζει την ακτίνα έκρηξης αντί να χτυπήσει το 100% των χρηστών ταυτόχρονα.

Οι ερωτήσεις που κάνουμε πριν εγκρίνουμε μια υποβολή πελάτη είναι απλές: λειτουργεί η κρίσιμη διαδρομή από άκρη σε άκρη, αυτή τη στιγμή, σε πραγματική συσκευή; Όχι στον simulator. Είναι αποδεκτό το ποσοστό χωρίς σφάλματα (crash-free rate); Είναι τα assets της καταχώρισης store πραγματικά τελικά, όχι placeholders;

• Επιβεβαίωσε ότι ο αριθμός έκδοσης ακολουθεί συνεπές σχήμα
• Δοκίμασε την κρίσιμη διαδρομή από άκρη σε άκρη άλλη μία φορά
• Ετοίμασε το ποσοστό σταδιακής κυκλοφορίας αν το store το υποστηρίζει
• Επιβεβαίωσε ότι το crash-free rate είναι αποδεκτό πριν υποβάλεις
• Τράβηξε screenshot και ετοίμασε όλα τα assets της καταχώρισης store

Ημέρα Υποβολής: iOS vs. Android

Οι υποβολές iOS και Android αποτυγχάνουν για διαφορετικούς λόγους, και η αντιμετώπισή τους ως ένα ενιαίο checklist είναι η μεγαλύτερη αιτία καθυστερήσεων κυκλοφορίας της τελευταίας στιγμής που βλέπουμε. Οι Κατευθυντήριες Γραμμές App Store Review της Apple και οι πολιτικές developer του Google Play ονομάζουν η καθεμία συγκεκριμένες, ελέγξιμες απαιτήσεις, και οι περισσότεροι ιδρυτές τις μαθαίνουν μόνο μετά από ένα email απόρριψης.

Στις δικές μας υποβολές εφαρμογών, τα δύο πράγματα που μπερδεύουν συχνότερα τους πρωτοεμφανιζόμενους ιδρυτές είναι η απαίτηση διαγραφής λογαριασμού και ένα μη προσβάσιμο Support URL. Και τα δύο είναι διορθώσεις μιας γραμμής αν τα πιάσεις πριν υποβάλεις. Και τα δύο προκαλούν αυτόματη απόρριψη αν δεν τα πιάσεις.

Οι Κατευθυντήριες Γραμμές App Store Review της Apple είναι συγκεκριμένες: η Κατευθυντήρια Γραμμή 5.1.1(v) απαιτεί οι εφαρμογές που υποστηρίζουν δημιουργία λογαριασμού να προσφέρουν επίσης διαγραφή λογαριασμού εντός εφαρμογής, η Κατευθυντήρια Γραμμή 1.6 καλύπτει τις γνωστοποιήσεις Data Security, και η Κατευθυντήρια Γραμμή 1.5 απαιτεί ένα λειτουργικό Support URL. Στο Android, η πολιτική developer του Google Play απαιτεί τόσο μια διαδρομή διαγραφής εντός εφαρμογής όσο και ένα δημόσιο web URL για αιτήματα διαγραφής λογαριασμού. Η Google ανακοίνωσε την απαίτηση τον Απρίλιο του 2023, όρισε προθεσμία 7 Δεκεμβρίου 2023 για τις ερωτήσεις διαγραφής δεδομένων της φόρμας Data safety, και επέτρεψε παρατάσεις έως τις 31 Μαΐου 2024, μετά την οποία οι μη συμμορφούμενες εφαρμογές αντιμετωπίζουν επιβολή. Αυτό δεν είναι παλιός κανόνας που καταργήθηκε για τις μικρές εφαρμογές. Ισχύει ακόμα.

Οι δύο ροές υποβολής αποκλίνουν επίσης μηχανικά, όχι μόνο στα χαρτιά. Στο iOS, ανεβάζεις ένα build μέσω Xcode ή Transporter, το App Store Connect το επεξεργάζεται (αυτό παίρνει από λίγα λεπτά έως πάνω από μία ώρα), και από εκεί είτε το δρομολογείς στο TestFlight για εσωτερικούς και εξωτερικούς δοκιμαστές είτε το υποβάλλεις απευθείας για App Review. Το TestFlight δεν είναι προαιρετική γραφειοκρατία: είναι ο τρόπος που η Apple περιμένει να πιάσεις τα bugs για τα οποία ένας reviewer θα σε απέρριπτε. Στο Android, το Google Play Console λειτουργεί με tracks αντί για μία ενιαία υποβολή, περνώντας από internal testing, μετά closed ή open testing, μετά production, το καθένα με το δικό του κοινό και το δικό του βήμα προώθησης. Η σταδιακή κυκλοφορία εμφανίζεται μόνο όταν ενημερώνεις μια υπάρχουσα production κυκλοφορία. Όπως λέει η ίδια η τεκμηρίωση κυκλοφορίας της Google, "αν κυκλοφορείς την πρώτη σου έκδοση, δεν θα δεις την επιλογή επιλογής ποσοστού κυκλοφορίας", οπότε μην σχεδιάζεις την πρώτη σου κυκλοφορία γύρω από μια κλίμακα ποσοστού. Αυτό έρχεται αργότερα.

Η γραφειοκρατία, όχι ο κώδικας, είναι αυτό που πραγματικά μπλοκάρει τις περισσότερες πρωτοεμφανιζόμενες υποβολές. Η Apple απαιτεί ένα privacy manifest για μια καθορισμένη λίστα συχνά χρησιμοποιούμενων third-party SDKs (δίκτυα διαφημίσεων, analytics, αναφορείς σφαλμάτων), και η δική της καθοδήγηση είναι ωμή για το ποιος φέρει την ευθύνη: "όταν χρησιμοποιείς ένα third-party SDK με την εφαρμογή σου, είσαι υπεύθυνος για όλο τον κώδικα που το SDK περιλαμβάνει στην εφαρμογή σου, και πρέπει να γνωρίζεις τις πρακτικές συλλογής και χρήσης δεδομένων του", σύμφωνα με τη σελίδα απαιτήσεων third-party SDK της Apple. Παράλειψε ένα manifest για ένα καταχωρισμένο SDK και το build σου δεν θα περάσει το App Store Connect. Το αντίστοιχο γραφειοκρατικό εμπόδιο του Google Play είναι η φόρμα Data safety, και είναι υποχρεωτική για κάθε εφαρμογή σε κάθε track εκτός από τα builds μόνο εσωτερικής δοκιμής: "όλοι οι developers που έχουν εφαρμογή δημοσιευμένη στο Google Play πρέπει να συμπληρώσουν τη φόρμα Data safety, συμπεριλαμβανομένων εφαρμογών σε closed, open ή production testing tracks", σύμφωνα με την τεκμηρίωση Data safety του Google Play. Κάνε λάθος και η Google λέει ξεκάθαρα ότι "μπορεί να λάβει κατάλληλα μέτρα, συμπεριλαμβανομένων μέτρων επιβολής" μόλις εμφανιστεί ασυμφωνία μεταξύ της δηλωμένης και της πραγματικής συμπεριφοράς της εφαρμογής.

Υπάρχει μια τρίτη κατάσταση αποτυχίας που δεν έχει καμία σχέση με κείμενο πολιτικής: ο reviewer κυριολεκτικά δεν μπορεί να δοκιμάσει την εφαρμογή σου. Η Κατευθυντήρια Γραμμή 2.1 της Apple το λέει απευθείας: "συμπεριλάβε πληροφορίες demo λογαριασμού (και ενεργοποίησε την back-end υπηρεσία σου!) αν η εφαρμογή σου περιλαμβάνει σύνδεση." Χωρίς λειτουργικά demo credentials, χωρίς ζωντανό backend κατά το παράθυρο αξιολόγησης, χωρίς προσβάσιμο Support URL, και θα απορριφθείς ανεξάρτητα από το πόσο συμμορφωμένη είναι η ροή διαγραφής λογαριασμού σου. Αν οποιοδήποτε μέρος της εφαρμογής σου βρίσκεται πίσω από paywall ή πύλη σύνδεσης, γράψε σημειώσεις reviewer που εξηγούν ακριβώς πώς να το προσεγγίσουν. Είναι ένα βήμα δύο λεπτών που οι πρωτοεμφανιζόμενοι ιδρυτές παραλείπουν συνεχώς.

Άλλο ένα εμπόδιο μόνο για Android ανήκει στην ίδια συζήτηση: το target API level. Η ίδια η τεκμηρίωση developer του Android δηλώνει ότι "νέες εφαρμογές και ενημερώσεις εφαρμογών πρέπει να στοχεύουν" το τρέχον απαιτούμενο Android API level "για να υποβληθούν στο Google Play," και ότι "οι ξεπερασμένες εφαρμογές δεν είναι διαθέσιμες σε νέους χρήστες συσκευών που τρέχουν νεότερες εκδόσεις του Android." Δεν έχει καμία σχέση με διαγραφή λογαριασμού ή Data Safety, αλλά μπλοκάρει μια υποβολή εξίσου κατηγορηματικά, και είναι το είδος της απαίτησης που αλλάζει κάθε χρόνο, οπότε έλεγξε τον τρέχοντα αριθμό πριν χτίσεις την κυκλοφορία σου.

Κανένα από τα κορυφαία checklists για αυτήν ακριβώς την αναζήτηση δεν παραθέτει ούτε έναν αριθμό κατευθυντήριας γραμμής του App Store. Εμείς το κάνουμε, επειδή η εικασία στη συμμόρφωση είναι ο τρόπος που οι κυκλοφορίες καθυστερούν κατά μία εβδομάδα κάθε φορά. Αν χτίζεις τη συνολικότερη στάση διαχείρισης δεδομένων σου, το checklist διαχείρισης δεδομένων πριν το launch καλύπτει την πλευρά ασφάλειας που δεν διπλασιάζουμε εδώ.

Checklist υποβολής iOS:

• URL πολιτικής απορρήτου ζωντανό και προσβάσιμο
• Διαδρομή διαγραφής λογαριασμού εντός εφαρμογής κυκλοφόρησε (Κατευθυντήρια Γραμμή 5.1.1(v))
• Support URL ζωντανό (Κατευθυντήρια Γραμμή 1.5)
• Γνωστοποιήσεις Data Security συμπληρωμένες (Κατευθυντήρια Γραμμή 1.6)
• TestFlight build εγκρίθηκε πριν τη δημόσια υποβολή

Checklist υποβολής Android:

• Φόρμα Data Safety συμπληρωμένη στο Play Console
• Διαδρομή διαγραφής λογαριασμού εντός εφαρμογής κυκλοφόρησε
• Δημόσιο web URL για αιτήματα διαγραφής λογαριασμού ζωντανό (απαίτηση Google Play)
• Ποσοστό σταδιακής κυκλοφορίας ορισμένο
• Target API level πληροί την τρέχουσα απαίτηση του Play

Ημέρα Κυκλοφορίας

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

Παρακολούθησε το dashboard του App Store Connect ή του Play Console ωριαία, όχι ημερήσια, για τις πρώτες 24 ώρες. Αν το crash-free rate σου πέσει, θέλεις να το μάθεις μέσα στην ώρα, όχι το επόμενο πρωί όταν εκατό ακόμα χρήστες έχουν χτυπήσει το ίδιο bug. Κράτα ένα rollback build έτοιμο. Η ίδια πειθαρχία harden-stabilize-deploy που χρησιμοποιούμε για AI features εφαρμόζει εξίσου άμεσα εδώ.

• Παρακολούθησε το crash-free rate ωριαία για τις πρώτες 24 ώρες
• Κράτα το κανάλι υποστήριξής σου επανδρωμένο και έτοιμο
• Επιβεβαίωσε ότι η σταδιακή κυκλοφορία επεκτείνεται όπως προγραμματίστηκε
• Κράτα ένα rollback build έτοιμο σε περίπτωση κρίσιμου bug

Η Πρώτη Εβδομάδα Ζωντανά

Η πρώτη εβδομάδα ζωντανά είναι όπου συμβαίνει το μεγαλύτερο μέρος της πραγματικής δουλειάς, παρόλο που σχεδόν κανείς δεν την προγραμματίζει. Η ημερήσια ανασκόπηση αναφορών σφαλμάτων και η απάντηση στις πρώτες σου κριτικές store έχουν περισσότερη σημασία από οτιδήποτε έκανες την ίδια την ημέρα κυκλοφορίας.

"Η ίδια η κυκλοφορία έχει λιγότερη σημασία από όσο νομίζεις. Αυτό που έχει σημασία είναι τι κάνεις τις εβδομάδες μετά," όπως έγραψε ένας ιδρυτής στο δικό του checklist μετά την κυκλοφορία. Αυτή είναι η ειλικρινής εκδοχή της πρώτης εβδομάδας: διόρθωσε γρήγορα, απάντησε προσωπικά, και πραγματικά έλεγξε ότι η ροή διαγραφής δεδομένων σου λειτουργεί πριν τη δοκιμάσει ένας πραγματικός χρήστης για εσένα. Αν τώρα αναρωτιέσαι πόσο κοστίζουν όλα αυτά να χτιστούν και να συντηρηθούν, ο προϋπολογισμός για συντήρηση και ενημερώσεις μετά το launch είναι το συνοδευτικό κομμάτι. Αυτό το άρθρο καλύπτει την ετοιμότητα. Εκείνο καλύπτει τον λογαριασμό.

• Ανασκόπησε αναφορές σφαλμάτων ημερησίως για την πρώτη εβδομάδα
• Απάντησε προσωπικά στις πρώτες 10 κριτικές store
• Τριασάρισε και διόρθωσε κάθε κρίσιμο bug μέσα σε 48 ώρες
• Επιβεβαίωσε ότι η διαδικασία αιτήματος διαγραφής δεδομένων λειτουργεί πραγματικά από άκρη σε άκρη
• Όρισε έναν ρυθμό για έλεγχο των analytics έναντι της αρχικής σου υπόθεσης MVP

Πώς το Προσεγγίζει η Techsy

Αντιμετωπίζουμε την αξιολόγηση πριν την υποβολή με τον ίδιο τρόπο για κάθε build πελάτη: πριν εγκρίνουμε μια υποβολή, ρωτάμε αν η κρίσιμη διαδρομή λειτουργεί σε πραγματική συσκευή, αν το crash-free rate αντέχει, και αν κάθε ροή που επιβάλλεται από κατευθυντήρια γραμμή (διαγραφή λογαριασμού, πολιτική απορρήτου, Support URL) πραγματικά λειτουργεί, όχι απλώς υπάρχει σε mockup. Είναι μια μικρή λίστα, αλλά είναι η λίστα που καθορίζει αν μια εφαρμογή περνά την αξιολόγηση με την πρώτη προσπάθεια.

Αν προτιμάς κάποιος που έχει πλοηγηθεί σε αυτές τις κατευθυντήριες γραμμές πριν να αναλάβει την υποβολή σου, η διαδικασία ανάπτυξης mobile app μας είναι χτισμένη ακριβώς γύρω από αυτό το βήμα αξιολόγησης πριν την υποβολή. Δεν είναι υποκατάστατο του να κάνεις τη δική σου προεργασία. Είναι αυτό που κάνουμε αφού την έχεις κάνει.

Συχνές Ερωτήσεις

Τι είναι ένα MVP και γιατί έχει σημασία για ένα checklist κυκλοφορίας;

Ένα MVP είναι η μικρότερη εκδοχή του προϊόντος σου που δοκιμάζει μία κεντρική υπόθεση με πραγματικούς χρήστες. Έχει σημασία εδώ επειδή κάθε στοιχείο σε αυτό το checklist κλιμακώνεται με το πεδίο. Ένα πιο σφιχτό MVP σημαίνει λιγότερα πράγματα που μπορούν να πάνε στραβά στην υποβολή και λιγότερες λειτουργίες για ενόργανωση, παρακολούθηση και διόρθωση στην πρώτη εβδομάδα.

Γιατί απορρίπτονται εφαρμογές από το App Store;

Οι πιο συνηθισμένοι αποτρέψιμοι λόγοι είναι σύνδεσμοι πολιτικής απορρήτου που λείπουν (Κατευθυντήρια Γραμμή 5.1.1(i)), καμία διαγραφή λογαριασμού εντός εφαρμογής (Κατευθυντήρια Γραμμή 5.1.1(v)), και ένα μη προσβάσιμο Support URL (Κατευθυντήρια Γραμμή 1.5). Κανένα από αυτά δεν απαιτεί μηχανική προσπάθεια για διόρθωση. Είναι στοιχεία checklist, όχι bugs.

Τι συμβαίνει αν δεν προσθέσω επιλογή διαγραφής λογαριασμού στην εφαρμογή μου;

Στο iOS, η Κατευθυντήρια Γραμμή 5.1.1(v) το καθιστά αυτόματο λόγο απόρριψης αν η εφαρμογή σου υποστηρίζει δημιουργία λογαριασμού. Στο Android, το Google Play απαιτεί τόσο μια διαδρομή διαγραφής εντός εφαρμογής όσο και μια δημόσια διαδρομή web, με τις μη συμμορφούμενες εφαρμογές να αντιμετωπίζουν επιβολή μετά την προθεσμία παράτασης της 31ης Μαΐου 2024, και η παράλειψή του μπλοκάρει την υποβολή και στις δύο πλατφόρμες.

Χρειάζονται τα startups πολιτική απορρήτου για μια mobile εφαρμογή;

Ναι, σχεδόν πάντα. Η Apple απαιτεί μια συνδεδεμένη πολιτική απορρήτου βάσει της Κατευθυντήριας Γραμμής 5.1.1(i), και το Google Play απαιτεί μία μέσα στη φόρμα Data Safety. Αν συλλέγεις οποιαδήποτε δεδομένα χρήστη, ακόμα και απλώς ένα email για εγγραφή, χρειάζεσαι μία πριν υποβάλεις.

Ποια είναι η διαφορά μεταξύ υποβολής στο App Store και στο Google Play;

Η αξιολόγηση της Apple καθοδηγείται από κατευθυντήριες γραμμές με ονομαστικές ρήτρες (5.1.1, 1.5, 1.6) και έναν ανθρώπινο reviewer. Το Google Play βασίζεται στη φόρμα Data Safety και αυτοματοποιημένους ελέγχους. Η απαίτηση διαγραφής λογαριασμού είναι παρόμοια στο πνεύμα αλλά διαφέρει στους μηχανισμούς. Δες τον παραπάνω πίνακα σύγκρισης.

Πόσο διαρκεί πραγματικά η αξιολόγηση app store;

Κανένα store δεν δημοσιεύει εγγυημένο χρόνο διεκπεραίωσης, οπότε αντιμετώπισε οποιονδήποτε αριθμό διαβάζεις ως χοντρική προσδοκία και όχι ως υπόσχεση. Στις δικές μας υποβολές πελατών, οι εγκρίσεις της Apple έχουν γενικά έρθει μέσα σε μία-δύο μέρες, με οτιδήποτε αγγίζει διαγραφή λογαριασμού ή γνωστοποίηση δεδομένων να παίρνει περισσότερο. Το Google Play είναι συνήθως γρηγορότερο. Προγραμμάτισε την ημερομηνία κυκλοφορίας σου με περιθώριο έτσι κι αλλιώς.

Τι είναι η σταδιακή κυκλοφορία και πρέπει να τη χρησιμοποιήσω;

Η σταδιακή κυκλοφορία απελευθερώνει μια ενημέρωση πρώτα σε ένα μικρό ποσοστό χρηστών, μετά επεκτείνεται σταδιακά, αντί να πάει στο 100% ταυτόχρονα. Χρησιμοποίησέ την όποτε το store την υποστηρίζει. Περιορίζει πόσοι χρήστες χτυπούν ένα bug πριν προλάβεις να πατήσεις παύση και να το διορθώσεις.

Χρειάζομαι support URL για να υποβάλω την εφαρμογή μου;

Ναι. Η Κατευθυντήρια Γραμμή 1.5 της Apple απαιτεί ένα λειτουργικό Support URL ως μέρος της υποβολής, και το Google Play περιμένει επίσης μια επαφή υποστήριξης. Ένας νεκρός σύνδεσμος ή ένα μη παρακολουθούμενο inbox εδώ είναι ένας εύκολος, αποτρέψιμος λόγος απόρριψης.

Τι πρέπει να παρακολουθώ στην πρώτη εβδομάδα της εφαρμογής μου;

Αναφορές σφαλμάτων ημερησίως, τις πρώτες δέκα κριτικές store, και αν η διαδικασία αιτήματος διαγραφής δεδομένων λειτουργεί πραγματικά από άκρη σε άκρη. Αυτή είναι επίσης η στιγμή που αρχίζεις να ελέγχεις τα πραγματικά δεδομένα χρήσης έναντι της υπόθεσης για την οποία χτίστηκε το MVP σου.

Είναι το GDPR ή ο KVKK σχετικά για την εφαρμογή ενός μικρού startup;

Αν έχεις χρήστες στην ΕΕ, το GDPR ισχύει ανεξάρτητα από το μέγεθος της εταιρείας σου. Αν έχεις χρήστες στην Τουρκία, ο KVKK ισχύει με τον ίδιο τρόπο. Κανένας νόμος δεν έχει εξαίρεση για μικρά startups, οπότε έλεγξε την εφαρμοσιμότητα κατά το scoping, όχι αφού έχεις πραγματικά δεδομένα χρηστών να προστατεύσεις.

Σχετικά με τον Συγγραφέα

Ο Mert Batur είναι Συνιδρυτής του Techsy.io, όπου η ομάδα κυκλοφορεί AI agents, συστήματα αυτοματισμού και voice/SDR pipelines για B2B πελάτες. Γράφει για το LLM tooling stack που η ομάδα της Techsy χρησιμοποιεί πραγματικά στην παραγωγή. Συνδέσου στο LinkedIn.

Συμπέρασμα

Ένα checklist mobile app για startups κερδίζει τη θέση του μόνο αν είναι αρκετά συγκεκριμένο για να δράσεις σήμερα: όρισε το MVP σου σε μία πρόταση, ενόργανα analytics πριν χτίσεις, αναθεώρησε το σχήμα έκδοσης την εβδομάδα πριν την υποβολή, και χώρισε τα checklists iOS και Android αντί να τα αντιμετωπίζεις ως μία λίστα. Μόνο τα στοιχεία διαγραφής λογαριασμού και πολιτικής απορρήτου ευθύνονται για τις περισσότερες αποτρέψιμες απορρίψεις που βλέπουμε.

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