Реалізація форми зворотного зв'язку в мобільному додатку
Форма зворотного зв'язку — це канал, через який розробники отримують інформацію про проблеми до того, як вони з'являються в відзивах App Store. Користувач, який знайшов, куди написати прямо всередину додатку, з меншою ймовірністю поставить 1 зірку публічно. Але погано реалізована форма — з довгою завантаженням або втратою тексту при повороті екрана — гірше її відсутності.
Що важливо в реалізації
Збереження стану
Користувач написав три абзаци, отримав звонок, повернувся в додаток — і текст зник. Це ломає бажання писати. На iOS зберігаємо чорновик у UserDefaults при кожній зміні:
textView.delegate = self
func textViewDidChange(_ textView: UITextView) {
UserDefaults.standard.set(textView.text, forKey: "feedback_draft")
}
При відкритті форми відновлюємо. Очищуємо тільки після успішної відправки.
Автоматичне прикріплення діагностики
Пусте повідомлення «все погано» безкорисно для розробника. При відправці автоматично прикріплюємо контекст: версія додатку, версія ОС, модель пристрою, user ID (якщо авторизований). Користувач це не заповнює — дані збираються програмно.
// Android: формуємо метаданні для відправки
val metadata = mapOf(
"app_version" to BuildConfig.VERSION_NAME,
"os_version" to Build.VERSION.RELEASE,
"device_model" to "${Build.MANUFACTURER} ${Build.MODEL}",
"user_id" to userRepository.getCurrentUserId()
)
Доставка повідомлень
Способи відправки залежать від інфраструктури:
- SMTP через backend — найпоширеніший, підтримка отримує лист на пошту
- Webhook у Slack/Telegram — зручно для малих команд, повідомлення видно відразу
- Інтеграція з helpdesk (Zendesk, Freshdesk) — для продуктів з виділеною підтримкою
Прямої відправки email з мобільного додатку через MFMailComposeViewController (iOS) або Intent.ACTION_SENDTO (Android) краще уникати — залежить від наявності поштового клієнта на пристрої й не дає централізованого зберігання обращений.
Підтвердження отримання
Після відправки — просте уведомлення: «Повідомлення отримане, відповімо протягом 24 годин». Якщо форма використовується як support-канал, корисно генерувати ticket ID й дати користувачу можливість відслідковувати статус.
Процес роботи
Визначаємо призначення форми: збір фідбеку по UX, репорт багів, обращення в підтримку або все разом. От цього залежить набір полів і маршрутизація.
Проектуємо UI: одне текстове поле + категорія (опціонально) + кнопка відправки. Складні форми з 10 полями користувачі не заповнюють.
Реалізація з збереженням чорновика, автосбором метаданних і обраним каналом доставки.
Тестування: втрата мережі під час відправки, дуже довгий текст, спеціальні символи.
Орієнтири по строкам
Проста форма з відправкою на email — 1–2 дні. Форма з інтеграцією в helpdesk, категоризацією й історією обращень — 3–5 днів.