Estudio Ingeniería en Tecnologías Computacionales en el Tec de Monterrey y soy estudiante de la Apple Developer Academy en Nápoles, Italia. Con ese perfil podrías pensar que tengo un sólido dominio de Swift y SwiftUI y la verdad es que no. No considero tener un dominio extraordinario de ninguna de las dos.
Y sin embargo, en febrero de 2026 entregué una aplicación funcional para el Swift Student Challenge de Apple: iDeary, un espacio para capturar, conectar y visualizar ideas como en un mapa mental inspirado en los grafos.
Este blog no es un tutorial técnico. Es la documentación honesta de mi proceso: desde no tener una sola idea clara hasta entregar la app en una amanecida de 24 horas. Lo escribo porque creo que el proceso importa tanto como el resultado, y porque me gustaría que le sirviera como referencia a cualquiera que esté pensando en participar.
¿Qué es el Swift Student Challenge?
Si no estás familiarizado: el Swift Student Challenge (SSC) es una convocatoria anual de Apple dirigida a estudiantes de todo el mundo. El reto consiste en desarrollar una app que demuestre creatividad, habilidad técnica y una experiencia significativa, todo evaluable en aproximadamente tres minutos. Los ganadores reciben reconocimiento de Apple, merch exclusivo, y en algunos casos una invitación a la WWDC.
En el SSC 2026 el entregable era una app de iOS o iPadOS empaquetada como Swift Playground App (formato .swiftpm). Además de la app en sí, hay que responder una serie de preguntas escritas donde explicas qué construiste, por qué y qué aprendiste. Esa parte escrita importa tanto como la app: es tu voz detrás del código.
El inicio: una meta en el aeropuerto
Todo comenzó a finales de 2025. En la Academy nos hablaron del SSC, uno de los mentores nos invitó a participar. Nos dejaron claro que por las reglas del challenge no podrían darnos feedback extenso como en otros proyectos, pero la motivación estaba ahí.
El 5 de enero de 2026, en la sala de espera del aeropuerto de la Ciudad de México esperando un vuelo a Roma, camino de vuelta a la Apple Academy en Nápoles, escribí mis metas del año en una hoja. Una de ellas: participar en el SSC. Pero con una condición que me puse a mí mismo: no quería participar solo por ganar. Quería hacer algo que de verdad me fuera útil y que disfrutara desarrollar, incluyendo las desveladas y el estrés.
Había visto proyectos de años anteriores y ninguno terminaba de conectar conmigo como referencia. Decidí que mi proyecto tenía que nacer de algo personal.
La primera idea (y por qué la descarté)
Enero se fue entero en la pregunta: ¿qué hago? Ninguna idea me enganchaba por completo. Desarrollé rápido un prototipo de una cámara instantánea pensada para viajes: la idea era capturar recuerdos con notas, no solo fotos que terminas olvidando.
Me gustaba, pero sentía que se parecía demasiado a MoMò, una app que había desarrollado con mi equipo en la Academy. La premisa era similar y no le encontraba una personalidad propia que la diferenciara. Así que la dejé como prototipo y decidí empezar un proceso de ideación desde cero.
La lección aquí fue importante: saber matar una idea a tiempo es tan valioso como tener una buena idea. Mi criterio para descartarla fue que si no podía articularla como algo distinto a lo que ya existía en mi propio portafolio, un juez tampoco podría.
Proceso de ideación: de lluvia de ideas a momento de claridad
Con el deadline encima, me tomé un día entero para hacer una sesión intensiva de brainstorming. La regla: sacar ideas rápido, sin filtro, y al final del día tener máximo tres candidatas.
Hice dos rondas. Primero partí de conceptos que me interesan: mis hobbies, cosas que me frustran, herramientas que uso a diario. Después hice una ronda de “ideas random” para ver si podía conectar conceptos entre sí. Y ahí apareció la palabra: ideario.
Un diario de ideas. La palabra como tal en español no se refería exactamente a lo que yo quería representar, pero el concepto me atrapó: un espacio donde capturar, relacionar y ver tus ideas de manera rápida, sencilla e integrada.
Me puse a repasar todas las veces que había tenido una idea y la perdí por no anotarla en el momento. O las veces que una idea creció cuando la relacioné con otro concepto. Pensé: “esto es justo lo que necesito y de verdad lo quiero construir.” En ese momento supe qué quería desarrollar.
Diseñando iDeary: de círculos a grafos
Captura rápida
La primera funcionalidad que definí fue la captura: tenía que ser inmediata y flexible. Anotar texto, tomar una foto, grabar audio, hacer un dibujo. Que la idea no se escape.
Visualización: la pieza clave
De nada sirve capturar ideas si después no puedes revisitarlas de forma clara. Aquí fue donde más iteré.
Desde el principio supe que quería representar las ideas como círculos. Pensé en la película Intensamente de Pixar y en cómo llega una emoción: de repente y por reacción. Una idea llega igual. Esa analogía me pareció muy buena y orientó todo el diseño visual.
Pero faltaba lo más importante: ¿cómo se relacionan las ideas entre sí? Ahí es donde mi ITC interior conectó con el diseño. Recordé mi clase de Algoritmos y Estructuras de Datos y llegaron a mi mente: los grafos. Cada idea sería un nodo con su información, y los vértices representarían las conexiones entre ellas.
Para alguien técnico, es un grafo. Para alguien no técnico, parece una mezcla entre un mapa mental y una red neuronal. Esa dualidad me convenció de que era la representación correcta.
Del papel a Figma (y rápido al código)
Pasé por Figma lo justo para tener una referencia digital. No te voy a mentir: no era bonito. Pero mi forma de trabajo es que una vez que tengo claro qué quiero hacer y más o menos cómo se vería, prefiero saltar al código lo antes posible. Figma me sirve para pensar, no para pulir.
Empecé con el código para descubrir qué era posible técnicamente y cómo se sentía en la práctica lo que tenía en la cabeza.
Desarrollo: del MVP a la app
Construcción técnica
Toda la app está construida en SwiftUI puro. No usé SpriteKit ni frameworks de físicas: el canvas infinito es una vista SwiftUI con gestos de arrastre (pan) y pellizco (pinch-to-zoom) implementados a mano, con límites de escala entre 0.3× y 3.0×. Cada nodo es una vista que se posiciona mediante un offset calculado en coordenadas del canvas, y las conexiones son trazos dibujados con Path directamente en SwiftUI.
Para la estructura de datos del grafo usé algo simple: dos arrays de structs Codable. Un array de Idea (los nodos) y un array de Connection (los vértices), donde cada Connection guarda los UUID de las dos ideas que conecta. No hay librería de grafos ni nada externo: es el modelo más directo que pude construir, y funciona.
Para la persistencia tampoco usé Core Data ni SwiftData. Serializo todo a JSON y lo guardo en el directorio Documents de la app, con un archivo por mapa de ideas. Sencillo, portable y fácil de debuggear.
Para las funcionalidades multimedia usé los frameworks nativos de Apple:
- AVFoundation para grabación y reproducción de audio.
- PencilKit para los dibujos a mano.
- PhotosUI para seleccionar fotos y videos desde la biblioteca.
- La cámara con
UIImagePickerControllerenvuelto en SwiftUI.
El reto técnico más interesante fue construir el modo de conexión entre ideas. El flujo es: el usuario activa el modo de conexión, toca un primer nodo (que queda “seleccionado”), toca un segundo nodo, y la app crea la conexión mostrando una línea degradada entre ellos. Manejar ese estado de “espera de segundo nodo” de forma reactiva en SwiftUI, propagando los cambios de estado entre vistas sin que todo explotara, fue lo que más iteraciones me costó.
Otra decisión de arquitectura que me alegra haber tomado: separar IdeaStore (el estado de un mapa específico) de MapStore (la lista de todos los mapas). Cada mapa tiene su propio store, lo que hace que agregar, eliminar o cambiar entre mapas sea limpio y sin efectos secundarios raros.
El proceso del día a día
Trabajaba en la app todos los días, no solo por el deadline sino porque me gustaba de verdad. Recuerdo estar en un bus de Nápoles a Milán (11 hrs de trayecto en bus aproximadamente) para sorprender a mi novia por el 14 de febrero, y la mitad del viaje lo dediqué a programar. Me sentía en “la zona”.
La primera iteración de desarrollo fue un MVP muy básico: solo quería saber si la idea que existía en mi cabeza tenía sentido como aplicación. Y aunque era simple, al usarlo me di cuenta de que me resultaba genuinamente útil. También lo probé en la Academy y el recibimiento me motivó a seguir.
Testing y feedback
Cuando la app ya era más que un prototipo, empecé a testearla con toda persona que pudiera. El feedback que incorporaba no era sobre cambiar la idea central, sino sobre mejorar la experiencia: hacer más claro cómo añadir ideas, cómo interactuar con ellas, cómo navegar el mapa.
Lo más recurrente: la gente no entendía de entrada que podía conectar ideas entre sí. Esa funcionalidad no era obvia. Eso me llevó a rediseñar el botón de modo conexión, agregar instrucciones contextuales en pantalla durante el flujo de conexión, y finalmente construir un onboarding que guía al usuario a conectar ideas como parte del tutorial.
Resolviendo la exploración rápida de ideas
Tenía el mapa de ideas, la captura rápida y las conexiones. Pero faltaba algo: ¿cómo explorar rápidamente qué tenías capturado sin tener que navegar todo el grafo? Si no puedes revisitar lo que capturaste de forma ágil, pierde sentido haberlo guardado.
Me imaginé un carrusel, un patrón reconocido en interfaces móviles y web. Investigando, encontré un ejercicio del Apple WWDC ‘23 (“Animate with Springs”, sesión 10159) que implementaba exactamente la experiencia que buscaba.
Repasé el ejercicio, lo adapté a mi app y el resultado fue justo lo que imaginaba. El carrusel pasó por muchas iteraciones de boceto a implementación.
Al final, la navegación por carrusel no fue la funcionalidad más usada de la app, pero es un detalle sutil que mejora la experiencia conforme la usas más. A veces las features más valiosas no son las más visibles.
Últimos detalles antes de la entrega
A pocas horas del deadline, tenía la app funcionando pero me faltaban tres cosas críticas: un onboarding, un ícono y las respuestas a las preguntas del SSC. Tuve que dividir mi atención en paralelo.
El onboarding
El onboarding tenía un doble propósito. Por un lado, guiar a un usuario nuevo para que entendiera cómo funciona la app. Por otro, cumplir con el requerimiento de que la experiencia se pueda vivir en tres minutos. Como me imaginaba que los jueces evalúan muchísimas aplicaciones, decidí usar el onboarding también para explicar el por qué de la app, no solo el cómo.
El flujo guía al usuario a crear una idea, explorar las formas de captura (texto, foto, audio, dibujo), conectar ideas entre sí, desconectarlas y navegar entre ellas. Y arranca con algo que no es tan común en un onboarding: mi historia. Le cuento al usuario por qué construí esto. Quería que desde el primer segundo quedara claro que iDeary nació de un problema real, no de un ejercicio técnico.
Herramientas que me ayudaron
Para el onboarding, usé Claude Code como herramienta de apoyo. Específicamente, lo utilicé para tomar la estructura base de mi código existente y generar el flujo paso a paso del onboarding, que luego personalicé y adapté al contexto de mi app. La lógica de la aplicación, el diseño de la experiencia y las decisiones de producto son mías; Claude Code me ayudó a ejecutar más rápido.
Para el ícono, utilicé Icon Composer de Apple, mientras en paralelo respondía las preguntas del SSC.
La entrega
La entrega se resume en una sesión continua de 24 horas: pulir los últimos detalles, responder preguntas y darle enviar. Tuve la fortuna de estar acompañado por mis amigos y compañeros de la Apple Academy. Nos pusimos a trabajar juntos toda la noche, probábamos las correcciones de nuestras apps entre nosotros, nos dábamos feedback, nos motivamos. Entregamos juntos, cada quien a su hora.
Hacerlo en comunidad no fue un detalle menor. Fue lo que nos ayudó a no distraernos y a sentir que no estábamos solos en el estrés.
Lo que aprendí (y lo que sigue)
No tuve oportunidad de pulir UI, UX ni accesibilidad como me hubiera gustado. Me quedo contento con el resultado final, pero no satisfecho, y creo que esa distinción es importante. Quiero seguir aprendiendo, hacer un refactor del código y, sobre todo, publicar iDeary.
Lo que me mantuvo trabajando no fue solo el SSC como meta. Fue que desde el día uno supe que estaba construyendo algo que yo mismo iba a usar. Y cuando las personas que lo probaron me dijeron que ellos también lo usarían, eso lo cambió todo.
Si pudiera hacer algo diferente, empezaría el diseño de accesibilidad desde el día uno, no como un checkbox de último minuto. VoiceOver, Dynamic Type, contrastes de color, o cualquiera que se le adapte mejor a iDeary por su naturaleza. Pensar en esto desde el principio cambia la forma en que diseñas: no son detalles que añades al final, sino decisiones que moldean todo lo demás.
También dedicaría más tiempo al testing con personas que no me conocen, porque el feedback de alguien que no sabe nada de la app es el más valioso y el más difícil de conseguir.
Si estás pensando en aplicar al SSC, te diría: elige una idea que tú mismo quieras usar. Algo que mueva algo en ti y que te dé ganas de seguir aprendiendo y construyendo, porque se vienen noches de estrés y desvelo. Pero hacer algo porque tú lo quieres y te es útil tiene un valor que se nota. Enamórate de tu idea y del proceso. Y una cosa más, práctica: empieza antes de sentirte listo. El prototipo más feo del mundo te va a enseñar más sobre tu idea que cualquier cantidad de tiempo pensando en ella.
Lo que sigue
Los planes para iDeary post-SSC son claros: refactor del código, mejorar la accesibilidad, explorar la sincronización con múltiples dispositivos, y eventualmente publicarla en el App Store. Hay una versión más completa de esta app esperando ser construida.
Resumen técnico de iDeary
Un vistazo rápido para quienes quieran entender el stack y las decisiones técnicas sin leer todo el post.
- Plataforma: iOS (Swift Playground App, formato
.swiftpm) - Lenguaje: Swift
- Framework principal: SwiftUI
- Multimedia: AVFoundation (audio), PencilKit (dibujos), PhotosUI (fotos y videos), UIImagePickerController (cámara)
- Estructura de datos del grafo: Dos arrays de structs
Codable:[Idea](nodos) y[Connection](aristas). Sin librerías externas. - Canvas infinito: Implementado a mano en SwiftUI con gestos de arrastre y pellizco. Escala: 0.3× – 3.0×.
- Persistencia: Serialización JSON al directorio
Documents. Un archivo por mapa. Sin Core Data ni SwiftData. - Animaciones: Spring animations basadas en WWDC '23 sesión 10159. Pulso en nodos con
withAnimation(.easeInOut)en loop. - Arquitectura:
MapStore+IdeaStorepor mapa +AudioManageryMediaManagercomo servicios independientes. - Herramientas externas: Claude Code, Icon Composer (ícono), Figma (wireframes y referencias)
- Líneas de código: ~5,800
- Tiempo total de desarrollo: ~6 semanas (enero–febrero 2026)