¿Qué debo saber antes de empezar mi app móvil?

Omar Saadoun
Jul 24, 2017 · 6 min read

Cada vez más seguido llega esta declaración a nuestras empresa, por teléfono, mail o la web.

Necesito una aplicación móvil para hacer….

Lo primero que tratamos de establecer es si nuestro cliente realmente necesita una aplicación móvil, necesita interactuar con sus clientes. ¿Es necesario que tenga posibilidad de trabajar sin conexión a Internet sobre la aplicación?¿Qué información debe ser accesible en ese contexto? Son simples preguntas, pero nos permiten establecer una base segura para nuestro presupuesto rápidamente. ¡De todas formas, nuestro trabajo está lejos de terminar y aún no realizamos la venta!

Lo siguiente que debemos evaluar es el conocimiento técnico que nuestro cliente tiene y desea tener, en algunas ocasiones nuestra contraparte es técnica y algunos aspectos de un desarrollo de software son más sencillos de explicar y sobre todo acordar, por el contrario, si ese expertise no está presente debemos redoblar nuestros esfuerzos para brindar el mejor servicio a nuestro cliente.

En cualquier desarrollo de software tenemos un ciclo de vida de lo que se va a realizar, el producto siempre NACE, VIVE Y MUERE. Como la vida misma, el software pasa más tiempo viviendo que en las otras dos etapas, por lo tanto, debemos considerar y sobre todo que nuestros clientes lo comprendan y es que van a invertir más dinero en mantener sus productos que en hacerlos o discontinuarlos.

En el mundo Mobile esto se potencia dado que los fabricantes (hablemos de los principales Apple y Google) modifican la base dura y blanda de nuestros productos; Apple lanza todos los años nuevos modelos de iPhone y iPad junto con las nuevas versiones de iOS (Sistema Operativo de Apple para estos dispositivos), sin contar las actualizaciones parciales varias durante el año, Google lanza una versión de Android todos los años, además de actualizaciones parciales y en cuanto a dispositivos, en el momento que compramos uno ya es antiguo.

Es decir que al momento de tener pronta una aplicación móvil está asegurado que deberíamos al menos hacer actualizaciones forzadas una o dos veces al año en las plataformas que soportemos o al menos asegurarnos que no debemos hacer cambios. Si a esto le agregamos los ajustes, modificaciones y agregados que debemos hacer para contemplar nuevas funcionalidades, sugerencias de usuarios, etc. Queda claro que debemos considerar presupuesto para el mantenimiento.

Volviendo a las explicaciones hacia nuestros clientes, un punto fundamental es el presupuesto que se tiene para el desarrollo; en general se trata de un dato reservado y que no sabremos hasta enviar la cotización. En un mundo competitivo esto es aceptable e incluso inevitable, aunque (esto es una apreciación personal) entendemos que muchas veces puede atentar contra el futuro del producto ya que de tener en cuenta el presupuesto total y el destinado para desarrollo podemos en una etapa temprana asesorar sobre las otras etapas de creación de un producto que también requieren de presupuesto. (Por ej. Una app extraordinaria, pero sin presupuesto para marketing, está destinada al fracaso).

Sorteado este punto, pero no dejando de lado el tema de presupuesto debemos profundizar un poco más en las opciones técnicas que se tienen para desarrollar aplicaciones móviles. Hoy por hoy tenemos 3 líneas generales de técnicas/tecnologías para crear una aplicación móvil.

Aplicaciones nativas, híbridas y de código generado

Este documento no intenta establecer si una técnica es mejor que la otra, cada una tiene un propósito, elementos a favor y elementos en contra; este documento intenta brindar toda la información de forma clara para que nuestros clientes tengan las herramientas necesarias para tomar una decisión adecuada y responsable en beneficio de su negocio.

Código generado

Herramientas como Xamarin permiten desarrollar aplicaciones móviles que ejecutaran código nativo, desarrollando en C# mediante Visual Studio. En la teoría, con un único desarrollo podemos generar una aplicación tanto para IOS como para Android. Estas aplicaciones probablemente funcionen con el mismo desempeño de una nativa.

Pro. Lo primero que surge en esta opción como gran beneficio es el costo de desarrollo inicial; un desarrollo, dos aplicaciones.

Pro. Si se cuenta con experiencia en el lenguaje C#, que maneja la herramienta no se debe aprender XCode o Java.

Pro. Con una sola persona podemos hacer el desarrollo.

Cons. Por otro lado, como toda herramienta, debemos considerar si hay costos de licenciamiento, la letra chica de los contratos, cómo puede ser el caso de ReactNative

Cons. Además, y este entendemos que es el punto más sensible y menos evaluado por nuestros clientes, el día de mañana, si nuestro cliente desea mantener por si mismo (con su equipo) su aplicación, deberá conseguir recursos capaces y experimentados en esta plataforma específica, aumentando el costo de mantenimiento, al menos respecto de los recursos más disponibles.

Cons. Por último, y tal vez menos predecible, estas son herramientas sin ningún apoyo o soporte (oficial) por parte de los fabricantes de dispositivos móviles (Google o Apple), en cualquier momento pueden ser comprados por otra empresa, cerrar o desaparecer. En ese caso el producto de nuestro cliente deberá ser desarrollado completamente de nuevo tarde o temprano.

Híbridas

Las aplicaciones híbridas pueden ser imaginadas como una aplicación o página web dentro de un browser enmascarado, al cual llamamos la cáscara. Al igual que las anteriores nos permiten, bajo un único desarrollo, variar la cáscara para poder tener nuestra aplicación funcionando en ambas plataformas.

Pros. Tal como la definimos con un único desarrollo podemos soportar ambas plataformas, por lo tanto, a nivel de presupuesto deberíamos de tener un impacto muy positivo.

Pros. Nuevamente con un único desarrollador debería de poder realizar el trabajo.

Cons. Desde su concepción esta técnica nos establece más capas que las anteriores por lo que nunca podremos lograr la misma performance ni velocidad de respuesta que una aplicación de código nativo. Si nos planteamos alguna aplicación con mucho multimedia o un juego, directamente es inviable.

Nativas

Las aplicaciones de este tipo son las más puras en el sentido de su construcción. Se desarrollan utilizando los mecanismos, lenguajes y herramientas brindadas o soportadas oficialmente por el fabricante del sistema operativo. En el caso de Android (Java y ahora Kotlin o C++) con Android Studio, en el caso de iOS (Objective-C o Swift 1, 2, 3) con XCode. Desde ya queda claro que deberemos realizar dos desarrollos potencialmente por personas diferentes.

Pros. Tenemos la máxima garantía que lo que vamos a hacer funcionará en la mayoría de los dispositivos posibles. Tenemos soporte de los fabricantes respecto de estas tecnologías. Esto también impacta en todo lo que refiere a manejo de recursos de los dispositivos, ya que no tendremos intermediarios ni ningún tipo de código generado.

Pros. Podemos hacer cualquier aplicación que se nos plantee. Las limitaciones pasan a ser las que tienen los sistemas operativos y no la tecnología con la que vamos a desarrollar.

Cons. Claramente el principal aspecto negativo es desde el punto de vista presupuestal, ya que requerimos al menos el doble de esfuerzo para lograr ambas plataformas (cuando corresponde).

Pros. Soporte en el tiempo. Muchos ya conocen la historia de Parse (plataforma de backend como servicio muy utilizada y comprada por Facebook hace un tiempo). Sirvió de base para muchísimas aplicaciones y un día, Facebook decidió cerrarlo, dejando a mucha gente (con tiempo de 1 año de aviso) en la obligación de migrar sus aplicaciones. Este es un ejemplo de las tantas situaciones que pueden suceder cuando utilizo una herramienta de terceros. En el caso nativo, mientras los Sistemas Operativos sigan funcionando, no tendremos ese problema.

Haciendo un repaso de pros y contras de cada técnica o herramienta vemos que el objetivo común es clarificar el impacto real a nivel de presupuesto en todo el ciclo de vida de la aplicación. De nada nos sirve generar una venta de una aplicación que no podrá sobrevivir el resto de su vida.

Desde inmind nos focalizamos en el desarrollo de aplicaciones nativas, hemos experimentado en los otros mecanismos planteados y si bien estamos convencidos que hay escenarios en los que son la mejor opción, nuestro esfuerzo, aprendizaje y experiencia está en las nativas.

Omar Saadoun

Written by

Mobile and web apps expert, blockchain consultant. Co-founder @inmind and father of one. Tech enthusiast, always looking to enhance or create new business

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade