Native ή React Native για μια hospitality app;

Το «native ή React Native;» είναι συνήθως η πρώτη ερώτηση σε ένα hospitality brief. Είναι η τρίτη που απαντάμε. Τρία από τα έξι projects σε αυτό το site είναι apps φιλοξενίας ή πολιτισμού — ένας οδηγός προορισμού, μια αυτοξεναγούμενη ηχητική περιήγηση, ένα CRM επισκεπτών με scanner για συνεργάτες — και ένα τέταρτο διαβάζει rapid tests μέσα από την κάμερα του κινητού. Και τα τέσσερα βγήκαν σε React Native. Είναι ρεκόρ, όχι πολιτική. Να με ποια σειρά ρωτάμε, και πού θα είχε γυρίσει η απάντηση.

Χρειάζεται καν να είναι app;

Το έχουμε γράψει ήδη, οπότε η σύντομη εκδοχή: περίπου τα μισά mobile briefs που βλέπουμε είναι ένα web flow με μία άδεια για notifications. Η φιλοξενία κάνει τον διαχωρισμό ασυνήθιστα καθαρό. Ένας επισκέπτης που κλείνει τραπέζι δεν θέλει να εγκαταστήσει τίποτα. Ένας συνεργάτης που σκανάρει perks όλη τη βάρδια, ή ένας επισκέπτης που περπατάει μια διαδρομή χωρίς σήμα, θέλει. Λέμε ναι στην εγκατάσταση όταν το κινητό είναι η επιφάνεια εργασίας. Όταν είναι μόνο ο προορισμός, βγάζουμε το web flow και κρατάμε το budget.

Ποια features επιβάλλουν την εγκατάσταση;

Η σκάλα παραπάνω είναι η σειρά. Πέντε features επιβάλλουν την εγκατάσταση, στην πράξη: κάμερα που σκανάρει ή τραβάει, τοποθεσία που δουλεύει με την οθόνη σβηστή, περιεχόμενο που πρέπει να είναι εκεί χωρίς σήμα, ήχος που συνεχίζει να παίζει μέσα στην τσέπη, και push που φτάνει χωρίς την τελετή του «πρόσθεσε στην αρχική οθόνη». Οι τρεις hospitality apps μας χρειάστηκαν, όλες μαζί, ζωντανή τοποθεσία με οδηγίες σε χάρτη, background player με offline downloads και presence tracking, και σκανάρισμα QR από την πλευρά του συνεργάτη, με app επισκεπτών και dashboard για τον operator στο ίδιο stack. Ο αναγνώστης rapid test χρειάστηκε την κάμερα. Κάθε μία από αυτές τις λίστες ακούγεται σαν επιχείρημα για Swift και Kotlin. Καμία δεν ήταν, ακόμα.

Πότε αρκεί το React Native;

Το τεστ που χρησιμοποιούμε στην πράξη για native vs React Native: το native κομμάτι είναι capture-and-hand-off ή συνεχής loop; Τράβα μια φωτογραφία και διάβασέ την, σκάναρε έναν κωδικό, πάρε ένα στίγμα, παίξε ένα κατεβασμένο αρχείο — λυμένα προβλήματα με συντηρημένα native modules, και το React Native τα τυλίγει καλά. Διάβασε ένα video stream με τριάντα καρέ το δευτερόλεπτο, οδήγησε έναν εκτυπωτή Bluetooth, ζωγράφισε ένα AR overlay — αυτά είναι loops, και η γέφυρα γίνεται το πράγμα που κάνεις debug. Και οι τέσσερις apps εδώ ήταν hand-offs. Το άλλο μισό του τεστ είναι οι άνθρωποι. Οι τρεις hospitality apps βγήκαν η καθεμία δίπλα σε μια web πλευρά σε Next.js, φτιαγμένες από τους ίδιους τρεις από εμάς στην ίδια γλώσσα. Για ένα studio τεσσάρων ατόμων, μία βάση κώδικα για iOS και Android αξίζει περισσότερο από το τελευταίο δέκα τοις εκατό στην απόδοση του scroll.

Πότε κερδίζει το native;

Ο πίνακας παραπάνω είναι η ταξινόμηση για τις τέσσερις δικές μας. Το native κερδίζει όταν η native δυνατότητα είναι το προϊόν. Αν ο αναγνώστης rapid test έπρεπε να διαβάζει το στριπ ζωντανά μέσα από το viewfinder αντί από φωτογραφία, θα τον είχαμε γράψει σε Swift και Kotlin — αυτό είναι loop, και το loop είναι όλη η ουσία. Το ίδιο για έναν ηχητικό οδηγό που επεξεργάζεται ήχο αντί να τον παίζει, για AR πλοήγηση σε μουσείο, για app ρολογιού, ή για έναν scanner που μιλάει όλη μέρα με εκτυπωτή αποδείξεων. Ισχύει και για ομάδες: αν οι άνθρωποι που θα έχουν την app το 2028 γράφουν Swift και Kotlin, τους δίνουμε Swift και Kotlin. Το React Native είναι απόφαση για το ποιος συντηρεί τον κώδικα, όχι πίστη σε frameworks. Ακόμα και τότε, η πρώτη μας κίνηση είναι ένα native module για το ένα loop που το χρειάζεται. Το rewrite είναι η τελευταία λύση.

Και το Flutter;

Είναι στη λίστα του stack μας και ανήκει εκεί. Το Flutter είναι δυνατό όταν το interface είναι custom σχεδιασμένο και η ομάδα νιώθει σπίτι της στη Dart. Κανένα από τα έξι projects σε αυτό το site δεν το χρησιμοποίησε, για τον λόγο από πάνω: κάθε app εδώ μοιραζόταν γλώσσα και ομάδα με ένα admin, ένα website ή ένα CMS σε Next.js, και ο άνθρωπος που την κληρονομεί γράφει TypeScript. Τη Dart τη συμπαθούμε. Απλώς δεν έχουμε σε ποιον να την αφήσουμε.

Τι αλλάζει η φιλοξενία;

Τρία πράγματα που μάθαμε στη δουλειά. Το προσωπικό έχει το κινητό στο ένα χέρι και έναν δίσκο στο άλλο, οπότε ο scanner δουλεύει με ένα tap ή δεν χρησιμοποιείται. Οι χώροι έχουν κακό σήμα — ένας αρχαιολογικός χώρος, μια παραλία, ένα υπόγειο — οπότε το offline δεν είναι feature, είναι το προϊόν· οι ηχητικές περιηγήσεις κατεβαίνουν πριν από τον περίπατο, όχι στη διάρκειά του. Και ο operator μετράει περισσότερο από τον επισκέπτη: στο destination CRM, το dashboard ήταν αυτό που κέρδισε την εσωτερική εμπιστοσύνη, και την επόμενη φορά θα το βγάζαμε πρώτο. Ένα ακόμα, από τη destination app: αποφάσισε τι είναι «μέρος» πριν από την πρώτη οθόνη. Μια παραλία, ένα μουσείο, ένα μονοπάτι, ένα σημείο θέας και ένα εποχικό περίπτερο δεν ανήκουν στο ίδιο μοντέλο. Δεν ανήκουν με τίποτα.

Τελικά, ποιο διαλέγεις;

Με αυτή τη σειρά. Ένα: κάνε το brief να υπερασπιστεί μόνο του την εγκατάσταση· αν δεν μπορεί, είναι web flow. Δύο: γράψε κάθε hardware feature και σημείωσε το καθένα ως hand-off ή loop. Τρία: ρώτα ποιος το συντηρεί το 2028 και τι γράφει. Τέσσερα: σχεδίασε τη web πλευρά μαζί της, όχι μετά — κάθε hospitality app εδώ βγήκε με μία. Πέντε: αν οτιδήποτε είναι loop, ή η ομάδα είναι native, πήγαινε native για εκείνη την app, πρώτα module, τελευταίο rewrite. Αν τίποτα δεν είναι, React Native, και ξόδεψε τις εβδομάδες που γλίτωσες στα empty states και στο offline μονοπάτι. Εκεί κρίνονται αυτές οι apps.

Τι άλλαξε από τότε που αρχίσαμε να ρωτάμε με αυτή τη σειρά: η συζήτηση για frameworks έγινε σύντομη. Κανείς στο τραπέζι δεν υπερασπίζεται ένα toolchain· ταξινομούμε μια λίστα features σε δύο στήλες. Σε αυτό το site η ταξινόμηση βγήκε React Native τέσσερις στις τέσσερις. Το επόμενο brief με ζωντανό viewfinder ή εκτυπωτή στη ζώνη βγαίνει αλλιώς — και θα το πούμε πριν ξοδευτεί το budget. Αυτό το κομμάτι είναι ο κανόνας.