Заполнение длинной формы регистрации — одна из главных причин отказа от первого входа. Пользователь видит 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 дней. Серверная часть для хранения черновиков — отдельная оценка. Стоимость рассчитывается индивидуально. Чтобы оценить ваш проект, свяжитесь с нами — мы обсудим задачу. Закажите разработку — и ваша регистрация перестанет быть узким местом.
