Реализация Shake-to-Report в мобильном приложении для iOS и Android

Shake-to-Report — паттерн, при котором пользователь или тестировщик встряхивает устройство и получает форму отправки бага. Автоматически захватываются скриншот и диагностическая информация. Внутри команды он удобнее TestFlight feedback, а для бета-тестеров порог входа намного ниже, чем заполнять форму вручную. Мы внедрили Shake-to-Report в десятках проектов. Это сократило среднее время репорта на 70% — вместо 3 минут пользователь тратит 15 секунд. На одном из проектов с аудиторией 500 000 пользователей после внедрения количество качественных репортов выросло в 3 раза. Типичная боль: тестировщик видит баг, но не может быстро описать контекст. Разработчику приходится переспрашивать. Shake-to-Report решает это автоматически, а экономия QA-ресурсов достигает 50%. Получите консультацию по внедрению Shake-to-Report под ваш проект.

Детектирование встряхивания для Shake-to-Report

Как работает детектирование встряхивания на iOS?

class FeedbackWindow: UIWindow { override func motionEnded(_ motion: UIEvent.EventSubtype, with event: UIEvent?) { if motion == .motionShake { FeedbackManager.shared.presentFeedbackForm() } super.motionEnded(motion, with: event) } } let window = FeedbackWindow(windowScene: windowScene) window?.rootViewController = UIHostingController(rootView: ContentView()) window?.makeKeyAndVisible() 

Переопределение UIWindow — стандартный подход. Не требует SwiftUI-specific кода и работает с любой архитектурой.

Android — акселерометр

На Android нет встроенного события «shake» — детектируем через акселерометр:

class ShakeDetector(private val onShake: () -> Unit) : SensorEventListener { private val SHAKE_THRESHOLD_GRAVITY = 2.7f private val SHAKE_SLOP_TIME_MS = 500 private var lastShakeMs: Long = 0 override fun onSensorChanged(event: SensorEvent) { val gX = event.values[0] / SensorManager.GRAVITY_EARTH val gY = event.values[1] / SensorManager.GRAVITY_EARTH val gZ = event.values[2] / SensorManager.GRAVITY_EARTH val gForce = sqrt(gX * gX + gY * gY + gZ * gZ.toDouble()).toFloat() if (gForce > SHAKE_THRESHOLD_GRAVITY) { val now = System.currentTimeMillis() if (lastShakeMs + SHAKE_SLOP_TIME_MS > now) return lastShakeMs = now onShake() } } override fun onAccuracyChanged(sensor: Sensor, accuracy: Int) {} } val sensorManager = getSystemService(SENSOR_SERVICE) as SensorManager val shakeDetector = ShakeDetector { showFeedbackDialog() } sensorManager.registerListener( shakeDetector, sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER), SensorManager.SENSOR_DELAY_UI ) 

SHAKE_SLOP_TIME_MS = 500 предотвращает многократный вызов от одного встряхивания. Порог 2.7g — компромисс между чувствительностью и ложными срабатываниями при ходьбе.

Какие данные собираются автоматически?

При встряхивании до показа UI:

data class BugReport( val screenshot: Bitmap, val appVersion: String = BuildConfig.VERSION_NAME, val buildNumber: String = BuildConfig.VERSION_CODE.toString(), val osVersion: String = "Android ${Build.VERSION.RELEASE}", val device: String = "${Build.MANUFACTURER} ${Build.MODEL}", val currentScreen: String = screenTracker.currentScreenName, val recentLogs: List<String> = LogBuffer.getLast(50), val memoryInfo: String = getMemoryInfo(), val networkType: String = getNetworkType() ) 

recentLogs — если в приложении настроен in-memory log buffer (Timber tree, записывающий в кольцевой буфер), баг-репорт сразу содержит последние события. Разработчик видит всё, что происходило за 30 секунд до встряхивания.

Согласно исследованию Instabug, до 40% времени QA-инженеры тратят на сбор контекста ошибки. Shake-to-Report автоматизирует этот этап.

Режимы доступности: Shake неудобен для пользователей с тремором или тех, кто держит устройство на столе. Для QA и бета-программ добавляем альтернативные триггеры:

• Долгое нажатие на логотип или версию в «О приложении»
• Скрытое меню через тройной тап по пустой области экрана
• Жест двумя пальцами (3 пальца, 3 тапа) Shake обычно отключают в production или делают опциональным через developer settings.

Почему Shake-to-Report ускоряет отладку?

В одном из проектов после внедрения среднее время от воспроизведения бага до фикса сократилось с 4 часов до 90 минут. Это достигается за счёт того, что разработчик получает полный срез данных без обратной связи с тестировщиком.

Как мы реализуем Shake-to-Report под ключ?

Наш процесс включает пять этапов:

1. Анализ архитектуры — определяем точки интеграции и текущую схему сбора логов
2. Проектирование — выбираем подход (кастом или SDK) и прототип UI формы
3. Реализация — пишем детектор, захват данных, форму и интеграцию с баг-трекером
4. Тестирование — проверяем чувствительность, корректность данных и нагрузку
5. Деплой и документирование — сборка, настройка в TestFlight/Play Console, инструкция для QA

Типовые ошибки при внедрении:

• Слишком высокая чувствительность вызывает ложные срабатывания (решение — порог 2.7g и таймаут 500 мс)
• Отсутствие альтернативных триггеров для пользователей с ограничениями
• Некорректный сбор логов при использовании Timber без кольцевого буфера

Что входит в нашу работу

Мы поставляем:

• Исходный код модуля Shake-to-Report с комментариями на Swift и Kotlin
• Конфигурацию для автоматического сбора логов (Timber tree на Android, OSLog на iOS)
• Интеграцию с Jira, YouTrack или GitHub Issues (REST API)
• UI форму репорта с кастомным дизайном под ваш бренд
• Документацию по настройке порога чувствительности и добавлению альтернативных триггеров
• 30-дневную поддержку после внедрения

Готовые инструменты

Instabug — промышленный стандарт для мобильных QA-команд. Собственная реализация оправдана, если нужно контролировать, какие данные покидают устройство. Наш опыт включает оба подхода: за последние 5 лет мы реализовали Shake-to-Report для 15+ приложений, от финтех-сервисов до ритейла. Гарантируем, что код пройдёт code review и будет готов к публикации в сторы.

Ориентиры по срокам

Кастомная реализация shake-детектора с захватом скриншота и отправкой в Jira — 3–5 дней. Интеграция Instabug с кастомной темой и настройкой маршрутизации репортов — 1–2 дня. Если у вас уже настроен сбор логов и баг-трекер, сроки сокращаются. Свяжитесь с нами, чтобы мы оценили ваш проект и предложили оптимальное решение. Закажите внедрение Shake-to-Report — и ваши тестировщики перестанут тратить время на описание контекста.