BMW iDrive 7 Custom Apps: MGU Store Research Guide

By /

We may earn a commission from products on this page — it never affects what we recommend. How we make money

Research-Based

What this means: Solid amber = Garage Tested: installed and run on our own BMWs. Outlined steel = Research-Based or Community-Vetted: specs and owner feedback reviewed, not yet run in our garage.

How this guide was researched: This is a research-based guide built from the developers’ own documentation for the MGU Store, the iDrive 7 custom apps collection, and the root SSH tool, all reviewed on November 3, 2026. Nothing in it has been tested on our 2020 BMW M340i xDrive yet. Where a claim depends on your specific head unit, this guide says so, and the testing section at the end is left blank for real results. The software described here is free and open source. It is not a paid product, it is not affiliated with BMW AG, and if anyone tries to sell you these apps, the developers themselves warn that you are being scammed. Open issue reports were checked on November 3, 2026, and are summarized in Reported Problems Under Investigation.

Quick start: what this guide covers. MGU Store is a free, open-source app store for BMW iDrive 7 head units (MGU hardware). It adds custom apps, including the M Vitals performance gauges, to cars whose head units already have root SSH access. Getting there takes three layers: first, a read-only compatibility check that changes nothing; second, a one-time flash of a debug package that enables root SSH (this is the step that wipes coding and Digital Key pairings); third, the Store install itself, which runs after SSH works. Compatibility depends on your head unit’s hardware and software version, not just your model or year, and recent project issue reports show some MainApp versions do not fit the current Store components. This guide is organized in four parts: verified project documentation, safe preliminary checks, advanced modifications that need special precautions, and features GarageTested has not yet tested. Nothing here has been run on our M340i.

Important disclaimer: read before you modify anything. Root SSH access requires modifying the factory MGU head unit. Flashing can wipe the head unit’s coding and CAFD definitions, delete BMW Digital Key pairings, remove stock apps, or leave settings that will not stay saved. In the worst case the developer states flashing can render the head unit unusable. Recent open issue reports describe settings resetting after a flash and coding restore, stock apps going missing, and one head unit stuck in programming mode. This guide reports those problems as open reports, not as proven universal defects, and it does not repeat the flashing or installation commands: for any step that changes the car, follow the developer’s maintained documentation linked in each section, after completing the backups and recovery plan described here.

BMW’s iDrive 7 head unit, known as the MGU, is a Linux computer with an Intel processor, a real GPU, and a full app platform hiding behind the menus you use every day. BMW ships its own apps on that platform. What BMW does not ship is a way for owners to add their own. MGU Store changes that. It is an app store that runs on the car’s own screen, installs community-built apps from GitHub repositories, web addresses, or a USB stick, and updates them the same way. The most interesting of those apps is M Vitals, a sport cluster with boost, fuel pressures, ignition timing, and temperatures, plus shift lights, a virtual dyno, drag timers, a G-meter, and a fault scanner that reads every control unit in the car.

Getting there is not a casual Saturday job. It requires root SSH access to the head unit, which means flashing a debug image over an ENET cable, and that flash wipes the head unit’s coding and deletes BMW Digital Key pairings. This guide walks through the whole chain in order, separates what is verified in documentation from what is still untested on our car, and starts with the read-only checks that tell you whether your unit is a candidate before anything is changed.

Contents

  1. What MGU Store Is, and Why iDrive 7 Owners Care
  2. Native MGU Apps vs. ConnectedDrive vs. CarPlay vs. Android Auto
  3. Which BMWs Are Compatible
  4. What You Need
  5. Step 1: The Read-Only Compatibility Check
  6. Step 2: Root SSH: Risks and Prerequisites
  7. Step 3: Installing MGU Store After SSH Access
  8. The Apps Available
  9. Building Your Own Apps
  10. Future Project: A Johnson Motorsports Performance Dashboard
  11. Troubleshooting and Common Questions
  12. Real-World Testing: 2020 BMW M340i xDrive (Placeholder)
  13. Frequently Asked Questions
  14. Sources
  15. Reported Problems Under Investigation

Table of Contents

What MGU Store Is, and Why iDrive 7 Owners Care

MGU Store is an app store for BMW iDrive 7 and iDrive 8 head units. Once installed, it appears as a tile among the car’s own apps. From the car’s screen you can browse apps and tools from your sources, install them, update them, and remove them. Updates never install on their own. Anything marked as needing a restart takes effect after a head-unit restart from the Store’s Settings page.

Installing the Store also installs the pieces that make the whole system work: the Store app itself, an updater that downloads and installs what the Store asks for, a deploy tool that performs every install and can roll it back, an app-privacy component that keeps installed apps out of the head unit’s reports to BMW, the renderer that draws the Store and other apps’ graphics, Python for apps the head unit builds from source, and an internet uplink that gives the updater and internet-capable apps a connection through a USB adapter, an LTE stick, a tethered phone, or Wi-Fi. A car without internet at all can still install and update from a USB stick.

The reason this matters to an owner is simple: the MGU already reads the data enthusiasts want. Engine speed, boost, fuel pressures, ignition timing, temperatures, gear, torque, g-forces, and tyre data all flow through the head unit on the car’s internal network. BMW’s own sport displays show a slice of it. Community apps show much more of it, at 60 frames per second, on the car’s own screen, using the iDrive controller and touch exactly the way BMW’s apps do.

The original project and the fork: do not mix them up

Two repositories carry the name mgu-store, and they are not the same project, even though their documentation currently reads the same.

RepositoryWhat it isRole in this guide
robertnisipeanu/mgu-storeThe original MGU Store project, by Robert Nisipeanu and IterioDev (GPL-3.0). Created October 27, 2026; 92 releases at the time of writing.The installer commands in this guide come from this repository. Follow it for installs.
cauliflowermossgrape/mgu-storeA fork of the original, created October 29, 2026. Its documentation currently mirrors the original, including installer commands that point back to the original repository.Useful as a mirror, but forks can drift. Do not assume it is identical, and do not install from it unless you have verified its current state.

The other two projects in this guide are originals, not forks. The custom apps collection lives at cauliflowermossgrape/idrive7-apps (MIT, with the GPU renderer under GPL-3.0 and Doom under GPL-2.0). The root SSH tool lives at cauliflowermossgrape/idrive7-8-ssh-root (public domain under The Unlicense). Each project contains a different piece of the chain: the SSH tool opens root access, the Store manages apps, and the apps collection supplies the apps themselves. No single repository does all three jobs.

One more scope note: the Store’s documentation states that iDrive 8 is tested in an emulator only, not yet on a real car, and that on iDrive 8, installs and removals take effect at the next head-unit restart. This guide focuses on iDrive 7, where the apps collection was developed and tested.

Native MGU Apps vs. ConnectedDrive vs. CarPlay vs. Android Auto

Four different things all put content on your BMW’s screens, and they are easy to confuse. Only one of them runs owner-installed software on the head unit itself.

SystemWhere it runsWhat it can showWho controls it
Native MGU appsOn the head unit, on BMW’s Online Apps Platform (OAP). Each app is a package running as its own Linux user under a Node.js host.Live vehicle data over the car’s internal network, BMW-style screens, full-screen GPU graphics.BMW by default; owners, after root SSH, through MGU Store or the apps kit.
BMW ConnectedDrive appsBMW’s backend services, delivered through the car’s telematics unit (TCB).BMW’s online services (weather, news, and similar backend apps).BMW. Access is gated by a BMW-signed provisioning file, and the head unit itself has no internet route of its own.
Apple CarPlayOn your iPhone; the car displays it.Your phone’s apps, mirrored to the car screen.Apple and the phone. CarPlay keeps working alongside the Store’s Wi-Fi uplink.
Android AutoOn your Android phone; the car displays it.Your phone’s apps, mirrored to the car screen.Google and the phone. One community app, AA Cluster Companion, adjusts how Android Auto’s Google Maps looks on the instrument cluster.

The practical difference is data access. A CarPlay or Android Auto app cannot read boost, fuel pressure, or ignition timing from the car, because the phone never sees the car’s internal network. A native MGU app can, because it runs on the head unit and talks to the car’s services directly. That is the entire point of MGU Store: it puts owner software on the same platform BMW’s own apps use, with the same vehicle data available to it.

Which BMWs Are Compatible

Compatibility depends on the head unit, not on the badge on the trunk. Two cars with the same model name and year can carry different head-unit hardware or software, and only the head unit decides whether this works.

What the documentation establishes:

  • Head unit: BMW MGU units running iDrive 7. The apps collection was developed and tested on firmware P18_23w44.2, and its documentation states that other MGU versions very likely work, with the installer’s check step confirming before anything is changed.
  • iDrive 8 variants: The root SSH tool covers iDrive 7, ID8-BDC3, and ID8-BCP. The Store covers iDrive 7 and iDrive 8, but iDrive 8 is emulator-tested only at the time of writing.
  • Hardware inside: The MGU is an Intel Apollo Lake x86-64 unit with an Intel GPU, running Linux, with a read-only root filesystem and a writable application area. If your car has an older non-MGU head unit (for example, the NBT or NBT Evo generations in earlier cars), this guide does not apply.
  • Software level matters: Some software levels behave differently. The SSH tool documents units on BTLD 030.016.006 / SWFL 030.016.002 that flash and enroll cleanly and open port 22, yet still refuse root login until a key repair is run. Your exact software level is therefore a test result, not an assumption.

Our test car is a 2020 BMW M340i xDrive (G20) with a factory MGU head unit and iDrive 7. That combination is the expected candidate, but it is not yet confirmed: the head-unit hardware identification and software version have not been recorded, and the read-only checks in Step 1 have not been run. Do not read this section as a fitment guarantee for any specific car, including ours.

What You Need

ItemWhy it is requiredStatus for our test car
ENET OBD2-to-Ethernet cableThe only connection the flashing and SSH steps accept. Wi-Fi adapters cannot carry the ENET flashing traffic, and the head unit is reached on a link-local address over this cable.Owned. [AFFILIATE PLACEHOLDER: Garage Tested has no existing ENET cable link; add a verified link here before publication.]
Computer: Windows 10/11, macOS, or Linux (x64 or arm64)Runs the SSH tool, the Store installer, and the apps kit. Apple Silicon Macs are supported.MacBook Pro M2 (arm64). Owned.
Ethernet adapter for the computerModern laptops, including the MacBook Pro M2, have no Ethernet port. A USB-C Ethernet adapter bridges the ENET cable to the laptop.[AFFILIATE PLACEHOLDER: no existing Garage Tested link found; add a verified USB-C Ethernet adapter link here.]
Software and dependenciesOpenSSH client (built into Windows 10/11, macOS, and Linux); Python 3.9 or newer for the SSH tool from source (or the prebuilt Windows .exe, which needs no Python); Python 3.6+ and Node.js 14+ for the apps kit; Node.js 18+ for the script form of the Store installer.To be installed and version-checked during testing.
Stable vehicle battery powerThe car must stay parked and powered until each install finishes. The apps kit recommends a battery charger connected during install. A voltage drop mid-flash is exactly how modules get bricked.[AFFILIATE PLACEHOLDER: no existing Garage Tested battery maintainer link found; add a verified link here.]
Root SSH access to the MGUThe prerequisite for everything else. Established once with the SSH tool (Step 2), then reused for the Store and the apps.Not yet established. Untested on this car.
USB stick (optional, for offline installs)A car without internet can install and update the Store and apps from a USB stick prepared on the computer.As needed.

Windows users should note one extra requirement from the SSH tool’s documentation: run the terminal or the app as Administrator, so Windows uses the link-local address on the ENET adapter. On macOS and Linux, the OpenSSH client is already present; verify it with ssh -V before you start.

Step 1: The Read-Only Compatibility Check

Safe preliminary checks: the commands in this section read information from the car and change nothing on it.

Do this before you flash anything, and do it in this order. Both checks below are read-only: they change nothing on the car. If either one reports something unexpected, stop and investigate before moving on.

Check A: the SSH tool’s status probe

With the ENET cable connected and the car awake (ignition on), run the SSH tool’s status command from the project directory:

python ssh_enable.py status

Per the developer’s documentation, this command reads the current state without changing it: the head unit’s software version (SVK), the head unit’s IP address, the debug-state fault code (B7F8E5), and a probe of port 22. It also tells you whether the tool can reach the unit at all. Record every line of its output. The software version it reports is the single most useful compatibility fact about your car, because later troubleshooting (including the refusing-key repair in Step 2) keys off software levels.

On Windows, the same tool is available as a prebuilt .exe (MGU-SSH-windows.zip from the project’s Releases page), run as Administrator. From source, install its one dependency first:

pip install -r requirements.txt

Check B: the apps kit’s check step

The apps collection’s installer has its own read-only step. After packing the kit (covered in the building section below), run the check variant before the install variant. On macOS, Linux, or WSL:

HU=root@<unit-ip> PORT=22 KEY=~/.ssh/id_mgu deploy/push-to-car.sh check

On Windows PowerShell:

powershell -ExecutionPolicy Bypass -File deploy\push-to-car.ps1 check -Key <path>\id_rsa -Ip <unit-ip>

The documentation states that this check inspects the unit and lists what the install would touch, and that the install’s first step test-builds the MainApp patch for your exact firmware and stops before changing a file if anything is unexpected. If you are installing from a USB stick with no network, the on-unit equivalents are sh deploy-car.sh check followed by sh deploy-car.sh install.

What these checks do not do: they do not guarantee that every app will work on your car. Individual apps read different vehicle signals, and a signal your car does not send simply does not appear. The apps handle that gracefully (an item with no data gives its space to the others), but “the check passed” is not the same as “every gauge will populate.” That is what the testing section exists to record.

Before you go further: back up, and make a recovery plan

Do not flash before you have all three of the following:

  1. A full coding backup of the head unit, made with a coding tool before the first flash (Step 2 explains why).
  2. The SSH key bundle the tool writes for your car, stored somewhere safe. Those private keys are what get you into the unit. Treat them like passwords, and never photograph, screenshot, or publish them.
  3. A written way back: the apps kit’s restore command returns the apps to stock, and the SSH tool’s disable command reverts SSH persistence and stops the debug service. Know both commands before you need them, not after.

Step 2: Root SSH: Risks and Prerequisites

Advanced modification, special precautions required: this section describes a step that reprograms the head unit. The exact flashing commands are not repeated here; they live in the developer’s maintained documentation, linked below. Complete every backup in this section before you touch them.

Root SSH is the key that unlocks everything else, and it is also the step with real consequences. Understand all of them before you run it.

What the tool does

The SSH tool, run once per head unit, flashes a small debug package (a developer certificate plus the debug-mode binaries, roughly 131 KB, bound to your VIN), enrolls the SSH identity, makes SSH persistent, and turns debug mode off. After a successful run, root SSH keeps working on every boot, with debug mode off and without the B7F8E5 “debugging active” fault code. The tool is then out of the picture: day-to-day SSH is the car’s own persistent service, and you simply connect over the ENET cable.

The recommended path is the GUI (run python gui.py, or the prebuilt Windows .exe), with its single “Flash + Enable” button. The command-line equivalent is documented in the SSH tool’s README, follow the maintained instructions there rather than copying a command from this article, and run the flash exactly once per unit.

The VIN must match the car, because it is written to the head unit. The tool finds the gateway automatically (default 169.254.254.36:6801, discovered by UDP broadcast), and it writes the root SSH key bundle, in every format you might need, under a folder named for your VIN, together with a connect file holding the head-unit IP and a ready-to-run SSH command. A typical connection then looks like:

ssh -i data/enrollments/<VIN>/id_rsa root@<head-unit-ip>

The IP can change with the DHCP-less link-local setup, so if a connection is refused, re-run the status probe rather than assuming the address is still correct.

Flashing wipes coding: back it up first

The developer’s warning is explicit and is based on a real car during development: flashing reprograms the head unit and wipes its coding and CAFD definitions. You will lose your saved settings. Before the first flash, read and save the head unit’s coding with a coding tool. The documentation reports BimmerCode working for this (connect, select the head unit, export and save its coding), and notes that BMW dealer tools such as ISTA or E-Sys can also save a full backup. After flashing, if functions misbehave or coding looks reset, restore the saved coding with the same tool. A restore from backup fixed the development car’s issue.

Only the flashing steps carry the reprogramming risk. The repair and status operations (enable, persist, close, disable, status) do not reflash the unit, but re-activating debug mode still deletes the local login and resets the head unit, which is one of the reported causes of settings not staying saved (see Reported Problems Under Investigation, below).

Flashing deletes BMW Digital Key pairings

Yes, confirmed on a real car and tracked as issue #13 in the project: after a flash, a phone’s digital key was gone and had to be set up again as new. The coding backup does not cover digital keys. Plan on re-pairing every digital key after any flash, including the key-repair flash below.

Worst case: a bricked head unit

The developer’s disclaimer states it plainly: in the worst case, flashing can brick the module. That is why the prerequisites in this guide are not optional extras. Stable battery power, the correct VIN, the exact documented commands, and a coding backup are the difference between a recoverable mistake and a dead head unit. If you are not comfortable accepting that risk on your own car, stop here. Nothing later in this guide is worth a head unit you cannot afford to replace.

Never re-flash “to be safe”

This is the mistake the documentation warns against most directly. After the first successful run, there is nothing to re-enable. Re-flashing rewrites the unit and wipes its coding and Digital Key pairings again, for no benefit. Re-flash only if you changed the head unit’s software. If SSH simply stopped answering, use the tool’s repair command, which re-opens SSH without flashing (see the README linked above).

Do not press the repair option if SSH already logs in: it re-activates debug mode and brings the B7F8E5 fault code back.

If login is refused after a clean flash

On some software levels (documented on BTLD 030.016.006 / SWFL 030.016.002), the flash and enrollment both succeed and port 22 opens, but root login is still refused with “Permission denied (publickey).” The cause is that the key the unit’s SSH daemon trusts lives in a signed system file that a normal flash does not overwrite, and on those units it holds a different key. The repair is the tool’s key-fix procedure, documented in the README and tracked as issue #2 in the project, which re-runs the same proven debug flash but carries the tool’s key in the one unsigned region of the flash image:

Like any flash, it writes the VIN, reboots the unit, and clears CAFD coding, so restore coding from backup afterward, and keep the verbose log of the first run. The developer notes the realistic worst case of this repair is simply that the key does not take, not a brick.

Security implications you should understand

Root SSH on the MGU is authorized against one fixed key baked into the flashed debug image. That key is the same across cars unless you deliberately change it, which means anyone with physical ENET access to the car and a copy of that key could log in as root. The tool offers an optional per-car unique key, but it is off by default and not recommended by the developer: the swap can only be done once, and if you reflash, re-run the tool, or lose the per-car key, you may lose SSH access entirely. The practical defenses are physical and procedural: the attacker needs hands on your car’s OBD port and cable, the private key bundle is yours to guard, and the Store’s phone-access page should be turned off when you are done using it. Separately, the Store’s app-privacy component keeps installed apps out of the head unit’s reports to BMW, but that is a report filter, not invisibility: a dealer scan of the unit itself will still see modified software.

Warranty

Modifying head-unit software can affect warranty coverage for related components, and a dealer may decline warranty work on a modified unit or charge for diagnosis tied to the modification. This guide makes no legal claim about your specific warranty, which depends on your contract, your jurisdiction, and the failure in question. If your car is under warranty and that matters to you, weigh that risk before flashing, and keep your coding backup and a record of the stock state so you can return the unit toward stock (apps restore plus SSH disable) before any dealer visit.

Step 3: Installing MGU Store After SSH Access

Advanced modification, special precautions required: the installation commands are not repeated here; run the installer exactly as documented in the original repository’s README, linked below, after SSH access works.

Status: this procedure has not been tested on our 2020 M340i. What follows is a summary of the developer’s documented procedure for the original MGU Store repository, verified against the current README at the time of writing. The installation commands themselves are not reproduced here: run them exactly as published in the original repository’s README, because this project is weeks old and moving fast, and a wrong character here matters.

Requirements, restated from the Store’s documentation: a computer (Windows 10/11, macOS, or Linux, x64 or arm64) with the OpenSSH client; root SSH access to the head unit and root’s private key; a route to the head unit’s SSH (the car’s Wi-Fi hotspot, default address 172.16.222.97, ENET, or any other SSH route); and the car parked and on stable power until the install finishes.

Connect the computer to the head unit, then run the installer from the original repository’s README with root’s SSH key, choosing the command for your computer (macOS/Linux, Windows PowerShell, or the Node.js 18+ script variant).

Substitute the path to the actual key file the SSH tool saved for your car wherever the examples show ~/.ssh/mgu_root_key. The installer finds the head unit by itself and reports which connection it used. When it asks “Restart the head unit now? [y/N]”, answer y. It restarts the head unit, the Store’s tile appears among the car’s apps, and every later update comes through the Store.

Useful installer options, from the same documentation: --host and --port to reach the head unit at a specific SSH address (port 22 unless given); --user to change the SSH user (default root); --ssh-opt for an extra ssh option, repeatable; --token to be asked for a GitHub token for private repositories; --no-uplink to leave out the internet uplink; --no-renderer to leave out the renderer; and --no-restart-prompt to end without asking to restart.

Once installed, the Store’s side menu has four pages: Store (apps and tools from your sources, with their state), Installed (what is installed, with Update and Update all), USB (what a plugged-in USB stick offers), and Settings (sources, Wi-Fi, accounts, phone access, Check now, and Restart head unit). The Store ships with default sources: its own repository, the idrive7-apps collection, the idrive-apps repository (including the renderer that draws on the instrument cluster and the head-up display, and the CarPlay map on the instrument cluster), and IterioDev’s car-apps (most of them for iDrive 8 only, at their newest version tag). To add a source, go to Settings, Add source, and type owner/repo, a GitHub link, or the address of a catalog.json file. For a GitHub repository, choose whether to follow its Releases, Tags, or one of its branches.

Internet for the car comes through the uplink: a USB Ethernet adapter, an LTE stick (the documentation gives the Huawei E3372h as an example), an Android phone with USB tethering, an iPhone with Personal Hotspot on and kept unlocked (tap Trust when asked; note that its USB music playback stops while it tethers), or Wi-Fi such as a phone’s hotspot. The car’s own hotspot and wireless CarPlay keep working beside it. One documented limitation: on iDrive 7 units with a Broadcom radio, WPA3-only networks cannot be joined. The Store shows Online once connected.

For a car without internet, prepare a USB stick on the computer with the Node installer, plug it into the car, and use the Store’s USB page. A car that does not have the Store yet can install it from the same stick folder with no internet at the car, using the installer’s USB install option documented in the README, pointed at the stick’s repository folder. Private repositories need an account in Settings, Accounts: either Sign in with GitHub (scan the QR code and enter the code on your phone, with the mgu-store GitHub App installed on the repository) or a GitHub token with read-only Contents permission on only the selected repositories, which is easier to type on the phone page or from the computer than on the car.

The Apps Available

Features not yet tested by GarageTested: everything in this section describes the developers’ apps from their documentation. None of these apps have been run on our car.

Availability below reflects the default sources the Store ships with and the apps collection’s documentation at the time of writing. Functionality notes are the developers’, not ours: none of these apps have been run on our car yet. Every app has a settings screen in BMW’s own HMI style, with four color themes (M Tricolour, M Red, Ice White, Night Amber), unit choices, and a demo mode. Results and records are saved on the unit and kept across reboots, and everything can be removed again with one command.

The technical reason these apps look smooth is worth knowing before you judge them. BMW’s app platform normally draws custom graphics by handing the HMI a compressed PNG image, which tops out at a handful of frames per second on the head unit’s processor. These apps instead ship with a GPU render engine that sends a few kilobytes of drawing commands per frame to be drawn on the head unit’s Intel GPU, on its own compositor layer, in step with the display’s refresh, for a true 60 frames per second. Without the renderer installed, the same apps fall back to the PNG path automatically, with the same look at a lower frame rate.

M Vitals: the sport cluster

M Vitals is the centerpiece for a performance owner. Across several pages it shows rpm, boost, speed with gear, power (from the iDrive sport display’s percentage times your car’s maximum power, so stock and tuned engines both read correctly) and torque, coolant and oil temperature, g-forces, and peak values. A fuel and ignition page shows intake air temperature, high-pressure fuel (HPFP / rail) and low-pressure fuel (LPFP) pressure, ignition timing, boost target against actual boost, requested against actual air charge with a five-minute trace, and the misfire counter of every cylinder for the current driving cycle. The chassis page shows tyre pressures against the car’s target, tyre temperatures, and an xDrive card that reads the torque split from the car or estimates it from engine torque and gear (and says which one it is doing). Each item has an Auto, Show, or Hide setting: Auto shows it once the car has sent real data, and anything the car does not answer is left out rather than faked.

[Photo placeholder: M Vitals engine page on the iDrive screen, showing rpm, boost, and temperatures. Capture during testing; do not substitute project screenshots without checking the repository’s license and attribution.]

Redline: shift lights and a full-screen rev display

Redline is a G20-style rev display: a wide rev bar that fills in slanted segments toward your shift point, digital rpm, a large gear readout, digital speed, and a 12-LED shift-light bar. At the shift point the lights, gear, and SHIFT prompt turn solid red. Every upshift is scored (early, spot on, late, or limiter), with a shift log and accuracy statistics. A cold-engine guard lowers the shift point until the oil is warm, and cold oil is always flagged.

Virtual Dyno, Brake Test, Drag Timer, G-Force, Warm-Up

  • Virtual Dyno: Do a full-throttle pull in one gear and get a power and torque curve, calculated from acceleration, car weight, air drag, and rolling resistance, with settings for weight, body shape, drivetrain loss, and units. Runs are saved, and one can be pinned as a baseline to show the difference on every new pull.
  • Brake Test: 100-0 and 200-0 km/h (or 60-0 and 100-0 mph) distance, time, peak deceleration, and a deceleration trace, with a brake-fade chart that compares recent stops and warns when distances grow.
  • Drag Timer: 0-50, 0-100, 100-200, and 0-200 km/h splits plus the quarter mile (or mph equivalents), with interpolated splits, an optional one-foot rollout, a live speed trace, and saved best times.
  • G-Force: A friction circle with a fading trail and a grip envelope that grows as you use more grip in each direction, with live lateral and longitudinal bars, session peaks, and all-time records.
  • Warm-Up: Oil and coolant gauges plus a warm-up calculator (minutes until working temperature, from the measured warm-up rate), a safe rev limit that rises with oil temperature, and a turbo cool-down countdown after hard driving.

Fault Scanner, Service, Live Data, eDrive

  • Fault Scanner: Scans every control unit for stored fault codes over the head unit’s diagnostic gateway, shows them per module with status and live Check Control messages, and can clear fault memories with a two-press confirm. Read the codes first: clearing fault memories in all modules can make control units restart, and the head unit itself may reboot.
  • Service: The car’s Condition Based Service requirements as iDrive’s own Vehicle status screen shows them, colored green, yellow, or red. Read-only: these cars offer the head unit no service reset.
  • Live Data: Custom screens of dials, sport-display bars, and large numbers built from the car’s signals, plus a trip computer and a raw engine-values view. Its decoding is documented as built in for the B58, B48, and B38 engine control units, which is directly relevant to our B58 car, but whether it covers our specific B58 generation is a testing item, not an assumption.
  • eDrive: For plug-in hybrids and EVs only: adaptive real electric range, battery health, charge log, and live battery power and cell data. On a car without a hybrid system it detects that the battery unit never answers and shows only the 12-volt battery. Not applicable to our M340i beyond that 12-volt reading.

Engine Config, AA Cluster Companion, Transmission Config, Doom

  • Engine Config: Live engine tweaks as tabs, starting with the exhaust flap (open, closed, or handed back to the car), which ships Disarmed (simulated, touches nothing) and must be deliberately Armed after you validate the command on your own car. Its tuned-DME tabs (BM3 and MHD engine maps, burbles, Max Cooling) and its xDrive-off switch are marked experimental, and some items (burble aggression read-back, engine-map read-back) are documented as not yet tested on a car. Treat this app as the highest-caution item in the collection: it sends control and write requests to the drivetrain.
  • AA Cluster Companion: Adjusts how Android Auto’s Google Maps looks on the instrument cluster (map size and whether the phone’s turn card shows). It only controls a separate tool that must be installed first; without it, the app shows a demo and says what to install.
  • Transmission Config (experimental): Reads ZF 8HP clutch adaptations, shift maps, temperature history, and live transmission data. Read-only, requires the verified gearbox variant, and carries an EXPERIMENTAL badge with only limited smoke testing so far.
  • Doom: Freedoom: Phase 1 running as WebAssembly in full resolution across the screen, driven by the iDrive controller. Parked only by default: the game saves and waits while the car drives. A fun proof of what the platform can do, and a reminder to keep your eyes on the road.

Two honest limitations from the developers apply to the whole collection. Calculated values (dyno power, brake distance) are only as good as the car’s speed and acceleration sensors, so compare against known figures and do runs on flat road. And there is no dashcam app: recording the cameras would need BMW’s Drive Recorder service, which requires BMW provisioning that these apps cannot provide.

Building Your Own Apps

For a technically inclined owner, the apps collection is also a complete development kit. An app is two files in its own folder: app.json (what the app is: id, title, version, icon, the vehicle signals it subscribes to, its screens, and its settings) and main.js (what it does: the drawing code, the render loop, and the button handling). A build tool generates the BMW package around them, including the screen descriptions, entry point, icon, text bundles for one fixed interface language and all 33 head-unit locale tables, manifest, permissions, and runner.

The workflow the documentation lays out is: extract BMW’s app SDK from your own head unit (it is BMW’s copyrighted code, so it is not in the repository; a tool rebuilds it in seconds from a preinstalled app copied off the unit, and it must never be committed to git); build with the kit’s build tool; preview on your PC with a tool that runs the built app against a stubbed head unit and demo data, saving every frame as an image; or run the live emulator, which builds the app, runs it with the real runtime, and draws it in the browser with the car’s own draw engine compiled to WebAssembly, at up to 60 frames per second, with mouse and keyboard standing in for touch and the iDrive controller. Then pack a kit, push it to the car over SSH, and install it the same way as the shipped apps.

Three kit details matter for anyone planning a custom app. First, check your signal flags against the catalog copied from your own unit: the unit’s installer refuses a read flag on a field without a getter, and a tool in the kit checks every app’s signal list against that catalog. Second, the kit’s car-data helper groups the common signals (rpm, speed, temperatures, acceleration, gear, torque) and filters invalid raw values, with an automatic demo fallback when no car data arrives for five seconds, clearly badged DEMO so simulated data is never mistaken for real data. Third, anything you build contains BMW’s SDK in the package, so keep built packages for your own car and do not publish them.

On the PC side, the kit needs only Python and Node.js: no Linux, no compiler, no Docker, and no npm packages. Docker is only needed if you recompile the GPU renderer’s C code yourself, and the renderer ships prebuilt in the repository.

Future Project: A Johnson Motorsports Performance Dashboard

Status: proposed, not built. The plan is a Johnson Motorsports performance dashboard app for the M340i, showing boost, fuel pressures, temperatures, ignition timing, and ethanol content on one screen, in the same visual language as the existing apps. None of this functionality exists yet, and no part of it should be read as completed.

Four of the five proposed signals are already documented in the existing apps, which is why this project is plausible:

Proposed gaugeDocumented source todayStill to confirm on our car
BoostM Vitals reads boost from the sport display, or from the engine control unit over OBD as a fallback.Which source our car actually answers, and sane scaling for a tuned B58.
Fuel pressures (HPFP / LPFP)M Vitals reads high- and low-pressure fuel pressure from DME data IDs, with an OBD fallback.That our DME answers those IDs, and the correct scaling.
Temperatures (coolant, oil, gearbox)M Vitals and Warm-Up read coolant, oil, and gearbox temperatures from the engine and gearbox units.Gearbox temperature availability on our ZF 8HP.
Ignition timingM Vitals reads ignition timing from the DME, with per-cylinder misfire counters.Per-cylinder timing availability on our DME variant.
Ethanol contentNot in the documented signal set. Neither the apps’ signal reference nor the M Vitals fuel page lists an ethanol content signal.Everything: whether the B58 DME exposes ethanol content over a data ID or OBD PID, and what scaling it needs. This is the gating question for the dashboard.

The confirmation path is built into the kit: copy the service catalog from our own unit, explore it with the kit’s signal documentation tool, and check the candidate signals against what the car actually sends, using the Live Data app’s raw engine-values view as a cross-check. If ethanol content has no documented source on this car, the dashboard ships without it, or with a clearly labeled manual entry, rather than a fabricated reading. A performance gauge that invents data is worse than no gauge at all.

Reported Problems Under Investigation (Checked November 3, 2026)

The reports below are open GitHub issues, not confirmed universal defects. They are included because they change the risk picture for specific cars and firmware versions. Check the linked issues for your head-unit software version before proceeding, and treat any fix on a development branch as unreleased until it appears in a tagged release.

  • Settings resetting after a flash and coding restore (SSH tool, issue #10, open since October 30, 2026): several owners, including a 2022 X5 45e and a 2020 330e, report head-unit and cluster settings, including shortcut buttons, emergency-braking defaults, and drive-mode popups, resetting after the car sits. The developer explains that enabling debug mode forces a factory reset, so coding must be restored; working theories include an incomplete restore (BimmerCode versus E-Sys VO-coding) and debug-mode activation deleting the local login (one owner reported settings persisting after logging out of and back into the BMW account). Stock apps, including weather and clock, were also reported missing after a flash and restore. Root cause is not confirmed; the issue is open. Issue #10
  • Head unit stuck in programming mode (SSH tool, issue #18, November 2, 2026; 2023 G07 X7 LCI, iDrive 8/BCP): the gateway returned HSFZ 0x0043 after the frame-11 reset. The developer’s analysis says the tool’s fixed 3.5-second post-reset pause is too short for BCP, no flash data was sent, and the unit was likely not bricked, but it was left sitting in the programming session. A fix exists on a development branch and is not confirmed in a release. Issue #18
  • Store components not fitting some MainApp versions (original MGU Store, open issues): 4 stock apps missing after back-to-back installs (MainApp 8.2.8); a Store that never installed plus a rollback restore that failed once (MainApp 7.1.2); app-privacy not fitting MainApp 8.2.0 (including a G20), 8.2.8, and 6.4.8; App Manager not running (G21, MainApp 8.3.2); and a CarPlay cluster patch failing (firmware E_19w44.1, G01). Check the open issues for your MainApp version before installing. MGU Store open issues
  • Experimental xDrive-off limits (apps collection, issues #52 and #63): on a G05 45e the write was accepted but all-wheel drive stayed engaged, and the newer VIP path was still refused on security access; a G26 440i reported a security-access refusal. An accepted write is not proof the drivetrain changed. Apps collection open issues
  • Touchscreen controls: no report of unresponsive touchscreen controls was found among the open issues checked on November 3, 2026. The closest adjacent report is apps issue #54 (page selectors not appearing after install; input method under triage). Issue #54
  • Safety note: paid “fix my MGU” offers appeared inside the settings-reset thread; the project developer declined that route publicly. Never give a stranger remote access to your car.

Troubleshooting and Common Questions

Before you touch anything

  • Can I check compatibility without changing anything? Yes. Run the SSH tool’s status probe, then the apps kit’s check step. Both are read-only. Do not skip them.
  • Do I need to flash to use the apps? Yes, in practice: the apps need root SSH, and root SSH needs the one-time flash. There is no documented path to these apps without it.
  • Can I go back to stock? Yes, in two parts. The apps kit’s restore command stops the platform, removes every custom app, the hook, and the boot drop-in, and restores every touched file from the first stock backup, which is never overwritten, verifying each file against it. The SSH tool’s disable command reverts SSH persistence and stops the debug service. Note that restore removes the apps; it does not un-flash the debug image itself, and it does not restore Digital Key pairings.
  • Will a BMW firmware update break this? After a firmware update, the apps are installed but hidden, because the provisioning hook refuses to patch an unknown MainApp version. Run the install again to rebuild the hook for the new firmware. Re-check the projects’ documentation after any update before reinstalling.
  • Is this legal? Will it void my warranty? This guide makes no legal claims. Modifying head-unit software can affect warranty coverage for related components, and a dealer may charge for diagnosis tied to a modification. Consider that risk before flashing, and keep your coding backup and a record of the stock state.
  • Does it cost anything? The software is free and open source: MGU Store under GPL-3.0, the apps collection under MIT (renderer GPL-3.0, Doom GPL-2.0), the SSH tool in the public domain. Your costs are the cable, the adapter, and your time. Anyone selling you these apps is reselling free software.

SSH and flashing problems

  • Login refused with “Permission denied (publickey)” after a clean flash: See Step 2. On some software levels the unit trusts a different key than the one the tool hands you. Run the tool’s key-fix procedure documented in the README, then restore coding from backup.
  • SSH stopped answering after working: Use the repair command (enable), not a re-flash. Then re-run persist if you want SSH to survive debug mode being off again.
  • Digital key gone after flashing: Expected and documented (issue #13). Set the key up again as new. The coding backup does not cover it.
  • Debug fault code B7F8E5 present: Debug mode is active. The persistent-SSH setup turns debug mode off by default and the code clears. If you deliberately keep debug on, the code stays.
  • Connection refused or wrong IP: The head-unit IP can change with the link-local setup. Re-run the status probe. On Windows, confirm you ran as Administrator so the link-local address is used.

Store and app problems

  • A tile shows “Loading app” forever: The app’s process is not reaching the HMI. Check the app’s log on the unit and the installer’s status command output.
  • An app vanished after crashing: That is the platform’s crash handler: it wipes an app’s data on an unexpected exit and uninstalls it on the second. Fix the crash, then install again. Never kill an app process by hand; restart the app platform instead.
  • Tiles are there but no app opens: The SDK created no screens for the app. This was a documented issue with SDKs extracted from newer donor apps (issue #39); the current build tool enables the required loading flag in every app’s config. Rebuild and reinstall, and restart the head unit if apps that already crashed still do not respond to taps.
  • A removed app’s tile is still shown: The HMI caches tiles. The restore command restarts the HMI service and the platform to clear this; a reboot does the same.
  • “Interface generation failed … no getter available” during install: A read flag is set on a field without a getter. Run the kit’s signal-check tool and change the flag to subscribe.
  • Everything shows DEMO in the car: The app got no data for that signal group for five seconds. Check the log, and confirm the ignition is fully on: with the head unit merely awake, much of the vehicle data is not sent.
  • On iDrive 8, typing does not work on some Store screens: Documented: on the Store’s widget screens without the renderer, add sources and tokens from the phone page or the computer, or use Sign in with GitHub.
  • On iDrive 7 with a Broadcom radio, a WPA3-only network cannot be joined: Documented limitation of the Wi-Fi uplink. Use a WPA2 network, a phone hotspot, or a USB route instead.

Real-World Testing: 2020 BMW M340i xDrive (Placeholder)

This section is intentionally empty. The procedure in this guide has not been tested on our car. Nothing below has been filled in, and nothing in the rest of this article should be read as a test result. This section will be completed only after hands-on testing, with real values, real screenshots, and real problems.

  • MGU hardware identification: [To be recorded: head-unit part number and hardware variant, from the unit and the status probe.]
  • Software version: [To be recorded: SVK / BTLD / SWFL versions from the status probe output.]
  • Compatibility-check results: [To be recorded: full output summary of the status probe and the kit check step, and whether either reported anything unexpected.]
  • Installation results: [To be recorded: coding backup method and confirmation, flash outcome, SSH persistence and debug-mode state, Store install outcome, head-unit restarts required.]
  • Apps tested: [To be recorded: each app installed, with the signals that populated and the signals that did not.]
  • Screenshots: [Photo placeholder: iDrive screen showing the Store tile among the car’s apps.] [Photo placeholder: M Vitals pages with live data on the M340i.] [Photo placeholder: Redline shift lights during a drive.] [Photo placeholder: ENET cable connected to the OBD port and the MacBook Pro M2.] Never include private keys, VIN-key material, or full VINs in any photo.]
  • Problems encountered: [To be recorded: every error, workaround, and unresolved issue, including any Digital Key re-pairing and coding restore steps.]
  • Final recommendation: [To be written after testing: who should do this, who should not, and what we would do differently.]

Frequently Asked Questions

What is MGU Store?

An app store for BMW iDrive 7 and iDrive 8 head units. It installs, updates, and removes community-built apps from the car’s own screen, from GitHub repositories, web addresses, or a USB stick.

Is MGU Store made by BMW?

No. It is an unofficial, open-source hobby project by Robert Nisipeanu and IterioDev, with a separate apps collection and SSH tool by cauliflowermossgrape. It is not affiliated with, endorsed by, or supported by BMW AG.

Will it work on my BMW?

Only if your car has a compatible MGU head unit. Compatibility depends on the head unit’s hardware and software, not just the model or year. Run the read-only checks in Step 1 before changing anything.

Do I need an ENET cable?

Yes for the flashing and SSH steps. Wi-Fi cannot carry the ENET flashing traffic. A USB-C Ethernet adapter is needed if your computer has no Ethernet port.

Will flashing delete my settings?

Flashing wipes the head unit’s coding and deletes BMW Digital Key pairings. Back up coding first with a coding tool, and plan on re-pairing every digital key afterward.

Can I remove everything and go back?

The apps can be fully removed with the kit’s restore command, which restores from the first stock backup. SSH persistence can be reverted with the SSH tool’s disable command. Digital Key pairings must be set up again as new.

What apps are available?

M Vitals (sport cluster with boost, fuel pressures, ignition timing, temperatures), Redline (shift lights), Virtual Dyno, Brake Test, Drag Timer, G-Force, Warm-Up, Fault Scanner, Service, Live Data, eDrive (hybrids), Engine Config, AA Cluster Companion, Transmission Config (experimental), and Doom (parked only).

Can I build my own app?

Yes. The apps collection includes a complete kit: define the app in app.json, write its behavior in main.js, build it, preview it on your PC or in the live emulator, and push it to the car over SSH. The SDK must be extracted from your own head unit and must never be published.

Does the Johnson Motorsports dashboard exist yet?

No. It is a proposed project. Boost, fuel pressures, temperatures, and ignition timing are documented signals in the existing apps, but ethanol content is not in the documented signal set and must be confirmed on the car before it can be promised.

Sources

Documentation reviewed November 3, 2026. These projects are weeks old and actively developed; re-check the repositories before running any command, and treat anything that has changed since this review as newer than this guide.

Keep Reading

Scroll to Top