Where Unity log files live — Editor.log, Player.log, and mobile log collection

This is a single page for "please send me the logs" — where QA and testers actually have to look. If you came here for a path, grab it from the tables below; the later sections cover how to remove this procedure entirely.

Editor.log — the editor's log

The previous session lives in Editor-prev.log in the same folder. If the editor crashed, restarting rotates the log — so secure Editor.log before restarting.

Player.log — the log from a standalone build

<Company> and <Product> are Company Name / Product Name from Player Settings. The previous session rotates to Player-prev.log here too — worth remembering, because telling someone "restart the game and check" pushes the log you actually need into prev.

Changing the path — -logFile

You can point the log somewhere else with a launch argument. Useful for gathering logs into one folder on QA machines.

Game.exe -logFile C:\qa-logs\run-2026-09-10.txt

Baking the run date into the filename from a batch file removes the "which session was this?" confusion.

Android — logcat

Android has no Player.log file; output goes to the system log (logcat). With the device connected over USB:

adb logcat -s Unity        # filter to the Unity tag
adb logcat -d > bug.txt    # dump the current buffer to a file

The logcat buffer is circular, so it gets overwritten if you wait — dump right after witnessing the bug. To collect without a cable, the game itself needs to write its own log file under Application.persistentDataPath (see below).

iOS — Console or Xcode

• During development: the Xcode console with the device attached is the most accurate
• Device alone: macOS Console.app shows logs from a USB-connected device
• TestFlight builds: system log access is effectively out of reach, so without your own file logging there's no practical way to get logs

The practical answer on mobile — persistentDataPath logging

On both platforms, "the tester extracts the system log and sends it" rarely survives contact with reality. The industry-standard setup is for the game to write log files under Application.persistentDataPath itself and share them (upload or email) from inside the game. The minimal implementation for hooking the log callback and writing to a file is in a separate post.

The structural problem with this whole procedure

That's how you get logs — and once it's written out, the problem is visible. This procedure depends on the person who saw the bug knowing the OS-specific path, finding the right file before it rotates to prev, and sending it. One broken step produces a ticket with no logs, and the fate of that ticket is cannot reproduce.

So we chose to remove the procedure — Rekon collects the preceding logs, video, and game state on one hotkey the moment a bug is witnessed, and uploads them to the web. Logs arrive even when nobody knows the file path.

Even if you collect them by hand, pinning this page in your team wiki should save one round of "where are the logs again?"