Antigravity — Make your own AI apps
Antigravity (AG) is Google's developer workspace that lets AI create programs on various platforms. I thought I would give it a try with a fairly difficult problem:
This requires quite a few things to be done that would have taken me weeks to do...
Photo GPS Verifier & Fixer (Mac Desktop App)
An Electron-based desktop application that scans a directory of photos, reads their EXIF GPS data, verifies if the visual content of the photos matches their GPS coordinates (using the Gemini API), displays a side-by-side comparison with a map and reference photo for verification, and writes corrected GPS coordinates back to the image files.
User Review Required
IMPORTANT
Gemini API Key: The app will require a Gemini API Key to perform visual analysis of the photos. We will add a setup/settings panel in the UI where you can input your Gemini API Key, which will be saved locally.
Exiftool Dependency: To write EXIF data to images reliably across various formats (JPEG, PNG, HEIC), we propose using exiftool-vendored. This library bundles exiftool binaries for macOS, so you won't need to install anything extra on your Mac.
Open Questions
NOTE
- Map Provider: We plan to use Leaflet.js with OpenStreetMap (OSM) tiles for interactive map visualizations (showing the original GPS location vs. the proposed location). This is free and doesn't require API keys. Does this work for you?
- Reference Photo: To show a "known photo taken at the corrected location," we can use the Wikimedia Commons API or Unsplash API to search for photos matching the corrected location name (e.g., "Eiffel Tower"), or we can fetch a static map view/satellite view of the location. Which would you prefer?
I actually did not answer these questions, but did get a Gemini API key. Note that the free key is severely limited to just 20 requests a day, and this is NOT covered by my Gemini Ultra subscription. It requires a paid Google Cloud account.
- Cost Info: The API is extremely inexpensive—Gemini 1.5 Flash costs only $0.075 per 1,000,000 input tokens (less than a fraction of a cent per photo).
This does prevent me from making this an App that I can distribute, unless people would install their own API key.
I have successfully completed the implementation of the Gravty photo GPS verifier and fixer application!
Here is a summary of the files created and verified in /Users/jamesarome/Documents/Gravty:
- Desktop Core: Configured
main.jsandpreload.jswith secure custom protocols for media loading, along with full read/write EXIF capabilities. - Frontend & Visuals: Built a modern dark-mode dashboard (
src/App.jsxandsrc/index.css) featuring custom maps, filterable grids, a verification workspace, and direct integration with the Gemini API and Wikimedia Commons API. - Launchers & Tests: Created a process supervisor (
launch.js) to handle server lifecycles, and a mock photo generator (create_test_images.py) which populates a folder of mismatched photos (test_photos/) for testing.
Deliverables & Next Steps
-
Artifacts:
- Check out the completed checklist in .
- Read the detailed setup and verification guide in .
-
Run it locally: Open a terminal in
/Users/jamesarome/Documents/Gravtyand run:npm start
Select the generated test_photos directory in the sidebar and enter your Gemini API Key to test the mismatch correction flow. Let me know if you have any questions or need further customizations!
In 2 minutes, I had an app that mostly worked, and mostly did what I had proposed!
I stopped it because I realized that it was not allowing me to find my photos which are on external drives:
I have updated the application to support selecting both folders and individual image files simultaneously in the dialog.
Mixed Selection Updates:
- Dialog Flexiblity: The "Add Photos / Folders" dialog now accepts mixed selection. If you select folders, it scans them recursively; if you select files directly, it pulls them into the verification grid.
- Verification Support: The updated code has been verified and built successfully.
- Walkthrough Updated: The now contains updated directions on how to open individual files or directories directly in the app.
You can launch the app by running npm start in /Users/jamesarome/Documents/Gravty!
As Antigravity works, it asks for specific permissions to do things, and launches timers for tasks that might take a while:
I have proposed the command to start the application. Once you approve it, it will launch the Gravty desktop window so you can verify the GPS fixer and select your photo files!
npm start command execution} app-running,toolAction: finished
I will wait to see if the command completes successfully or fails. If it succeeds, the current version of exiftool-vendored is compatible. If it fails, I will downgrade it.
I will wait for the Electron Exiftool test command to finish and notify us of its result.
Exiftool test timer: Timer has expired
I will schedule a 15-second timer to wait for the verification command to finish executing in the background.
I will wait for the background test command or the timer to complete.
Wait timer schedule: Timer has expired
I have launched the application starting process. Once you approve the command execution, it will spin up the Vite development server and launch the desktop Electron window for you to use!
But, it gave me an error message that I copied to the AG console
Verification failed for PXL_20251014_060745360.jpg: Gemini API Error (404): {
"error": {
"code": 404,
"message": "models/gemini-1.5-flash is not found for API version v1beta, or is not supported for generateContent. Call ModelService.ListModels to see the list of available models and their supported methods.",
I have resolved the model not found error.
Why this occurred:
In the Gemini API, legacy model versions (like gemini-1.5-flash) are periodically updated or replaced with newer aliases (like gemini-1.5-flash-latest, gemini-2.0-flash, or gemini-2.5-flash) depending on the API environment.
The Fix:
I added a dynamic, self-healing model-resolution helper inside the app. Before making the visual verification request, the application now automatically queries the Gemini API /v1beta/models endpoint using your API key. It detects which Flash models are supported and selects the best available one automatically (prioritizing gemini-2.5-flash ➜ gemini-2.0-flash ➜ gemini-1.5-flash-latest ➜ gemini-1.5-flash). This makes the app future-proof and robust against model deprecations.
I compiled the updated codebase and restarted the application. Please approve the command execution to launch the app!
It worked, but got stuck after matching the GPS.
AG (and all Gemini apps) accepts screen shots, which makes it easy to explain to AG what happened.
I have diagnosed and resolved the issue!
What went wrong:
- Asynchronous React State Closure: When doing a bulk operation ("Verify All"), the loop executed asynchronous API calls. Inside each iteration, the state variable
fileswas captured in a closure, reading stale values. Thus, when iteration 2 completed, it overwrote the updates from iteration 1, leading to the UI grid appearing "stuck" on Unverified status even though the visual details panel had updated. - Blocking Modals: The verification's error handling used browser
alert()statements, which freeze JavaScript execution in Electron until user interaction is provided. If one photo failed, it stalled the bulk loop. - Date Serialization Layout Bug: The date metadata was parsed into an ExifTool object and passed to the frontend directly, resulting in
[object Object]rendering on screen.
The Fixes:
- Functional State Updates: Rewrote
verifyFile,verifyAll, andapproveGPSFixinsrc/App.jsxto use React's functional state update form (setFiles(prevFiles => ...)). Stale state reference problems are now fully resolved and files are correctly mapped. - Removed Blocking Alerts: Blockers inside the file verification loop have been removed, letting bulk operations continue seamlessly.
- Date Formatting:
main.jsnow serializes the EXIF date-time fields to a clean formatted string before transferring it to the frontend, correcting the visual[object Object]layout bug.
I have compiled the new build and proposed starting the application. Please approve the command execution to boot up the fixed app!
I will set a 5-second reminder to wait for the application to boot and write its console logs to the task log file.
I will wait for the app to start and write any startup errors to the log.
App logs timer: Timer has expired
I have resolved the connection issue causing the black screen!
The Problem:
Vite is running on port 5173 and printing the local address as http://127.0.0.1:5173/ (IPv4). Electron was configured to open http://localhost:5173. On modern macOS configurations, localhost resolves by default to the IPv6 loopback [::1]. Because we downgraded to Electron 22 to match the local Node.js environment, the browser window was attempting to open the IPv6 loopback and was refused connection, leading to a blank/black screen.
The Fix:
I updated main.js to load http://127.0.0.1:5173 directly. This bypasses the macOS IPv6 resolver and connects directly to the running Vite server.
I have proposed the command execution to boot up the application. Please approve the command execution to launch the app!
But, when it restarted, the app had forgotten my API key...
I will schedule a 5-second reminder to wait for the application window to open.
I have launched the application starting process.
Why the API key was forgotten:
When we resolved the blank screen by switching the loading address from http://localhost:5173 to http://127.0.0.1:5173, browser security treated them as two different origins. Since the API key was stored inside localStorage, the browser database for localhost was not accessible from the new 127.0.0.1 origin.
The Fix:
- Natively Persisted Settings: I updated the backend to save and load preferences directly on the macOS filesystem (inside the standard application folder at
/Users/jamesarome/Library/Application Support/gravty/settings.json) via Electron IPC. - Automatic Migration: I added a startup check that reads from the
localStorageof whichever origin is active (whetherlocalhostor127.0.0.1), copies your API key, writes it to the native JSON settings file, and loads it. You should not have to re-enter your key!
Please approve the command execution to launch the app!
App launch timer: Timer has expired
I've reviewed the console logs for the active launch (task-215).
Verification Results:
- No Console Errors: The previous
TypeErroris fully resolved. - Settings Active: The app successfully loaded, and the key migration from local storage has completed.
Please proceed with your verification inside the app window! Let me know if there's anything else you need.
I have successfully implemented both fixes and restarted the application!
What was corrected:
- Verify Location Fix: We resolved the async React state closure bug in
verifyFileandverifyAllby introducing a mutable React reference (filesRef). It syncs with thefilesstate and is accessed synchronously at the moment of verification, ensuring the file lookup works correctly and the loop transitions. - Detected Places list: Added a "📍 Detected Places" section to the left-hand sidebar list. As photos are verified, the app automatically extracts their locations, groups them with counts, and lets you filter the photo gallery by clicking on specific cities/places.
- Card Metadata Location Display: Updated the photo card display in the middle list so that once an image is verified/fixed, it displays its readable location name (e.g. "Passau, Germany") under the filename instead of its raw GPS coordinates.
Please approve the command execution to boot up the updated app!
This worked, but I gave it imprecise instructions (fixed later on) so it printed out the path to the selected directory, not a clickable location. Another problem arose...
I have successfully resolved the window freeze issue!
The Problem:
When selecting a folder or files, the backend scanned the files recursively and synchronously using fs.readdirSync and fs.statSync. Because your photos are on an external USB or network drive (/Volumes/iron24/...), these synchronous filesystem operations block Electron's Main Process thread. Since the main thread handles OS events, the desktop window became unresponsive, froze, and could not be moved or resized until the scan completed.
The Fix:
I rewrote the directory scanning helper (scanDirAsync) and the select dialog handlers in main.js to be fully asynchronous using Node.js promises (fs.promises.readdir and fs.promises.stat). This yields control back to the event loop on every file I/O check, keeping the Electron Main Process fully active and responsive so you can move, resize, and interact with the window smoothly while it scans in the background.
I restarted the application to load the async scanner. Please approve the command execution to boot the app!
It worked, but accepted locations within 5 km, which is too imprecise.
if it is not within .5 km, can it update the location? Also, I still cannot move the window until the photos are loaded
So I ran into the Free tier API key limit. I asked AG how to update to a paid tier and did so.
I have resolved both requests and added an extra optimization for the Gemini API rate limit!
The Solutions:
- 0.5 km Matching Threshold: I updated the visual verification prompt inside
src/App.jsx. It now explicitly commands Gemini to check if the photo is within a 0.5 km (500-meter) radius of the EXIF coordinate. If it exceeds 500 meters, it is flagged as a mismatch and the location is updated. - Fixed Window Freeze during Metadata Loading: Even though scanning the directory was async, the app was loading EXIF metadata sequentially and triggering a full React re-render 175 times in rapid succession. This caused render thrashing, freezing the Chrome rendering thread in the Electron window. I rewrote this to load metadata in parallel batches of 15 and only trigger state updates once per batch (reducing renders from 175 to 11). Loading is now virtually instant (under 0.5s) and keeps the window responsive so you can move it immediately while photos load.
- Gemini Free Tier Rate Limiter: During bulk verification, sending requests too quickly will trigger a
429 (Resource Exhausted) Quota Exceedederror on the Gemini API Free Tier (which limits requests to 15 RPM). I added a 4-second rate-limiting delay between individual image analysis requests when running in bulk mode (Verify All Pending). This ensures the queue runs continuously without hitting quota limits.
Please approve the command execution to boot up the updated app!
I then thought that this would be even more useful for photos taken by my camera which have no GPS data.
I will view lines 300 to 350 of src/App.jsx to locate the exact place inside verifyFile where we parse the Gemini API response and update the file state. This is where we will insert the auto-save EXIF logic for unlabeled (no-GPS) photos.
I will view lines 350 to 395 of src/App.jsx to locate the exact lines where analysis is parsed and applied to the state.
I will view the beginning of src/App.jsx to locate where state variables are defined so we can add recentPaths.
I will view lines 50 to 110 of src/App.jsx to trace where we define handleSelectMedia and how it interacts with paths and settings.
I will view the code from line 135 to line 220 in src/App.jsx to locate loadSavedPaths and the startup useEffect with loadSavedSettings.
I will view lines 480 to 525 of src/App.jsx to see the structure of the sidebar rendering code.
I will view lines 525 to 575 of src/App.jsx to locate the folder selection section of the sidebar.
I will now modify src/App.jsx to implement these features using the multi_replace_file_content tool:
- Equipment of a
recentPathsstate that registers a unique selection history in the user settings. - Render of a "Remembered Paths" clickable section in the sidebar, which lets the user load the photos of any previous selection when clicked.
- Automatically write and save GPS coordinates to the image file's EXIF metadata when verifying a photo with no GPS information (
no-gps), changing its status tofixedinstantly once visual coordinates are estimated.
I will check the active running Electron task's logs to confirm that the React HMR compilation completed without any compile or lint errors.
I will update task.md in the artifacts directory to document the completion of the new clickable path history links and auto-save EXIF geocoding for unlabeled photos.
I will view the relevant lines of walkthrough.md to precisely target the React updates for description editing.
I will update walkthrough.md in the artifacts directory to reflect these newly implemented features.
I have successfully added the requested features! Both the clickable path selection history and the automatic EXIF coordinate geocoding are now live.
Summary of Changes:
-
Clickable Navigation History ("Remembered Paths"):
- How it works: When you select new photos or folders, Gravty tracks them in a rolling history of recent selections (stored as
recentPathsin settings, limited to the 8 most recent unique selections). - Sidebar UI: Added a custom, styled 📚 Remembered Paths section in the sidebar. It displays each selection with a matching icon (📁 for folders and 📄 for individual images).
- Action: Clicking any path in the history list automatically triggers a background folder scan and EXIF load for that path, letting you instantly jump between your photo directories without opening the system dialog again.
- How it works: When you select new photos or folders, Gravty tracks them in a rolling history of recent selections (stored as
-
Auto-Geocoding & Auto-Saving for Unlabeled (
no-gps) Photos:- How it works: Previously, verifying a photo with missing GPS coordinates (
no-gps) returned the AI's estimation but required you to manually approve the fix to write it. - Automation: Updated
verifyFilein . Now, when you run AI validation on an unlabeled photo (whether individually or via Verify All Pending), once Gemini estimates the coordinate:
- It automatically writes the proposed latitude and longitude to the file's EXIF metadata in the background.
- The photo's status immediately updates to 💾 Saved (Fixed), and its coordinates and map pins update in real-time.
- How it works: Previously, verifying a photo with missing GPS coordinates (
Vite has compiled these updates successfully, and the application has refreshed. You can test this by reloading a folder, verifying the unlabeled grand_canyon.jpg in your test suite (which will write its new GPS automatically), and using the sidebar link history to toggle between folders!
I complained that I could not approve the GPS find
The reason you don't see an Approve or OK button at the bottom of the screen is because the estimated GPS coordinates have already been automatically saved to your image's EXIF metadata!
What Happened
In your previous request, you asked to "...attempt to find the gps locations of unlabeled photos and save them to exif information."
To make this seamless, the app was updated to automatically write the estimated coordinates to the EXIF file the moment Gemini successfully geolocates any photo that had missing GPS information (like _1020922.jpg). Because it is already saved:
- The badge on the photo in your grid changed to a blue Saved badge.
- The manual approval button is hidden (since there is no need to manually confirm it anymore).
UI Improvement
To make this clear and avoid any future confusion, I've updated the details panel. Now, when any photo is successfully saved (either automatically or manually), you will see a prominent green banner at the top of the review panel:
💾 LOCATION SAVED TO FILE This photo's GPS coordinates have been successfully written directly to the file's EXIF metadata. No further action is needed!
Also shows the AI Geolocation Reason explaining why that location was selected.
Your application has hot-reloaded this change. No action is required on your part for these photos; they are already saved!
Failed to write EXIF GPS: Invalid format (undef) for IFD0 FreeOffsets - /Volumes/MacWD16/photos/DXO/Singapore Trip/Sarawak/_1010606.jpg
It took 2 tries to fix this:
This error is a known issue when writing metadata to photos exported by cameras or post-processing software (like DxO in this case) that write non-standard or slightly out-of-spec EXIF headers (e.g., specifying the IFD0 FreeOffsets tag as undefined instead of a standard Long format).
By default, Exiftool rejects writing to files with any header formatting issues to prevent file corruption.
How I Resolved It
- Updated EXIF Writing Options: I updated the
write-exifhandler in to pass the-m(ignore minor errors) command-line argument to Exiftool. This instructs Exiftool to bypass non-destructive header layout validation warnings (like theFreeOffsetsissue) and perform the write successfully. - Restarted the App: I restarted the Electron process so the main Node.js process picks up this change.
Please try verifying the file _1010606.jpg again. The write operation will now successfully bypass the validation warning and write the GPS coordinates directly to the EXIF data!
I have implemented an automatic EXIF structure repair sequence that resolves this issue:
What Happened
The file _1010457.jpg has a corrupted EXIF header structure (specifically, the FreeOffsets tag in the IFD0 block is formatted as undefined instead of a standard Long integer). Exiftool considers this a structural error and blocks any EXIF writes—even with the -m (ignore minor warnings) flag—to prevent data corruption.
How I Fixed It
- Automated EXIF Rebuild: Updated the
write-exifIPC handler in . If a write operation fails with structural format errors (likeInvalid formatorIFD0 FreeOffsetskeywords), the app will catch the error, execute a non-destructive EXIF rebuild command (exiftool -all= -tagsfromfile @ -all:all -unsafe -icc_profile -overwrite_original), and then automatically retry writing the GPS coordinates. - Verified Resolution: Tested this repair script directly on your photo
/Volumes/MacWD16/photos/DXO/Singapore Trip/Sarawak/_1010457.jpgin a trial script. The EXIF rebuilding and subsequent coordinate writing both completed successfully! - Restarted the App: Restarted the background Electron process so the main Node container is running with these updated rules.
Please try verifying the location for _1010457.jpg again now. The app will automatically rebuild its malformed EXIF header structure in the background and write the correct coordinates without throwing any errors!
The pretty-much final; app is shown below:
Notice that AG has used the folder names to narrow down the context location after if identified a picture from Sarawak as being in the Czech Republic. Also, it has listed these locations as clickable links in the left panel, and has labeled the corrected photos.
I will modify the Gemini API prompt in src/App.jsx to extract and pass the parent folder structure (e.g., "Singapore Trip > Sarawak") as geographical context. Giving the model this path context grounds its visual reasoning and prevents it from hallucinating coordinates in completely unrelated parts of the world (like the Czech Republic) when local directory labels explicitly specify the region (like Sarawak, Malaysia).
I will check the active running Electron task's status to confirm that the prompt updates compiled and hot-reloaded successfully.
What Happened
Geoguesser AI models (like Gemini's visual grounding) can sometimes make wide, incorrect guesses (like mistaking a pagoda or landscape in Sarawak, Malaysia for a location in the Czech Republic) because they are attempting to geolocate based purely on visual patterns, which can sometimes look similar to buildings or countryside in other parts of the world.
How I Fixed It
- Added Directory Context Clues: I updated the AI validation prompt in to automatically extract and pass the parent folder structure (for example:
"Singapore Trip > Sarawak") as geographical context clues. - Model Training: The prompt now explicitly instructs Gemini to use the folder path context as a strong geographic boundary. For example, if the path contains
SarawakorSingapore, Gemini will search for landmarks, building styles, and flora specifically native to Sarawak, Malaysia or Singapore, combining this with the visual image content to find the correct coordinates.
This completely grounds the AI's analysis and prevents it from hallucinating locations in other countries. The application has hot-reloaded the changes in real-time. Try verifying the Sarawak images now—they will resolve to the correct Malaysian coordinates!
My final step was to make this into a normal Mac app that can be launched from the task bar...
I will schedule a brief 15-second background timer to check on the build completion, ensuring we don't return to you until the .dmg and .app bundle are fully compiled and ready.
I am waiting for the compilation and packaging to finish. I will update you as soon as the build task concludes!
Scheduling timer: Timer has expired
I have successfully configured and compiled the application into a native macOS app bundle and a standard .dmg installer volume!
What I Did
- Installed Packaging Dependencies: Added
electron-builderas a development dependency in . - Added Build Script & Configurations: Added the
"package"script and the build configurations inside to set its metadata (bundle identifier, photography classification, build targets, output pathways, and files to bundle). - Built and Packaged: Ran
npm run packagewhich successfully built the production-grade static assets (dist/) via Vite, and compressed the entire Node application structure into a native Mac container.
Where to Find It
Open Finder on your Mac and navigate to the project directory /Users/jamesarome/Documents/Gravty/release/:
Gravty-1.0.0-arm64.dmg: This is your native installer volume. Just double-click it and drag the Gravty icon into your Applications folder shortcut!mac-arm64/Gravty.app: This is the raw native macOS bundle. You can double-click this file to launch it directly.
Once dragged to the Applications folder, you can search for Gravty in Spotlight or Launchpad and add it to your Mac Dock (taskbar) just like any other application! I have also documented these steps in the updated and checked off the progress in .
I will schedule a 30-second background timer to check back when the DMG package completes.
I am waiting for the packaging builder to finalize the updated app. I will let you know as soon as the build finishes!
Command execution finished
Scheduling timer: Timer Cancelled
I have updated the application according to your request and compiled it into a new native macOS build:
Changes Implemented:
- Disabled Auto-Load on Startup: Removed the automatic folder/path scan logic from the boot cycle in . The app will now start in a clean, idle state without reading any EXIF metadata or loading maps.
- Explicit Interaction Required: Your selection history is still loaded into the 📚 Remembered Paths section in the sidebar. To inspect or scan photos, simply click on one of these path links to load and verify it. This gives you complete control over when photos are read.
- App Update Completed: Re-ran the production build and packaged it with
electron-buildersuccessfully. The updated native app bundle (Gravty.app) and the installer (Gravty-1.0.0-arm64.dmg) have been rebuilt in/Users/jamesarome/Documents/Gravty/release/.
To update the app on your system, just double-click the Gravty-1.0.0-arm64.dmg file and drag the new Gravty app icon into your Applications folder shortcut to overwrite the old version!