Introduction

Refreshing on device shake is possible, but it should be implemented carefully because accidental triggers are easy to create. On mobile platforms, the usual approach is to detect a shake gesture or a strong accelerometer event and then call the same refresh logic your app already uses for manual reload.

Design First: Should Shake Really Refresh?

Before the code, decide whether shake-to-refresh is actually a good interaction for your app.

It works best when:

• refresh is safe and cheap
• users benefit from a hidden power gesture
• there is still a visible refresh control for discoverability

It is a poor fit when refresh is destructive, expensive, or easy to trigger accidentally.

iOS: Use Motion Events

UIKit can notify a responder when a shake gesture ends. For many apps, that is simpler than reading raw accelerometer data.

1import UIKit
2
3final class ViewController: UIViewController {
4    override var canBecomeFirstResponder: Bool {
5        true
6    }
7
8    override func viewDidAppear(_ animated: Bool) {
9        super.viewDidAppear(animated)
10        becomeFirstResponder()
11    }
12
13    override func motionEnded(_ motion: UIEvent.EventSubtype, with event: UIEvent?) {
14        guard motion == .motionShake else { return }
15        refreshContent()
16    }
17
18    private func refreshContent() {
19        print("Refreshing data...")
20    }
21}

This uses the built-in motion event path rather than raw sensor processing.

Android: Detect a Shake with the Accelerometer

Android does not give you a high-level shake callback in the same way, so the common approach is to listen to accelerometer updates and detect a strong acceleration pattern.

1import android.content.Context
2import android.hardware.Sensor
3import android.hardware.SensorEvent
4import android.hardware.SensorEventListener
5import android.hardware.SensorManager
6import kotlin.math.sqrt
7
8class ShakeDetector(private val onShake: () -> Unit) : SensorEventListener {
9    private var lastShakeTime = 0L
10
11    override fun onSensorChanged(event: SensorEvent) {
12        val x = event.values[0]
13        val y = event.values[1]
14        val z = event.values[2]
15
16        val gForce = sqrt((x * x + y * y + z * z).toDouble()) / SensorManager.GRAVITY_EARTH
17        val now = System.currentTimeMillis()
18
19        if (gForce > 2.7 && now - lastShakeTime > 800) {
20            lastShakeTime = now
21            onShake()
22        }
23    }
24
25    override fun onAccuracyChanged(sensor: Sensor?, accuracy: Int) = Unit
26}

Then register it from an activity:

1lateinit var sensorManager: SensorManager
2lateinit var shakeDetector: ShakeDetector
3
4override fun onResume() {
5    super.onResume()
6    val sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
7    sensorManager.registerListener(shakeDetector, sensor, SensorManager.SENSOR_DELAY_UI)
8}
9
10override fun onPause() {
11    super.onPause()
12    sensorManager.unregisterListener(shakeDetector)
13}

Reuse Existing Refresh Logic

Do not write separate business logic just for the shake gesture. Instead, route the gesture into the same refresh function used by:

• pull to refresh
• retry buttons
• automatic background refresh

That keeps the app behavior consistent and makes testing easier.

Tuning the Threshold

Shake detection is mostly about tuning:

• acceleration threshold
• debounce interval
• whether multiple spikes are required

If the threshold is too low, normal walking or setting the phone on a table can trigger refresh. If it is too high, users will think the feature is broken.

Testing on real hardware matters here. Emulator motion simulation is useful, but it is not enough.

Accessibility and User Expectations

Shake gestures are hard to discover and may be difficult or uncomfortable for some users. Treat them as an optional shortcut, not as the only way to refresh.

A visible refresh affordance should still exist.

Common Pitfalls

The biggest mistake is coupling shake detection directly to network code instead of calling a shared refresh function. That makes behavior inconsistent across refresh entry points.

Another mistake is forgetting lifecycle cleanup on Android. If the accelerometer listener stays registered while the screen is inactive, you waste battery and may trigger unwanted callbacks.

On iOS, developers sometimes override motion handlers but forget becomeFirstResponder(), which prevents the responder from receiving shake events.

Finally, if the threshold is not tuned carefully, false positives will make the feature feel unreliable.

Summary

• Shake-to-refresh is possible on both iOS and Android, but it should be an optional shortcut.
• On iOS, overriding motionEnded is often the simplest solution.
• On Android, use the accelerometer and a threshold-based detector.
• Route shake detection into the same refresh logic used elsewhere in the app.
• Tune thresholds and debounce timing on real devices to avoid false triggers.