Google va incontro ad Apple: basta un pulsante sul telefono per cambiare il mondo
Da Google le cose cambiano. Le applicazioni su iPhone e iPad ora vengono costruite con componenti Apple. Per gli utenti cambia poco, ma Google ha ottenuto un grande successo, anche se sta dando una mano alla concorrenza.
Le app Google su iPhone e iPad dovrebbe sembrare più come applicazioni Apple.
Questo da solo non sembra una grande sensazione, ma significa molto: dietro la decisione di rendere le app Google più simili a quelle di Apple c'è molto lavoro, politica, risentimento e competitività.
Il passaggio dallo sviluppo proprio di Google ai componenti Apple può giocare a favore della concorrenza, ma è stato amaramente necessario e utile per Google.
Architettura dell'app: cosa succede dietro le quinte
Ogni app ha un framework. Facendo il paragone con la costruzione di una casa, il framework sarebbe l'impalcatura su cui è costruita l'interfaccia utente che vedi e usi. Esistono framework per backend e frontend. Per questo articolo sono rilevanti solo i frontend – ovvero le interfacce utente e tutto ciò che vede il cliente. Per semplicità, in seguito mi riferirò ad essi come «framework».
Il framework, la sua scelta e le sue peculiarità, è una decisione presa dai manager, non solo dai programmatori.
Le applicazioni sullo smartphone sono create in un cosiddetto framework app.
Questi due framework sono integrati in Software Development Kits (SDK). Da Google si chiama Android Studio, da Apple Xcode. Entrambi gli SDK sono stati inventati dai rispettivi produttori e vengono costantemente sviluppati. Nel caso della costruzione di una casa, sarebbe la cassetta degli attrezzi, in cui si trovano tutti gli strumenti per costruire la casa.
È possibile creare applicazioni Android con l'SDK di Apple. Questo perché UIKit e Xcode lavorano con il linguaggio di programmazione Swift, che può essere utilizzato anche per le app Android. Android funziona con Java, ma supporta praticamente ogni linguaggio di programmazione comune sul mercato.
In breve: è possibile fare applicazioni iOS con competenze di programmazione Android e viceversa. Solo che questo ha senso in pochissimi casi. La ragione è più politica che tecnologica.
La politica dietro la programmazione
Gli SDK sono gratuiti e liberamente accessibili. I linguaggi di programmazione sono open source e anche liberamente accessibili. Questo promette la grande era delle app: un solo programma, compatibile con tutto. Tecnologicamente, la strada sarebbe spianata perché tutti possano sviluppare e usare app native con tutti, sempre.
È solo che né Google né Apple sono molto interessati a farlo accadere.
Certo, entrambi i gruppi parlano di apertura e sparano termini come «intuitivo». Ma questo riguarda solo il caso di un programmatore Android che programma con Android Studio per Android. Tutto il resto è come un workaround. Uno sguardo a Flutter for iOS Developer mostra come farlo. I termini sono diversi, le cose funzionano in modo diverso e generalmente i programmatori devono imparare il linguaggio di programmazione completamente da zero.
Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS.
Poi però non è più «intuitivo» o «facilmente accessibile». È estremamente complicato costruire questo ponte in un modo che sia anche solo lontanamente sensato nella pratica. Sembra più facile che un programmatore installi semplicemente due SDK e praticamente scriva l'app due volte, ma questo richiede tempo e risorse che hanno solo i grandi studi di programmazione. In realtà, tutti gli studi di programmazione di app, piccoli o grandi, devono affrontare una scelta:
- Scelgono una piattaforma (iOS o Android) e promettono di gestire anche l'altra piattaforma un giorno.
- Lo studio utilizza una struttura ibrida. Non è obbligatorio usare un framework nativo. Ionic è un framework ibrido. Flutter può anche fare l'ibrido, ma non si può aggirare Xcode.
- Lo studio costruisce l'applicazione due volte. Questo può anche essere più economico che un approccio ibrido.
The Apple Swift compiler has had the ability to compile code for the Android platform for a few years now, but it hasn’t made many friends in the developer community owing to its complexity.
È qui che si incontrano la gestione e l'efficienza operativa. Gli sviluppatori costruiscono qualcosa che è open source, ma la cui effettiva implementazione nella vita reale al di fuori di un quadro prestabilito è assurdamente complicata. Potrebbe essere reso semplice? Sì. Viene reso semplice? No. Motivo: i componenti per le proprie piattaforme devono essere ulteriormente sviluppati. Questo richiede risorse, tempo e lavoro. Risorse che non devono essere spese per la concorrenza.
Un esempio leggermente meno astratto: se Apple ottimizzasse l'esportazione di Swift per Android, la società di Cupertino lavorerebbe per il suo grande avversario Google. Apple sprecherebbe le risorse di Apple per lo sviluppo di Google. Perché Apple stessa non ne ricaverebbe nulla. Il mondo della programmazione forse, ma Apple non vuole davvero lavorare per la concorrenza ed è davvero brava a creare e mantenere aree appartate per sé.
Google Maps su iOS: un gran armeggio, storicamente parlando
Con l'ascesa degli iPhone e il contemporaneo trionfo di Android, non solo si è creata una situazione competitiva, ma anche una necessità: la necessità di YouTube, Google Maps e forse Google Photos sull’iPhone.
A Google non andava, perché avrebbe tolto agli utenti Apple un motivo per passare ad Android. Ma la pressione pubblica era troppo grande. Così le app Google hanno gradualmente trovato la loro strada sulle piattaforme di Apple. E viceversa. Apple offre una manciata di applicazioni sul Google Play Store, ma non fa alcuno sforzo per portare l'iCloud su Android.
Perché mai dovrebbe? Chi vuole l’iCloud usi un iPhone.
Chi vuole Google Drive può usare praticamente qualsiasi smartphone.
Entrambi sono decisioni politiche dei rispettivi produttori. E c'è solo una cosa da dire a riguardo: fair enough. Le aziende non sono costrette all’apertura. Può essere più sportivo essere aperti, ma nessuno può obbligare Apple ad essere sportiva. Così come Google non è obbligata ad essere presente sulle piattaforme Apple. Da un punto di vista legale, l'unica cosa che deve essere evitata nello sviluppo del software è l'ovvio monopolio. Finché nessuno può provare un monopolio, va tutto bene.
Nel 2012, Google ha deciso di essere la prima a portare Google Maps su iOS. Durante lo sviluppo dell'app di Google per l'ecosistema di Apple, il team intorno al leader dello sviluppo Jeff Verkoeyen ha notato che ad Apple mancavano alcuni elementi obbligatori per le app di Google. Pertanto, il team ha ricreato questi elementi – come corpi estranei, chiamati Material Components in gergo tecnico. Ovviamente sono open source. In questo modo, Google e Apple evitano l'accusa di monopolio.
Ciò significa che la prima versione di Google Maps su iOS di Apple era un gran armeggio. L'app ha librerie, elementi di design e funzioni proprie di Apple mescolate con quelle fornite da Google.
Ecco come è andata. Per nove anni.
Material Components: in modalità manutenzione da luglio
Nel luglio 2021, tuttavia, questo cambia. I Material Components per iOS – i corpi estranei – sono messi in modalità manutenzione da Google. Questo significa che non saranno sviluppati ulteriormente fino a nuovo avviso, ma solo mantenuti. Se qualcosa dovesse essere rotto, sarà riparato. Le falle di sicurezza vengono riempite. Ma per il resto i Material Components possono morire con dignità.
Con questo, Google sta facendo un grande passo, politicamente parlando. Perché invece di caricare i propri componenti, Jeff Verkoeyen e il suo team si affidano interamente ai componenti di Apple in futuro. Verkoeyen lo conferma in un thread di Twitter.
But as we continued on the pursuit of cross-platform pixel parity, our iOS components were slowly drifting further and further from Apple platform fundamentals because those fundaments were also evolving year over year.
Verkoeyen descrive la situazione che è inevitabile nello sviluppo non comune di un software. I Material Components sono sviluppati ulteriormente e vanno in una direzione. I componenti principali di Apple si stanno evolvendo e vanno in una direzione diversa. Il ponte che i Material Components devono costruire sta diventando sempre più grande.
All'inizio del 2021, la squadra di Jeff Verkoeyen si chiede: abbiamo ancora bisogno di costruire ponti?
Uno sguardo a ciò che l'SDK di Apple e i suoi componenti possono fare mostra: ormai anche Apple può farlo. Era il momento di porre alcune domande scomode: Un semplice interruttore in un'applicazione ha davvero bisogno di richiedere il proprio componente di una libreria esterna?
La risposta era chiara: No. Molti dei Material Components non sono più necessari, poiché i componenti principali di Apple ora li forniscono. I pochi componenti aggiuntivi che devono essere caricati riceveranno più attenzione grazie alla modalità manutenzione di tutti gli altri componenti. Questo promette uno sviluppo più veloce ed efficiente delle app Google su iOS.
È molto probabile che tu come utente non noterai nemmeno questo cambiamento. Questo nonostante il fatto che gli elementi semplici nelle app Google sono ora realizzati con il proprio «UINavigationController» di Apple invece del Material Component «App bar».
App bars become UINavigationControllers. Standard controls just need light branded touches. Lists can align with modern UITableView and list-based collection view APIs. Menus are just UIMenus.
Naturalmente, questi componenti Apple nelle app di Google non avranno l'aspetto di essere create da Apple. L'identità del marchio di Google sarà incorporata.
Conclusione: i soldi (e un po' di sviluppo) sono al di sopra della politica
La decisione di Google di lavorare con i componenti di Apple è un'arma a doppio taglio. Ma dimostra che la ragione può prevalere. Perché passare dai componenti propri di Google agli equivalenti di Apple fa risparmiare soldi a Google, ma allo stesso tempo porta alla concorrenza informazioni, conoscenze e forse anche codice per migliorare qualcosa che Apple non ha voluto migliorare fino ad oggi. O che Apple non sapeva di dover migliorare.
Ma dal punto di vista funzionale, la decisione è ragionevole. Solo perché qualcosa era buono o addirittura necessario dieci anni fa, non significa che sia ancora buono o necessario oggi. Se Apple può fornire componenti che svolgono la stessa funzione di quelli di Google, allora ha senso lasciar morire con dignità gli sviluppi interni.
Anche Google sta facendo un gran colpo con il cambiamento. I servizi forniti dalle app del gigante dei motori di ricerca sono cari a tutti gli utenti. Ma la critica che le applicazioni su iPhone non si sentono bene come su Android o come le applicazioni Apple su iOS è valida. E con il cambiamento, è molto probabile che diventi obsoleta.
Il gigante dei motori di ricerca risparmia denaro, tempo e fa colpo sugli utenti. Un vero successo.
Ma la squadra di Verkoeyen ha dovuto dare prova di coraggio: ammettere che il lavoro di dieci anni non è più necessario non è cosa da poco. Da un lato, nella squadra si potrebbero perdere posti di lavoro, dall'altro, Verkoeyen e Co. dimostrano che la «Sunk Cost Fallacy» può essere superata. O addirittura che deve essere superata. Solo perché finora sono stati investiti tempo e denaro, non significa che valga la pena di investire ancora.
Per gli utenti, forse potrebbe cambiare un interruttore nell’app. Nella metafora della costruzione di una casa, questo sarebbe un materiale isolante nel muro. Per Google e Apple, tuttavia, il mondo è appena cambiato un po'.
A 142 persone piace questo articolo
Giornalista. Autore. Hacker. Sono un contastorie e mi piace scovare segreti, tabù, limiti e documentare il mondo, scrivendo nero su bianco. Non perché sappia farlo, ma perché non so fare altro.
