08. Apps natives vs WebApps.pdf

Tema 8 App Mòbils: Aplicacions natives vs WebApps. Avantatges, inconvenients i tendències d'aquestes dues alternatives. 1 Atesa la distribució de les quotes de mercat dels dispositius mòbils a nivell mundial, on pràcticament entre iOS i Android es reparteixe...

Tema 8 App Mòbils: Aplicacions natives vs WebApps. Avantatges, inconvenients i tendències d'aquestes dues alternatives. 1 Atesa la distribució de les quotes de mercat dels dispositius mòbils a nivell mundial, on pràcticament entre iOS i Android es reparteixen el 100% del mercat, en aquest document només parlarem d’aquests dos sistemes (quan sigui necessari). Windows, utilitzat encara dins l’Ajuntament, pràcticament no té representació en el mercat. APPS MÒBILS Entenem com a apps per a dispositius mòbils totes aquelles aplicacions que s’instal·len i s’executen directament a través del sistema operatiu del dispositiu, habitualment descarregades des dels markets d’aplicacions (Google Play per Android i Apple Store per iOS). Aquestes aplicacions són arxius binaris en format.apk per Android,.ipa per iOS. APPS NATIVES Les aplicacions natives són aquelles desenvolupades en el llenguatge propi del dispositiu on s’executa. Aquesta simple definició implica que són aquelles aplicacions que permeten accedir a tots els recursos disponibles del dispositiu. Dit d’una altra manera, si alguna cosa es pot fer amb un dispositiu, segur que es pot fer amb una app nativa, amb la resta no és segur. Segons els sistema operatiu tenim els següents llenguatges de programació:  Android (Google): Java  iOS (Apple): Objective C / Swift  Windows Phone: C# APPS HÍBRIDES Són aquelles apps que, sobre una base de codi natiu, part de la seva funcionalitat s’implementa utilitzant tecnologies web. Aquest tipus d’apps bàsicament són contenidors d’un navegador (webviews). Com a app, es distribueix com un arxiu executable, habitualment, a través dels markets. Per tant, acabem tenint un executable per cada plataforma. Aquesta tecnologia permet que tota la funcionalitat desenvolupada dins del webview pugui ser compartida amb les diferents plataformes on s’executa (iOS/Android/Windows), mentre que alhora, podem desenvolupar funcionalitats especifiques per cada plataforma, podent explotar tota la funcionalitat que ens proporcionen les apps fetes amb codi natiu. Atès que gran part de la funcionalitat d’aquestes apps s’executa en un webview, solen utilitzar-se conjuntament amb frameworks de desenvolupament de Webapps. Existeixen diverses eines o frameworks que permeten el desenvolupament d’apps híbrides, entre les que destaquem Ionic i Apache Cordova. L’objectiu ideal d’aquest tipus d’app (juntament amb les Cross-Platform) és desenvolupar un sol cop i poder executar les apps en diferents plataformes. A la pràctica hi ha especificitats que cal desenvolupar per a cada plataforma, ja que el codi web no permet arribar al mateix detall que el codi natiu. EINES CROSS-PLATFORM Són eines que, partint d’un únic codi Font, generen codi natiu per a cada plataforma en temps de compilació. El llenguatge de programació varia segons la plataforma, però sol ser basat en tecnologia web. De la mateixa manera que hem dit per a les apps híbrides, el codi comú no sempre permet arribar a desenvolupar totes les funcionalitats de cada plataforma. Això vol dir que després de generar el codi 2 nadiu per a cada plataforma cal fer ajustos per a adaptar-lo i que funcioni correctament. Per tant l’objectiu de desenvolupar un sol cop quasi mai s’aconsegueix. Una altra de les característiques d’aquestes plataformes és que moltes funcionalitats ja venen desenvolupades dins del framework. Això vol dir que per un costat facilita la programació, però per l’altre quedem lligats a la implementació que n’hagin fet i la qualitat corresponent. Dins d’aquestes eines destaquem ReactNative (Facebook), Flutter (Google), Kotlin (Jetbrains), Titanium, Xamarin. LOW CODE APPS El terme “low code platform” es refereix a plataformes que permeten crear aplicacions mit an ant interfícies gràfiques sense necessitat de programar codi. Aquestes plataformes poden generar aplicacions sense haver programat una línia de codi o bé poden incloure una part de programació per a aquelles funcionalitats que no es puguin implementar amb la interfície gràfica. Els principals avantatges d’aquestes solucions son:  Accelerar el desenvolupament de les aplicacions  Desenvolupar aplicacions sense ser programador Per contra el fet de “no programar” limita a les possibilitats que els desenvolupadors d’aquestes plataformes hagin previst, de manera que si no han previst una funcionalitat no es podrà implementar. Normalment aquetes plataformes també inclouen una part servidora, eines per a facilitar les integracions amb altres sistemes i per a gestionar el cicle de vida de les aplicacions. WEBAPPS S’anomena webapp a una aplicació desenvolupada utilitzant tecnologies web. Aquestes són aplicacions de tipus client servidor de manera que el client s’executa en el navegador web del dispositiu client. Dins de les webapps existeixen les Progressive Webapps (PWA), que són aquelles més adaptades a la mobilitat i que, per aquest motiu, són les que té més sentit comparar amb les apps. Per aquest motiu en aquest tema només parlarem de PWA. Tinguem en compte que tant les Webapps com les PWA són aplicacions que s’executen en un navegador i, per aquest motiu no estan restringides als dispositius mòbils. És cert que una PWA està orientada sobretot a dispositius mòbils, però igualment es pot executar en una tauleta o en un navegador d’escriptori, això si, adaptant-se a les prestacions que el navegador i dispositiu permetin. D’aquesta manera els frameworks de desenvolupament d’aquestes eines són compartits per aplicacions més orientades a escriptori. Dins dels frameworks de desenvolupament de webapps (o PWA) destaquem: React (Facebook), Angular (Google), VUE, Polymer (Google) i Ionic. Normalment estan programades en HTML + JS + CSS, utilitzen service worker que permeten executar serveis en segon pla, i guarden la caché en el navegador en el qual s’executa aquesta PWA per a poder funcionar sense connexió. A més, en executar-se sobre un navegador i tenir aquesta caché el temps de càrrega és inferior, igual que la capacitat de memòria que necessita el dispositiu. A més, en ser webs emmarcades tampoc necessiten accedir a tantes parts del dispositiu, pel qual és una amenaça inferior en la part de seguretat. 3  PROGRESSIVE WEBAPPS Existeixen diverses definicions de Progressive Webapps, però podríem dir que són aquelles WebApps construïdes utilitzant tècniques web modernes i que generen una experiència d’usuari molt propera a la de les apps natives, incloent entre altres el funcionament off-line o l’accés a elements del dispositiu com la càmera,.... Segons Google una Progressive Webapp ha de complir tres característiques:  Fiable (reliable) – sempre funciona independentment de la xarxa  Ràpida (fast) – la resposta a una acció de l’usuari és immediata  Atractiva (engaging) – poder estar en l’escriptori del dispositiu, experiència immersiva i adaptada al dispositiu i l’enviament de notificacions push fa que es pugui generar un ús satisfactori i recurrent. Les PWA són un pas més a les web responsives de manera que no només s’adapten visualment al dispositiu on s’executen, si no que permeten un ús de les diferents capacitats d’aquest, aprofitant al màxim les seves possibilitats. Per exemple, una PWA té accés a l’ús de la càmera per aquells dispositius que en tinguin, mentre que si el dispositiu no en té, l’aplicació segueix funcionant però sense oferir aquella funcionalitat. En realitat, la diferenciació entre una PWA i una Webapp és difícil, ja que tècnicament hi ha poca diferencia, pel que hi ha qui ho considera només com un terme de marketing. Google ens dóna una checklist per a comprovar que una web app és progressiva:  Site is served over HTTPS  Pages are responsive on tablets & mobile device  The start URL (at least) loads while offline  Metadata provided for Add to Home screen  First load fast even on 3G  Site works cross-browser  Page transitions don't feel like they block on the network  Each page has a URL Ofereix un complement de Chrome anomenat Lighthouse que permet, entre moltes altres coses, validar aquests checks. A més també disposa d’un altre checklist “per nota” és a dir, un conjunt de bones practiques que es recomanen. Aquestes, en gran part no es poden validar de forma automàtica.  Site's content is indexed by Google  Schema.org metadata is provided where appropriate  Social metadata is provided where appropriate  Canonical URLs are provided when necessary  Pages use the History API  Content doesn't jump as the page loads  Pressing back from a detail page retains scroll position on the previous list page  When tapped, inputs aren't obscured by the on screen keyboard  Site is responsive across phone, tablet and desktop screen sizes  Any app install prompts are not used excessively  The Add to Home Screen prompt is intercepted  First load very fast even on 3G  Site uses cache-first networking  Site appropriately informs the user when they're offline  Provide context to the user about how notifications will be used  UI encouraging users to turn on Push Notifications must not be overly aggressive.  Site dims the screen when permission request is showing  Push notifications must be timely, precise and relevant  Provides controls to enable and disable notifications 4   User is logged in across devices via Credential Management API  User can pay easily via native UI from Payment Request API. Per a l’usuari l’adquisició d’una PWA és a través d’una URL que la troba com un enllaç o en un cercador web. En la primera execució aquesta es percep similar a una pàgina web, però li ofereix la possibilitat d’instal·lar una icona a l’escriptori. A partir d’aquest moment quan l’usuari prem la icona, la PWA s’obre dins del navegador per defecte però sense mostrar la barra de navegació. Això, junt amb el disseny i usabilitat que ofereixen pràcticament les fa indistingibles d’una app. SITUACIÓ ACTUAL DE LES PROGRESSIVE WEBAPPS Dedicarem aquest apartat a descriure molt breument què permeten fer les PWA, principals característiques i tendències de futur. Com ja hem explicat anteriorment, les PWA s’executen en un navegador i s’adapten a ell i al dispositiu on es troben, de manera que les funcionalitats que ofereixen depenen del navegador i del dispositiu. Per exemple, si un dispositiu no té xip Bluetooth, no podrà oferir cap funcionalitat referent a aquest. Però tant important com el dispositiu és el navegador i el sistema operatiu on s’executa. Per a que una PWA pugui tenir una prestació cal que el navegador on s’executa la suporti. En aquest sentit Google fa temps que lidera amb el seu navegador Chrome per Android el major número de prestacions disponibles, mentre que Apple té molt més limitat aquest ús. De fet, fins l’any 2018 i el sistema iOS 11.3, Apple no ha implementat en el seu sistema algunes funcionalitats clau per considerar que suportava les PWA:  Web App Manifest: fitxer de definició de característiques d’una PWA  Service Workers: mètodes que poden executar-se en background, de manera que permeten coses com la recepció de notificacions push o l’emmagatzematge off-line. Val a dir, però que tot i existir aquests service workers Apple encara no suporta les notificacions push. Abans d’aquesta versió iOS 11.3 els programadors havien trobat maneres de resoldre alguns d’aquests problemes i, per exemple, la PWA PIC’s de l’A untament (https://webapp.barcelona.cat/pics/) Punts d’Interès de la Ciutat ja permetia l’emmagatzematge off-line tot i no utilitzar service workers. Val a dir, que a dia d’avui aquesta és la única PWA publicada per l’A untament per a ús ciutadà. Tot i que hi ha projectes per a tenir-ne més en breu. A l’IMI s’ha fet una prova de concepte de d’una PWA amb la qual s’ha comprovat quins elements es poden fer servir i quins no en les PWA. S’entrega com annex a aquest tema el document final (tot i que es considera massa detallat per l’abast del tema), i a continuació destaquem:  Es pot fer servir emmagatzematge off-line amb limitacions (limitació fixa per iOS, relativa a l’espai del dispositiu per Android)  Es poden fer notificacions push en Android  Es pot accedir a la càmera en els dos sistemes  El Bluetooth no funciona correctament  La gestió de permisos en iOS no és bona, generant problemes de privacitat, ja que es delega la gestió en el desenvolupador.  iOS no suporta nativament el fet de notificar l’usuari que es pot instal·lar la PWA, s’hauria d’implementar un popup per aquest cas en específic (manualment es pot fer). Android si que ho permet. Per instal·lar s’entén que es guardi la icona a l’escriptori i que es guardi la informació necessària per arrencar tingui o no connexió a internet.  Quan es fan servir elements que requereixen processar moltes dades (per exemple mapes o carrerer) el rendiment de les PWA no és adient.  En general hi ha més problemes en iOS que en Android, com per exemple bugs d’accessibilitat. També com a conclusió de la POC hem obtingut el següent: 5   Tot i la teoria de que es permeten certes coses, a la pràctica és una tecnologia força nova i no sempre és fàcil l’ús.  Els frameworks i la tecnologia per a construir PWA està evolucionant constantment. En poques setmanes es pot passar de que una cosa no es pot fer a que si, o aparèixer un nou framework que canvia els estàndards de desenvolupament. Finalment, donem dues webs on es poden consultar les diferents prestacions possibles per a navegadors i dispositius, saber si estan implementades en web i per a quins navegadors:  https://caniuse.com  https://whatwebcando.today Fent la següent cerca podreu trobar multitud d’exemples i llistats de PWA, donat que és impossible fer un llistat acotat d’exemples. Només dir que moltes de les apps més conegudes (Google Maps, Twitter, Facebook, Uber,...) tenen la seva versió PWA, que permet consumir menys recursos i que solen anar identificades pels sufixos “Lite” o “Go”. COMPARATIU En aquest apartat compararem les apps natives i les PWA, però també posarem algunes notes de la resta de tecnologies. Les compararem sobretot des d’un punt de vista tècnic, però també hi ha altres punts de vista com per exemple la no presència de les PWA als Markets o de les apps al cercadors, però aquest és un tema més de marketing que tecnològic. Els factor que s’haurien de tenir en compte a l’hora de triar una tecnologia haurien d’estar relacionats majoritàriament amb la tecnologia, però moltes vegades veiem que hi ha altres factors relacionats amb l’entorn que influeixen molt en les decisions que es prenen. Factors relacionats amb la tecnologia:  Complexitat i viabilitat tècnica de l’aplicació  Experiència d’usuari  Seguretat  Accessibilitat  Rendiment Factors relacionats amb l’entorn:  Disponibilitat de programadors a l’empresa  Disponibilitat de programadors al mercat laboral  Homogeneïtat dels desenvolupaments  Facilitat de reciclar programadors  Experiència prèvia en la tecnologia  Existència de codi reaprofitable  Cost  Temps  Vendor lock-in A partir de les característiques de cada una i a grans trets podem dir que cadascuna d’aquestes tecnologies es adient en els següents casos:  Natiu: s’hauria de fer servir per aplicacions complexes o en aquells casos on l’aplicació i l’experiència d’usuari es consideri clau.  Progressive Web Apps: Aplicacions que no requereixen accedir a tot el potencial del dispositiu i que tenen ús moderat.  Aplicacions brides. El mateix cas que les PWA però que requereixen accedir a totes les funcionalitats dels SDKs natius. 6   Cross-platform. Quedaria en mig de les altres opcions, agafant avantatges i inconvenients de les altres opcions.  Lowcode. Aquesta opció és apropiada per a grans empreses amb moltes aplicacions que necessitin homogeneïtzar tota la mobilitat amb recursos no especialitzats en mobilitat o per a petites empreses que no vulguin contractar un recurs especialitzat. Actualment no hi ha una tendència clara al sector a l’hora de triar una tecnologia, es poden veure tendències contraposades que moltes vegades venen marcades per experiències prèvies o per la disponibilitat de recursos. Tot i així, les PWAs és l’opció que actualment ha guanyat més for a i per tant hauria de ser la primera opció a tenir en compte. De fet, a l’Ajuntament de Barcelona, la postura de Comunicació es realitzar web apps i no apps natives. APPS NATIVES vs WEBAPPS De forma més detallada posarem un llistat d’elements a favor de les apps natives i de les webapps, entenent que els punts forts d’un són febles de l’altre. Avantatges apps natives  Permet obtenir la màxima funcionalitat, accedint a totes les prestacions del dispositiu  Millor rendiment de les aplicacions, en termes d’eficiència.  Permet implementar la interfície d’usuari seguint les recomanacions i particularitats del fabricant.  é accés a totes les novetats i innovacions que se inclouen en els SDKs des del primer moment, mentre que en la resta de solucions depenem d’un element intermedi com és el navegador o el llenguatge de programació dels frameworks o eines utilitzades.  Es pot assolir el grau més alt de seguretat.  Tecnologies madures.  Hi han moltes llibreries i frameworks que faciliten la feina.  Molta documentació sobre arquitectures i bones pràctiques. Avantatges webapps  Fan servir tecnologies web conegudes.  És suficient disposar de desenvolupadors de tecnologia web, mentre que per a apps natives és necessari tenir especialistes en cada plataforma.  Simplifica la gestió i el manteniment al gestionar un únic equip de desenvolupament.  No requereix instal·lació i per tant els canvis es propaguen automàticament  Permet homogeneïtzar el desenvolupament al tenir un codi comú per a varies plataformes.  Cost menor que el desenvolupament natiu.  Disponibilitats de programadors. APPS HÍBRIDES, CROSS-PLATFORM i LOW CODE PLATFORM Les apps híbrides i les eines Cross-Platform es queden a mig camí entre les apps natives i les webapps. Persegueixen el somni de que un sol codi sigui vàlid per a tot tipus de dispositius, independentment del seu sistema operatiu, de la mida de les pantalles i de l’experiència d’usuari. Aquest objectiu s’ha assolit en bona part, però sempre anirà un pas enrere respecte al desenvolupament natiu de cada dispositiu. De fet, al llarg de la curta historia d’aquestes tecnologies han nascut múltiples projectes que semblaven que anessin a fer oblidar el codi natiu, però que al cap d’un temps no s’han consolidat. Donat que estan basades en bona part en tecnologia web, no permeten l’explotació total dels 7 recursos del sistema o, si ho fan, requereixen d’una programació espec fica per cada plataforma, perdent l’avantatge del desenvolupar un sol cop. Tant les híbrides com Cross-platform es recomana utilitzar-les en casos en que el cost de desenvolupament sigui un factor determinant, ja que té un estalvi respecte al codi natiu, sent les cros- platform les que permeten actualment unes millors prestacions. En quant a les Low code Platform encara que els venedors asseguren que es poden generar aplicacions molt complexes, la realitat es que s’hauria de reduir a aplicacions simples, prototips o bé aplicacions mitjanes si la plataforma està focalitzada en algun sector o tipologia d’aplicacions. A banda de les restriccions tècniques, s’ha de tenir en compte que són plataformes comercials que poden implicar un alt “vendor lock-in”. La informació que he posat a l'annex no crec que sigui necessària saber-la donat que és molt específica. Les dos preguntes del test en relació a aquest tema són molt simples. TEST 8. Una tendència recent de desenvolupament d’aplicacions mòbils és la d’aplicacions web que fan ús de funcions modernes del navegador per a oferir experiències semblants a les de les aplicacions natives. Com es coneix aquesta tendència? A. Aplicacions híbrides. B. Aplicacions web progressives. C. Aplicacions web-natives. D. Aplicacions mòbils. 9. Quin NO és un tipus de desenvolupament d’apps (aplicacions mòbils)? A. Natiu. B. Híbrid. C. PWA (Progressive Web App). D. DEVOPS. BIBLIOGRAFIA A més dels links posats en context dins el text, adjuntem tres documents utilitzats per a l’elaboració d’aquest: .Informe de tendències tecnològiques MAS ER-DEF.pdf - document elaborat per Worldline al 2019 dins el marc de l’AM de l’Oficina de Serveis al Mòbil (OSAM). És un informe que es demana de forma anual a l’adjudicatari per a posar context de cap on es dirigeixen les tecnologies mòbils. En aquest document hi ha un conjunt de recomanacions que no s’han traslladat íntegrament en aquest tema, ja que s’ha considerat que no són clarament objectives.  robot-innocent-informe-apps-ajuntament-de-barcelona-sense-annexos.pdf - document elaborat per Robot Innocent a encàrrec de Comunicació Digital de l’Ajuntament al 2016. És un estudi sobre la presència digital de l’Ajuntament a través d’apps, comparant amb altres ciutats i donant unes recomanacions. Va servir per a definir l’estratègia marcada per Comunicació per a reduir el nombre d’apps i marcar com a preferent les PWA. 8   06-07-AJUN.BCN.IMI-PoC PWA-v2.pptx  document elaborat per Worldline al 2018. És el document final d’una prova de concepte que es va fer amb l’Oficina de Serveis al Mòbil per a saber què permeten les webapps en resposta a la necessitat de Comunicació Digital per a construir PWA. Altres links que poden interessar:  Circular de l’Ajuntament per consolidar l’estratègia en la que es troben mesures per a reduir el nombre d’apps: https://w123.bcn.cat/APPS/egaseta/cercaAvancada.do?reqCode=downloadFile&publicacionsId=168 52  Guia de comunicació digital per a la construcció de productes digitals: https://ajuntament.barcelona.cat/guia-comunicacio-digital/  Requeriments tècnics per a la construcció d’apps a l’Ajuntament: http://druida.dtibcn.cat/estatiques/serveis_mobils/02/requeriments_tecnics_desenvolupament/req ueriments_tecnics_catala/ ANNEX TENDENCIES Actualment no hi ha una tendència clara al sector a l’hora de triar una tecnologia, es poden veure tendències contraposades que moltes vegades venen marcades per experiències prèvies o per la disponibilitat de recursos. Durant els darreres 10 anys s’han vist empreses i institucions que han adoptat amb molta força alguna de les solucions hibrides o cross-platform de moda en aquell moment i que en poc temps l’han abandonat perquè no complia amb les seves expectatives o simplement perquè no va tenir l’adopció esperada. Algunes d’elles són:  Titanium – Appcelerator  Rhomobile  Xamarin  PhoneGap/Cordova  Sencha Touch També hi va haver una tendència a fer servir tecnologia de jocs per a desenvolupar aplicacions, aquí destacaven solucions com:  Unity  Marmalade Aquestes opcions tampoc han acabat de consolidar-se. Fruit d’aquestes experiències prèvies podem trobar empreses o institucions que han decidit desenvolupar-ho tot en natiu, abandonant totalment la resta d’opcions i prohibint explícitament l’ús de qualsevol opció que no sigui la nativa. Aquestes empreses normalment han tingut males experiències amb solucions cross-platfom o hibrides i han apostat per frameworks propis i mòduls reutilitzables per a poder optimitzar la productivitat. Hi ha altres que aposten per la tecnologia Web i per les PWA, deixant les aplicacions (híbrida o nativa) per a casos molt concrets i justificats. Per un altra banda, les eines cross-platform segueixen tenint el seu espai. A mesura que les eines cross- platform existents anaven perdent força sense ser capaces de consolidar-se com a líder del mercat, n’han 9 aparegut de noves que podrien acabar convertint-se en el estàndard de facto per a aquest tipus de solució. Les més destacades actualment son React Native i Flutter. React Native es una solució de Facebook que ha tingut molt d’èxit i que està sent adoptada per moltes empreses. Alguns dels motius per a aquesta adopció són la disponibilitat de recursos amb coneixement de React i el bon resultat final. A pesar que l’entorn i el resultat final és molt millor que la resta de solucions existents fins ara, ens estem trobant amb un patró semblant al que va ocórrer amb les primeres solucions cross-platforms que van aparèixer fa uns anys: empreses que han apostat molt fort per React Native i després de 2 anys han decidit abandonar-ho i tornar al desenvolupament natiu. Exemples d’aquesta situació els podem trobar amb AirBnB o Udacity. Tanmateix, Google està apostant per Flutter, una solució semblant a React Native, encara que de moment l’adopció és molt baixa, no obstant podria ser una de les candidates a fer front a React Native en aquest sector. El paper de Google Google sembla que segueix el model que està fent en quasi tot. Mira d’enfocar-se en quasi tots els àmbits possibles, de manera que no perdi oportunitat en res i a més ho fa d’una manera en la que, aparentment, el seu negoci no sempre és evident, fent moltes coses aparentment gratis. Per això Google està en tot: - Sistema operatiu Android (codi obert) amb una botiga d’aplicacions amb apps a la venta i gratuïtes, però amb uns requisits pels desenvolupadors molt més fàcils i menys restrictius. - Fabrica dispositius però no són exclusius. També permet a altres fabricants instal·lar Android - Treballa amb Kotlin o Flutter, que no només permet fer apps en Android si no també per iOS. - Intenta liderar la definició de les PWA i fa que el seus navegadors siguin el màxim de compatibles amb aquestes. - Lidera el desenvolupament de diversos frameworks de PWA: Angular, Polymer,... - Està desenvolupant un nou sistema operatiu que pot substituir o ser complementari a Android (Fuchsia) Amb tot això i més coses que fa, sembla que no aposti clarament per res i, a l’hora, aposti per tot. Per tant és difícil dir cap a on evolucionaran les aplicacions en els seus sistemes operatius. El paper d’Apple Per Apple, la seva botiga d’aplicacions (App Store) és un negoci molt lucratiu. A diferència d’Android, els usuaris d’iOS solen estar més disposats a pagar per les seves aplicacions. Per cada aplicació que es ven a l’App Store, Apple s’emporta un 3 % de la venta. També participa dels guanys de les In-app purchase (ventes dintre de les apps). Per a ells, una PWA és una aplicació que s’escapa d’aquest model i, per això es resisteix a promocionar-ho. Fins a la versió.3 d’iOS (2018), no ha implementat en el seu navegador i sistema operatiu les capacitats (service workers) per a poder utilitzar les PWA i ho ha fet d’una forma tímida i sense fer una gran publicitat. Segueix però, no implementant totes les funcionalitats que ja tenen altres sistemes. Per exemple, segueix sense permetre la recepció de notificacions push, la qual cosa és un greu limitant per a poder fer que una PWA tingui èxit i sigui útil en iOS. De totes maneres tampoc tanca totalment les portes a aquesta tecnologia, ja que sap que ha de seguir també el que faci la competència. 10 Per tant, a falta de que trobin una altra manera de fer rendibles les PWA, és de preveure que seguiran sempre un pas enrere en aquesta tecnologia i segueixin apostant per les apps natives. A més Apple treballa amb un ventall de dispositius molt limitat i que, a més, els dissenya i fabrica ell mateix. Per aquest motiu d’una forma “fàcil” pot aprofitar al màxim les capacitats dels dispositius amb el llenguatge de programació que ell mateix ha creat. És a dir, segueix l’estratègia d’intentar tenir un ecosistema “tancat” tant pels programadors com per l’usuari final. Evolució d’apps natives i PWA Les apps natives estan en un punt de maduresa molt elevat. Ara mateix hi ha multitud de frameworks, patrons de desenvolupament i llibreries que ens permeten agilitzar i fer sostenibles els desenvolupaments. Els SDK’s propis de Google i Apple cada cop ofereixen més facilitats, el que fa més fàcil la reutilització de codi i la reubicació de programadors d’un pro ecte a un altre. A més, l’aparició de Kotlin pot arribar a ser una eina de futur, ja que permet generar aplicacions amb les mateixes prestacions que les fetes amb Java i, a més compilar-les per iOS. I per últim aquest llenguatge i Swift són força similars, de manera que ja no és tant complicat disposar de programadors que puguin treballar en Android i iOS. La conclusió doncs és que estan en un alt grau de perfeccionament i que segueixen millorant però d’una forma més lenta que fa uns anys. Les PWA en canvi és tot el contrari. Encara els hi queda molt camí per recórrer, ja que no tenen el mateix rendiment ni prestacions, però a l’hora els permet millorar constantment i de forma molt ràpida. Probablement les prestacions que ofereixen encara no són suficients per a moltes coses, però en un anys és molt possible que es segueixin incorporant de noves. Val a dir, que totes les millores que puguin obtenir les Webapps són aplicables a les apps híbrides. Per aquest motiu, a mesura que aquestes permetin més funcionalitats, les apps híbrides guanyaran preferència respecte a les eines Cross-Platform. ot i que no és un tema tècnic, també és força simptomàtic de l’aproximació entre els dos mons, que Google permet trobar apps natives des del cercador web i, des de fa un temps, també permet publicar PWA en el market d’apps (però cal modificar-les). Si fem l’anàleg amb les aplicacions per PC, fa anys quasi tot era client-servidor (equivalent a natiu), mentre que les webs es limitaven a coses informatives i de poc rendiment. Amb el temps, realitats com per exemple, les eines que ofereix Google (fulls de càlcul, presentacions o altres), fan que ja no sigui tant necessari una aplicació instal·lable i que aquestes es reserven per a coses realment molt potents. És possible que les aplicacions per a mòbils segueixin aquest mateix camí, sobretot si algun dia s’estabilitza l’evolució d’aquests dispositius a nivell de hardware, ja que si no sempre el codi natiu tindrà avantatge. Ajuntament de Barcelona APPS (Aplicacions mòbil) La nova estratègia en matèria d'aplicacions mòbils consisteix en el següent:  Evitar fer aplicacions natives quan la mateixa necessitat pot estar coberta per un web responsiu.  Ús preferent d’aplicacions web, més universals que les aplicacions natives pel fet de ser accessibles directament des del navegador web, sense necessitat de baixar-les al dispositiu, i que permeten un respecte més gran per les eleccions tecnològiques dels ciutadans.  Unificar les funcionalitats actuals en poques aplicacions natives.  Desenvolupar, mitjançant programari lliure, compartible i reutilitzable per tercers.  Potenciar l’ús de dades obertes, la seguretat i la privacitat. 11 La publicació d’aplicacions mòbils es fa de manera centralitzada, des de l’Oficina de Serveis al Mòbil de l’Institut Municipal d’Informàtica. Qualsevol petició d’obertura de nous canals o canvis substancials en un canal existent s’ha de vehicular a través del cap de comunicació corresponent de cada àrea o districte, qui ho sol·licitarà a la Direcció de Comunicació Digital (referents) mitjançant el formulari annex. La Direcció de Comunicació Digital valorarà si és procedent tirar-ho endavant o no. Frameworks de desenvolupament de PWA ANGULAR Un dels seus principals avantatges és que està desenvolupat per Google, cosa que dona a aquest framework una gran robustesa i suport de desenvolupament. En el moment d’escriure aquest document es troba a la versió 7, i rep una major versió aproximadament cada 6 mesos. Disposa d’una gran comunitat de desenvolupadors arreu del mon, i, si hi ha funcionalitats no suportades pel framework original, sempre és probable que aquestes funcionalitats hagin estat implementades per algun plugin o llibreria externa suportada per Angular, cosa que fa que sigui un framework molt complet. Google ofereix tanmateix una llibreria de components visuals que implementa el seu disseny Google Material, anomenada Angular Material, amb poc cost de desenvolupament i totalment responsive. Un altre avantatge de cara als desenvolupadors de l’aplicació és el CLI d’Angular, que ajuda tant a la generació d’un pro ecte base com a la generació de nou codi, reduint el temps i cost de programació del codi base. Tot el codi generat segueix la guia d’estil i bones pràctiques de Google. És un framework òptim per al desenvolupament de SPA (Single Page Applications). 12  VUE Un altre framework a analitzar és VUE. Aquest va ser llançat al 2014 per un ex-empleat de Google, i es tracta d’un framework progressiu. Això vol dir que és igual d’útil per fer una aplicació súper bàsica (com es feia abans amb jQuery) fins a complexes SPA. VUE pot ser utilitzat com una llibreria molt simple com ja hem explicat prèviament, però la potencia ve quan utilitzem components, ja que el core està centrat en la implementació de vistes, per tant, en tenir una arquitectura orientada a components igual que Angular. A més, podem accedir a aquests components quasi en qualsevol moment del seu cicle de vida el que permet fer el que es vulgui i d’una forma molt intuïtiva. VUE, a més, té la llibreria Vuex que implementa Flux i que, d’una forma també molt intuïtiva, ens permet accedir a l’estat i mètodes mutacionals en el moment que es necessiti. Un dels desavantatges que tenim respecte a Angular és que la comunitat de desenvolupadors és menor que en Angular, no obstant això, molts dels desenvolupadors estan passant d’Angular a VUE, per la potència que dona i per la fàcil cost d’aprenentatge, el que fa que aquesta comunitat de desenvolupadors cada vegada sigui superior. 13 Igual que Angular, VUE també té una llibreria Material per donar un look & feel Material de manera fàcil al desenvolupat, i també té un CLI que a uda a la generació de codi base de manera fàcil al desenvolupador. React El tercer framework a analitzar és React. Desenvolupat per Facebook, va ser llançat inicialment com un framework per a crear i desenvolupar components visuals. Va tenir molt bona acceptació i va anar creixent fins a convertir-se en un potent framework de progressive webapps. React és un dels frameworks més òptims en la renderització de les vistes gràcies al seu virtual DOM que redueix la manipulació dels objectes al DOM del navegador. Això té un gran impacte a mida que una pàgina creix en nombre de components, ja que només aplica els canvis en els components que canvien, no renderitza tota la pàgina quan canvia algun component al DOM. La següent imatge mostra la diferencia entre la recarregar d’una pàgina normal i com ho fa ReactJS: React és reactiu, com el seu nom indica, el que fa que no s’hagin d’implementar observables ni fer canvis expressament per això, ja que tot funciona per sota, el que fa que el desenvolupament sigui més fàcil en aquesta part. React, igual que Angular, té una gran comunitat de desenvolupadors, el que fa que, com ja hem explicat, funcionalitats no suportades pel framework original puguin estar implementades per altres desenvolupadors. No obstant tots els punts positius, React no té una corba d’aprenentatge simple com VUE i es necessita a un equip amb certs coneixements per tal de començar a construir una aplicació amb aquesta tecnologia. IONIC El framework d’Ionic és un conegut per facilitar que les aplicacions híbrides multi-plataforma mantinguin el look and feel natiu del sistema operatiu on s’executa, transparent al desenvolupador. Ionic es troba ara a la versió 4, on s’elimina la imposició d’Angular com a framework d’aplicació donant la possibilitat d’integrar-se amb altres frameworks com React o Vue. A més ofereixen en aquesta quarta versió la possibilitat d’implementar progressive web apps completes amb totes les funcionalitats. Ionic incorpora també el seu CLI que ajuda a la generació de codi base de manera fàcil al desenvolupador. A més d’això incorpora multitud d’APIs natives que permeten mitjançant plugins utilitzar tots els components de les diferents plataformes on s’executa el codi imitant el funcionament de les aplicacions natives. 14  Polymer Polymer, a diferència de les tecnologies tractades anteriorment no és un framework, sinó que és una potent llibreria per al desenvolupament de webs basada en els estàndards dels web components. Polymer té diverses versions i en concret la versió 3 migra de M -imports a ES6 i es centra en el codi per facilitar l’ús de module bundlers que carreguen, interpreten i executen modules en el build time i no en execution time. També Polymer té una comunitat d’usuaris gran i en la seva documentació oficial tenen components creats per la comunitat que es poden utilitzar fàcilment en les nostres construccions. A continuació es mostra la quota de mercat de les diferents llibreries i frameworks: A més, encara que hi ha navegadors que no donen suport a aquests Web Components, Polymer inclou en els seus un polyfill que fa que aquests navegadors que encara no els suporten puguin suportar-los. Altres A continuació posem un llistat d’altres frameworks menys utilitzats o menys rellevants:  Ember: https://www.emberjs.com/  Meteor: https://www.meteor.com/  Aurelia: http://aurelia.io/  Riot.js http://riotjs.com/  Dojo (Toolkit): https://dojotoolkit.org/  Stencil: https://stenciljs.com/ 15