Proxee

Your localhost on your phone, synced.

133 followers

Your localhost on your phone, synced.

133 followers

Proxee turns your phone into a dedicated mobile UI preview monitor for local development. Unlike browser emulators or tools like BrowserSync, it's a native macOS menu bar app with QR pairing, automatic reconnection, bidirectional sync (navigation, scroll, theme), SSR-safe proxying and support for auth flows including OAuth redirects. It's zero-config, framework-agnostic, 100% local, and includes a native iOS companion for a seamless real-device testing workflow.

Payment Required

Launch tags:Mac•Developer Tools•Maker Tools

Launch Team

Framer AI AgentsDesign and publish professional sites with AI

Promoted

Maker

📌

I build websites and web apps on my Mac and I always want to see the mobile version while I work to ensure I don't ship any responsive UI bugs, which happens more than it used to now that I'm coding with agents. Toggling Chrome devtools and resizing the window is a constant annoyance. Checking responsive only at the end of a feature means catching layout problems too late. On top of that, I have hit real-device rendering differences against Chrome's mobile emulator and got burned by trusting the emulator then running into Safari iOS quirks after I shipped. The honest fix is testing on a real phone as you go. But nobody does that, because the workflow is too much friction: you have to find your LAN IP, type something like 192.168.x.x:3000 into the phone and redo it every time you come back to work. So I built Proxee. It is a macOS menu bar app that turns my phone into a dedicated mobile UX preview monitor. With Proxee you set your dev server port, click Go Live, scan a QR with your iPhone, approve the device once. That is the whole setup. From then on your phone follows along while you work. Live reload, navigation, scroll position and theme state stay in sync between Mac and phone. It goes both ways too. Scroll or navigate on the phone and the Mac follows, so you can drive from whichever device is in your hand. Any mobile browser on the same Wi-Fi works for quick checks but I also built a free iOS companion app that remembers the session and keeps the iPhone screen awake during long sessions (iOS prevents this in browsers - I experimented with some hacks but nothing was stable enough or worth pursuing) so no need to change settings in your iPhone every time you work. The biggest thing that sets Proxee apart is the UX. It is designed specifically for Apple devices: native macOS menu bar app, native iOS companion, QR pairing, trusted-device approvals and automatic reconnection. Everything else in this space is either a desktop browser pretending to be a phone, a manual IP chore, or an npm tool you wire into your build. Proxee also handles auth. It supports local login flows, browser-owned OAuth redirects and shared app-session refreshes across paired devices, so you can test logged-in views on the phone. OAuth providers validate redirect URLs on their side, so you add the Proxee callback URL (proxee.local:port) next to your localhost one in the provider dashboard. Proxee cannot change a provider allowlist, but it relays the redirect correctly once it is listed. By default, Proxee operates in SSR-safe proxy mode that does not rewrite absolute URLs so it does not trigger hydration mismatches. But I added a strict mode for when assets still point at localhost. On the obvious comparison: BrowserSync. It pioneered cross-device sync but it is a Node tool you configure into your build pipeline, it predates the SSR hydration era and it has no device pairing or native app. Proxee is zero config with no build-tool changes and no adapters. It is framework-agnostic (so far I tested it with Next.js, Vite, Astro, SvelteKit and vanilla HTML but it should work with others too). A few deliberate choices: - 100% local. The proxy runs on your Mac and talks only over your LAN. No cloud relay, no tunnel, nothing leaves your network. - It syncs deterministic state like navigation, scroll and theme. It does not mirror client-side DOM state, so opening an accordion on one device will not replicate on the other. Think of synced screens being pointed at the same place rather than being a relay or a remote control. - Pairing-gated. Go Live exposes the proxied site on your LAN, but unpaired clients are blocked. New devices are approved from the Mac app. - SSR-safe by default to keep frameworks from breaking hydration. Honest limitations: - LAN traffic is HTTP not HTTPS, same as your localhost server, so use a trusted network or a personal hotspot for sensitive work and production data. - Some corporate or public Wi-Fi blocks device-to-device traffic - a personal hotspot works around it. - Android browsers work, but the tuned long-session experience is iPhone first. When I started building Proxee, I thought of it as a nice-to-have vitamin tool, but I then started using it while working on my projects and I can’t really imagine going back to the old way. Curious what you think and what would make it more useful.

Report

5mo ago

@piodubro looks and works great!! Super useful

Report

5mo ago

Maker

@raulonrails Thanks so much Raul!

Report

5mo ago

@piodubro Nice launch! The workflow looks much smoother than relying on emulators. Any plans to support Windows in the future? 👀

Report

5mo ago

Maker

@boopathi_raja007 Thank you! Currently it's Mac-only, but Windows support is not off the table! 🙂

Report

5mo ago

One OAuth detail I couldn't tell from the docs: if I only change the target app port, say from localhost:3000 to localhost:5173, does the callback stay on the same proxee.local proxy URL, or do I need another provider allowlist entry?

Report

5mo ago

Maker

@novamaker01 The provider allowlist only needs the external callback URL that the browser sees. Changing the target app port behind Proxee, like localhost:3000 to localhost:5173, should not require another OAuth allowlist entry as long as the callback URL stays on the same Proxee URL, for example:

http://proxee.localhost:7331/api/auth/callback

You’d only need another provider entry if the actual redirect_uri sent to the provider changes, such as a different host, port, scheme or callback path.

Report

5mo ago

The QR-and-go setup is so much nicer than typing my LAN IP into my phone for the hundredth time. I catch way more responsive bugs since agents started writing my CSS too. Does the live reload feel instant on the phone, or is there a noticeable lag behind the Mac?

Report

5mo ago

Maker

@ianhxu Thanks! It’s instant but really depends in your network. This one time, I was working at a cafe and their WiFi was very slow which obviously made everything slower.

Report

5mo ago

Cortex

Congrats on the launch..! but i can also run ngrok on that port from my mac and can preview in my mobile. How its different ?

Report

5mo ago

Reviews