App review

Sealion 7 Pilot 0.9.0

Our own navigation app for the Sealion 7: the country's roads now live on the car, the hills are in the plan, and the app speaks its turns.

BYD LabUpdated Verified 32 min read

A planned route from Benslimane to Tanger on the head unit: 313 km, 2 h 58, arrive 24 %, with an amber terrain pill reading minus 3.8 percent.

Our own app. Sealion 7 Pilot is developed by BYD Lab. It is held to the same standards as every other app on this site — read with that in mind.

Tested on

Vehicle
BYD Sealion 7 · Morocco
Head-unit version
51.1.4.2606220.1
Android
11
Verified

The Sealion 7’s screen is good at being a car and poor at being a computer. Its navigation does not know it is driving an electric car — it will not tell you what the battery will be when you arrive, and it will not put the charging stop in the route for you. It also forgets every drive the moment it ends.

Sealion 7 Pilot is the navigation app we wrote for our own car to fix that. This is version 0.9.0, and it is a different app from the 0.1.0 this review first covered: the roads now live on the head unit instead of coming from a server, the hills are priced into the plan, and it speaks its turns. The published build has since moved on to 0.9.8.0; where that changes what is written here, the section says so and says it was read in the source rather than driven. It is free for three months from the day you sign in; after that it needs a licence, and what one costs has not been decided. The app has its own site at sealion7pilot.bydlab.dev, which is where it is described and where the install starts; this page is the review. It is also our own app being reviewed by us, on one car in one market — read the Limitations before you weigh any of it.

What it does#

It is a driving app, and it is built like one: everything you need while moving is on the map screen or on the dials, in numbers big enough to read at a glance. The rest of the tabs are for when you have stopped.

Planning a route that includes the charging#

Enter a destination and the app does not just draw a line — it works out whether you get there, and where you stop if you do not.

It slices the route into stretches, asks a charge-point directory what exists near each one, and keeps only the chargers inside a corridor around your route rather than anything vaguely nearby. Then it treats the whole thing as a shortest-path problem, where the cost of a stop is the driving time plus the charging time plus a penalty for going out of your way and for slow chargers. What comes back is the chain of stops that gets you there soonest overall — not the nearest charger, and not the fastest one in isolation.

The plan, captured on the car at 0.9.0. The line under the buttons — "Offline · Morocco returned 2 routes" — is the router saying where it came from.

The assumptions it plans to are unchanged and still deliberately conservative: leave each charger at about 78 % — because the last fifth takes as long as the first three — and never plan to arrive anywhere below 5 %. If it cannot find a route under tight rules (fast chargers only, narrow corridor), it widens them step by step rather than giving up.

The roads are on the car#

This is the change that defines 0.9.0. You pick one country in Settings, the car downloads that country’s road pack, and from then on every route, every alternative, every reroute and every repair after a missed turn is computed on the head unit. Morocco is 185 MB of roads and terrain, which arrives as about 91 MB compressed.

At 0.9.0, one country at a time — picking another deleted the first; 0.9.7.0 lets up to four others sit beside it. The App update card underneath is where the 0.9.0 in this review comes from.

What you get for it: a plan costs nothing and waits for nothing, a reroute lands in tens of milliseconds instead of a network round trip, and a drive through a dead zone or a tunnel keeps navigating. What you pay for it is the other half of the sentence, and it is not small: a car with no pack installed cannot route at all. There is no online fallback any more — planning simply fails with “No offline country installed”. A country BYD Lab has not built a pack for is a country this app cannot navigate.

The map is on the car too. The base map is a second per-country file that downloads after the roads — for Morocco about 230 MB on top of the 92 MB road pack in today’s catalogue — so an unfamiliar road draws itself with no signal. Until it has arrived, the map screens show the route on a plain background. Search still needs the network. Since 0.9.6.0 it puts your own places — home, work, favourites, recent destinations — above the results from the first letter, keeps “hotel agadir” in Agadir rather than around the car, and shows an address on every result.

Since 0.9.7.0 the country is a home country plus up to four others, added in Settings › Offline navigation › Other countries. The router joins every pack on the car into one network, so a route can cross the borders between them. The backup search still stays inside the home country. This is from the source at commit 5d3c913 and the developer’s release notes; we have not driven across a border with it.

What the road pack knows since 0.9.7.0#

The 0.9.7.0 packs carry more than the road network, and the router uses it. All of this is read in the source at commit 5d3c913; none of it is in a figure here, and none of it has been driven by us.

  • Car ferries are routes. A crossing is timed from the ferry’s own scheduled duration where the map has one, plus 20 minutes for boarding, and costs no battery. Guidance says “Take the ferry” and “Leave the ferry”, and the route card counts the crossings.
  • Turn bans are respected — the ones that apply at a single junction. Bans that run through a stretch of road are not used yet, and no ban is applied at a turn between two countries’ packs.
  • Unpaved roads cost more. They are planned at no more than 40 km/h and weighted against when the router chooses, so a paved road wins where there is one; a route that still has 0.5 km or more of them says how much on its card. This is a preference, not a ban.
  • Speed bumps and level crossings can be announced about six seconds before you reach them. The switch is in Settings › Offline navigation and starts off.
  • Left-hand-traffic countries get their roundabouts the right way round: the exit angle is measured clockwise and the cluster uses the clockwise roundabout icons. The source notes those icons have not been seen on a car yet.
  • Tunnels no longer freeze the car’s position. From just before the portal to 150 m after the exit, a GPS fix is ignored unless it agrees with the odometer, so the arrow keeps moving on distance driven instead of stopping at the entrance or drifting off the route.

All of it needs the updated pack, which the car downloads by itself on Wi-Fi (it asks first on mobile data) and which Settings offers with an Update now button. Older packs still load without these features. In the catalogue as served on 8 Oct 2026, Germany, France, the United Kingdom, Italy and Russia are still on the older pack: it carries no turn bans and no speed-bump or level-crossing data, so none of that applies there yet.

What you see while driving#

During guidance the strip carries the numbers that actually matter in an EV, and they are live:

  • ETA — when you arrive
  • Distance remaining
  • Battery on arrival — the percentage you will have left when you get there
  • ΔSOC — whether you are ahead of the plan or behind it, right now

The four numbers during guidance, with ΔSOC in the speed pill. Captured on the car; the motion comes from the app's own replay simulator, with the car parked.

Arrival battery is the figure the built-in navigation will not give you, and it is what turns “can I make it?” from a worry into a number. ΔSOC is the difference between the battery the plan expected at this point and what the car actually has: green means you are holding more charge than planned, red means the motorway or the cold or your right foot is costing more than predicted, and zero means you are driving exactly the journey it planned.

Both directions of the readout. This figure is from the 0.1.0 capture session in August — the readout itself is unchanged.

Two events used to break that number, and 0.9.0 fixes the second one. A reroute already rebuilt the plan from the live battery, so ΔSOC returned to zero and started tracking the new road. A charge did not: stop at a planned charger, leave at 95 % where the plan said 80, and the pill read +15 for the rest of the trip. Now the plan is re-chained the moment you drive off again, so the readout goes back to measuring your driving rather than your charging stop.

The hills are in the plan#

A route over a pass is not the same energy as the same distance on the flat. The road pack carries a height for every point of every road — sampled from a global 90 m elevation model — so the planner can price the climbs and credit the descents, and the arrival percentage already contains that adjustment.

On the plan card it is one pill next to the energy figure. Tap it and you get the profile:

Benslimane to Tanger: 1 337 m of climbing against 1 565 m of descent still costs 3.1 kWh net, because a descent never gives back what the climb took.

The line at the bottom is the honest part — “Climbing costs 9.8 kWh, descending gives back 6.7 kWh” — and it says where the heights came from. Regeneration is not symmetric with gravity, and a planner that assumed it was would flatter every mountain route.

It speaks now#

At 0.1.0 the voice work was a 2.6 GB language model that had not been made to work. That model is now switched off in the build, and what shipped in its place is smaller and far more useful: the app speaks its turns.

A 61 MB voice, on the car, with nothing sent anywhere. The instructions themselves come from the road pack, so guidance speaks with no network at all.

It calls the turn once when the instruction becomes current, again as you approach it, and once more inside a speed-aware window a few seconds before the turn itself — then says nothing else about it, however much the GPS jitters or however long you sit at the light before it. A reroute cuts whatever it was saying and re-announces from the new road. It tells you when you are five minutes out, and says you have arrived when you actually have.

You can talk back, in a small way: “Hi Pilot” wakes it, and mute, unmute, repeat and cancel do what they say. Understanding a free-form sentence is a rule-based parser, not a model — “go to Agadir with a DC charger” works, and anything more conversational does not.

Live traffic: missing from the build we tested, back since#

Moving the router onto the car cost the app its traffic, and it deserves its own heading because the 0.1.0 review sold the opposite.

That review described a monitor that re-checked your route every 30 to 120 seconds, corrected the ETA silently when the road was the same, and offered you a card with the time saved when a genuinely faster road existed. All of that machinery is still in the build — the monitor, the proposal card, the side-by-side comparison, the cluster banner, and the tests that cover them. None of it runs, because the thing it needs is a source of traffic data, and the router on the car is not one. It reports that it cannot provide live traffic, and the monitor stays stopped. So there is no traffic colouring on your route, no faster-route proposal, and no speed-limit roundel on either screen.

What you keep is rerouting for the reasons the car can see for itself: you missed a turn, you left the route, you changed the destination, you finished charging. What you lose is any notion that the road ahead is blocked. On a motorway with a queue on it, this app will drive you into the queue and re-time your ETA afterwards.

That was 0.9.0, the build this review tested. The developer reports that live traffic came back in 0.9.5.1 and is still there in the current 0.9.7.0. We have read how in the source (commit 3cee5b8); we have not driven it. The traffic comes from an outside traffic service, through a key bydlab.dev issues to a linked car rather than one built into the app. Before a plan is shown, the app fetches that service’s traffic tiles over the route’s corridor, lays the current speeds over the road pack and routes again if they change the answer. During guidance it sends the road ahead of the car to the same service on a refresh cycle and gets back the live travel time and the slow sections — jams, roadworks, closures — which become the ETA and the colouring on your route, and which turn the faster-route monitor back on. With no signal or no key, the app routes on normal road speeds exactly as 0.9.0 did. It is on by default.

0.9.6.0 and 0.9.7.0 changed how it behaves rather than what it is, again by the source at commit 5d3c913:

  • A faster route is spoken, once. “Faster route available, saves N minutes” is said once per offer, held for up to 20 seconds until there is a quiet moment, and never queued ahead of an imminent turn. It is only offered if it actually leaves your road at least a kilometre ahead, and driving onto it makes it your route without a tap. Once you are past the turn-off, the offer is dropped; one you turned down with Keep is not offered again.
  • Old traffic is ignored. A reading older than 30 minutes no longer changes the route.
  • The car’s own time wins when the traffic service takes a different road. If the service’s version of your route is not the same length as the car’s, the car keeps its own driving time and adds only the delays on sections that lie on your road. The release notes give a 22-minute trip that used to show 38.
  • Rerouting is quieter and smarter. If the way back starts behind you, the first instruction is “Make a U-turn”. A reroute keeps the route style you planned with and plans from the live battery, re-planning the charging if the detour puts the next charger out of reach. “Route updated” is said at most once every 30 seconds.

None of that has been tested here, and no figure in this review shows it. What 0.9.0 did is what we can vouch for; what 0.9.7.0 does is what the code says.

The map on the dials#

The route also renders on the instrument cluster behind the wheel, so you can follow the next turn without looking across to the centre screen.

The cluster, captured from the second display (id 3, 1920×720) while the head unit ran the same route. The black bands above and below are cropped.

One control swaps what the two screens are doing: normally the cluster follows the car turn by turn while the head unit shows the whole route, and swapping puts the overview on the dials and the close-in view on the big screen. Both are driven from the same navigation state, so they never disagree about where you are or which turn is next — and if the head-unit side of the app is killed for memory, the cluster keeps navigating on its own. All three of the car’s native modes work, and the projection lives in its own process fed by the same 30 FPS pipeline as the head-unit map.

What has not changed is the way in. It uses a route into the cluster that BYD does not document, and a head-unit update could take it away without warning.

What 0.9.8.0 takes from the car#

0.9.8.0 reads three more things from the car and talks to one more of its screens. All of it is from the source at commits 28694e9 and 8d53cdf; none of it is in a figure here, and none of it has been tried by us.

  • The windshield head-up display. On a car fitted with one, the app sends it the next turn — the arrow, the distance and the next road’s name, the same numbers as the cluster’s turn card — through the calls BYD’s own navigation app makes, read from that app’s decompiled code. It follows guidance by itself, whatever the cluster mode. The switch is in Settings › Head-up display and starts off, and the source says plainly that it has never been run on a car with a head-up display: the development car does not have one. Until an owner with one reports it working, treat it as unverified.
  • The car’s distance unit. If the car is set to miles, every navigation distance follows: the guidance on the head unit, the trip bar, the cluster’s turn card and the head-up display show miles, with yards under a tenth of a mile, and English guidance speaks “half a mile” or “300 yards”. The other guidance languages still speak metric. A car set to kilometres, or a value the app cannot read, leaves everything as it was. Our car is metric, so the miles path has not run on it.
  • The car’s low-battery warning. When the warning lamp the car shows on the cluster comes on, the app raises a Battery low card — on the car’s signal, not a threshold of its own — with a button that opens the map’s charger list. During guidance the card only informs and has no button. It comes up once per warning: dismissed, it stays away until the lamp goes off and on again.
  • Places from other apps on the head unit. A standard Android location link — from a contact, a message, a web page, a calendar entry — and a place shared from Google Maps on the head unit now open in the app, as the same accept-or-dismiss card a place from the phone arrives as, labelled Opened from another app. A link with coordinates keeps them; an address is matched by the app’s own place search near the car. Nothing is routed without a tap: the source records that letting such a link start a route directly would have ended a trip in progress.

It remembers your driving#

Every drive is recorded — distance, consumption, how long it took — and the history survives a reboot.

A recorded drive. This figure is from the August 0.1.0 session; the screen is unchanged at 0.9.0.

Charging is where 0.9.0 fixed something that had quietly never worked. On this car the head unit sleeps while the car charges, so nothing was running to record it — a week of history on the paired unit held zero charging sessions, while the battery had clearly gone from 26 % to 87 % overnight more than once. The app now writes a checkpoint every 30 seconds and reconciles it against what it finds when it wakes: if the battery rose while it was asleep and the odometer did not move, it records the session it slept through and says so.

Two kinds of record. The second one is inferred: the app was asleep for all ten hours, so it has the start, the end and the battery either side, and honestly reports no curve.

That second card is the design being honest about its own limits — an upper bound on when the charge happened, labelled as such, rather than a curve it would have had to invent.

Your phone can see the car#

New at 0.9.0, and the part to be most careful about. Link the car to your BYD Lab account and it reports what it sees to the server: battery, range, odometer, gear, battery health, and your finished trips and charging sessions. A phone app can then show the car and send it a destination — which arrives as a card the driver accepts or ignores, never as something that starts guidance by itself.

What the car reports, and the switches over it. Position is the one that is off until you turn it on — and turning it off again deletes the position already stored.

Telemetry is on by default once the car is linked; position is not, and turning it off deletes what the server already holds. That asymmetry is the right one — you linked the car to see its battery, not to file where it sleeps — and it is the sort of default that is worth checking for yourself in the switches above.

The Android phone app is now out as a Google Play test that you join from an opt-in link, ahead of a public listing; the iPhone version is still waiting on the App Store. The part of it we have run is the one that matters first — it is now how the car app gets installed, described in Install below, and that worked on the car end to end. Its other half, the one that reads the car and sends it destinations, we have not assessed: everything above is what the car does — the reporting, the switches, the destination card.

Since 0.9.6.0 the Android app also takes a place shared from Google Maps on the phone, including one found with Maps search, and shows its name, full address and pin before you tap Send, so a wrong match can be caught on the phone. It still arrives on the car as a card. That is read in the source, not tried; note that in the source the car’s Accept destinations from the phone switch starts on once the car is linked.

Since 0.9.8.0 the car asks the same question before Start that it already asked during guidance. A place sent from the phone while a trip is still being planned can be added to it as a stop, in route order, with the route re-planned straight away if one is on screen; or it can replace the trip. Also read in the source, not tried.

It can install other apps#

The head unit has no app store, so the app brings a small one. The Apps tab lists packages held in an online folder — Aurora Store, Brave, ABRP, a dashcam viewer, Google Play services — each with its size and an ADB Install button that installs it over the unit’s own adb connection.

The Apps tab is a small curated store, not a file picker: each entry installs over the local adb connection.

That convenience has a condition attached, in Install below, and it is the most important thing in this review.

Not finished: the camera and the assistant#

Two things are in the project but are not features of the build you would install:

  • 360° camera. It is no longer in the app at all — the surround-view work was taken out of the main build and continues on a branch. We can bring the camera up outside its normal parking trigger, but how the car’s system really wants to be driven is still open, and nothing about it ships today.
  • A real assistant. The wake word, the speech recognition and the voice are all on the car, and they run the commands listed above. The language model that would let you talk to it properly is switched off in the build, and the plumbing that would bring it back is a one-line change nobody has earned yet.

Neither is a reason to install the app today. Both are a reason to keep an eye on it.

Install#

There is no store on the car, so the app goes on from a phone. The Android version of the companion app has an installer: with the phone and the car on the same Wi-Fi — a home network, or the phone’s hotspot — it looks for the head unit’s debug port, lists what it finds, and asks the car what it is running and bydlab.dev what the newest build is. Nothing is downloaded until it has shown one summary (version, size, which device at which address, what is on it now) and you have confirmed it. Then it downloads the build, checks it against the checksum the server published and against the one package name it is allowed to install, sends it to the car, and deletes its copy. The first time, the car asks whether to allow debugging from that phone.

We ran that end to end on the car, and it is simpler than the computer route it replaces: no computer, no command line, no checksum to compare by eye. Two things still stand in front of it. The phone app is a Google Play test, not a public listing: you join the test first, then install it from Google Play. And the car has to have its debug port turned on first, which is still the part specific to this car and still carries a medium-risk warning — the procedure is in Sealion 7: turn on adb over Wi-Fi and install an app. The app’s own site walks through the rest: sealion7pilot.bydlab.dev.

Installing needs an account. Signing in with Google, GitHub or Facebook creates one, and every new account is issued a three-month licence for this app at that moment — nothing to enter and nothing to pay.

Compatibility#

Works on BYD Sealion 7 with the DiLink 5 head unit
Checked on Sealion 7, Morocco, head-unit build 51.1.4.2606220.1, Android 11 — read off the car
Needs Google Play No
Needs a linked account Yes — for the licence, the map and search keys, and the road pack
Needs a road pack Yes. No pack for your country means no routing at all. 136 countries have one (the published catalogue, 8 Oct 2026), each with a map; Germany, France, the UK, Italy and Russia are still on an older pack without turn bans or road alerts. We have driven on Morocco’s
Price Free for three months from sign-in; a licence after that, price not announced. One car per account

Everything interesting depends on BYD’s own software being underneath. The app will install on an ordinary Android tablet, but there it is an empty shell — no car data, no cluster, no camera. Other BYD models and other head-unit builds are untested: what the app reads from the car was worked out by watching this one car, not from anything BYD documents, so a different model may show nothing at all.

Route planning assumes an 82.5 kWh battery. On a different pack the arrival figures will be wrong until that is made configurable.

Permissions and privacy#

The install asks for a long list of permissions. Most of them are BYD’s, and BYD splits car data very finely — reading tyre pressure alone takes two separate permissions — so a short list of features turns into a long list of requests. Here is what it actually means.

What it reads from your car: speed, gear, battery and charging state, range, odometer, tyre pressures, doors, lights, parking sensors, cabin air quality, the car’s location — and, since 0.9.0, the VIN.

Everything the app reads, in one panel. Captured at 0.9.0; the map behind it is cropped away because it showed a home location.

The VIN is there for one reason: it ties your licence to the car rather than to the head unit, so a factory reset or a replaced unit does not cost you the licence. It is read from the car’s own service and hashed before anything leaves — the raw number is never written to a file, a log or the server.

What it can change: two things only — the climate settings, and starting the 360° camera. It cannot unlock your doors, control the lights, or touch anything to do with driver assistance. Those permissions were not requested.

What leaves the car — and this is the paragraph that changed. At 0.1.0 this review said your trips and charging sessions stayed on the head unit and were not uploaded. That is no longer true. A linked car sends a telemetry snapshot — charge, range, odometer, gear, battery health — about once a minute when something a person would notice has changed, mirrors your finished trips and charging sessions every quarter of an hour, and holds a connection open to the server while the app is running so a phone can watch it move. Where the car is parked is the one piece behind a switch that starts off.

Place searches and charge-point data still come from outside services, so searching for a destination means telling one of them where you want to go. Routing itself still runs on the car, and in the 0.9.0 build we tested no route request left it. Live traffic, added since, changes that: with it on — the default — the app fetches a traffic service’s tiles over your route’s corridor and, during guidance, sends that service the road ahead of the car to time it. That is your route, and where you are on it, going to one more company. We read this in the source; we have not watched it on the wire.

What stays on the car: the full trip history and the detailed samples behind it, your settings, and every route you plan. There is still no analytics and no advertising identifier of any kind in the app — we checked for it specifically. Since 0.9.7.2 there is one more thing a linked car sends: when the app crashes, the car files the crash as a support report on the owner’s account, with the error, the app and head-unit versions and the end of the app’s own log. The developer’s notes say keys, email addresses and VINs are removed and any position is cut to about a kilometre before it leaves; we have read that, not inspected a report. A switch on the car’s Link screen turns it off. The account-linked reporting above and those crash reports are the whole of what is sent.

Two things we would fix before calling it finished: the app still allows unencrypted web traffic, and it still allows Android’s backup system to copy its data — which means your recorded trip history could be pulled off the unit by anything able to run a backup. Both were on the list at 0.1.0 and both are still on it.

Limitations#

  • It is version 0.9.0. One car, one market, one head-unit build. Expect rough edges and expect things to change.
  • Live traffic is untested here. The 0.9.0 build we tested had none — the single biggest regression from 0.1.0 for anyone driving a busy road. The developer reports it back since 0.9.5.1 and refined in 0.9.6.0 and 0.9.7.0; we have read the code, not driven it, and it needs a signal, so a dead zone is still a stretch with no traffic.
  • No road pack, no navigation. Packs exist for 136 countries, but we have only driven on Morocco’s; the rest are published, not tested here. This is a harder dependency than the online routers it replaced, and a fresh install cannot route until the pack has downloaded.
  • The 0.9.6.0 and 0.9.7.0 features are reported, not tested. Other countries and border crossings, ferries, turn bans, unpaved-road avoidance, road alerts, left-hand-traffic roundabouts, the tunnel tracking and the reworked rerouting are described from the source. Five large countries — Germany, France, the UK, Italy, Russia — do not have the pack those features need yet.
  • The 0.9.8.0 additions are reported, not tested — and the head-up display is untested by anyone. Miles, the low-battery card and places from other apps are described from the source. The head-up display has not run on a car that has one, and our car is set to kilometres.
  • The app has been driven; the screenshots have not. Every figure except Trips was captured on the car on 20 September at 0.9.0, but the car was parked and the motion in the guidance figures comes from the app’s own replay simulator. They also come from a debug build — the Settings figures show a DEBUG badge and a developer row a release build would not have.
  • The phone companion is a test, not a release — and it is now the way in. The Android app is a Google Play test you join from an opt-in link; the iPhone app is waiting on the App Store. We have used its installer to put the app on the car; its dashboard and its destination sending we have not assessed.
  • The camera is not in the build, and the assistant’s language model is switched off.
  • The cluster map may break. It uses an undocumented route into the instrument cluster; a BYD update could disable it.
  • The planner is tuned to one battery (82.5 kWh) and to charge-point data that is only as good as the charge-point directory’s coverage where you drive.
  • Updates need the debug port left on, with the exposure described above.
  • Nobody independent has reviewed its security, and it is an app that can install other apps.

Verdict#

The navigation is the reason this app exists, and 0.9.0 makes it both better and narrower. Routing that plans the charging stops into the journey, an arrival-battery figure that updates as you drive, a ΔSOC readout that now survives a charging stop, hills priced into the plan from real elevation data, turns spoken out loud, and the next turn on the dials — that is a genuinely better tool for a long EV drive than what the car ships with, and most of it works with the radio off and no signal — the map included, in the current builds.

The narrowing is real and a reader should weigh it: the 0.9.0 we tested could not see traffic, and the app cannot navigate a country we have not built a pack for. For a driver whose long trips are motorway queues around a city, 0.1.0’s traffic proposals were worth more than everything 0.9.0 added. The developer reports traffic back since 0.9.5.1, and 0.9.7.0 adds the neighbouring countries, ferries and turn bans a long trip runs into; until we have driven them, that driver should try it on a road they know before relying on it. For a driver whose long trips cross a country with patchy coverage, the trade already went the right way.

We are not giving it a score. A rating from us, on our own app, tested on one car in one market, would be worth nothing — and the rule here is that our app is judged on the same evidence as everyone else’s. It gets a rating when it has earned one.

Who it is for: a Sealion 7 owner who drives far enough to care about charging stops, is comfortable sideloading an app, and understands the debug-port trade-off. Who it is not for: anyone who wants something supported, anyone who needs traffic information that has been tested, or anyone who would rather not leave a door open on their car’s network.

Alternatives#

  • The built-in navigation. Supported, updated by BYD, properly integrated with the cluster, and it knows about traffic. It will not plan around charging, will not show you the battery on arrival or how you are tracking against a plan, and will not remember your trips.
  • A Better Routeplanner. The reference for EV route planning, and it can be sideloaded the same way. It does not read your car’s own battery and consumption on this unit, so it plans from your phone’s picture of the world rather than the car’s — and it does not reach the cluster.
  • Neither. Built-in navigation plus a phone in a cradle is the right answer for a lot of owners, and it does not involve leaving a debug port open on your car.