Quick answer: Compare electric-scooter apps with the same exact-model hardware, phone operating systems, app versions, starting states, test steps, repetition count, and failure rules. Preserve screenshots or video, timing records, permissions, privacy disclosures, raw results, and drawbacks. Do not name a winner when an app, scooter, or required platform has not been tested under comparable conditions.
Reviewed September 20, 2026. App listings, versions, phone requirements, permissions, privacy disclosures, cloud services, and product compatibility can change. Repeat the protocol with current versions before relying on a result.
Correction: Metro is not claiming that five electric-scooter apps were tested and ranked. The prior ranking premise is not supported by published units, versions, screenshots, raw results, failure records, and drawbacks. This replacement provides a blank protocol and makes no product or app recommendation.
Safety and test boundary
Perform app tests with the scooter stationary, powered and supported exactly as the manufacturer instructs, in an authorized location. Do not test phone interactions while riding, bypass a safety interlock, lift or drive a powered wheel unless the exact service procedure requires it, or issue an unfamiliar command around people, pets, traffic, or objects. Stop if the manual, app, or scooter reports a condition requiring service.
This protocol evaluates documented app behavior. It does not certify electrical, mechanical, cybersecurity, privacy, or riding safety.
Pre-register the comparison
Write the method before installing the apps. This prevents criteria from changing after results are known.
- Question: Which exact behaviors will be compared, and for which intended use?
- Eligible products: Exact scooter model, hardware revision, market, and app named by the manufacturer.
- Phone platforms: Exact phone models and operating-system versions.
- App versions: Exact official-store version and listed developer.
- Network states: Bluetooth on/off, internet available/unavailable, and any account state.
- Repetitions: The same stated number for every comparable step.
- Success rule: What visible state proves success?
- Failure and timeout rule: How long before the attempt is marked unsuccessful?
- Evidence plan: Screenshots, screen recording, external video, timestamps, logs, and notes.
Record the exact test matrix
| Field | Test setup A | Test setup B |
|---|---|---|
| Scooter brand and exact model | ____________ | ____________ |
| Hardware or production revision | ____________ | ____________ |
| Scooter firmware version | ____________ | ____________ |
| Official app name and developer | ____________ | ____________ |
| Official store URL | ____________ | ____________ |
| App version and release date shown | ____________ | ____________ |
| Phone model and OS version | ____________ | ____________ |
| Account, region, and subscription state | ____________ | ____________ |
| Bluetooth, Wi-Fi, and mobile-data state | ____________ | ____________ |
| Test date, place, and tester | ____________ | ____________ |
Test 1: official listing and installability
- Start from the scooter manufacturer's current official app link, not a third-party download site.
- Confirm the app name, developer, supported platform, minimum operating-system version, country availability, update date, and listed cost or in-app purchases.
- Install on each pre-registered phone and record success, error text, download size, time, and whether an account is required.
- Preserve the listing and compatibility evidence with the access date.
An app being installable does not prove that it pairs with the exact scooter or that every listed feature works with that model.
Test 2: first pairing
- Reset only the connection state that the exact manual permits.
- Place the phone and scooter at the prewritten distance and starting state.
- Follow the official pairing steps without improvising.
- Record every permission and account prompt in order.
- Define completion by a visible, repeatable connected state—not merely by finding a device name.
- Repeat the same number of clean-start attempts for every setup.
| Attempt | Starting state | Time to defined success or timeout | Prompts or errors | Evidence file |
|---|---|---|---|---|
| 1 | ____________ | ____________ | ____________ | ____________ |
| 2 | ____________ | ____________ | ____________ | ____________ |
| 3 | ____________ | ____________ | ____________ | ____________ |
Test 3: reconnect behavior
Test the documented reconnect sequence after one controlled change at a time:
- close and reopen the app;
- turn the scooter off and on as permitted;
- turn phone Bluetooth off and back on;
- restart the phone;
- move out of local connection range and return; and
- sign out and back in, if the app uses an account and the test plan includes it.
Record whether reconnection is automatic or manual, time to the defined connected state, prompts, lost settings, and the documented recovery step. Do not invent a universal acceptable time.
Test 4: offline and dependency states
Bluetooth, internet access, a manufacturer server, and scooter-side location or cellular hardware are different dependencies. Test only the states documented for the exact product.
| State | Expected behavior from manual or listing | Observed behavior | Recovery required |
|---|---|---|---|
| Bluetooth on; internet available | ____________ | ____________ | ____________ |
| Bluetooth on; internet unavailable | ____________ | ____________ | ____________ |
| Bluetooth off | ____________ | ____________ | ____________ |
| App closed | ____________ | ____________ | ____________ |
| Phone absent or out of power | ____________ | ____________ | ____________ |
| Account or service unavailable | ____________ | ____________ | ____________ |
Do not describe Bluetooth as GPS, cellular tracking, theft recovery, or access “from anywhere.” Those claims require separate hardware, service, account, coverage, permission, and failure evidence.
Test 5: documented command latency
Test only commands the exact manual says are available and safe to use while stationary. Define the start event and the visible end event before timing. Use video with a visible timing reference or another disclosed method rather than human reaction alone. Repeat the same number of times and publish every result, including timeouts.
| Documented command | Starting state | Timing definition | Raw repetitions | Failures or unexpected states |
|---|---|---|---|---|
| ____________ | ____________ | ____________ | ____________ | ____________ |
| ____________ | ____________ | ____________ | ____________ | ____________ |
A faster observed response does not, by itself, establish better security, safety, or overall app quality.
Test 6: permissions and privacy disclosures
Capture every permission prompt and compare it with the app-store privacy disclosure and current privacy policy. Apple says its App Privacy Report can show how often apps access certain permission-protected data and which domains they contact. Google Play says its Data safety section contains developer-provided information about collection, sharing, security, and deletion practices. These tools provide useful evidence but do not independently prove every statement a developer makes.
- Which permissions are requested at install, pairing, and feature use?
- Can a permission be denied while retaining unrelated functions?
- What data does the listing say is collected, shared, linked, or used for tracking?
- Does the privacy policy identify the operator, purposes, recipients, retention, and contact route?
- What domains are contacted during the defined test?
- If an account can be created, is there a working deletion path?
Google Play states that apps offering account creation must provide an in-app path and a web resource for requesting account and associated-data deletion. Test and preserve the current path rather than assuming it works because a disclosure exists.
Test 7: update, export, deletion, and transfer
Record the update path, release notes, firmware relationship, and what happens when an update is interrupted. Do not intentionally interrupt a firmware update unless the manufacturer supplies a safe test procedure and suitable equipment.
Where the app claims export, account deletion, device unbinding, or ownership transfer, follow the official steps using a dedicated test account. Record confirmation messages, completion time, data returned, residual access, and support escalation. Do not expose personal data in the published evidence.
Test 8: failure recovery
For each failure, record the exact message, state of the scooter, whether essential non-app operation remains available as documented, recovery steps, attempts, time, and support response. Include unresolved failures and settings that changed unexpectedly.
| Failure condition | Exact message or state | Documented recovery | Observed outcome | Unresolved drawback |
|---|---|---|---|---|
| ____________ | ____________ | ____________ | ____________ | ____________ |
| ____________ | ____________ | ____________ | ____________ | ____________ |
Publish raw results before a conclusion
A defensible comparison identifies the owner of the comparison, exact products, funding or brand relationship, eligibility rules, method, versions, dates, raw attempts, missing tests, errors, permissions, privacy evidence, drawbacks, and correction policy. A product should not receive a guessed score for an untested platform or unavailable function.
If the evidence is incomplete, publish “not tested” or “not publicly verified.” Do not convert missing data into a winner. Metro makes no app ranking on this page.
