Cómo hacer una buena app en 3 pasos

Si es tan simple hacer una buena app, ¿por qué no hay tantas?

Hoy exploramos los tres puntos claves que deberíamos tener en cuenta para hacer una buena app tanto para Android como para iOS.

Un repaso por reglas de sentido común que, no obstante, podrían generar susceptibilidades y opiniones encontradas por opinar distinto.

¿Realmente es solo una opinión? ¿Una fórmula de éxito? Vamos a analizarlo.

Convierte en un Senior iOS Developer con el Swift Full Stack Bootcamp. Encuentra toda la información aquí: IV Swift Full Stack Bootcamp 2024.

Descubre nuestro canal de Twitch en: twitch.tv/applecoding.

Descubre nuestras ofertas para oyentes:

• Cursos en Udemy (con código de oferta)
• Apple Coding Academy
• Suscríbete a Apple Coding en nuestro Patreon.
• Canal de Telegram de Swift. Acceso al canal.

---------------

Consigue las camisetas oficiales de Apple Coding con los logos de Swift y Apple Coding así como todo tipo de merchadising como tazas o fundas.

• Tienda de merchandising de Apple Coding.

---------------

Tema musical: "For the Win" de "Two Steps from Hell", compuesto por Thomas Bergensen. Usado con permisos de fair use. Escúchalo en Apple Music o Spotify.

Wanda, la comunidad de podcast independientes en español.

Hola y bienvenidos a un nuevo episodio de Apple Coding Daily. ¿Cómo hacer una buena app. Es una pregunta bastante complicada, yo la respuesta la tengo muy clara, el problema es que mi respuesta es mi respuesta, pero puede haber muchas otras respuestas y, en fin, hay que darle respeto a cualquier tipo de opinión, una cosa es que tú no estés de acuerdo con esa opinión, pero desde luego hay que respetarla. En mi opinión, en fin, esto es obvio, mi opinión es acertada, la de los demás cuando se desvían de lo que voy a decir, no lo es. Una buena app es una app que respeta el diseño de interfaces humanas del dispositivo.

Una buena app es aquella que está hecha con las herramientas nativas que proporciona el fabricante, el creador del operativo. Una buena app es aquella que respeta ciertas normas de experiencia de usuario, usabilidad, facilidad. Una buena app es aquella que aprendemos a manejar sin que nadie nos enseñe, porque a nivel intuitivo se maneja por sí sola y, pues, es como si, bueno, pues eso es algo tan intuitivo que ni siquiera tengo que pensarlo, ¿vale? Pero, por desgracia, esto no todo el mundo opina igual. Esto, no todo el mundo piensa que son reglas que, dichas así, parecen lógicas, pero parece ser que para llegar a esa solución, pues puede que tal vez haya otras salidas.

Vamos a verlo. Os vamos a hablar de nuestro colaborador de este episodio, que no es otro que Vodafone. Vodafone, que tiene novedades muy interesantes si eres autónomo o una pequeña empresa, porque ya sabes que, si este es tu caso, Necesitas contar con los mejores, por eso Vodafone Business presenta la nueva tarifa negocio a medida, que incluye todo lo que necesitas para llevar tu negocio a otro nivel. Ofrece un soporte técnico e informático veinticuatro por siete, por lo que siempre están ahí cuando algo falla, que es lo más importante, porque tu negocio, cuando algo falla, no puedes esperar. Vodafone Business te acompaña para impulsar tu negocio con soluciones profesionales para reparar y sustituir tus dispositivos, protegerte de ciberataques o mejorar tu presencia y visibilidad en Internet.

Con negocio a medida de Vodafone Business tendrás fibra de seiscientos megas, Dos líneas de móvil cinco G y puedes escoger entre un servicio de ciberseguridad, yo escogería este, De posicionamiento de tu negocio en Internet o de reparación y sustitución de dispositivos por tan solo cincuenta y cuatro con cincuenta y cuatro euros al mes, más IVA, lógicamente. Descubre todos los detalles y apúntate entrando a Vodafone punto es, o pinchando en el enlace en las notas de este episodio. Como siempre, muchísimas gracias a Vodafone por colaborar con Apple Coding. Todo esto viene básicamente de un clip que saqué el otro día de mi último directo, donde comentaba que una app no es una página web, porque uno de los grandes problemas que tienen las aplicaciones a día de hoy es que están diseñadas por personas que no están cualificadas para poder diseñar aplicaciones. Personas que no están cualificadas porque piensan que una app puede ser igual que una página web en el sentido de que puede diseñarse igual que se diseña una página web.

Personas que, a lo mejor, solo conocen la experiencia de un único sistema operativo y diseñan solo para ese sistema operativo, por lo que están diseñando, a lo mejor, una aplicación para iPhone y ponen la misma exacta experiencia e interfaz en Android. Error. No podemos, cada sistema operativo es distinto y los usuarios de cada sistema esperan encontrar los elementos cada uno en su sitio, por lo que está tan mal replicar una interfaz de iPhone en Android como una de Android en iPhone. Por por desgracia, aquí en España lo que más se repite es que las apps de Apple intentan, o las apps de Apple replican las apps de iOS, replican la interfaz de Android, porque el diseñador solo conoce Android, porque tal vez solo ha visto Android en su vida, esa es su referencia y, por lo tanto, piensa que todo es igual. Y diréis, bueno, ¿y por qué no tienen la formación apropiada?

¿Por qué, como tú dices, no están cualificados? Pues no están cualificados por falta de interés. Falta de interés barra desconocimiento. Hay que hacer cursos de gran calado, económicamente inviables, de mucho tiempo, no. Hay que acceder a la web, y en la web tenemos el manual de Material design por parte de Google y el Panual de Diseño de Interfaces Humanas de Apple, donde además tanto Google como Apple tienen bastantes vídeos dentro de sus vídeos, en el caso de Android, de Google IO, en el caso de Apple, de la TabDad DC, de la WWBC, donde se nos habla del diseño de aplicaciones.

Diseñar una aplicación no es hacer una aplicación, como muchos diseñadores dicen, que parezca los ajustes del iPhone o los ajustes de Android, no. Hacer una aplicación Puede darnos libertad creativa respetando la experiencia nativa del sistema, respetando su diseño y maximizando el trabajo de los desarrolladores. Algo que yo me encuentro en muchas empresas es que desarrolladores y diseño viven en mundos separados, viven como uno en Finlandia y el otro en Australia, Y se envían las cosas y ni siquiera saben quiénes son los unos y los otros. Parece como si no vivieran en el mismo mundo ni estuvieran en la misma empresa y por lo tanto no tienen en cuenta, no trabajan en común. Lo que no tiene ningún sentido es que yo tengo un desarrollador Que me pueda resolver un problema con un control nativo en horas y, por mi desconocimiento como diseñador, Le obligue a hacer algo que no es nativo, que no aporta nada a la experiencia de usuario, aunque tú creas que sí, Porque se sale de la experiencia nativa del sistema y, por lo tanto, es algo que nadie va a saber cómo funciona de una manera intuitiva, pero lo peor de todo es que vas a hacer que ese desarrollador tarde días o semanas en hacer algo que tal vez hubiera tardado horas.

¿Por qué tú, diseñador, estás haciendo que el programador tenga un coste mayor en tiempo y un coste mayor económico, por tu desconocimiento, porque estás haciendo mal tu trabajo. Lo siento, no pretendo criticar, pretendo ser positivo pretendo hacer una crítica constructiva, y esa crítica constructiva lleva a que si tú como desarrollador Sabes lo que puedes y lo que no puedes hacer, y sabes qué te cuesta más y qué te cuesta menos, puedes hablar con la gente de diseño, la La gente de diseño puede hablar contigo para que la gente de diseño conozca los componentes nativos y los aproveche, porque usar un componente nativo supone un trabajo mucho más sencillo, mucho más simple, mucho más atado al sistema Y, sobre todo, libre de de de posibles problemas en el futuro, porque si tú creas un control que es demasiado personalizado, que retuerce demasiado el framework de desarrollo, cuando Apple saquen una nueva versión, hay una muy alta probabilidad que ese control personalizado deje de funcionar como debería o presente problemas secundarios, problemas derivados, cosas que habrá que cambiar tarde o temprano. Por lo tanto, tenemos que intentar que desarrollo y diseño vayan de la mano, que cada uno entienda el trabajo del otro, que la gente de desarrollo entienda lo que hacen en diseño y lo respete, y que la gente de diseño entienda y respete lo que haga la gente de desarrollo, y que trabajen en una piña Para mejorar la aplicación y la experiencia, e igual que para desarrollar, tienen que estudiar UIKit, Jet Pack Compose, XML, Kotlin, SWIFT UI, lo que sea, dependiendo de el tipo de Herramienta, tú no pondrías a una persona a desarrollar, no deberías poner a una persona a desarrollar si no conoce las herramientas que necesita para desarrollar y los frameworks.

Entonces, ¿por qué pones a alguien a a diseñar sin conocer cómo se diseña para ese sistema? Es que es así de sencillo de entender. Y luego entramos dentro de otros elementos aparte. Por ejemplo, librerías de terceros, ¿sí o no? Mi respuesta es clara, no, nunca, jamás.

No hay nada, sobre todo en iOS, En Android es cierto que hay ciertas cosas que no podemos hacer sin librerías porque Android está pensado para funcionar sobre dependencias. Por lo tanto, incluso un reproductor de vídeo necesita una dependencia externa, ¿vale? Porque no están cargadas por defecto. Pero si hablamos específicamente de iPhone, iPad de iOS en este sentido, de desarrollo en entornos Apple, Apple nos proporciona todo lo que necesitamos, no necesitamos ni una sola librería, para poder resolver nuestro problema, porque esas librerías son problemas, esas librerías es código que no está hecho por nosotros, esas librerías, En realidad, van a enfangar nuestro desarrollo, lo van a hacer menos eficiente. Esas librerías nos van a obligar a depender de un ciclo de actualización y corrección de errores, o nos van a condenar a posibles problemas de rendimiento o malas prácticas que ni siquiera sabemos que tienen, O acostumbrarnos a trabajar en base a una forma de trabajo, en base a unas arquitecturas, en base a unas Formas de organizar el código a unas formas de usar ciertos patrones, paradigmas, etcétera, que probablemente sean mucho más ineficientes, como puede ser trabajar, por ejemplo, con Álamo Faller, que te obliga a ciertas concesiones que te impiden trabajar con formas mucho más prácticas de trabajo como as inawait, como codable, etcétera.

Por lo tanto, no tiene ningún sentido que usemos este tipo de librerías u otras librerías hechas por ciertas personas. Eso quiere decir que las librerías no deberían existir, no, las librerías son una buena solución, pero lo son para que si yo no sé hacer algo, y es lo que yo hago, Si yo no sé hacer algo, tengo dos opciones, o busco información y aprendo, o voy y busco una buena librería, veo cómo está hecha Y replico yo esa funcionalidad directamente. Y algunos dirán, bueno, es que muchas veces no hay tiempo para hacer esto y tenemos que Depender de esas librerías, pues mal, mal hecho, mal hecho, porque entonces eso te va a repercutir un problema a la larga en el depender de código que no es tuyo, código que no controlas. Sí sé que hay lenguajes, como acabo de decir, por ejemplo, con Android por ejemplo JavaScript. JavaScript es un lenguaje que no tiene prácticamente nada, por lo tanto tienes que tirar de un montón de dependencias, pero el problema es convertirte de un programador que sabe cómo funciona su código y sabe cómo mantenerlo a un montador de muebles de IKEA, que piensa que es interiorista o carpintero y lo único que sabe es seguir unas instrucciones para montar un mueble siguiendo lo que otros han dicho antes.

No, montar muebles de IKEA no te hace interiorista, ni te hace carpintero, ni te hace experto en muebles. Te hace ser una persona que sabe seguir reglas sin saber por qué, Igual que montar un set de Lego, ¿vale? No te hace ser un buen constructor montar un set de Lego porque solo estás siguiendo instrucciones. Eso es usar librerías de terceros. En la medida de lo posible, obviamente, una librería de terceros no es Firebase.

Montarse toda la implementación para usar Firebase es de locos, para eso está el framework, pero eso no es una librería de terceros, eso es algo que te incorpora una funcionalidad que, de otra manera, ¿vale? Pues, obviamente, tú no podrías hacer por ti mismo, sería inasumible. No podemos confundir términos, ¿de acuerdo? Pero de ahí a bajar librerías que te gestionan el flujo de red cuando ya se maneja perfectamente con la XynAwait. Bajar librerías que te facilitan el trabajo con la cartera de certificados o con user default, cuando ya de por sí es sumamente fácil hacerlo en nativo, Es decir, no usar librerías al tuntún, intentar ver, aprender y conseguir cómo funcionan las cosas de manera nativa.

Y por último, también, obviamente, para mí lo más importante es el desarrollo nativo, el desarrollo con las librerías nativas, el desarrollo con las librerías, no solo nativas, sino las que fabrica, las que hace el fabricante, las que hace el creador del sistema operativo. Usar Reagnatic, Dadif, Aionic, usar Flatter, usar No, no es la solución, nunca vas a conseguir que se pegue a la experiencia del sistema, que funcione de una manera nativa correcta Y además tampoco vas a tener un co de base para todos los sistemas, es mentira, porque Android y iOS están separando desde hace muchos años, tanto que al final tienes que tener la versión de código común, la versión con las adaptaciones para iPhone y la versión para las adaptaciones para Android. No es la solución, estás atado de pies y manos, y no puedes poner de una manera simple todo lo nuevo que los nuevos sistemas van incorporando. Que es cierto que en ocasiones no hay presupuesto y entonces no puedo pagar dos desarrollos y no tengo otra manera, etcétera. Bueno, pues la solución menos mala en ese respecto, según mis últimas investigaciones, efectivamente, es Flutter, pero Si hacemos un presupuesto real, podremos averiguar que la diferencia no es tanta y que hacer las aplicaciones nativas va a dar mucha más calidad, sobre todo, y con esto termino, cuando el Eje de mi negocio, que esto es algo que jamás entenderé, cuando alguien quiere hacer un negocio y ese negocio pivota alrededor de una página web y de unas apps, y gasta lo mínimo en ellas.

Pero vamos a ver, no lo entiendo. Si el eje de tu aplicación son las apps, tendrías que gastar lo máximo en ellas. No tiene ningún sentido que no gastes el dinero necesario y el tiempo necesario por querer salir lo más rápido posible y hagas un producto mediocre. No lo sé, no lo entiendo, es como decir, no, no, voy a montar un restaurante, pero solo voy a dar platos malos hechos en microondas, que no sepan bien, que a la gente no le gusten, pero bueno, yo abro el restaurante. Hombre, no, tendrás que dar servicio que a la gente le guste para que vuelva de nuevo, ¿no?

No lo sé, llamadme loco, en fin. Entonces, creo que en este sentido hay Mucha carencia de formación, hay mucha carencia de conocimiento, hay mucha falta de interés, hay mucho Personas, que es algo muy común hoy día en nuestra sociedad, tomando decisiones sobre cosas que no comprenden, conocen o saben, Y eso, obviamente, es un problema, porque al final lo que sale es algo mediocre, y no hay más que echarle el vistazo, un vistazo a la App Store o Google Play Store, La comunidad de podcast independientes en español. Hola, para darnos cuenta que apenas ni un dos por ciento de lo que hay ahí es realmente reseñable, es realmente notable. Todo lo demás son productos mediocres, y esto podría solucionarse de una manera muy sencilla, pues, siendo coherentes y entendiendo lo que se tiene que hacer. Vamos, digo yo, llamadme loco, a lo mejor estoy totalmente equivocado, pero bueno, en fin, es mi opinión.

Disculpe, señor Ramírez, tienes un momento.

Sí, claro. Pasa, pasa, pasa, cierra. ¿En qué puedo ayudarte?

Vara, Es que ella lleva unos años en esta empresa, pero sigo siendo Junior y me preguntaba, ¿cuándo seré serio?

A ver, Paco, ¿cómo te explico? Esto es un millón. Sesenio, en esta empresa, es un sentimiento, Es algo que se arraiga en el alma y en tu forma de sentir la vida. No seas suerdo, ¿no?

No será.

Es tener conocimiento para volar más harto. ¿Cómo huelo más alto? Bajito Oridón, tú tienes estudio. Sabes que debes conocer, pases serio. Anda, a ver aquí, tomate, estúdiate.

Mira. Yuaiki. Soy el Yua. T del del. Esto de servidores que no sé qué pone, vapos de agua o algo así, no sé qué, esto también.

Arquitectura, esto es muy importante por aquí, muy importante. Seguridad, que no tenemos lío, ¿ah? ¿Y tú sabes qué es eso de la realidad Armentados. Sí, eso de los

Pokémon, ¿no? Que los cazaba en la calle, ¿no?

Muy bien. Pues, vale, también el Vice un pro, que no va a venir bien para proyecto Sí, sí, vale, vale, ven, arreando. Ah, ven ahí. Ay, dios mío, estos niños que hay que llevarlos de la manita, y es que no me crecen, y no me crecen. Ay, Qué disgusto.

No, esta no es la empresa ideal, ¿verdad? Pero al menos el señor Ramírez tenía razón en algo, aunque sea de casualidad. El conocimiento es lo que te abrirá las puertas para mejorar en tu carrera profesional, conocimiento y experiencia. ¿Quieres avanzar en tu carrera profesional apostando por el desarrollo móvil en entornos Apple? En Apple Coding Academy tenemos lo que estás buscando.

Presentamos la cuarta edición de nuestro Swift full stack bootcamp. Un bootcamp diseñado para convertir a cualquier desarrollador, Sea cual sea la tecnología o lenguaje donde trabaje, en un senior iOS Developer con conocimiento en todo lo que en cualquier empresa o consultora piden, o lo que necesitas para montarte por tu cuenta si quieres trabajar por ti mismo. En el Swift Four Stav Bootcamp encontrarás Swift Como elemento común a todo el desarrollo y la formación, a partir de ahí aprenderás concurrencia de procesos, asincronía, arquitectura de proyectos, que ninguna combinación, sea cual sea, se te resista. Todo ello, por supuesto, aprendiendo UIKID y Swip UI al completo. Cómo aplicar test y una aproximación basada en TTD cien por cien, seguridad, desarrollo del lado servidor, machine learning y, por supuesto, Todo un módulo dedicado al próximo paso en el desarrollo en entornos Apple, Apple Vision Pro y Vision OS.

Un bootcamp único pensado tanto para desarrolladores en otras tecnologías, junior o senior, que quieran reinventarse y dar un cambio en sus vidas Hacia el muy demandado sector del desarrollo en entornos Apple o para aquellos desarrolladores que ya trabajen con Apple, pero quieran especializarse Y cubrir todas las lagunas que puedan llegar a tener o ponerse al día con las últimas novedades y actualizaciones Para iOS diecisiete y el resto de sistemas lanzados por Apple en el año dos mil veintitrés. Tienes toda la información en nuestra web, acoding punto Academy barra bootcamp, y descubre las distintas formas de financiación hasta en treinta y seis meses o, incluso, en doce meses sin intereses. Nunca has sido más fácil apostar por invertir en ti mismo para llegar más lejos. Da el paso y apuesta por tu formación, apuesta por ti, por ese senior ios developer que llevas dentro y que encontrarás en el Swift full stack bootcamp De Apple

Coding Academy.

Y poco más. Quería, bueno, pues dar esta pequeña reflexión al respecto de cómo yo lo veo. ¿Que no lo ves así? Bueno, pues te espero leer en los comentarios, siempre con respeto, amor y y palabras bonitas, ¿vale? Y me encantará oír tu opinión al respecto, como digo, ponla abajo en los comentarios si estás en YouTube, o si no, pues a través de redes sociales puedes mencionarlos a mí personalmente como arroba JCF Munoz, y estaré encantado de, siempre que vaya con respeto, amor y cariño, puedes contestar y debatir sobre cualquiera de estos temas con cualquier persona de bien.

Si no es tu caso, pues nada, pues simplemente, pues no te haré caso y punto, así de simple. En fin, Debatir, podemos debatir siempre de buenas maneras. Así que, lo dicho, poco más, muchísimas gracias. Como le digo, si les ha gustado, denos un like, suscríbanse, compartan el

AppleCore. Apple Code. Puedes escuchar más episodios de Apple Coding en Wanda punto com, la comunidad de podcast independientes en español.