Most browsers are designed around one active webpage.
You can keep dozens of tabs open, group them and move them between windows, but you still spend much of the day looking at one page and hiding the others.
That works until the task itself involves several pages.
You might be:
- comparing products or prices
- researching a subject across several sources
- working from documentation while using a web application
- watching dashboards or operational tools
- planning a trip with maps, accommodation and transport open
- checking a website at desktop, tablet and mobile widths
In each case, the pages belong together. But the browser keeps making you switch between them.
Opening several Safari windows helps, but then you are arranging and resizing windows manually. When you finish, you have to clean everything up or reconstruct the arrangement next time.
That was the problem that led me to build TiledBrowser.
The problem was not too many tabs
At first, I thought I wanted a better way to manage tabs.
What I actually wanted was a temporary workspace.
I wanted to select a few pages that belonged to the task in front of me, place them side by side and work with them as a group. Safari should remain my normal browser, with its bookmarks, history, passwords and familiar interface.
TiledBrowser would only take over when seeing several pages at once was more useful than switching between them.
The current workflow is straightforward:
- Open the TiledBrowser extension in Safari.
- Select between two and four open tabs.
- Send them to a tiled workspace.
- Resize or rearrange the panes as the task changes.
- Open any page back in Safari when it needs the full browser.
Saved workspaces can also be kept as tabs, making it possible to switch between groups such as research, documentation, analytics or a particular project.
The important distinction is that TiledBrowser is not intended to become your browser. It is a working surface beside your browser.
Why not build it entirely inside Safari?
This is probably the most obvious question.
A Safari extension can add a toolbar button, display a popover, interact with webpages and exchange information with a containing macOS app. Apple explicitly supports communication between Safari extensions and native applications.
What Safari’s public extension model does not provide is a way for an extension to redesign Safari’s main window into a custom grid containing several independently sized webpages.
That is why TiledBrowser has two parts.
The Safari extension handles the part that belongs in Safari: choosing the tabs you want to work with.
The native macOS app handles the part that requires its own window: displaying, resizing, rearranging and saving a multi-page workspace.
This is not an attempt to work around Safari or replace it. It follows the boundary Apple provides between an extension and its containing application. Apple describes this extension-to-app model in its Safari extension documentation.
Why not build another browser?
There are already browsers with split views, sidebars and workspaces. Switching to one of them would be a reasonable answer for some people.
It was not the answer I wanted.
I use Safari because it is integrated with the rest of my Mac and Apple devices. I did not want a tiling feature badly enough to move my browsing history, passwords and everyday habits into another browser.
Building another browser would also turn a focused tool into a much larger product. It would need to take responsibility for everything a browser does, rather than solving the narrower problem of working with a small group of pages at the same time.
The companion model lets each application keep a clear role:
- Safari handles everyday browsing.
- The extension handles selection and handoff.
- TiledBrowser handles the temporary multi-page workspace.
That division has become one of the most important parts of the product.
A web view is not a Safari tab
TiledBrowser displays pages using Apple’s WKWebView.
That gives a native Mac application a capable WebKit-powered view of the web, but it does not turn the application into Safari.
This distinction is most noticeable during authentication.
Some websites sign in normally. Others open additional windows, expect browser state that is not available in the same way, or deliberately restrict authentication inside embedded web views. Google and Microsoft sign-in flows are common examples.
There is no universal fix an application can apply to make every embedded login behave like Safari.
TiledBrowser improves popup and session handling where WebKit permits it, but it also warns about known sign-in limitations. Every pane has an Open in Safari action for cases where authentication or another browser-specific feature works better there.
I would rather expose that boundary clearly than make someone wonder whether the application has stopped working.
The same limitation applies to restoring a workspace. TiledBrowser can save the pages, arrangement and viewport settings, but a URL is not the complete state of a browser tab. Form contents, navigation history, temporary JavaScript state and some authentication information may not return exactly as they were.
A saved workspace is therefore a way to return to a useful working context, not a promise to freeze several Safari tabs perfectly in time.
What changed after using it
Some of the most useful features were not part of the original idea.
Panes initially used buttons for moving left, right, up or down. Those controls were precise, but dragging a pane to a new position felt more natural. TiledBrowser now supports both.
Saved layouts were originally something I expected to reopen occasionally. In practice, I kept several of them active and switched between them. That led to workspace tabs at the top of the window.
Viewport presets started as a convenience for frontend work. They turned out to be useful whenever the same page needed to be compared at several widths.
The limit of four panes was also deliberate. It is technically possible to display more, but beyond four, most screens become a wall of websites too small to use comfortably. The objective is not to fit the largest possible number of pages into a window. It is to make a small number of related pages genuinely usable together.
Where TiledBrowser is now
TiledBrowser 1.0.8 includes:
- selection of two to four open tabs from Safari
- tiled, resizable web panes
- saved workspaces and workspace tabs
- drag-and-drop pane reordering
- directional movement controls
- viewport presets
- per-pane Open in Safari actions
- first-run Safari extension guidance
- improved popup and session handling where WebKit permits it
- warnings for known embedded sign-in limitations
The original idea was simply to put a few Safari tabs next to each other.
After using and refining it, the more useful idea became clearer: some browsing tasks are not really about individual tabs. They are about a group of pages that form a working context.
Safari remains the browser.
TiledBrowser provides the workspace beside it.
I would be interested to hear how other people handle multi-page work on macOS, particularly where the boundary should sit between a browser extension and a companion application.