EF-Map has technically loaded on phones for a while. That was not the same as being usable. The map appeared, you could pinch and pan, but the moment you opened anything useful the desktop layout fought back. This is the story of how EF-Map became something you can actually use on a phone, and why the answer was to reuse what already existed instead of building a second product.
Why phones were bad before
The honest starting point: the EVE Frontier map already ran in a mobile browser. The 3D starfield rendered, gestures worked, and you could fly around the galaxy. What did not work was everything you'd actually want to do once you got there.
EF-Map's interface is built for a desktop window manager. Routing, Intelligence, the Blueprint Calculator and the rest live in draggable panels and floating windows sized for a 1440p monitor. On a phone, those panels were crushed into slivers, the toolbar chrome ate the top of the screen, and dialogs that assumed a mouse and a wide viewport were hard to even close. The data was all there. Reaching it was miserable.
That gap mattered more over time. As we leaned into shareable Intelligence Cards with QR codes and short links, more of those links were being scanned on phones. A route or an intel card someone opens on their phone should lead somewhere usable, not to a desktop UI folded in half.
The wrong first instinct
People had been asking for a better phone experience for a while, so we ran a proper mobile audit. The audit (and, candidly, the LLMs helping with it) kept gravitating toward the same shapes: gate the phone experience behind a notice, ship a read-only companion, or "build a mobile version." Each of those is a reasonable-sounding answer, and each one quietly assumes you are willing to maintain a second thing.
That is the trap. A separate mobile app or a read-only companion means two codebases, two sets of business logic, and two places every future feature has to land. For a project that ships features constantly, duplicate maintenance is how a mobile experience slowly rots while the desktop one races ahead.
The pushback that mattered
The maintainer's call was blunt: do not build and maintain a separate mobile app alongside the desktop app if the existing feature panels can be reused. If the architecture allows reuse, reuse it.
The decision that mattered
The reframing was simple but it changed everything: one feature implementation, two hosts. Keep a single implementation of Routing, Intelligence, System Finder, Blueprint Calculator and Smart Assemblies. Don't fork them. Instead, change what wraps them. On desktop, the wrapper is the familiar window-and-toolbar chrome. On a phone, the wrapper becomes a mobile host that strips the desktop chrome away and presents the same feature content in phone-friendly sheets over the live map.
Crucially, this is not a cut-down database or a separate site. The real EF-Map experience still loads underneath the mobile host. The full universe and the full EVE Frontier dataset remain available; the host just changes how you reach them on a small screen, leaning on performance-friendly defaults where that helps.
Why the old panel design paid off
This only worked because of a design choice made long before mobile was on the table. Over time, many EF-Map panels were deliberately kept portrait-shaped and vertically flowing rather than spreading sideways into wide desktop dashboards. Routing reads top to bottom. Intelligence is a stack of cards. The Blueprint Calculator, System Finder and Smart Assemblies all flow down the page.
A panel that already flows vertically is, structurally, most of the way to a mobile sheet. There was no fundamental relayout to fight. Once the desktop frame was replaced with a mobile host, a surprising number of existing features simply worked on a phone, in a matter of hours and iterations rather than weeks. The payoff for keeping panels portrait-shaped showed up months later, in a feature nobody had planned for at the time.
What changed under the hood
The mobile host is a map-backed shell rather than a new app. The map stays live behind everything. Desktop chrome (the floating toolbar, the window manager, the draggable panels) is removed. In its place:
- A bottom navigation bar to switch tools, sized for thumbs.
- Full-width mobile sheets that host the existing feature content directly.
- Tap to select a system, and long-press for system actions like setting origin or destination straight from the map.
- A back-to-universe path so you never get stranded inside a sheet.
What there is not is a parallel set of business logic for the key tools. Routing still uses the same routing engine. System Finder still queries the same data. The mobile host is presentation; the brains are shared. That is the whole point, and it's the same instinct behind our earlier decision to keep one large coordinator component instead of splitting it for the sake of splitting.
What works on a phone today
This first pass already covers most of what people open EF-Map to do:
- The live 3D map, with tap-select and long-press system actions
- Setting origin and destination directly from the map
- Routing
- Search
- Intelligence cards
- System Finder
- Blueprint Calculator
- Smart Assemblies
- State of the Frontier
- Shared route and Intel links: the QR codes and short links people scan on phones now lead somewhere usable
What is still rough
This is a first satisfactory pass, not the final word, and it's worth being candid about the edges.
- It is not a native app. It's the web experience, reshaped for a phone.
- For now, the full desktop app still loads behind the mobile host rather than a lean mobile-only bundle.
- Some dense surfaces (Killboard, Leaderboards and similar data-heavy views) are still better handled separately and will come later.
- Real phones, browsers and foldables vary wildly. Some of the remaining rough edges will only surface through actual feedback from actual devices.
Where the AI workflow helped, and where it didn't
LLMs did a lot of the legwork here. They were genuinely useful for the mobile audit and for the implementation passes, and Claude Code Cowork helped inspect the existing experience and reason about what could be reused. The overall loop is the same one we use elsewhere: audit, chunk the work, implement in safe batches, then manually smoke-test on a real device. We've written that loop up in more detail in Audit, Chunk, Implement.
But the decision that actually made this possible wasn't an AI output. Left to their defaults, the models leaned toward building a mobile version. The human call (reuse the panels you already have, don't fork the product) is what turned a multi-week rebuild into a few iterations. Call it lazy in the good sense: if the architecture already supports reuse, reuse the thing that works. That kind of product judgement is still the part humans bring.
Related posts
Try it on a phone
If you've only ever used EF-Map on a desktop, open the map on your phone and try planning a route or pulling up an Intelligence card. It should feel like the EVE Frontier tool you already know, just reshaped for the screen in your hand. It is not native, it is not finished, and it will have quirks, so if something feels wrong, tell us. This is the first mobile pass we're actually happy with, and real-device feedback is how it gets better.