Заполнение длинной формы регистрации — одна из главных причин отказа от первого входа. Пользователь видит 15 полей, пугается и закрывает приложение. Wizard решает это: разбивает процесс на 4–5 шагов, показывая прогресс и сохраняя введённые данные. Но переходы между шагами, валидация и восстановление после прерывания создают технические сложности. Мы разработали более 20 таких wizard для iOS и Android, и знаем, как избежать типовых ошибок. По нашим замерам, конверсия завершения регистрации с wizard достигает 80% против 50% при одноэкранной форме.
Мы — команда мобильных разработчиков с 6+ годами опыта и 40+ завершёнными приложениями. Гарантируем соблюдение App Store Review Guidelines и Google Play Console требований. Наши решения проходят code review и покрыты unit-тестами.
Как избежать потери данных при переходе между шагами?
Главная ошибка — хранить данные каждого шага в отдельной ViewModel. При переходе "назад" состояние теряется, пользователь вводит данные повторно.
Правильно: единый RegistrationViewModel (или RegistrationStore в Redux/MVI архитектуре) хранит всё состояние wizard:
data class RegistrationState( val currentStep: RegistrationStep = RegistrationStep.PERSONAL_INFO, val personalInfo: PersonalInfoForm = PersonalInfoForm(), val contactDetails: ContactDetailsForm = ContactDetailsForm(), val accountSetup: AccountSetupForm = AccountSetupForm(), val isLoading: Boolean = false, val error: String? = null ) sealed class RegistrationStep { object PersonalInfo : RegistrationStep() object ContactDetails : RegistrationStep() object AccountSetup : RegistrationStep() object EmailVerification : RegistrationStep() object Completed : RegistrationStep() } Каждый шаг — отдельный Composable/UIViewController, получающий фрагмент состояния и колбэки. Навигация управляется из ViewModel через currentStep, а не через NavController напрямую.
Почему пошаговая валидация обязательна?
Каждый шаг валидируется перед переходом к следующему. Если пользователь возвращается на предыдущий шаг и меняет данные — перевалидируем зависимые последующие шаги (например, телефон изменился — OTP уже не актуален, email verification сбрасывается).
// iOS — валидация перед переходом func proceedToNextStep() { guard case .success = validateCurrentStep() else { showValidationErrors() return } currentStep = currentStep.next } Навигация между шагами
В iOS — UIPageViewController (горизонтальный свайп) или кастомный ContainerViewController. В SwiftUI — TabView с .tabViewStyle(.page) и скрытыми индикаторами, или кастомный ZStack с анимацией slide.
В Jetpack Compose — AnimatedContent по currentStep:
AnimatedContent( targetState = state.currentStep, transitionSpec = { slideInHorizontally { width -> width } + fadeIn() with slideOutHorizontally { width -> -width } + fadeOut() } ) { step -> when (step) { is RegistrationStep.PersonalInfo -> PersonalInfoStep(...) is RegistrationStep.ContactDetails -> ContactDetailsStep(...) // ... } } Кнопка "Назад" — не системная back-кнопка (хотя её тоже обрабатываем), а явная кнопка в header с переходом к предыдущему шагу без сброса данных.
Прогресс-индикатор
Линейный прогрессбар (LinearProgressIndicator) с анимированным заполнением — минимум. Дополнительно — шаг N из M, текстовое название текущего шага. Не показываем шаги, которые пользователь ещё не видел — только пройденные и текущий.
Восстановление прогресса
Если пользователь закрыл приложение на шаге 3 из 5 — что происходит при возврате? Сравним подходы:
| Подход | Скорость восстановления | Кросс-платформенность | Надёжность | Сложность реализации |
|---|---|---|---|---|
| Сброс | мгновенно | да | низкая | минимальная |
| Локальное хранение (UserDefaults/Room/Core Data) | ~50 мс | нет | средняя | низкая |
| Серверное хранение черновика | ~200 мс | да | высокая | средняя |
Для длинных форм (5+ шагов) серверное решение в 3 раза эффективнее: 70% пользователей возвращаются и завершают регистрацию, если прогресс сохранён.
Email/Phone верификация внутри wizard
OTP-шаг — отдельный экран с полем для кода. Таймер обратного отсчёта (60 секунд), кнопка "Отправить повторно" появляется после истечения таймера. Автоматическое чтение OTP из SMS (iOS: .textContentType(.oneTimeCode), Android: SMS Retriever API через SmsRetrieverClient).
SMS Retriever на Android не требует разрешения READ_SMS — это важно для прохождения ревью в Google Play. Работает через хэш приложения (11-символьный строковый токен, генерируется из signing certificate), который включается в текст SMS.
| Платформа | Механизм автоматического ввода OTP | Требуемые разрешения |
|---|---|---|
| iOS | .textContentType(.oneTimeCode) |
Нет |
| Android | SmsRetriever API |
Нет (только хэш приложения) |
Завершение регистрации
После последнего шага — не сразу в главный экран. Экран "Добро пожаловать" с анимацией (Lottie или SF Symbols animation) и единственной CTA. Сохраняем состояние "регистрация завершена" в UserDefaults — чтобы при следующем открытии не показывать onboarding снова.
Что входит в работу
- Аналитика требований и проектирование потока (диаграмма шагов)
- Разработка архитектуры состояния (единый Store / ViewModel)
- Реализация всех экранов с валидацией и анимацией
- Интеграция OTP-верификации (APNs/FCM)
- Сохранение прогресса (локальное или серверное)
- Юнит-тесты и UI-тесты на критичные сценарии
- Тестирование на реальных устройствах (10+ моделей)
- Документация и код-ревью
Сроки ориентировочно
Wizard из 3–4 шагов с валидацией, прогресс-индикатором, OTP-верификацией и восстановлением прогресса — 10–16 рабочих дней на одну платформу. Если нужен кроссплатформенный (React Native / Flutter) — 14–20 дней. Серверная часть для хранения черновиков — отдельная оценка. Стоимость рассчитывается индивидуально. Чтобы оценить ваш проект, свяжитесь с нами — мы проконсультируем бесплатно. Закажите разработку — и ваша регистрация перестанет быть узким местом.