La receta para una gran app de iOS 🍳

Ya conoces esa sensación. Una app que abres y que simplemente funciona; no en el sentido de «compila», sino en el de «me entiende». Todo está donde debe estar, nada chirría y, cuando terminas, piensas: «Vaya, qué bien». Y también conoces lo contrario: el botón que tarda en responder, el desplazamiento a trompicones, la ventana emergente de permisos que se te echa al cuello antes incluso de que hayas averiguado para qué sirve la app. Entre ambos extremos hay todo un mundo. Y lo que marca la diferencia casi nunca es una ~~función~~ capacidad mágica. Es una receta.

Publico apps desde los primeros tiempos de la App Store, allá por 2008. He lanzado unas 40 apps, con cientos de millones de descargas acumuladas, y he asistido a unas 15 WWDC. Y la pregunta que más me hacen no ha cambiado lo más mínimo: ¿Qué hace que una app sea excelente, en lugar de simplemente funcional? Estoy escribiendo esto sobre la marcha, todavía algo aturdido, desde el otro lado del mundo: estuve en Apple Park para la WWDC26 y, a mi regreso, di una charla junto con Claire. La charla se titulaba La receta para crear una gran app de iOS. Esta es la versión larga —la receta completa—, la que nunca tenemos tiempo de explicar íntegramente sobre el escenario.

¿Por qué una receta?

Dos personas con los mismos huevos no cocinan el mismo plato. Así de sencillo. En el desarrollo para iOS, todo el mundo tiene los mismos huevos: Swift, SwiftUI, Xcode, todo gratis; cientos de sesiones de la WWDC disponibles públicamente; tutoriales paso a paso; y las Human Interface Guidelines, la biblia del diseño de Apple, a un solo clic. Nadie tiene un ingrediente secreto escondido en la nevera. Lo que distingue a una gran app es cómo combinas todo eso. Y aquí viene la buena noticia: se puede aprender.

Apple lo demuestra cada año. En 2026, de entre más de dos millones de apps, solo 12 ganaron un Apple Design Award, elegidas entre 36 finalistas de seis categorías. El listón está alto. Pero fíjate en quiénes lo superan: un estudio de dos personas de los Países Bajos junto a un equipo que lleva diez años perfeccionando su producto; un desarrollador independiente de la India junto a CD Projekt Red. El mensaje de Apple es claro: el diseño no depende del presupuesto, del tamaño del equipo ni del público. Depende del cuidado.

Y lo curioso es que ya utilizas estas apps. Lo que aún no sabes es por qué funcionan. Conoceremos unas cuantas por el camino, no para presumir de nombres, sino porque cada una encarna una idea concreta mejor de lo que podría hacerlo un párrafo.

Diseña con intención: el propósito antes que el código

En la WWDC26, Apple publicó una nueva sesión fundamental, Principles of great design (sesión 250, diecisiete minutos; mírala dos veces). Expone ocho principios: Propósito, Autonomía, Responsabilidad, Familiaridad, Flexibilidad, Simplicidad, Oficio y Deleite. Y Apple insiste en algo que a los principiantes no les gusta oír: no hay ninguna fórmula. «Depende de ti aplicar tus conocimientos y tu intuición». Potenciar un principio puede perjudicar a otro. Tomar esa decisión: en eso consiste el oficio. Estos ocho principios no son una receta que debas seguir al pie de la letra. Son tus ingredientes. Tú cocinas.

En el escenario, Claire se ocupó de cuatro y yo de los otros cuatro. Aquí te presentaré los ocho, en el orden de la receta y no en el de las diapositivas. Y todo empieza por el más ingrato, el que todo el mundo se salta: el Propósito. La mise en place. En una cocina, consiste en prepararlo todo antes de encender los fogones. En diseño, consiste en hacerte la única pregunta que importa antes de escribir una sola línea de código: ¿lo que estoy creando tiene un propósito real? Si no está perfectamente definido, aún no está listo.

Mi primer testigo es grug, ganador de un Apple Design Award de 2026 (Deleite y diversión), creado por el estudio neerlandés Ocho, formado por dos personas, Jip van der Velde y Michel Elings, que trabajan juntos desde 2012. grug es una idea: una sola afirmación al día, expresada con gruñidos neolíticos. «solo grug que camina encuentra avance… grug sentado no encuentra nada». Sin inicio de sesión, sin nube, sin funciones sociales. Su fuerza no reside en lo que ambos tenían talento para añadir, sino en todo lo que tuvieron el valor de no añadir. (Incluso crearon un motor de tipografía dibujada a mano y una barra de estado personalizada; merece la pena leer su sesión de preguntas y respuestas en el sitio web de Apple). Omitir cuenta tanto como añadir. Elegir lo que creas implica decidir qué dejas fuera.

Entonces, ¿cómo encuentras ese propósito? Lo escribes en una frase: [qué hace] para [quién], en [qué momento de su vida]. Si tu frase necesita una «y», quizá tengas entre manos dos apps, no una. Después, haces una lista de todo lo que podrías crear y eliminas cualquier cosa que no contribuya a esa frase. Cada función que sobreviva tiene que «pagarse el alquiler»: ¿merece el tiempo, la atención y la confianza que exige? Porque ese es el coste real de una función: no las horas de desarrollo, sino tres recursos escasos que le estás quitando al usuario. La trampa del principiante es añadir algo porque puede hacerlo («bah, son dos horas de trabajo»). Cada añadido diluye el propósito. Defender el propósito implica decir que no, a menudo. La prueba definitiva: enséñales tu frase a tres personas. Si no pueden adivinar qué hace la app, tu propósito no está lo bastante definido. «Planificador diario visual para cerebros neurodivergentes». «Sabiduría diaria en gruñidos neolíticos, sin necesidad de cuenta». Si no puedes hacerlo, vuelve a la cocina.

Con el control y con derecho a equivocarse

El segundo principio, la Autonomía, consiste en permitir que las personas actúen a su manera. Una interfaz nunca debería interponerse en lo que alguien intenta hacer. Deja que se lancen, que exploren a su ritmo, que se salten la introducción si quieren y que reorganicen la interfaz como mejor les parezca. Tú orientas; no obligas a nadie a seguir un camino prefijado. Más control significa más implicación: no es un eslogan, es pura mecánica.

Mi testigo aquí es Tiimo, nombrada app del año para iPhone en los App Store Awards de 2025 (y ya finalista de los Apple Design Awards en 2024). Es un planificador visual que devuelve a los cerebros neurodivergentes el control de su tiempo. El equipo está en Copenhague, más de un millón de personas utilizan la app y —un detalle que no es menor— está 100 % libre de publicidad, para siempre. Tiimo se diseñó con las personas a las que sirve, no solo para ellas. Eso es dar autonomía: no decidir en nombre de los demás.

El corolario de la capacidad de acción es el perdón. La gente envía, edita y elimina cosas por accidente constantemente. Tu trabajo consiste en hacer que todo ello sea reversible. Apple propone una jerarquía clara para gestionar las acciones arriesgadas, de mejor a peor. Primero, Deshacer, de forma predeterminada: todo debe ser reversible, para que el usuario se atreva y luego pueda echarse atrás. Después, Confirmar, solo cuando deshacer sea imposible (una eliminación permanente, un envío irreversible). Interrumpir como último recurso, para evitar un verdadero desastre. El error clásico de principiante es pedir confirmación para todo: después de suficientes avisos de «¿Seguro?», el usuario hace clic en «Sí» sin leer y la advertencia deja de protegerle. En el código, esto se reduce a tres cosas que debes conocer a la perfección: un UndoManager, un confirmationDialog y el rol .destructive en tus botones sensibles. Esa red de seguridad no ralentiza al usuario: le da la confianza necesaria para explorar tu app. Y, por tanto, para adoptarla.

En beneficio de las personas y con una IA responsable

El tercer principio, la Responsabilidad, comienza con la privacidad. Apple utiliza una metáfora que me encanta: imagina que un desconocido se acerca a ti y te dice «dame tu número de teléfono», sin explicar por qué. No confiarías en esa persona ni un segundo. Y, sin embargo, miles de apps hacen exactamente eso: muestran la ventana emergente de permisos al iniciarse, antes de que hayas entendido para qué sirve la app. Una interfaz responsable espera al momento adecuado, pide únicamente lo estrictamente necesario y explica por qué.

El ejemplo perfecto es Be My Eyes, ganadora del premio al Impacto Cultural en los App Store Awards de 2025. La app, lanzada en 2015 por Hans Jørgen Wiberg —que empezó a perder la vista a los 25 años—, conecta a personas ciegas o con baja visión con voluntarios videntes y, más recientemente, con una IA, Be My AI. Y este es el detalle que lo cambia todo: el acceso a la cámara se activa solo cuando el usuario solicita ayuda visual, nunca al abrir la app. Be My AI se desarrolló conjuntamente con miles de personas ciegas o con baja visión que participaron en las pruebas. La IA complementa al ser humano; no lo sustituye. Ese es el modelo.

Y tenemos que hablar de la IA, porque en 2026 está en todas partes. iOS 27 —anunciado en esta WWDC, la última presentación de Tim Cook como CEO— lleva Siri, Apple Intelligence y los Foundation Models ejecutados en el dispositivo a todos los rincones del sistema. Esos modelos se ejecutan en el dispositivo, de forma gratuita y sin enviar tus datos a ningún sitio. Es una oportunidad enorme para quienes desarrollamos. Pero cuanta más inteligencia añades, mayor es la responsabilidad. El ejemplo de Apple es deliberadamente cotidiano, y precisamente por eso resulta tan eficaz: una app de recetas. El usuario ha indicado que tiene una alergia. El modelo, por su cuenta, sugiere un plato que contiene el alérgeno. No es un fallo estético: es un peligro real. La lección es que un modelo puede generar resultados inesperados, erróneos o perjudiciales. Anticipa lo peor y añade después medidas de protección (vistas previas, confirmaciones, avisos legales), o elimina por completo la función si el riesgo supera su valor. Las medidas de protección se incorporan durante el diseño, no como un parche después del rechazo.

Hablar el idioma de la plataforma: familiaridad y flexibilidad

Cuarto principio: la Familiaridad. Tu público llega con toda una vida de experiencia: la del mundo real, además de las convenciones de todas las demás apps que utiliza. Aprovéchala. La papelera = eliminar (y recuperar); si reutilizas ese icono para otra cosa, destruyes al instante su reconocimiento. Las cosas que se parecen deben comportarse de forma parecida. En un Mac, las ventanas siempre se cierran desde la esquina superior izquierda: el usuario no debería tener que pensar. Para las acciones habituales, no reinventes la rueda: utiliza primero los componentes del sistema. La expresión de esa familiaridad en 2026 es Liquid Glass, el material presentado en WWDC25 y ahora omnipresente en iOS 26. En el código, se reduce a .glassEffect(), GlassEffectContainer y .buttonStyle(.glass). Una trampa que puede hacerte perder una tarde: un elemento antecesor con .clipped() o .mask() rompe el efecto sin mostrar ningún aviso. Da prioridad a los componentes del sistema antes de esparcir cristal personalizado por todas partes. (Los ejemplos oficiales de Apple de este año son Moonlitt y Tide Guide, por si quieres ver cómo se hace bien).

Después está la Flexibilidad: las personas utilizan tu diseño de formas tan únicas como ellas mismas. El ejemplo de Apple es la música: en casa con altavoces, corriendo con unos AirPods y un Watch, o en el coche con las manos libres; la misma app, tres experiencias. La forma más concreta de materializar la flexibilidad en 2026 es salir de tu propia pantalla. Expones las acciones de tu app al sistema mediante App Intents y, de repente, esta cobra vida en Siri, Spotlight, Shortcuts, los widgets, el Centro de control y Apple Intelligence, sin que nadie abra la app. Eso supone descubrimiento y retención a la vez. Para una app nueva, elige una o dos acciones clave («añadir una tarea», «iniciar un temporizador»), asígnales un App Intent y conéctalas después con Apple Intelligence mediante Assistant Schemas. John Geleynse, todo un veterano, ya llamaba a esto «Connected» en la época de iOS 5: tu app debe ir más allá de su propia ventana. La versión de esa idea en 2026 es App Intents.

Las herramientas adecuadas: Swift, SwiftUI y Xcode

Ya tenemos presentes la intención, el propósito y los principios. Es hora de pasar a los utensilios. Y aquí viene la parte tranquilizadora: basta con tres para empezar, y todos son gratuitos. Nada de React Native, Flutter ni backend desde el primer día. Primero, Swift: un lenguaje seguro (los opcionales y el tipado estricto eliminan categorías enteras de errores antes incluso de que se inicie la app), accesible y rápido. No tienes que dominarlo por completo; los genéricos, los actores y la concurrencia vendrán después. Solo necesitas saber lo suficiente para seguir avanzando.

Después, SwiftUI: un framework declarativo en el que describes qué debe hacer la interfaz, no cómo dibujarla. Menos código y una única base para iPhone, iPad, Mac, Watch y Vision Pro. La prueba viviente es Moonlitt, ganadora del Apple Design Award 2026 en la categoría de Interacción, creada íntegramente en SwiftUI por el estudio italiano Flipping Hues (tres desarrolladores que se conocieron en la Apple Developer Academy de Nápoles). Fases lunares, planificación fotográfica, incorporación en unos pocos toques y una integración de Liquid Glass que el jurado calificó como «la mejor de su categoría». Un poco de magia de 2025–26: recompila con el SDK de iOS 26 y la app adoptará Liquid Glass automáticamente. No hace falta reescribirlo todo, pero realiza de todos modos una revisión visual, porque «automático» no significa «perfecto».

La tercera herramienta es Xcode, el taller completo: editor, simulador, depurador, pruebas y distribución. La combinación de SwiftUI + Previews lo cambia todo cuando estás empezando: ves el efecto de cada línea al instante, sin tener que recompilarlo todo. Añade un #Preview a cada vista que no sea trivial hasta que se convierta en un acto reflejo. Y, sobre todo: no se aprende a cocinar leyendo recetas. Apple ofrece itinerarios guiados gratuitos — completa Scrumdinger de principio a fin, la aplicación de ejemplo que abarca listas, navegación, persistencia y accesibilidad. Aprenderás más con una aplicación terminada que con cien vídeos vistos a 2×.

La base — arquitectura y datos

Un plato sin estructura se viene abajo. Antes de pensar en el acabado, establece unos cimientos sólidos. Una aplicación es una conversación entre tres elementos: las vistas, los datos (la verdad) y la navegación. Hacerlo bien desde el principio evita que tengas que reescribirlo todo tres meses después. La trampa para principiantes son los datos que se contradicen de una pantalla a otra. La regla de SwiftUI: una única fuente de verdad (@State, @Observable, @Bindable), con enlaces que mantienen sincronizado todo lo demás. Para conservar los datos entre ejecuciones, SwiftData es más que suficiente para una v1: comparte la filosofía de SwiftUI y ofrece más potencia y menos código que Core Data.

Y luego está la enfermedad que veo por todas partes: lees diez siglas de arquitectura (MVVM, TCA, VIPER… ~~y otros conjuros que provocan ansiedad~~) y te quedas paralizado antes de escribir una sola vista. Para. No te compliques, sigue la filosofía de la plataforma y refactoriza solo cuando aparezcan los problemas. Recuerda: grug son dos tipos sin un blog sobre arquitectura. Tiimo es el resultado de diez años de iteración antes de conseguir el título de App of the Year. Una aplicación imperfecta que existe siempre será mejor que una arquitectura perfecta que nunca se termina.

El aderezo — lo que distingue lo bueno de lo excelente

El plato está cocinado. Es hora de cuidar los detalles: invisibles por separado, pero que se perciben en conjunto. Esto es Craft: «la atención al detalle que demuestra a la gente que de verdad te importa su experiencia». Un producto descuidado se nota: una puerta que se tambalea, una camisa que se descose. Un botón que responde con retraso, un desplazamiento a trompicones, iconos desalineados, un diseño que se rompe al girar el dispositivo: todo parece frágil y empiezas a dudar de la calidad de todo lo demás. El cuidado artesanal, por el contrario, inspira confianza. Sus «materiales» son una tipografía nítida en cada pantalla, colores que se adaptan a los modos claro y oscuro y animaciones fluidas que responden a tu dedo, todo ello sobre SDK fiables. Mi testigo aquí es (Not Boring) Camera, finalista de los ADA de 2026 (Visuals & Graphics): el sello del estudio es su obsesión por los materiales — una interfaz 3D, iluminación dinámica, respuesta háptica y un sonido tan realistas que jurarías estar sosteniendo una cámara de cine.

La prima hermana de Craft es la Simplicity — y cuidado con el malentendido: simple ≠ minimalista. Esconderlo todo en un único lugar es minimalista, no simple. Simple significa sin fricciones, intuitivo: encuentras lo que buscas sin esfuerzo. Se consigue siendo conciso (lenguaje sencillo, menos pasos) y claro (una jerarquía sólida: orden, espaciado y contraste, para que lo más importante sea lo más evidente). A veces, simplificar significa incluso añadir contexto en el lugar adecuado — por ejemplo, mostrar el tiempo restante en un botón de reproducción/pausa. El testigo perfecto es Tide Guide, ganadora de un Apple Design Award de 2026 (Visuals & Graphics) del estudio estadounidense Condor Digital. El tema es totalmente cotidiano — las mareas —, pero la ejecución es excepcional: datos complejos hora a hora condensados en un único gráfico que se entiende de un vistazo, con una paleta que coincide con el color del cielo a lo largo del día. Un tema cotidiano, un cuidado obsesivo. De eso se trata.

El aderezo también implica accesibilidad — y voy a ser tajante: no es un lujo, significa más usuarios y una aplicación mejor para todos. VoiceOver, Dynamic Type, contraste suficiente y áreas táctiles de al menos 44×44 puntos. Be My Eyes y Tiimo la convirtieron en un pilar desde el principio; en el ámbito televisivo, HBO Max incluso obtuvo el título de Apple TV App of the Year de 2025 tras añadir la lengua de signos estadounidense. Y desde iOS 26 hay Accessibility Nutrition Labels en la página de la App Store: nueve funciones que se pueden declarar (VoiceOver, Voice Control, Larger Text, Dark Interface, Differentiate Without Color, Sufficient Contrast, Reduced Motion, Captions y Audio Descriptions). Hoy es voluntario, pero acabará siendo obligatorio, así que adelántate. Una regla de oro: sé honesto. Todas las tareas habituales de la aplicación deben poder realizarse con cada función que declares. De lo contrario, no la declares. (La sesión de WWDC25 «Evaluate your app for Accessibility Nutrition Labels» explica el método paso a paso).

Y ya que hablamos de cuidado artesanal, hablemos de rendimiento, porque en junio de 2026 la señal de Apple es inequívoca. iOS 27 es lo que la prensa bautizó de inmediato como una versión «Snow Leopard» — un guiño al famoso Zero New Features de 2009. Sin fuegos artificiales, pero Apple publicó una lista de más de cuarenta optimizaciones muy reales: las aplicaciones se abren hasta un 30 % más rápido, las fotos aparecen un 70 % más rápido después de capturarlas, AirDrop es un 80 % más rápido y se ha reescrito el planificador de la CPU, lo que beneficia a toda la gama, hasta el iPhone 11. Para ti, la conclusión es brutal: una aplicación que parezca lenta se verá aún más penalizada por contraste. Animaciones fluidas, inicio rápido, cero bloqueos al desplazarse — y haz pruebas en dispositivos reales, idealmente un iPhone 11 o 12, no solo en el simulador del último modelo. Por último, el cuidado artesanal implica longevidad: cuando lleguen nuevas funciones o nuevo hardware, evoluciona con ellos y la gente se sentirá respaldada. «El diseño nunca está realmente terminado» — no es una cita de ~~Pinterest~~, sino la realidad de todas las App of the Year.

Emplatado y servicio — probar y publicar

Un gran plato no se sirve en un plato sucio. Antes de la App Store está TestFlight: hasta 100 probadores internos (los miembros de tu equipo de App Store Connect) y 10.000 probadores externos mediante un enlace público o correo electrónico. La primera compilación externa pasa por una Beta App Review — una cola independiente de la de la App Store, que suele tardar unas horas, aunque a veces más. Los comentarios, las capturas de pantalla y los fallos llegan directamente a App Store Connect. Y lo repetiré porque nadie lo hace: prueba en dispositivos reales. El simulador no reproduce ni el rendimiento, ni la batería, ni los permisos reales.

La segunda cosa que la gente infravalora: la página de la App Store forma parte de la app. El icono, las capturas de pantalla, la descripción, la etiqueta de información nutricional sobre privacidad, la etiqueta de información nutricional sobre accesibilidad… todo debe reflejar fielmente lo que hace la app. Apple es muy clara al respecto: los metadatos engañosos garantizan el rechazo (directriz 2.3). Las capturas de pantalla deben mostrar la app real, no una interfaz falsa ni un «próximamente». Y, ya que estás, lee las App Review Guidelines desde el principio, no como un muro al final: cinco secciones (seguridad, rendimiento, negocio, diseño y aspectos legales). Si alguna vez añades compras dentro de la app, lee la sección de negocio antes de programarlas, no después. En 2026, Apple afirma que alrededor del 90 % de los envíos se revisan en un plazo de 24 horas, pero eso se cumple sobre todo para las actualizaciones de apps consolidadas. Un primer envío suele tardar entre 2 y 5 días (más en septiembre y diciembre, y más en categorías reguladas: salud, finanzas e infantil). Y trata cada rechazo como un requisito técnico preciso, nunca como un veredicto: pega el texto del rechazo en tus notas y corrige cada punto.

Publicar implica inscribirse en el Apple Developer Program, por 99 $ al año: TestFlight, App Store Connect, certificados, notificaciones push, Sign in with Apple… todo incluido. (Y para programar en tu propio iPhone ni siquiera tienes que pagar: basta con la cuenta gratuita de desarrollador, con un certificado renovable de 7 días. El programa de pago solo es necesario para TestFlight externo y para publicar). Archivas en Xcode, subes la app, la envías en App Store Connect e incluso puedes activar un lanzamiento gradual que la distribuye progresivamente durante siete días. Y, así de fácil, tu plato llega a 175 escaparates de todo el mundo. Piensa pronto en la localización: como mínimo, la descripción y las capturas de pantalla para tus mercados objetivo.

Atrae a los clientes y mantén vivo el plato

Has servido un plato estupendo. Pero un restaurante que nadie puede encontrar no es un gran restaurante. La App Store recibe cientos de millones de visitantes cada semana, y la visibilidad hay que ganársela. El descubrimiento combina ASO y marketing, y cada elemento de tu página influye en las descargas. En cuanto a los campos indexados para búsquedas, dispones de 30 caracteres para el título, 30 para el subtítulo y un campo de palabras clave de 100 caracteres: 160 caracteres de superficie SEO que debes elegir con bisturí. El nombre y el icono causan la primera impresión; la primera línea de la descripción es la más leída (pero no se indexa; sí lo hacen las palabras clave del campo específico). Elige bien la categoría y no atiborres el título de palabras clave si no quieres que te rechacen la app (otra vez la 2.3).

Tres palancas que mucha gente ignora. Custom Product Pages: hasta 70 versiones de tu página, cada una con sus propias capturas de pantalla, texto promocional y una URL única (?ppid=…) para incluir en tus campañas: una página para «padres», otra para «profesionales», otra de temporada; cada una se mide por separado y, desde iOS 18, pueden incluir enlaces profundos a la pantalla adecuada. Product Page Optimization: una prueba A/B nativa de App Store Connect que muestra variantes de tu icono, capturas de pantalla o vista previa de la app a una muestra aleatoria y determina una ganadora con un 90 % de confianza (mide durante al menos dos semanas). Y el trío formado por los enlaces de campaña (para atribuir tus canales en App Analytics), Apple Ads (posicionamiento en la pestaña Today y en los resultados de búsqueda; basta un presupuesto modesto para probar palabras clave) y Featuring Nominations (un formulario de App Store Connect para presentar tu propuesta al equipo editorial de Apple; cuenta la historia humana: Be My Eyes y Tiimo son los modelos a seguir). Empieza con una o dos Custom Product Pages alineadas con tus canales principales; el límite de 70 no es un objetivo.

Y, una vez que publicas, empieza el verdadero trabajo. Una app nunca está «terminada». Escuchas los comentarios (TestFlight, reseñas de la App Store, correo electrónico de soporte), consultas los fallos en Xcode Organizer y publicas actualizaciones periódicas. Lo mides todo en App Analytics: conversión de la página a descarga, retención D1/D7/D30, sesiones y rendimiento de cada Custom Product Page. Respondes a las reseñas, sobre todo a las negativas y, especialmente, a las primeras: la persona que escribió la reseña recibe una notificación y puede subir su valoración. Tiimo tardó diez años en conseguir su título. Be My Eyes lleva iterando desde 2015. grug son dos tipos que llevan iterando desde 2012. Ninguna de estas apps se publicó siendo perfecta. Iteraron.

El ingrediente secreto

Esperabas un ingrediente secreto, ¿verdad? Siempre hay uno. Y este no es un framework, una API ni una sesión de la WWDC. Es el cuidado. La intención puesta en cada paso, desde la primera pantalla hasta el momento en que te atreves a pedir un pago. En realidad, es Craft y Delight combinados; y Delight, ese octavo principio difícil de definir pero reconocible al instante, nunca es confeti añadido al final. Es la suma de toda la consideración volcada en el producto: el resultado natural de aplicar bien todos los demás principios. Identifica la emoción que quieres que sienta la gente (relajación, confianza, entusiasmo) y refuérzala en todas partes. Eso es lo que convierte «funciona» en «me encanta».

Mis cuatro testigos —grug, Be My Eyes, Tiimo y Moonlitt— no comparten ni una sola función. Una afirmación prehistórica, una ayuda visual, un planificador y una app de fases lunares. Pero detrás de todas ellas hay personas a las que de verdad les importaba. Lo único que importa, al final, es lo bien que tu app satisface las necesidades de las personas para las que la estás creando. El resto es técnica. Y la técnica se puede aprender.

Así que el mejor consejo que puedo darte cabe en dos palabras: ven a cocinar. Abre Xcode hoy, elige un tutorial de Apple y crea una app pequeña, aunque sea absurda, aunque sea fea. Una app que puedas describir en una frase, una beta de TestFlight enviada a tres amigos, una página honesta en la App Store. Completa todo el ciclo una vez; aspira a eso, no a la perfección. Es lo que seguimos diciéndonos en cada encuentro de la comunidad ⌘+F, y es la diferencia entre quienes «están a punto de empezar» y quienes publican.

Y si tienes un proyecto excepcional, ponte en contacto conmigo. Innovar es lo que me mueve.

Para ir más allá

En cuanto al diseño, ten a mano las Human Interface Guidelines (gratuitas, en constante evolución y ampliadas con una nueva página de Principios de diseño en la WWDC26) y la sesión Principles of great design. En cuanto al código, Swift, SwiftUI, App Intents y los tutoriales de Apple. Para la distribución, TestFlight, las App Review Guidelines y las Custom Product Pages. Y, para inspirarte, nada supera las páginas de los Apple Design Awards y los App Store Awards 2025, además de las fichas en la tienda de las apps citadas aquí, donde quienes empiezan pueden ver el trabajo de cerca. Gracias a Claire por la mitad de esta receta. Ahora ve a cocinar. 🍳