Tutorial para iPhone
Esta guía sobre cómo usar rork en iPhone muestra la ruta más sencilla desde una idea de app hasta una vista previa funcional, tanto si empiezas desde el teléfono como si continúas un proyecto en otro lugar.
El flujo de trabajo adecuado para iPhone depende del estado actual de tu proyecto. Elige el punto de partida más parecido antes de escribir un prompt largo o solucionar problemas de la vista previa.
Tienes un concepto inicial, algunas pantallas en mente o un problema que quieres resolver con una app móvil, pero aún no tienes un proyecto.
Abre el creador, describe una primera versión concreta y pide un conjunto reducido de pantallas que puedas revisar en un iPhone.
cómo usar rorkYa tienes un proyecto generado y quieres inspeccionarlo en un iPhone, probar un flujo o perfeccionar una pantalla con otro prompt.
Mantén la solicitud concreta, compara la nueva vista previa con la anterior y cambia una interacción cada vez.
cómo usar rorkEl proyecto se creó o probó para otra plataforma móvil y quieres entender qué cambia en un iPhone.
Trata el iPhone como una superficie de prueba independiente: comprueba el diseño, la navegación, los permisos, el comportamiento del teclado y las áreas táctiles en lugar de dar por supuesta la paridad.
cómo usar rork en AndroidNecesitas una demostración rápida y tangible para un cliente, compañero de equipo o parte interesada antes de invertir en una implementación completa en producción.
Usa un prompt breve, demuestra un recorrido de usuario completo y registra las decisiones que aún necesitan revisión de diseño o ingeniería.
constructor de apps rorkElige esta ruta cuando el proyecto aún no exista. El objetivo no es especificar todas las funciones futuras, sino crear una primera versión coherente que realmente puedas inspeccionar.
Comienza con la tarea principal de la app: reservar una cita, hacer seguimiento de un hábito, recopilar notas de campo u organizar un entrenamiento. Nombra al usuario previsto, la acción principal y el resultado útil más pequeño. Un brief enfocado da a la primera generación una forma más clara que una lista de funciones sin relación.
Describe la primera pantalla, la siguiente acción, la información que debe mostrar cada pantalla y la dirección visual. Menciona detalles adecuados para iPhone, como una barra de navegación inferior, texto legible, áreas táctiles grandes y un diseño que siga siendo cómodo en una pantalla estrecha. Pide contenido de ejemplo realista en lugar de marcadores de posición vacíos.
Cuando aparezca la primera versión, sigue el recorrido principal como lo haría un usuario. Busca etiquetas confusas, controles abarrotados, estados vacíos faltantes y acciones que no expliquen qué ocurre después. Envía un prompt de seguimiento que cambie una prioridad a la vez y vuelve a comprobar el resultado en el iPhone.
Elige esta ruta cuando ya tengas un proyecto que inspeccionar. Una comprobación en iPhone es más útil cuando pruebas flujos reales en lugar de limitarte a mirar la pantalla inicial.
Una vista previa generada puede ayudar a validar la estructura y la interacción, pero no demuestra automáticamente que la app esté lista para la revisión de App Store, las obligaciones de privacidad, las comprobaciones de accesibilidad o la monitorización en producción.
Solución alternativa
Mantén una lista de comprobación para el lanzamiento e involucra a los revisores adecuados de diseño, ingeniería y cumplimiento antes de la distribución.
Un solo iPhone no representa todos los tamaños de pantalla, versiones del sistema operativo, condiciones de red, estados de permisos o dispositivos antiguos. Un diseño que funciona bien en un modelo aún puede fallar en otros.
Solución alternativa
Prueba el recorrido crítico en más de un viewport e incluye conectividad deficiente, datos vacíos, texto largo, permisos denegados y sesiones interrumpidas.
Añadir más requisitos a una sola solicitud puede dificultar saber qué cambio provocó un nuevo problema. El constructor puede sugerir una estructura, pero no puede decidir por ti tus prioridades, políticas o el comportamiento en casos extremos.
Solución alternativa
Divide el trabajo en iteraciones breves: primero la navegación, después la acción principal y, una vez que el flujo principal sea sólido, los estados y los detalles finales.
El acceso a la cámara, las notificaciones, la ubicación, el inicio de sesión, los pagos, los enlaces profundos y el comportamiento en segundo plano pueden requerir configuración o pruebas específicas de la plataforma más allá de un prototipo visual.
Solución alternativa
Enumera de antemano todas las capacidades del dispositivo y verifica cada una con una prueba específica, en lugar de considerar que un botón visible demuestra que la capacidad funciona.
Antes de compartir el proyecto, realiza siempre la misma inspección breve. Estos son puntos de control, no afirmaciones sobre lo que el creador completa automáticamente.
Empieza con un recorrido útil, descríbelo en un lenguaje sencillo y usa la vista previa para descubrir qué debe cambiar. Rork es más eficaz cuando cada indicación tiene un propósito claro y cada revisión en iPhone termina con una decisión concreta sobre el siguiente paso.
Crea un prototipo para iPhoneEstas respuestas cubren las preguntas prácticas que suelen surgir al comenzar un flujo de trabajo centrado en iPhone.
Sí, puedes usar un iPhone para describir una idea, revisar una experiencia generada y dar instrucciones de seguimiento. Para la edición detallada, la depuración o la gestión del proyecto, una pantalla más grande puede resultar más cómoda.
Indica para quién es la app, cuál es el problema principal que resuelve, cuál es la primera acción y qué pantallas se necesitan para completar esa acción. Añade preferencias móviles como una navegación sencilla, texto legible, áreas táctiles claras y datos de ejemplo realistas.
Abre la vista previa del proyecto en el dispositivo y completa el recorrido principal sin omitir pasos. Comprueba el teclado, el desplazamiento, las áreas táctiles, el ajuste del texto, el comportamiento de carga, los estados vacíos y qué ocurre cuando falla una solicitud.
No. Una prueba en un iPhone puede revelar problemas importantes de usabilidad y diseño, pero no sustituye las pruebas de lanzamiento, privacidad, accesibilidad, seguridad ni en varios dispositivos. Considera la vista previa como evidencia para iterar, no como aprobación final.
Describe la pantalla exacta, la acción y el problema observado; después, solicita un cambio específico. Vuelve a comprobar el mismo flujo después de la actualización y mantén una lista breve de problemas sin resolver para que los prompts posteriores no mezclen correcciones no relacionadas.