Android · iOS (coming soon)
Every tap, request and crash — as it happens.
Bantu360 shows you what your mobile app is doing on any phone — a tester's across the office or a customer's across the country. Its traffic, its screen and its data, live in one dashboard.
Android
7.0 and later
Available now
iOS
iPhone & iPad
Coming soon
Acme Shop
Aina's Pixel 8 · online
242 ms
POST /cart/items · 201
Live in seconds
Traffic arrives while the app runs
Staging & production
Two keys, never mixed up
Secrets stay on the phone
Named headers are redacted first
Kind to data plans
Batched, capped, a few kB an hour
Features
One SDK in the app. Everything else, on its own.
Nothing to set up per screen or per request — turn a feature on and it starts reporting.
HTTP Monitor
Every request, exactly as it happened
Method, status, timing and the full headers and bodies of both sides — searchable long after the app was closed. Copy any call as cURL.
App Control
Drive the app from here
See the screen, then tap, type and press Back. The phone shows where you pressed.
Mocking
Test the error screen
Answer a call with a 503, a delay or a dead network — on the phones you choose.
Crashes & Logs
"It crashed" — and why
Grouped across devices, with the requests and logs that led up to it.
W Payment: Card needs 3-D Secure
E Checkout: Cart emptied mid-payment
Database & Preferences
Its data, live
Query the app's databases and change its settings in place — with a backup first.
FROM cart_items;
dark_mode = true — applied
Notifications
Tell every tester at once
A message, a picture or a new build, shown inside the app — delivery tracked per device.
Build 3.5 is ready
Checkout is fixed — please try a card payment again.
Seen on 2 of 3 devices
Overview
How the app is doing, at a glance
Volume, failures and response times against the period before — for one device, one build, or all of them.
Requests
48.2k
Failed
1.8%
95% within
412 ms
iOS, in the same dashboard
iPhone and iPad apps will report beside your Android ones — same projects, same keys, same pages.
Use cases
With you from the first build to the store
-
Step 1
Build
See what the app sent and what came back — no cable, no proxy, no certificate on the phone. Replay any call as cURL.
-
Step 2
Test
Watch a tester's phone as they go: its traffic, its screen, its data. Reach in and tap, or message every tester at once.
-
Step 3
Ship
Production builds report with their own key. Staging and production never mix, and one switch moves between them.
How it works
Up and reporting in three steps
Android today, iOS coming soon. Kept out of release builds unless you want it there.
Ck7g••••••••••••wLGc
HNtH••••••••••••wfBj
Every project gets a staging key and a production key.
-
1
Add the SDK to your app
One dependency, added to testing builds — so none of it reaches a release build unless you ask. Android now; iOS coming soon.
-
2
Connect it with your project key
Start it once when the app launches, with the staging key for a staging build. Turn on every feature, or only the ones you want.
-
3
Open the dashboard
The app and its device appear on their first report — named, with the app's own icon. Pick them in the top bar and every page follows.
FAQ
Questions, answered
Android 7.0 and later, today. iOS — iPhone and iPad — is coming soon, and will report to the same dashboard.
Only if you choose. It is added to testing builds, so a release build carries none of it unless you ask for it there.
Name the headers to hide — Authorization, cookies, anything else — and they are redacted on the phone, before anything is stored or sent.
Little. Requests are batched every 15 seconds with bodies capped, and the status heartbeat costs a few kilobytes an hour.
Yes. Each project has a staging key and a production key; the key a build reports with decides where its data goes.
See what your app is doing — right now
Every request, every device, both environments. Android today, iOS coming soon.