Des de The Next Web, Nate Swanner ha sorprès avui a tota la comunitat de desenvolupaments d’aplicacions mòbils amb una notícia bomba: Google podria estar considerant Swift com a llenguatge de primer nivell de desenvolupament en Android, per substituir Java.
Google vs Oracle
Però per entendre bé la notícia, cal aprofundir una poc en l’històric de Java i Google, així com parlar de el tercer en discòrdia en aquesta relació: el propietari de Java, Oracle. El 2012, Oracle demandar a Google per utilitzar determinades llibreries de Java sense permís dins d’Android. Perquè alguns diran, Java és de codi obert i per tant Google no hauria de pagar res. Cert: però també ho és que mentre el llenguatge és de codi obert, determinades llibreries (APIs) claus per Android estan subjectes a un pagament per la seva explotació comercial. I encara que Google no obté benefici directe d’Android, si ho obté indirectament pel que Oracle reclama la seva part de l’pastís. En total, 9.300 milions de dòlars, que es diu aviat. Una quantitat que és el doble del que va declarar tot el conglomerat empresarial Alphabet (a què pertany Google) l’últim trimestre.
D’ells 8.829.000 corresponen a la part que Oracle creu que li correspon sobre el total que s’estima que Google ha ingressat durant la vida d’Android a través de Google Play Store o amb la venda de continguts i publicitat. 37 APIs que Google declara usar com fair usi (ús raonable) i que Oracle nega a la major.
Swift, l’alternativa de codi obert
L’article de The Next Web ens posa en situació sobre una reunió que va tenir lloc al desembre entre tres grans: Google, Uber i Facebook. Aquesta reunió, que va tenir lloc a Londres, va tractar sobre Swift i el seu recent alliberament com a llenguatge de codi obert. Determinades fonts han confirmat a The Next Web que Google està considerant fer a Swift llenguatge de primer nivell, sent primer una alternativa a Java, per posteriorment substituir definitivament a llarg termini. I d’altra banda, tant Uber com Facebook també es plantegen migrar tot el seu codi i desenvolupament a el nou llenguatge, no només les apps, si totes les seves APIs i serveis backend.
Analitzant això, l’arribada de Swift a Android suposaria una cosa molt interessant perquè Swift no necessita una màquina virtual i aniria dins d’una capa per sota de l’actual JVM que dóna suport a Java. Això donaria un millor rendiment a el sistema i a el maquinari sense fer res més. El mateix desenvolupament seria molt més ràpid i eficient a tots els nivells, perquè ja aniria compilat a major nivell i executat més proper a el maquinari. Actualment, el llenguatge que compleix aquest paper enganxat a el maquinari d’Android i que suporta diversos components de la JVM és C ++, i aquest podria ser substituït per Swift.
Seria factible?
cada vegada més empreses migren seus desenvolupaments a Swift i ara, amb l’expansió per part d’IBM, comença a haver-hi qui desplega els seus backend també en aquest llenguatge. Apps com Pixelmator ja estan desenvolupades en Swift, per citar un simple exemple i cada vegada més empreses comencen a migrar tots els seus desenvolupaments per aprofitar les bondats de el nou llenguatge. En el cas Android, adoptar Swift no seria cap bogeria i els permetria oblidar-se dels problemes de Java, ja que Apple ha fet completament lliures tot el llenguatge i les seves APIs, sense cap restricció més que la simple autorització en casos puntuals.
el problema és la pròpia estructura de sistema Android ja que ara mateix té dues parts ben diferenciades: la part JVM de Java que executa gran part de les apps i serveis de el sistema i la compatible NDK que permet l’ús d’altres llenguatges com C ++ (la que fan servir molts motors de jocs com Unity o Unreal). Aquesta NDK podria veure modificada per implementar Swift, però té el problema que com a tal, segueix sent com una eina secundària però no un component principal que permeti l’execució de components de sistema. I a més, com hem comentat, el propi sistema actual d’Android té parts de l’nucli en C ++ que necessitarien ser re-escrites en Swift.
Per tant, el primer que podem pensar és que Android hauria de crear una capa en Swift (substituint l’actual nucli en C ++) i muntar sobre ell la JVM de Java perquè el sistema tingués una coherència i no perdés les compatibilitats. D’aquesta manera, es podria seguir desenvolupant en Java però podria treballar-se amb la capa inferior en Swift i realitzar programes o components de sistema que fossin més eficients. Com Swift funciona sense problema en el nucli de Linux d’Android, no hi hauria problema de compatibilitat algun sigui quin fos el maquinari. Però resulta curiós pensar-: una màquina virtual Java desenvolupada en Swift.
No obstant això, en l’article ens expliquen que també s’estan plantejant altres llenguatges com Kotlin, també de codi obert i que ja permet desenvolupar amb Android, directament per a la seva JVM. Aquest llenguatge, genera un codi intermedi compatible amb el que genera Java i permet fins i tot interoperar amb ell. Per tant, seria una bona alternativa tot i que, com bé ha vist Google, seria molt menys eficient ja que és molt lent en compilació i poc òptim en els seus resultats i velocitat, comparat amb Swift que ara mateix és dels llenguatges més eficients, ràpids i assegurances de el panorama de el desenvolupament.
La transformació per Swift
La transformació per Swift comença a arribar. Un empleat de Facebook té una petició de pull al repositori oficial de Swift anomenat “Portar a Android” on especifica com afegir un target d’Android a la compilació de la llibreria estàndard de Swift. O per exemple, Uber, està en procés de migrar tots els seus sistemes, tant APIs, apps com a servidor a Swift, per millorar l’eficiència del seu servei.
Grans empreses i grans apps aposten pel nou llenguatge, i cada vegada tenim més opcions interessants com el nou servidor Perfect, que permet un desplegament a servidor de recursos en Swift d’una manera fàcil i ràpida.
No estem parlant d’alguna cosa ràpid ni immediat, portarà el seu temps perquè requereix de transformacions a nivell tècnic i nous desenvolupaments, però no podem deixar de pensar que potser, en un dia no molt llunyà, l’important pas d’Apple de fer Swift codi obert, arribi a port perquè sigui un llenguatge universal que permeti desenvolupar per a qualsevol plataforma. Després caldrà fer servir les corresponents APIs de cada sistema, però tenir un únic llenguatge sense dubte (tant en frontal com en backend) serà una cosa molt pràctic. Així que vagin aprenent per al seu futur, i Good Apple Coding.