Google Earth Pro desktop: flying over a map without the tabs

Anyone searching for Google Earth Pro desktop in 2026 is arriving at an awkward moment. The application is still there, still free, and still the only version that does several jobs no browser can. It also has a published end date for downloads, and on a Mac it carries a second and less discussed clock: the installer is an Intel binary, and Apple has already announced when translation for Intel applications stops. Those two dates change what the right answer looks like, so it is worth separating the software from the browser window, and the deadline from the panic.

The download deadline, in Google's own words

The notice appears in two places on Google's own properties. The banner on the Earth versions page carries it, and the help centre page for updating Earth Pro states it plainly.

As of June 25, 2027, Google Earth Pro for desktop will no longer be available for download. Source: support.google.com

Read that sentence carefully, because a lot of secondhand coverage stretches it. What Google has announced is the end of availability for download. It does not say that an installed copy stops opening on a stated date, and it does not put a date on the KML format. Treating June 25, 2027 as a download deadline rather than a shutdown date leads to sensible preparation instead of a scramble.

The same help page still lists direct installers for every 7.3 release up to version 7.3.7, and notes that versions 7.1.7 and earlier are no longer supported. So the practical state today is that the application works, updates exist, and the supply of new downloads has a known last day.

What the desktop version does that the browser version does not

This is the part worth checking before any decision, because for many people the answer is that nothing is lost. Google describes the split between the two versions directly.

Google Earth Pro on desktop is available for users with advanced feature needs. Import and export GIS data, and go back in time with historical imagery. Available on PC, Mac, or Linux. Source: google.com

Two capabilities carry the weight there. Importing and exporting GIS data means shapefiles and other survey formats going in and out of the map, which matters to anyone whose work involves parcel boundaries, utility routes or site surveys. Historical imagery means the time slider, which matters to anyone documenting change on a site over years.

Everything else on a typical day, browsing the globe, looking at high resolution imagery, dropping placemarks, using Street View, exists in the browser version at earth.google.com. A person whose Earth Pro habit is really site reconnaissance and screenshots is using a heavyweight installer for work the web version already covers, and moving is a matter of getting the window right rather than replacing a workflow.

The honest test takes one session. Open the browser version, do the things a normal day involves, and note what is missing. If the answer is nothing, the deadline is not a problem. If the answer is shapefile import or the time slider, the desktop application stays until Google publishes a replacement path for those two features.

Installing it on a Mac, and the version numbers that matter

For anyone who still needs the application, the installation is unremarkable and the version numbers are not. Google's install page lists two thresholds: version 7.1.8 or newer is required to use Earth Pro at all, and version 7.3.3 or newer is required to reach Street View from inside it. A copy inherited from an old machine may sit below one of those lines, which produces the confusing experience of an application that opens and then refuses a feature.

The Mac system requirements are modest by current standards: macOS 10.8 as a minimum with an Intel 64-bit processor, 2GB of memory and 2GB of free disk space, with 4GB of each recommended, and a graphics processor compatible with OpenGL 1.4 at minimum or 2.0 recommended. The install itself is a disk image containing a package file, so it goes through the standard macOS installer rather than a drag into Applications.

Those numbers are worth noting for one reason. They describe a Mac from a decade ago, which is a clue about how long this codebase has been stable, and why the architecture question below is the one that actually decides its future on a Mac.

The Mac specific problem nobody mentions

The Earth Pro installers for macOS have a naming convention that gives the situation away. Every Mac file on Google's direct installer list, from version 7.3.1 through 7.3.7, is named for the Intel architecture. There is no Apple silicon or Universal build in that list.

On an M series Mac, an Intel application runs through Apple's translation layer, and Apple has published the timetable for that layer.

Rosetta is available for any Mac with Apple silicon using macOS 27 or earlier. Starting with macOS 28, the next major macOS release, Rosetta functionality will be available only for certain older, unmaintained games that rely on Intel-based frameworks. Source: support.apple.com

Put the two announcements side by side and the picture is clear. The download deadline is one constraint, and the end of general Rosetta support is another, arriving from a different direction. An Apple silicon Mac that keeps taking macOS upgrades will eventually reach a release where an Intel only application is outside what the system supports, regardless of whether a copy of the installer was saved.

That reframes the preparation task. Saving the last installer to a drive is worth doing, and it is not a long term plan on Apple silicon. The long term plan is either the browser version for the common work, or a specialist desktop application for the GIS work that Earth Pro was being used as a substitute for.

The routes, side by side

Route What it is Historical imagery GIS import and export Runs natively on Apple silicon
Earth Pro on desktop Installed application, Intel build Yes Yes No, through translation
Earth for web in a browser tab earth.google.com in any tab No No Yes, the browser is native
Earth for web, Safari Add to Dock Same site, own Dock icon No No Yes
Earth for web through a site to app tool Same site, own app and profile No No Yes

The two right hand columns are the whole argument. No window trick adds features to the web version, and no installer rescue plan makes an Intel binary native. Being clear about that prevents the most common mistake, which is spending an afternoon on a wrapper and then discovering the time slider is still absent.

Why the window matters for a map more than for a text app

For a mail client or a task list, a browser tab is a mild inconvenience. For a map it is worse, and the reasons are specific.

A map wants the whole window. Earth for web draws a globe that rewards screen area, and a tab strip plus a bookmarks bar plus an address bar takes a visible slice off the top of it. Apple's General settings for a web app allow turning the navigation controls off, which removes the back button and forward button from the toolbar and returns that space to the map.

A map is a long session. Nobody opens Earth for thirty seconds. Sessions run while a spreadsheet, a PDF of a site plan and a mail thread are all in use, and a tab that has to be found again each time is a small tax paid dozens of times. Apple's documentation for turning a site into an app is short and describes exactly this result.

You can open and use a website as if it's an app. Go to the Safari app on your Mac. Go to a website. Click in the toolbar, then choose Add to Dock. Click Add. An icon for the web app is added to the Dock and Spotlight Applications. Source: support.apple.com

A map is a graphics workload. This is the one technical point that should influence which route gets picked. Google's own documentation for its map products notes that some browsers block the WebGL technology used to produce 3D images, and that a computer meeting the system requirements can still end up without the full 3D view because of the browser. The implication for a wrapper is direct: the engine underneath it decides what the globe looks like. A wrapper built on a Chromium engine behaves like Chrome, because it is Chrome's rendering path. A route built on Safari behaves like Safari. Neither is wrong, and testing the 3D view in each before committing takes two minutes.

A map often belongs to a work account. Survey data, shared projects and saved places sit under whichever Google account is signed in. On a machine that also holds a personal Google login, this is the usual source of the wrong saved places appearing. An application with its own cookie store opens the right account every time, which is what separate profiles give: each app gets its own login store rather than sharing the browser's. The Features page describes how that separation is arranged, and the Supported services page lists sites already set up as presets.

Preparing for 2027 without overreacting

Four things are worth doing, in this order, and none of them is urgent enough to interrupt a working week.

Export what only exists inside the application. Saved places, custom placemarks and imported layers should be written out as KML or KMZ files and stored where the rest of the project files live. This is worth doing regardless of deadlines, because a local Earth Pro database on one laptop is a single point of failure.

Write down which Pro features the work actually uses. Not which ones exist. Which ones were used in the last three months. Most lists come back shorter than expected, and a short list means the browser version is enough.

Check the imagery dates that matter. If historical imagery is part of the job, capture the specific comparisons that a project depends on now, as image exports with dates recorded, rather than assuming the slider will always be reachable.

Set the browser version up properly. If the conclusion is that Earth for web covers the work, give it a real window now rather than in eighteen months. The habit forms while there is still a fallback installed, which is a much calmer way to change tools.

Anyone whose work genuinely depends on GIS import and export should also spend an hour looking at desktop GIS software rather than at Earth alternatives. Earth Pro has been serving as a free stand in for that category for years, and the deadline is a reasonable moment to stop stretching it.

What to change first

Export the saved places and imported layers out of Earth Pro to KML or KMZ today, then spend one session in the browser version to find out whether anything on the real job list is missing. If nothing is, give earth.google.com its own window and its own Google login so the map is one click away and always the right account, which is what Kagemusha is for.

Frequently asked questions

Will Google Earth Pro stop working on June 25, 2027?

Google's notice says the desktop version will no longer be available for download as of that date. It does not state that an installed copy stops opening then. The separate risk on an Apple silicon Mac is that the Mac installers are Intel builds, and Apple has said general Rosetta support ends with macOS 28.

Is there an Apple silicon version of Google Earth Pro?

Not on Google's direct installer list. Every Mac file there, up to version 7.3.7, is named for the Intel architecture, so on an M series Mac it runs through Apple's translation layer rather than natively.

What does the browser version of Google Earth lose compared with Pro?

The two features Google names for the desktop version are importing and exporting GIS data and viewing historical imagery through the time slider. Browsing the globe, high resolution imagery, placemarks and Street View are all present in the browser version.

Does turning earth.google.com into a Mac app add back the Pro features?

No. A window gives the site an icon, a place in the Command+Tab switcher, more screen area for the map and its own login store. It cannot add features the website does not have, so the time slider and shapefile import stay absent.

Why does the 3D globe look worse in one browser than another?

3D views depend on WebGL, and Google's documentation notes that some browsers block it, which leaves a computer showing a simpler 2D view even when it meets the system requirements. Since a web app runs on a browser engine, the engine chosen for it decides which view appears.

Back to all posts