Make Site-Specific Browsers with Google Chrome
For some Web-based services, it’s far more appropriate to use the term “app” than “site” because they do things, rather than just presenting static information. And in fact, most such sites — like Google Docs, Trello, and Strava, to name a few I use — have a dedicated app in iOS.
But such apps usually aren’t written for the Mac. Before the focus on iOS apps, that was understandable, but now it’s downright odd. If you’re a company with a Web app that has millions of desktop users, wouldn’t you want to provide a native experience rather than competing with every other tab in a Web browser? Apparently not, but from the user perspective, if you use a particular Web app all the time, aren’t you tired of hunting it down in your browser’s tabs or bookmarks?
That’s the point of a site-specific browser on the Mac — to free a Web app from the Web browser, and turn it into something that looks, walks, and quacks like a native app. And you don’t need any help from a Web app developer to do it.
Mailplane is the best known dedicated site-specific browser for the Mac, providing a native app experience for Gmail and Google Calendar (see “Zen and the Art of Gmail, Part 4: Mailplane,” 16 March 2011). And the now-defunct RocketDocs did the same for Google Docs (see “RocketDocs Brings Coherence to Google Docs,” 8 July 2013).
For years, making your own site-specific browser on the Mac required Fluid, which builds its apps around WebKit. It’s free, although a $4.99 license purchase provides a few extra features, like full-screen mode and per-app cookie storage. But Fluid relies on an old version of WebKit that isn’t compatible with current versions of Google’s Web apps (and perhaps others). If it works for you, great.
The solution I prefer relies instead on Google Chrome, and has the benefit of supporting Chrome extensions within each site-specific browser that you create. Such extensions might include 1Password and LastPass, so you don’t have to copy passwords, or extensions that extend Gmail or Google Docs, for instance. You can install them individually or sign in to Chrome to sync all extensions, settings, and bookmarks over from your main Chrome installation.
Before I get to the best way of making these site-specific browsers, a little history. Chrome includes site-specific browser functionality via a Create Application Shortcut menu item. Unfortunately, Google exposes this capability in only the Windows and Linux versions, not on the Mac. Back in 2010, Bracken King came up with a shell script that made it possible to create Chrome site-specific browsers on the Mac, and Mait Vilbiks then turned it into the AppleScript-based createGcApp that eliminated the need to fuss with permissions and work in Terminal. This worked, but the apps it created were a little funky — notably Keyboard Maestro had trouble differentiating them from Chrome, so it was hard to assign keyboard shortcuts to launch them or work with them in other ways. I don’t recommend either of these solutions.
Further spelunking around the Internet revealed an updated version of King’s shell script written by Leonard Lin that didn’t suffer problems with Keyboard Maestro and other utilities, but it too required fussing in Terminal. Luckily, you don’t need to mess with it either, because it was turned into the AppleScript-based Make Chrome SSB app (packaged on Github as osx-chrome-ssb-gui-1.0.0.dmg
), this time by Github user dmarmor. (This happened in January 2015, which is nice to see, since so little else has happened in the site-specific browser area in years.)
The upshot of all this is that although you may run across these other solutions when searching for Chrome-based site-specific browsers, I recommend sticking with the Make Chrome SSB app. Here’s how to get started:
- Once you’ve downloaded the
osx-chrome-ssb-gui-1.0.0.dmg
file, double-click it to mount it as a volume, and drag the Make Chrome SSB file to the alias of your Applications folder. (You can’t run it successfully from the disk image.) -
In your Applications folder, Control-click the Make Chrome SSB icon, choose Open from the contextual menu that appears, and click Open in the dialog. Since it’s not signed, OS X’s Gatekeeper won’t let you launch it otherwise.
-
Ignore Make Chrome SSB’s dialog for the moment, and take a moment to gather a few pieces of information for your site-specific browser.
- Most notably, you need the URL for the Web app (make sure it goes exactly where you want the site-specific browser to start). Copy it to the clipboard.
-
You also need an icon. For a good one, search Google Images on the name of the desired Web app and “PNG icon”. You’ll almost certainly find a variety of good images; view one at full size and then drag it to the Desktop so you can easily select it later.
-
If the Web app in question requires login credentials, make sure you’re ready to extract those from your password manager.
-
Click back in the Make Chrome SSB dialog and paste in the URL for your site.
-
Follow the prompts to locate the PNG image you downloaded previously to use as an icon.
-
Provide the name and location of your site-specific browser app (ignore the incorrect text that tells you to select an image again).
-
When you’re done, Make Chrome SSB offers to launch your app or show it in the Finder. Launch it, and log in if necessary. You’ll be prompted to make Chrome your default browser; deselect that button, since you don’t want this site-specific browser to be your default.
-
To make additional site-specific browsers for other Web apps, double-click Make Chrome SSB and repeat Steps 3–7.
Once you have a fully configured site-specific browser, it should work just like the Web app. “Should” is the operative word here — you may notice an occasional failure or odd behavior, particularly when working with plug-ins or the filesystem. For instance, I can drag a PDF into a Chrome window and it displays in Chrome’s PDF Viewer. But doing that in a site-specific browser results in a “Couldn’t load plug-in” error. This doesn’t seem to affect PDFs loaded from a link within the window, but still…. This workaround may help.
Despite an oddity here or there, these Chrome site-specific browsers are tremendously useful. If you use a Web app regularly, consider taking a few minutes to turn it into a native Mac app so it doesn’t get jumbled in with everything else in your Web browser.
Are cookies shared between the apps or separated per app?
Cookies are separate for each Site-Specific browser made by "Make Chrome SSB." Each browser gets its own folder in ~/Library/Application Support/Chrome SSB/, equivalent to ~/Library/Google/Chrome/, for storing their respective cookies, passwords, file cache, etc.
The history menu in the SSBs is weird, it shows Safari's history. If you want to use a non-SSB copy Chrome, you have to launch it before you launch any SSBs. There's no problem with running multiple SSBs simultaneously.
It's weird that you're seeing Safari's history - when I look in the history menu of the Chrome SSBs I've created, I see only sites I've navigated to with that SSB.
I've not tried launching an SSB before Chrome itself, since I launch Chrome at startup. What are you seeing if you do that?
Yes, the history thing is odd but it's only the Safari history prior to the SSB being created/launched. I figured it imported the history though it definitely did not import other things like bookmarks.
If an SSB is running and I try launching Chrome, it just brings the SSB to the front (if there's two SSBs running, it brings the one launched first to the front).
Two other examples of site-specific browsers (though they often aren't perceived that way) are TweetDeck and Sunrise calendar. Both exist as Web sites and Mac App Store apps, but the latter are all but indistinguishable in look and functionality from the browser-based versions.
I still use Fluid. I got it to work with Google's suite of apps simply by changing the User Agent. My only major preference for them vs. Chrome is the memory footprint seems lower with Fluid over SSB's from Chrome.
I'm not quite sure how to evaluate the disk space and memory differences between Fluid and Chrome SSBs. I have three running - two Chrome and one Fluid.
Strava (Chrome SSB): 83K on disk, 65 MB memory used.
Trello (Fluid): 5.5 MB on disk, 182 MB memory used.
Google Docs (Chrome SSB): 616 MB on disk, 226 MB memory used.
I can't explain why the Google Docs Chrome SSB is so much larger, but I suspect (from looking inside the package) that it has to do with cached data from all the changes.
Otherwise, disk space and memory usage don't appear to be notably different in my examples.
Discovered something interesting just now: An increasing number (though definitely not all or a majority) of Chrome apps are launching in SSB-like windows with no tweaking required. These include Evernote, Feedly, TweetDeck and Google Plus. Those that still do not include all the Google and Microsoft productivity Web apps.
What does that mean, Julio? When I go to those sites, they seem just like another tab in the browser.
After ctrl click open will just crash and never open!?
Process: launchd [2533]
Path: /Applications/Make Chrome SSB.app/Contents/MacOS/applet
Identifier: launchd
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: launchd [354]
Date/Time: 2015-04-12 23:56:08.570 +0200
OS Version: Mac OS X 10.7.5 (11G63)
Report Version: 9
Interval Since Last Report: 3958972 sec
Crashes Since Last Report: 42
Per-App Crashes Since Last Report: 22
Anonymous UUID: DBB27793-5543-4CA2-AAE9-BF9C204E6E52
Crashed Thread: Unknown
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fff5fc01028
Backtrace not available
Unknown thread crashed with X86 Thread State (64-bit):
rax: 0x0000000000000055 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x0000000000000000
r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000
rip: 0x00007fff5fc01028 rfl: 0x0000000000010203 cr2: 0x00007fff5fc01028
Logical CPU: 0
Binary images description not available
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 1
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 4177
thread_create: 0
thread_set_state: 0
Just read the main.applescript which says: Tested on Mac OS X 10.10.1 (only). Does this explain why it wouldn't run on my Mac OS X 10.7.5 or could there be other reasons too?
Yes, that's very likely - things may have changed in the intervening years.
This has now been updated, and works fairly well. It's also been renamed. https://github.com/dmarmor/epichrome/releases
Yes, and it's on my list to cover soon!