Generar interfaces de usuario en SwiftUI usando prompts en Cursor te permite acelerar el desarrollo móvil sin perder control sobre la arquitectura. La clave está en trabajar archivo por archivo, validar cada generación en Xcode y no dejar que el agente tome decisiones que rompan tu estructura.
Esta guía te muestra un flujo práctico para crear vistas a partir de imágenes de referencia, integrar modelos del dominio y resolver los errores de referencias que aparecen cuando Cursor no logra interpretar bien un proyecto iOS.
Cómo preparar la estructura de carpetas antes de hacer prompts
Antes de escribir cualquier prompt, conviene tener lista la arquitectura del proyecto en Xcode. Así el agente sabe dónde colocar cada archivo y tú evitas que invente rutas.
La estructura inicial parte de tres capas: presentation, data y domain. Dentro de domain creas la carpeta Models, y dentro de presentation creas ViewModels y Views. Una vez creadas en Xcode, te pasas a Cursor y verificas que la jerarquía se refleje correctamente [03:18].
¿Por qué crear las carpetas en Xcode y no en Cursor? Porque Cursor no está optimizado para proyectos iOS y a veces no resuelve bien las referencias. Xcode garantiza que los archivos queden registrados en el project file.
Cómo escribir el prompt para que Cursor genere las vistas correctas
El prompt debe ser específico, anclado a archivos reales y con referencias visuales claras. Cualquier ambigüedad se traduce en código que tendrás que rechazar después.
El flujo recomendado dentro del chat de Cursor es:
- Selecciona el modo agente para que aplique el código directamente.
- Usa el modelo Claude 4 Sonnet para mejor razonamiento sobre SwiftUI.
- Arrastra la carpeta
@/presentation como contexto de destino.
- Adjunta tu prompt de UI personalizado como guía de generación.
- Sube dos imágenes de referencia: una para
CourseListView y otra para los ítems de la lista.
- Indica que cree el modelo
Course en Models siguiendo tus contratos del dominio.
- Aclara explícitamente que solo genere la feature de listar cursos.
- Adjunta el archivo de arquitectura como contexto adicional.
Esa última aclaración sobre limitar el alcance es la que evita que Cursor empiece a crear módulos que no pediste. Mientras más acotado el prompt, más limpio el resultado.
Por qué adjuntar imágenes y contratos como contexto
Las imágenes le dan al modelo una guía visual concreta de espaciados, jerarquía y componentes. Los contratos del dominio le dicen qué propiedades debe tener el modelo Course para que las vistas se enlacen correctamente con el ViewModel.
Sin esos dos insumos, la salida queda genérica y suele inventar campos que después chocan con tu capa de datos.
Qué hacer cuando Cursor crea referencias duplicadas
Aquí viene lo interesante. Durante la generación, Cursor intenta resolver errores de linting sobre la marcha y termina creando archivos duplicados o queriendo borrar archivos que están bien.
Por ejemplo, en un caso real el agente trató de eliminar el archivo Course recién creado porque no encontraba la referencia, aunque en Xcode estaba perfectamente registrado [05:42]. La respuesta correcta es rechazar ese cambio y detener al agente.
¿Qué hago si Cursor entra en bucle corrigiendo sus propios errores? Detén el agente, revisa archivo por archivo, acepta lo que está bien y rechaza lo demás. Después reinicia Cursor para que recargue las referencias.
El criterio para aceptar o rechazar archivos:
- Acepta el modelo
Course si respeta tus contratos.
- Rechaza vistas que mezclen
View y ViewModel en el mismo archivo.
- Acepta la vista que use el
ViewModel por separado, aunque agregue extras como una barra de búsqueda.
- Acepta el componente de card o ítem si refleja la imagen de referencia.
- Acepta los archivos de Design System generados, ubicándolos en la carpeta de vistas.
Después de aceptar, ejecuta un build without run desde Xcode para validar que todas las referencias compilen.
Cómo resolver los errores de referencias que solo aparecen en Cursor
Es común que Xcode marque build success mientras Cursor sigue mostrando errores rojos en los mismos archivos. Eso pasa porque Cursor no analiza bien el grafo de referencias de un proyecto iOS.
La solución es simple: cierra Cursor por completo y vuelve a abrirlo. Al recargar el proyecto, los errores fantasma desaparecen y el editor reconoce los símbolos correctamente.
Cómo validar la UI generada con previews de SwiftUI
Una vez compila el proyecto, no necesitas correr el simulador completo. Los previews de SwiftUI te muestran el resultado en segundos.
En la prueba, el agente generó previews en modo normal, en dark mode y hasta una variante para iPad sin haberla pedido. La interfaz se veía bien, aunque los fondos en dark mode no correspondían a la paleta esperada y el listado usaba un grid en lugar de una lista vertical simple.
Ahí entra tu criterio como ingeniero. Puedes lanzar un nuevo prompt pidiendo que reemplace el grid por un List, que ajuste los colores del dark mode o que elimine la optimización para iPad si no la necesitas.
¿Cursor reemplaza el trabajo del desarrollador móvil? No. Genera un primer borrador funcional, pero la decisión de arquitectura, la corrección de referencias y el ajuste fino de la UI siguen dependiendo de tu expertise.
El proceso iterativo solo funciona si tú marcas los límites. Si dejas que Cursor corrija sus propios errores indefinidamente, entras en un loop infinito donde el código empeora con cada intento.
Cuéntame en los comentarios cómo te fue resolviendo los detalles de la UI generada y qué prompts te funcionaron mejor para afinar el dark mode o reemplazar el grid.
