The browser was made as an Arc replacement, and so has most of its features.
Features currently available in the alpha version include:
Pinned tabs, tab groups, tab filtering, tab sorting, favorites (Arc model), spaces with optionally different profiles, custom download paths, and authentication via TouchID or password, RSVP reader, split-view for tabs (2, 3, or 4), and a side panel that has its own tabs, per-tab volume and audio control, link previews, custom routing rules for links, you can make all mailto: links open gmail, open all links to a domain in a specific browser, etc., automatically detects phone numbers, flight numbers, and similar info on right click and shows relevant actions, can also convert measurements, can download videos from most services with yt-dlp integration, can be controlled from Claude Code or similar, and has a DSL for the commands, blocks APIs like page visibility, disables copy-paste blocking, strips tracker parameters, shortcuts app integration, calendar integration (will remind of meetings), handoff support, auto-detects and marks tabs as unread when you receive a new message, auto-add custom search engines, can show the memory use of each tab, supports Chrome, Firefox extensions, can pin window to be always on top, make it transparent, or show on every space, windowed fullscreen, tab screenshots and video recording, quick drag and drop shelf
Why not open source it? Pretty sure no one will try seriously unless it’s open source.
And you won’t get the flex without showing off the source.
Growing it as a business seems pretty hard and you kind of have a catch-22: non-developer audience probably doesn’t care about it, developer audience won’t touch it unless it’s open source.
This is a really clever use of CAPortalLayer. Feels like you're essentially bypassing the “one WKWebView per hierarchy” constraint by turning the problem into a rendering problem instead of a state problem.
Curious how you handle input events across mirrored views — does only the “real” view receive interaction and others proxy it, or is there some trick there too?
For me the main use case is screen sharing (share only the mirrored window). It can also be useful for multi-monitor setups when you want to show something to other people on a bigger screen without mirroring your main screen.
The browser was made as an Arc replacement, and so has most of its features.
Features currently available in the alpha version include: Pinned tabs, tab groups, tab filtering, tab sorting, favorites (Arc model), spaces with optionally different profiles, custom download paths, and authentication via TouchID or password, RSVP reader, split-view for tabs (2, 3, or 4), and a side panel that has its own tabs, per-tab volume and audio control, link previews, custom routing rules for links, you can make all mailto: links open gmail, open all links to a domain in a specific browser, etc., automatically detects phone numbers, flight numbers, and similar info on right click and shows relevant actions, can also convert measurements, can download videos from most services with yt-dlp integration, can be controlled from Claude Code or similar, and has a DSL for the commands, blocks APIs like page visibility, disables copy-paste blocking, strips tracker parameters, shortcuts app integration, calendar integration (will remind of meetings), handoff support, auto-detects and marks tabs as unread when you receive a new message, auto-add custom search engines, can show the memory use of each tab, supports Chrome, Firefox extensions, can pin window to be always on top, make it transparent, or show on every space, windowed fullscreen, tab screenshots and video recording, quick drag and drop shelf
Why not open source it? Pretty sure no one will try seriously unless it’s open source.
And you won’t get the flex without showing off the source.
Growing it as a business seems pretty hard and you kind of have a catch-22: non-developer audience probably doesn’t care about it, developer audience won’t touch it unless it’s open source.
This is a really clever use of CAPortalLayer. Feels like you're essentially bypassing the “one WKWebView per hierarchy” constraint by turning the problem into a rendering problem instead of a state problem.
Curious how you handle input events across mirrored views — does only the “real” view receive interaction and others proxy it, or is there some trick there too?
Nice one! Looking forward to trying it out. Have had the same grievances about Arc being abandone. Dia? … nah
that's a pretty genius use of the "portals" primitive; I suppose its akin to Portals in React-ish.
Although I've never needed to open 2 tabs of the same site and wanted them share the state.
For me the main use case is screen sharing (share only the mirrored window). It can also be useful for multi-monitor setups when you want to show something to other people on a bigger screen without mirroring your main screen.