Ponencia de Juan Alonso Moreno de Tecnilogica ofrecida en Droidcon Spain. Sinopsis: En un mercado donde aún se tiene una mentalidad “iOS first”, es posible evitar que las apps de Android queden relegadas a meras adaptaciones de los originales. En esta charla expondremos cómo conseguirlo, potenciando las características más sobresalientes de la plataforma Android y esquivando las trampas mas habituales. Utilizaremos como ejemplo algunas aplicaciones que estamos desarrollando.

1. Me enamoré de un robot
Hola. Me llamo Juan Alonso, y soy Director Técnico en Tecnilógica. Es una empresa de desarrollo,
que incluye un departamento de aplicaciones móviles, formado hace cuatro años. A lo largo del
último año, en Tecnilógica estamos viendo cambiar el mercado de las aplicaciones móviles. Los
clientes demandan cada vez más aplicaciones Android, para desarrollar a la vez o en vez de la
correspondiente aplicación iOS.
“Me enamoré de un robot” no pretende ser una charla técnica. No voy a hablar de frameworks,
metodologías, librerías, stacks, fragmentos ni nada por el estilo. Simplemente quiero hablar de la
situación actual y exponer algunos argumentos que os pueden ayudar a la hora de convencer a
ese ser mitológico del que habéis oído hablar y que alguno de vosotros incluso habéis llegado a
ver - el cliente - para animarle a desarrollar primero una aplicación Android o, al menos, poder
desarrollar las diferentes versiones simultáneamente.
No pretendo avivar el fuego entre ambas plataformas. Tanto iOS como Android tienen unos
aspectos que las hacen muy atractivas, así como reconozco que en otros campos se quedan un
poco cojas y hay campo para la mejora. Curiosamente, parte de las ventajas y desventajas de
cada plataforma viene de la filosofía “sistema abierto / sistema cerrado” que aplican a rajatabla,
hasta las últimas consecuencias.
Primero para iOS
Hasta hace unos meses, cuando un cliente nos solicitaba desarrollar una aplicación, siempre
empezaba por la versión iOS y si la cosa iba bien o le quedaba algo de presupuesto, a veces se
animaba a hacer la aplicación Android.
No es habitual que el cliente conozca de primera mano el mercado, y en muchas ocasiones se
rige por un conocimiento que puede resultar incompleto o sesgado. Así, el cliente escucha
afirmaciones como que “el dinero está en iOS” o que “desarrollar una aplicación para Android es
mucho más complicado” y no va más allá.
Es cierto que hay más dinero en iTunes: se calcula que cerca de dos veces y media más, pero,
por otro lado Google Play está creciendo mucho más rápido. Y, respecto a las herramientas, es
verdad que hasta hace muy poco tiempo el desarrollo en Android era bastante infernal, pero las
herramientas han madurado mucho, facilitando las tareas de desarrollo y testing.
Otro factor a tener en cuenta, y que desarrollaré posteriormente es el tipo de mercado en el que
estamos. El cliente, cuando se informa, no siempre se da cuenta de que la información que le
llega no tiene porqué servir para el mercado europeo o español, donde las condiciones son
diferentes.
Estadísticas
Está claro que las empresas, los clientes, quieren apostar sobre seguro y para ello, lo primero que
hacen es consultar cifras. Lamentablemente, hay una guerra tremenda de cifras así como multitud
de estudios con resultados dispares: unos comparan el market share,; otros, el número de
teléfonos en uso, lo que nos lleva a preguntarnos si sirven de algo estos datos. Como referencia
son útiles, pero conviene manejarlos con precaución, ya que es frecuente que nos den una
imagen sesgada o incompleta de la realidad. ¿Qué beneficios se obtiene con cada venta? ¿Qué
dispositivos se están comparando? ¿Qué porcentaje de dispositivos está en uso?
Las cifras que se manejan en España es de tres terminales Android por cada terminal iPhone. A
nivel mundial, diferentes estudios hablan de mil millones de terminales Android frente a

2. setecientos millones de terminales iOS. Como veis son unas cifras lo suficientemente importantes
para presentarlas al cliente y aportarle una visión más amplia de la realidad.
Filosofía: abierto y cerrado
Resulta curioso que lo que para nosotros es uno de los puntos fuertes de la plataforma Android,
los clientes lo perciben a veces como una debilidad. Me refiero al sistema abierto, que a veces es
percibido como el salvaje Oeste, una plataforma sin ley donde, en cuanto te descuides, te has
instalado un programa con malware. Y lo que es peor, a veces Android es el mayor enemigo de sí
mismo. Os pongo unos ejemplos:
• Un sistema operativo abierto permite a las operadoras distribuirlo. Así, los usuarios no tendrán
que esperar por sobrecarga de los servidores cuando aparece una versión nueva del sistema
operativo para todos los usuarios. Sin embargo, hay veces que las operadoras tardan en
distribuir la versión nueva, o es una versión modificada con funcionalidad diferentes.
• Al ser fácilmente modificable, se da el caso de que los sistemas operativos se hacen la
competencia entre ellos mismos: los diferentes “flavours” de Android compiten entre ellos. Esta
situación peculiar no se da en un sistema cerrado, donde la experiencia resulta mucho más
consistente.
• Se ofrece una mayor variedad de hardware, lo que permite producir modelos muy
personalizados. Como contrapartida, aparece una fragmentación que no existe cuando el
hardware está controlado.
• El proceso de aprobación de aplicaciones es prácticamente inexistente, lo que permite subir
aplicaciones a la tienda en apenas una hora. Sin embargo, esto permite que programadores
poco escrupulosos puedan subir aplicaciones que no hacen lo que dicen, con la posibilidad de
encontrare con malware o un troyano.
Esta situación, la oposición entre sistemas abiertos y cerrados, no es nueva en absoluto. Un
ejemplo equivalente ocurre en el mundo de los videojuegos: ¿qué es mejor, una consola cerrada y
propietaria, con un sistema de aprobación de juegos estricto, o un sistema abierto, tipo PC, donde
cualquiera puede vender su juego, sea una castaña o algo sublime?
Hardware
Vamos a ver en detalle algunos de estos puntos. El primero de ellos es el hardware. Se estima
que hay más de doce mil dispositivos Android diferentes, entre teléfonos, relojes, tabletas, lectores
de ebooks y televisores. Por el contrario, el número de dispositivos iOS no va más allá de una
docena. Esto hace que inicialmente sea más sencillo desarrollar para iOS, la variación de
funcionalidad es mucho menor.
Sistema operativo
Hay que tener presente que no somos el usuario tipo. Nosotros, en cuanto sale una versión nueva
del sistema operativo, corremos a instalarla. Sin embargo, un usuario “normal” no está al tanto de
las novedades, y actualiza el sistema operativo con mucha menos frecuencia.
En el caso de iOS, una vez estabilizado el sistema operativo, aproximadamente un noventa y seis
por ciento de usuarios lo han instalado en sus dispositivos. Así, pasado cierto tiempo, podemos
permitirnos abandonar la versión anterior sin graves repercusiones. Actualmente, tres meses
después de la salida de iOS7, ya lo ha instalado un setenta y cinco por ciento de usuarios.
Por el contrario, en el caso de Android, la tasa de actualización es mucho menor:
aproximadamente un treinta y tres por ciento de los usuarios están usando la versión más reciente
del sistema operativo, otro treinta y tres la anterior, y el resto, una versión dos iteraciones por

3. detrás. Esta fragmentación dificulta la tarea de los programadores, y a su vez, potencia la idea de
dificultad y complejidad del entorno Android.
Mercados
Como comentaba antes, otro reto al que debemos enfrentarnos es desechar la información que no
aplica, educando al cliente. Las noticias más espectaculares suelen venir de EE.UU. e - insisto es un mercado muy diferente del europeo y del español. Pero, lamentablemente, el cliente no
suele filtrar esa información y el cliente la malinterpreta.
Software
Os quiero poner tres ejemplos que muestran la diferencia entre mercados:
• Instagram - empresa estadounidense - empleó dieciocho meses en tener disponible una versión
para Android. Lamentablemente, esa es la información que recibe el cliente: han hecho primero
una versión iOS y han tardado dieciocho meses en tener la de Android. Sin embargo, pocos se
acuerdan de que en las primeras veinticuatro horas, la aplicación tuvo un millón de descargas en
Google Play.
• Vine - también estadounidense - empezó también como iOS y seis meses después sacó al
mercado la versión Android.
• King - empresa europea - lanzó la primera versión de Candy Crush Saga para Facebook y siete
meses después, simultáneamente, lanzó la versión móvil para ambas plataformas.
Primero para Android
A pesar todo lo indicado anteriormente, Android tiene una serie de ventajas que le convierten en
una primera opción totalmente viable, y que debemos recalcar al cliente, para que pierda el miedo:
• El gran número de dispositivos vendidos (diez a siete en el mundo, tres a uno en España) lo
convierten en una plataforma a tener en cuenta.
• La curva de aprendizaje es menor, por lo que cuesta menos formar a un programador.
• Las herramientas de desarrollo han mejorado enormemente.
• La UI ha madurado en los dos últimos años, acortando distancias con iOS en unos aspectos,
superándole en otros.
Filosofía (II): principios de diseño
Esta madurez de la UI, así como el cuidado por el detalle permite un acercamiento a ambas
plataformas. Si echáis un vistazo a las recomendaciones de diseño, veréis que, con distintos
nombres, se buscan metas comunes: que yo disfrute usando el dispositivo, que vea sólo la
información relevante, pero que se pueda acceder a la totalidad de la misma en caso necesario,
que se utilicen atajos consistentes en todas las aplicaciones, que simplifique mi vida, que me
ayude a tomar decisiones…
Hasta aquí hemos analizado la situación actual: dónde estamos y por qué. Ahora tenemos la
pelota en nuestro tejado. ¿Qué podemos hacer para ir cambiando la situación? Voy a hablar de
cada uno de los pasos que se suelen dar en un desarrollo. No todos se pueden aplicar a todos los
proyectos, pero resulta útil tenerlos en cuenta.
UX
El primer paso es el diseño del producto digital. Si estamos adaptando una aplicación de iOS, hay
que tener presente las diferencias entre ambas plataformas.

4. • Mantener la simplicidad. Si una operación que en iOS se se hace en dos gestos necesita siete
en Android, es que esa operación no es adecuada. En vez de replicarla y complicar
innecesariamente la interacción, es mejor sustituirla por otra que sea más sencilla.
• Hay que tener en cuenta las diferencias de navegación y las interacciones. No hay que imitar,
sino sustituir. Si una interacción no es habitual en Android, conviene sustituirla por una que lo
sea.
Y podemos inclinar la balanza a nuestro favor si aprovechamos las funciones propias del sistema
operativo, aunque no estén presentes en la versión original de la aplicación. Por ejemplo, incluir el
reconocimiento de voz, que en Android es muy robusto, añadir la posibilidad de compartir
información entre otras aplicaciones o crear un widget para la aplicación, funcionalidades que no
existen o son muy pobres en iOS.
Diseño
Si nos limitamos a portar la aplicación sin más, vamos a obtener una especie de monstruo de
Frankenstein, que ni es iOS ni es Android. No se trata de trasladar, sino de adaptar la aplicación, y
eso implica rehacer los assets, teniendo en cuenta las diferentes densidades de píxeles y los
tamaños de pantalla de los dispositivos. Igualmente, hay que modificar el interface gráfico para
eliminar algunos botones necesarios en iOS, pero redundantes en Android, como el botón “atrás”.
Para lograr esta adaptación, la situación ideal es contar con un diseñador que conozca ambos
mundos. Al disponer de una visión global de ambos interfaces, puede aportar las soluciones más
adecuadas en cada caso. Y, si se trata de un desarrollo en paralelo, se puede diseñar desde el
primer momento buscando una meta común.
Acceso a recursos
Otro punto a considerar son los botones físicos que hay en cada plataforma. Android nos ofrece
un botón “Atrás”, un botón “Menú” y, en algunos dispositivos, un botón “Configuración”. Vamos a
utilizarlos, eliminando los elementos redundantes del interface gráfico. Así podremos liberar un
valioso hueco en la pantalla, algo imprescindible en dispositivos con pantallas pequeñas.
Y, al igual que tenemos en cuenta los diferentes botones, hay que tener en cuenta el resto del
hardware. ¿Tiene GPS el dispositivo? ¿Bluetooth? ¿Acelerómetro? ¿Cámara? Un ecosistema tan
abierto como el de Android nos obliga a comprobar la existencia de esas funcionalidades y
adaptar el comportamiento de nuestra aplicación según existan o no.
Por ejemplo, y volviendo al tema de adaptar en vez de trasladar: ¿qué ocurre si el dispositivo
donde queremos ejecutar la aplicación no tiene GPS? Si el GPS es imprescindible para el
funcionamiento de la aplicación, tendremos que indicarlo así, pero si no lo es, quizás podamos
ofrecer al usuario algo en su lugar (un mapa fijo, por ejemplo) que supla esa funcionalidad. Demos
al usuario una alternativa viable, no un pegote sin sentido.
Desarrollo
Reconozco que esta cosa de hablar así en abstracto es muy fácil. Por ejemplo, una situación ideal
es desarrollar ambas aplicaciones en paralelo, con un único jefe de proyecto, un diseñador / UX y
dos equipos de desarrollo. Así, tanto el jefe de proyecto como el diseñador tienen una visión global
del proyecto, lo que permite a los equipos de desarrollo centrarse en su tarea, sin otras
distracciones.

5. Y en cuanto a las herramientas, ya podemos enterrar el Eclipse y lanzarnos de cabeza al Android
Studio, eso sí, siempre usando la support library, que hasta que no nos libremos de las versiones
más antiguas del sistema operativo tendremos que ir arrastrando.
API
Este consejo no es tanto orientado al desarrollo Android, sino al desarrollo multiplataforma. Si la
aplicación que estáis desarrollando va a correr en diferentes sistemas operativos y, por la lógica
de negocio, hay que hacer cálculos complicados, cread un API para realizar las operaciones en el
servidor. Es un consejo de sentido común que no se puede aplicar en todos los casos, pero si se
alinean los astros y lo podéis usar, adelante.
Estamos desarrollando una aplicación de productividad personal llamada Hightrack
(http://hightrack.me) En este caso, el cliente tenía claro desde el primer momento que quería
aplicación web, aplicación Android y aplicación iOS. Montamos un API para traernos los datos y,
al cabo de un tiempo nos dimos cuenta de que en cada versión estábamos haciendo por separado
la lógica de negocio. No sólo estábamos repitiendo el mismo trabajo tres veces, sino que
aumentaban las posibilidades de cometer un error.
Decidimos modificar el API para que los resultados ya estuvieran procesados, y nuestra vida
mejoró notablemente: no se repite el trabajo, las pruebas son más fáciles de hacer y, si hay un
error, basta con modificarlo en el servidor: las aplicaciones recibirán los datos correctos sin
necesidad de subir una nueva versión a la tienda correspondiente.
Testing
El testing ha sido la bestia negra del proceso de desarrollo de Android. Si tenemos en cuenta el
funcionamiento del emulador, el número de dispositivos, la diversidad de hardware, los distintos
tamaños de pantalla… es natural delegar las pruebas en el usuario final y esperar a su feedback
para hacer las correcciones necesarias.
NUNCA se debe hacer algo así. Es un error muy grave sacar una aplicación a medio probar: no
vamos a tener una segunda oportunidad y, si algo no funciona, el usuario lo borra y a otra cosa.
Además, esta situación contribuye a la imagen que a veces tiene Android como algo
desorganizado (el salvaje Oeste al que hice referencia anteriormente).
En este caso, el entorno iOS es mucho más robusto: el entorno de desarrollo incluye herramientas
para comprobar el consumo de recursos, si se crean procesos zombies, si hay leaks de memoria,
y permite hacer test de usuarios automatizados, algo que podemos hacer desde hace poco si
utilizamos espresso.
Para mejorar esta situación es vital utilizar las nuevas funcionalidades de alfa y beta testing que se
han implementado en Google Play, y así hacer un despliegue controlado al cliente, testers o
compañeros y probar la aplicación en más dispositivos, pero de manera controlada. Una vez que
haya pasado los ciclos de revisión necesarios, podemos abrirla al público.
Publicación
Ya para terminar, aunque no es parte estricta de la migración de aplicaciones, quería - por
completar - comentar la publicación en la tienda. Una vez más, las diferencias de filosofía entre
ambas plataformas se hace patente.
Por un lado, la aproximación de Apple, controlando lo que se sube, mediante revisión, lo que
incluye un retraso considerable a la hora de publicar, pero garantizando que la aplicación funciona

6. y hace lo que se espera de ella. A nosotros, por ejemplo, tras seis días de espera, nos echaron
atrás una aplicación porque nos faltaba un logo en una pantalla. Lo corregimos en cinco minutos y
seis días más tarde, la aprobaron: tardamos doce días en total en publicar la aplicación.
Por otro lado, la aproximación de Android, sin revisión salvo que haya quejas, permite tener una
aplicación disponible para descargar en una hora. Eso sí, puede haber aplicaciones de baja
calidad, malas copias o “cosas” que ni siquiera funcionan.
Otras alternativas
Una posibilidad para abaratar costes es utilizar herramientas que permiten reutilizar código, sin
depender de la plataforma. No soy muy partidario de esas herramientas, pero pueden ser una
solución adecuada si se cumplen estos tres requisitos:
• El proyecto tiene un gran alcance: necesitamos llegar a todos los dispositivos lo antes posible.
• El presupuesto es reducido.
• Estamos dispuestos a hacer sacrificios de usabilidad y diseño.
Conclusiones
Si habéis llegado hasta aquí, enhorabuena. Espero que ahora tengáis una visión un poco más
clara de por qué estamos en esta situación y como va evolucionando de “iOS first” a “Vamos a
desarrollar para ambas plataformas” En nuestras manos está hacer o adaptar aplicaciones de
manera que entreguemos un producto brillante, mejor que el original que acabe de inclinar la
balanza a nuestro favor y conseguir así que nuestros clientes también se enamoren de un robot.
Muchas gracias.