Why I built it

A world-class bike deserves a world-class app.

Twistgrip is my answer to one question: what should a motorcycle's connected app feel like? Connected the moment you turn the key, silent when you don't, and instant everywhere in between. I built it to prove it can be done, and then I built it properly.

How it started

I ride an Apache RTR 310, and it's an outstanding machine. It's fast, precise, and packed with technology that riders feel every time they twist the grip. Its Bluetooth-connected cluster sends a stream of live data to the phone. But the app experience didn't match the bike. Connecting was manual, the battery took a hit, and the phone kept getting nudged long after the ride was over.

So I went to the source. I mapped the bike's Bluetooth protocol frame by frame, worked out what every field means, and rebuilt the connected experience from the ground up. The aim was an app that feels engineered as tightly as the motorcycle it talks to.

The problems, and how Twistgrip solves them

Each of these is something I hit as a rider. Each fix is a deliberate engineering decision, built into the app and tested end to end.

Battery drain between rides

The problem

The phone's battery drained even on days the bike stayed parked, because the connection work carried on in the background whether or not the bike was nearby.

The solution

Zero work between rides: no Bluetooth scanning, no wake locks, no polling. Twistgrip hands presence detection to Android's companion device framework, so the operating system wakes the app only when the bike starts advertising. When the bike leaves, the app shuts itself down.

No auto-connect when the bike starts

The problem

Every ride began the same way: unlock the phone, open the app, tap connect, wait. Starting a paired bike didn't bring the app up.

The solution

Pair once, then just turn the key. Twistgrip connects in the background with no tap needed. It dials directly with a short timeout, then falls back to Android's controller-level reconnect. Dropped links, silent streams and the radio's own error states are all handled automatically.

Constant pings and notifications with the bike off

The problem

With the app open and the bike paired but switched off, the phone kept getting messages every few seconds and notifications piled up.

The solution

One quiet notification, updated only when the connection actually changes. When the bike goes silent, retries back off from 10 seconds to a minute. Once Android confirms the bike has gone, everything stops. Alerts fire exactly once per event, never on a loop.

Location running around the clock

The problem

Location tracking stayed on in the background all day, costing battery even when no one was riding.

The solution

GPS runs only while a ride is recording, and stops the moment it ends. It powers the route map and Find my bike, never leaves the phone, and background access is optional.

Slow to open, slow to show data

The problem

Getting from tapping the icon to live numbers took long enough to lose interest before the ride began.

The solution

Performance is a design requirement, with explicit budgets: under half a second to the cockpit, a tenth of a second from the bike's answer to the first number, and zero memory allocations per Bluetooth frame. Baseline profiles ship with the app, and a benchmark suite keeps startup measured.

Data the bike sends but riders never see

The problem

The cluster streams far more than riders were ever shown, including battery voltage, throttle position, brake, side stand, indicators and fault lights.

The solution

Decoded and put to work: a live cockpit, battery health with charging checks, an indicator-left-on reminder, engine and sensor fault alerts kept in a history, and real fuel costs from your own fill-ups.

What went into it

SURFACESPhone, watch and watch faceAn Android app, a Wear OS app with a tile, and a Watch Face Format face
PROTOCOL14 hidden data pointsMapped from the bike's own Bluetooth stream and put on screen
CODE20,000 lines of KotlinJetpack Compose, a modular protocol core and a custom design system
QUALITY40+ end-to-end flow testsEvery screen driven the way a rider uses it, plus startup benchmarks
PRIVACYZero serversNo account, no analytics, no trackers. Everything stays on the phone
RELEASEPlay-readySigned bundles for phone, watch and face, with store listings and a privacy policy

Built by

Arun Prakash

I designed and built Twistgrip end to end: the protocol work, the Android and Wear OS apps, the watch face, the design system, the test suite and the release. It's the kind of product I want to build for riders, and it shows the standard I bring to connected vehicles.

If you're building the next generation of connected motorcycles, I'd love to talk: support@arunprakashg.com

Not a product. A proof.

Twistgrip is a personal, non-commercial project, made for educational purposes. It's free, with no ads, no subscriptions and no in-app purchases, and it will never try to make money or raise funds. It exists to show what's possible when the bike and the phone are designed to work as one.