Retroscena
Apple iOS 14.5: privacy per l'Internet moderno
di Dominik Bärlocher
Google va incontro ad Apple: basta un pulsante sul telefono per cambiare il mondo
13.10.2021
Traduzione: Nerea Buttacavoli
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.
È 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.
Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS.
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.
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.
Perché mai dovrebbe? Chi vuole l’iCloud usi un iPhone.
Chi vuole Google Drive può usare praticamente qualsiasi smartphone.
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
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?
È 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'.
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.
Smartphone
Segui gli argomenti e ricevi gli aggiornamenti settimanali relativi ai tuoi interessi.
Retroscena
Curiosità dal mondo dei prodotti, uno sguardo dietro le quinte dei produttori e ritratti di persone interessanti.
Visualizza tutti
