Who are you?
Indie dev who has worked on released Mac App Store apps in the past.
What kind of game are you trying to build or would like to build?
Small simple 2D and some 3D games that are highly portable from mobile to desktop.
How does OS X standalone player fit into that? What use-cases do you have?
We would like to target the OSX player as a 1st-tier platform for all of my apps.
What are the GOOD things about OS X standalone player that you like?
I like that it generally works pretty well out of the box. It seems to function properly in terms of code porting and graphical displays. I like that there are full screen option setting. I like the no fuss configuration dialog concept.
What are the BAD things about OS X standalone player that you dislike?
The process to make a Mac app store version of the app is convoluted.
No good way to properly brand or change the functionality of the the setup dialog.
No way to change/add command functions to the menu bar.
There are problems with command-tab working properly in Fullscreen window. (A popular Hearthstone issue)
The icons generated by Unity doesnāt do a visually correct sin3 resize of the icon texture. It produces aliasing artifacts on the icons as they are shrunk from the default icon source. (this is a problem on all platforms).
Editing the info.plist can be annoying every export.
The size of the export is pretty large in comparison to some of the other platforms.
Unity projects tend to have problems with Steamās content delivery app.
The export size of the app is relatively large compared to the overhead associated with iOS for example. Could we also get some stripping options for OS X as well?
How can we make it BETTER? What use-cases, features, workflows would like to see?
A big help would be to get an XCode export of the project as an option that could append/replace similar to the iOS deployment platform. This would allow us to code sign and sandbox using Apple documented XCode processes. As part of this give us the .xib for the configuration dialog as well as the menu bar so that we can create custom handling of these? This would also include the ability to alter the plist file via XCode.
With the state of most Mac OS and computing, I feel that you could drop the 32-bit app from the export options.
Work with Valve to make sure that the app goes through their ContentPrep.app without any tweaks or modifications.
Fix the automatic icon generation so that the texture can be resized without artifacts automatically without the need to set the sizes manually for every platform.
Improve the fullscreen functionality so that command-tab works properly in fullscreen window without using the fullscreen with dock and menubar?
If I think of more, I will edit this post.
EDIT1: After working on another project that is primarily PC/Mac/Linux standalone I have some additional suggestions/wishlist items.
Better retina/hDPI screen support as well as general runtime fullscreen display options. Currently, the capture full-screen display mode is the only display mode that recognizes high-dpi screens. Unfortunately, this comes with some side effects that users tend not to like (such as not working well with Command+Tab or blanking out their second monitor). Other fullscreen options do not recognize the OSās scale property and will only display the windows as 1440x900 instead of the 2880x1800 that it should allow the users to display. Also, having this as a build setting is really poor as users may want one functionality or another, and we canāt give them both options because it is a build setting on the player. Having a runtime option for screen display mode would be excellent, allowing users to pick the best option for their machine and purposes. Something like Windowed, Borderless Window, Fullscreen (Capture), Fullscreen (Windowed). The problem is that with fullscreen windowed, I do not want the dock or menu bar to display at all, but others may want that functionality, so having runtime APIs to enable/disable these functions would also be ideal.
