Σε κάθε έργο app έρχεται μια στιγμή που η ομάδα γιορτάζει την υποβολή. Και μετά ανακαλύπτει ότι η υποβολή δεν είναι launch, ότι το launch δεν σημαίνει τέλος, και ότι ένα app δεν είναι ποτέ «τελειωμένο». Ό,τι ακολουθεί είναι το κομμάτι που κανείς δεν βάζει σε παρουσίαση.
Πρώτα έρχεται ο έλεγχος από τα stores. Οι περισσότερες απορρίψεις είναι τόσο προβλέψιμες που, αν σας ξαφνιάσουν, φταίει ο προγραμματισμός και όχι η ατυχία. Η απαίτηση της Apple για διαγραφή λογαριασμού, αν το app επιτρέπει τη δημιουργία λογαριασμού. Οι ετικέτες απορρήτου και το privacy manifest, που πρέπει να ταιριάζουν με ό,τι συλλέγει πραγματικά ο κώδικας, μαζί με όσα συλλέγουν για λογαριασμό σας τα SDK τρίτων. Μια ισοδύναμη επιλογή σύνδεσης που σέβεται το απόρρητο, όπου προσφέρεται σύνδεση μέσω τρίτων. Και η οδηγία 4.2 για την ελάχιστη λειτουργικότητα, που λέει ευγενικά ότι ένα app που απλώς δείχνει ένα website μέσα σε πλαίσιο θα απορριφθεί. Στο ίδιο συμπέρασμα καταλήγει και αυτό το journal, για εμπορικούς λόγους. Αν τα ετοιμάσετε πριν την υποβολή, ο έλεγχος κρατά λίγες μέρες. Αν τα ανακαλύψετε μετά, λίγες εβδομάδες.
Μετά η κυκλοφορία, που δεν πρέπει να γίνεται ποτέ για όλους μαζί. Η σταδιακή κυκλοφορία του Google Play και η phased release της Apple αφήνουν μια έκδοση να φτάσει πρώτα σε ένα μικρό ποσοστό χρηστών. Και οι δύο είναι άχρηστες χωρίς ένα κριτήριο διακοπής που έχει συμφωνηθεί από πριν: ποσοστό συνεδριών χωρίς crash κάτω από ένα όριο, ποσοστό σφαλμάτων πάνω από ένα όριο, μια απότομη αύξηση σε μια συγκεκριμένη οθόνη. Αν αποφασίζετε την ίδια μέρα αν ένας αριθμός είναι αρκετά κακός για να σταματήσετε, οι κακές εκδόσεις φτάνουν σε όλους. Γιατί μέχρι τότε κάποιος έχει ήδη ανακοινώσει το launch.
Η πιο χρήσιμη δυνατότητα που μπορεί να έχει μια ομάδα app είναι να διορθώνει κάτι χωρίς να περιμένει τον έλεγχο. Σε ένα app React Native, οι ενημερώσεις over-the-air μέσω Expo καλύπτουν το κομμάτι JavaScript, δηλαδή τα περισσότερα bugs: μια ροή που χάλασε, ένα λάθος κείμενο, μια ετικέτα με λάθος τιμή. Και φτάνουν στους χρήστες σε λίγα λεπτά. Δεν καλύπτουν ό,τι αλλάζει native κώδικα, άδειες ή βιβλιοθήκες. Αν τις χρησιμοποιήσετε για να βγάλετε ουσιαστικά ένα διαφορετικό app, παραβιάζετε την πολιτική των stores, και αυτό πρέπει να το πάρετε στα σοβαρά. Δείτε τις ως τρόπο να διορθώνετε, όχι ως τρόπο να βγάζετε νέες εκδόσεις.
Κάτω από όλα αυτά βρίσκεται η πειθαρχία που κάνει τα υπόλοιπα να δουλεύουν: τα feature flags, διακόπτες που ανοίγουν και κλείνουν λειτουργίες χωρίς νέα έκδοση. Αν η κυκλοφορία του κώδικα και η ανακοίνωση μιας λειτουργίας είναι το ίδιο γεγονός, κάθε προθεσμία σημαίνει πάγωμα του κώδικα και κάθε επιστροφή πίσω σημαίνει νέα υποβολή. Αν ο κώδικας κυκλοφορεί σβηστός και τον ανάβει ένας διακόπτης, η ημερομηνία του marketing και η ημερομηνία της ανάπτυξης σταματούν να συγκρούονται. Και μια λειτουργία που δεν συμπεριφέρεται σωστά κλείνει το ίδιο απόγευμα, αντί να διορθωθεί σε δεκαπέντε μέρες.
Ο δείκτης υγείας δεν είναι οι εγκαταστάσεις ούτε η βαθμολογία. Είναι οι συνεδρίες χωρίς crash, ανά έκδοση του app και ανά έκδοση λειτουργικού. Στο Android τα ANR (application not responding, όταν το app παγώνει) παρακολουθούνται χωριστά. Ένα app που παγώνει είναι χειρότερη εμπειρία από ένα που κλείνει, και δεν εμφανίζεται καθόλου στον αριθμό των crash. Το 99,5% συνεδριών χωρίς crash είναι λογικό κατώτατο όριο για ένα καταναλωτικό app. Αυτό που πραγματικά σας προειδοποιεί όμως δεν είναι ο αριθμός μόνος του. Είναι η πτώση που εμφανίζεται τρεις μέρες μετά από μια έκδοση.
Και μετά η ρουτίνα που δεν σταματά ποτέ. Το iOS και το Android βγάζουν το καθένα μια μεγάλη έκδοση κάθε φθινόπωρο, και η καθεμία καταργεί κάτι. Η απαίτηση του Google Play για target API level αναγκάζει σε ετήσιο ξαναχτίσιμο. Οι βιβλιοθήκες παλιώνουν, τα πιστοποιητικά λήγουν, ένα SDK στο οποίο βασίζεστε εξαγοράζεται και κλείνει. Τίποτα από αυτά δεν το βλέπει ο πελάτης, όλα τιμολογούνται. Η μόνη εναλλακτική είναι να σταματήσει το app να ανοίγει μετά από μια ενημέρωση λειτουργικού και η επιχείρηση να το μάθει από μια κριτική.
Κι έτσι επιστρέφουμε στον μόνο αριθμό που αξίζει να μπει σε dashboard: το ποσοστό όσων το εγκατέστησαν τον Ιανουάριο και το άνοιγαν ακόμη τον Μάρτιο. Όλα τα παραπάνω υπηρετούν αυτόν τον αριθμό. Ένα app που ελέγχεται, κυκλοφορεί, παρακολουθείται και συντηρείται σωστά δεν γίνεται γι' αυτό καλό app. Ένα app όμως που δεν τα κάνει αυτά δεν θα ζήσει αρκετά για να γίνει.
Common questions
- Πόσο κρατά ο έλεγχος στο App Store;
- Συνήθως μία έως τρεις μέρες για μια υποβολή που έχει ετοιμαστεί σωστά, και αρκετά περισσότερο αν το app απορριφθεί και ξαναϋποβληθεί. Οι συνηθισμένες απορρίψεις είναι προβλέψιμες: λείπει η διαγραφή λογαριασμού, οι ετικέτες απορρήτου δεν ταιριάζουν με ό,τι συλλέγει το app, οι απαιτήσεις σύνδεσης, και η οδηγία 4.2 όταν ένα app κάνει ελάχιστα περισσότερα από το να δείχνει ένα website μέσα σε πλαίσιο.
- Μπορείτε να ενημερώσετε ένα mobile app χωρίς να περάσει από έλεγχο;
- Εν μέρει. Ένα app React Native μπορεί να στέλνει ενημερώσεις over-the-air στο κομμάτι JavaScript μέσω Expo. Αυτές καλύπτουν τις περισσότερες διορθώσεις bugs και αλλαγές κειμένων και φτάνουν στους χρήστες σε λίγα λεπτά. Ό,τι αλλάζει native κώδικα, άδειες ή βιβλιοθήκες χρειάζεται νέα έκδοση στο store και νέο έλεγχο. Και η πολιτική των stores δεν επιτρέπει να χρησιμοποιείτε τις ενημερώσεις over-the-air για να αλλάξετε ουσιαστικά τι κάνει το app.
- Ποιο είναι ένα καλό ποσοστό χωρίς crash για ένα mobile app;
- Πάνω από 99,5% των συνεδριών είναι λογικό κατώτατο όριο για ένα καταναλωτικό app, με παρακολούθηση ανά έκδοση του app και ανά έκδοση λειτουργικού. Στο Android, τα συμβάντα application-not-responding πρέπει να παρακολουθούνται χωριστά. Ένα app που παγώνει δεν καταγράφεται ως crash και είναι χειρότερη εμπειρία από ένα crash.
The service behind it
Mobile App Development
Native και cross-platform εφαρμογές για iOS και Android, με την ίδια φροντίδα στον σχεδιασμό του interface όση και στον κώδικα.