Search Issue Tracker
By Design
Votes
0
Found in
2019.2.0a4
2019.3
2020.1
2020.1.0a14
Issue ID
1203716
Regression
Yes
[OS X] Unix executable inside build's .app package derives its name from the project's product name instead of the build's name
How to reproduce:
1. Create a Unity project
2. In the "Edit" > "Build Settings..." window, build any Scene for the Mac OS X Standalone platform and make sure to give it a unique name
3. After the build is finished, open the folder where the build .app file is located in Finder
4. Right-click on the build .app file and press "Show Package Contents"
5. Navigate to "Contents" > "MacOS" and observe the name of the Unix executable file
Expected results: the Unix executable derives its name from the unique name of the build
Actual results: the Unix executable's name is identical to the product's name (found in the Player Settings)
Reproducible with: 2019.2.0a4, 2019.2.16f1, 2019.3.0f3, 2020.1.0a17
Not reproducible with: 2017.4.35f1, 2018.4.14f1, 2019.2.0a3
Notes:
1. Until Unity 2019.2.0a3, the Unix executable in the Contents > MacOS folder is a document, but it is named after the build .app file.
2. Reproducible when building on Mac OS X Standalone on both macOS and Windows devices.
3. To observe the issue on a Windows device, build the project on Mac OS X Standalone, open the build directory through File Explorer, navigate to "Contents" > "MacOS" and note the file's name in the directory.
-
Alloc
Jul 09, 2020 11:58
This is even more of an issue as macOS seems to cache the data from the Info.plist file. Which means that quite a lot of our users now can not start our game anymore as before the executable name had no blanks and now it has, i.e. the binary name changed (and the Info.plist accordingly) but macOS does not see this change.
I don't even see why this had to be changed in the first place? It never hurt anything before to have the executable name be the build name instead of the product name and normally no one sees that file anyway ...
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [OpenGLES][XR] Zooming in on the camera's URP opaque texture causes "double vision" on Quest in OpenGLES3
- “[Worker0] Could not generate preview image“ error when opening macOS native plugin in the Inspector with Architecture to build for set to ARM 64-bit
- [iOS] Application.absoluteURL is empty on Awake/Start when opening via deep link with Splash Screen disabled
- Crash on MemoryManager::Deallocate when rapidly calling Addressables.LoadAssetAsync
- Crash on physx::shdfnd::atomicIncrement when adjusting values on a character controller component after entering Play mode in Prefab edit mode
Resolution Note (2020.1.X):
This is the expected behavior and users can change the executable name by editing "Product Name" project setting. In the future we may consider adding a separate setting if this becomes a common issue.