Mac App Store

Yeah, there's a permission issue with the Contents/Data folder. You can see it if you test the install with the installer command they provide.

I wrapped up the Mac App Store knowledge I have in this post: http://technology.blurst.com/unity-games-and-mac-app-store/

 

It took some effort but we were able to validate the receipt using just Javascript.

Does anyone know how to do the "Exit 173" via script?

This will give some hope to those not using Pro.

 

Great, thanks.

Looks like the permission issue caused the problem with my installation process, I will start a second submission tonight.

 

Awesome work Matthew... wish you would have had this ready a few weeks ago... would have saved me days of frustration!

 

To create the 512x512 .icns file we use this site... http://iconverticons.com/

And when validating the receipt, we set the game window resolution to 0x0 by default and change it to the desired resolution when validation is passed. This works only the first time the game is installed, as it should.

And according to the Apple developer forum, if the application uses NSUserDefaults to save preferences, it will save on the right folders in 10.6.6. I am not 100% sure, but it seems that Unity uses NSUserDefaults to save the preferences as well. If this is the case we are all set.

 

Hey Andres,

Thanks a clever Idea... Thanks for sharing it. If we get knocked back about the flashing window I will look at adding this trick in

 

The 0x0px window sounds like a good idea. However, I think the DRM is for companies and not for some random student like me I hope people will support me and my project by buying it anyways.

I just sent in a second try, let's hope we all have a little luck this time The good thing: I submitted the graphically enhanced version of my game with an all-new background algorithm and some decent texture clouds. Unity is such a great tool, really. I can't wait to go 3D with it.

 

My app was just rejected, for two reasons. Seems both reasons are due to the Unity framework and beyond my control. Here is the email I received from Apple...

We've reviewed Zen Of Clover *and are unable to post this version to the App Store because it is using a private API. *The use of non-public APIs is not permissible, as documented in section 2.5 of the App Store Review Guidelines <https://developer.apple.com/appstore/mac/resources/approval/guidelines.html>. We have included additional details below to help explain the issue, and hope you’ll consider revising and resubmitting your application.

Using private APIs can lead to a poor user experience should these APIs change in the future. The non-public API, thread_stack_pcs, that is included in your application comes from the following private Apple frameworks - libSystem.B.dylib.

For discrete code-level questions, you may opt to consult with Apple Developer Technical Support at <http://developer.apple.com/support/resources/technicalsupport/>. To ensure that Developer Technical Support can best help you, please be sure to include any logs, screenshots, or steps to reproduce the issues you’ve encountered.


Furthermore, we cannot post this version to the App Store because your application is creating files in the incorrect directories. This is not in compliance with the App Store Review Guidelines <https://developer.apple.com/appstore/mac/resources/approval/guidelines.html>

* *2.30 Apps that do not comply with the Mac OS X File System documentation will be rejected

The application is creating files or writing to ~/.wapi. **Please review the section "File-System Usage Requirements for the App Store" on this page *<http://developer.apple.com/devcenter/mac/documents/submitting.html> for further guidance.

 

Is there any official word from Unity about all of this? Couldn't find anything from looking on their blog site. Meanwhile Shiva is touting on their website that their developers are having their apps accepted.

http://www.stonetrip.com/developer/1365-shiva3d-games-mac-app-store

I sure hope they backfill whatever fix they come up with to 2.6.

 

Wow, that sounds exactly like the IOS terms a while ago.

 

@Jonas Are you saying that your modified UnityPlayer binary resolves the thread_stack_pcs issue for 2.6 only and that 2.6 does not have the ~/.wapi issue? If so, can you provide me with a link to the 2.6 version of Unity.... I am at 3.0 and no longer have access to 2.6

 

@Jonas - You are awesome.

@randy - http://download.unity3d.com/download_unity/unity-2.6.1.dmg

 

I just made some research. I spotted the 2 files in ~/.wapi with the latest Unity 3.1.1 build while the game is running, they are gone as soon as the game exists.

However, 2.6 doesn't seem to like my prefabs and my scenes. 2.6 just doesn't want to open the scenes and when I create a new scene I cannot use the prefabs.

 

As mentioned above: 2.6 isn't an option for 3.1 users, it takes way too much effort to convert a 3.1 project to 2.6 - I'm really looking forward to the upcoming version 3.x and hope you guys will be able to fix both ~/.wapi and thread_stack_pcs().

Is there an ETA for the next release of 3.x? The Mac App Store launches the next weeks, only apps sent in before 1/1/11 will be up and running from day one on - looks like that won't happen for us unity users?

 

It looks like a simple environment variable, MONO_SHARED_DIR.

We could probably use Jonas's build in concert with recompiling the mono runtime DLL for 2.6 from original source, that is if Unity uses the stock sources from the mono project unaltered. Still, providing this for your 2.6 customers would certainly generate a lot of good will.

 

On one hand, I'm very hopeful that we may find a quick solution to the .wapi issue... and on the other hand I'm very worried that we (the Unity community) will not be able to fix this ourselves. I worked my butt off trying to get my app into the Mac Store's launch ... It's sucks to get this close and have this limitation stop me cold.

 

Unity should have come to the rescue two months ago, when we asked for help on different unsupported issues:

- Hiding the user interface until validation.
- Moving the preferences file to a valid folder and naming it correctly.

Now we also need:

- Implementing an internal "Exit 173" function (for non-Pro users)
- Fixing the Data folder privileges
- Avoid writing to ~/.wapi folder
- Remove the libSystem.B.dylib
- And simplifications extras such as 512x512 icon, info.plist file edition and even signage and final package build.

 

My Unity 2.6 app has been rejected as well - but the only reason was "2.5 Apps that use non-public APIs will be rejected". So hopefully with Jonas binary the submission will be fine the next time.

 

The important issue is passing the approval process, and a developer can do everything required except libSystem.B.dylib (fixed 2.6 build available). It looks like the Mono in 3.x respects the MONO_DISABLE_SHM environment variable, which just means a simple Info.plist change.

For 2.6.1 projects we do need a ~/.wapi fix, since it looks like that version of Mono isn't respecting either MONO_DISABLE_SHM or MONO_SHARED_DIR environment variables.

 

@matthew Was your app rejected too?

 

I didn't know that Unity had a forked version of Mono on GitHub... did you??
I see that the last commit was "quick fix .wapi problem (support for Mac App store)"

https://github.com/Unity-Technologies/mono/commit/e3eb3bc496fa467eef0ff90ba1bf1df814b0f179

 

And a garbage collection routine for releasing unallocated memory automatically. Two of three apps i have currently run fine for hours in the editor but I watch the blocks build at 16 bytes a loop in Xcode Instruments. If I knew what code to put in or where to put it I would solve this.

BTH

 

My app, Light Quest, got the exact same rejection letter as yours did. I'm also running the project of the latest version of Unity 3.x and swapping back to 2.6 is not an option for me. Do you know if there is a work around? What exactly would I do with the forked version of Mono?

Thanks,
~Andrew

 

We have got the same rejection letter. I hope the guys at U.T. will solve the problems asap because we would like to release our game just in time.

Jozsef Trencsenyi
CEO, Lead Programmer
Artex Studios, Inc.

 

Ok guys we have 2 days left to get our apps ready. I just want to sum up the current state.

Our 2 main problems for approval are
- thread_stack_pcs
- files in ~/.wapi

Everything else is fixable with some workarounds posted Matthew's blog. Downgrading to 2.6 isn't an option for 3.x users, upgrading to 3.x might eventually work for 2.6 users, but currently we don't have a fix for 3.x either.

3.x
Does MONO_DISABLE_SHM deactivate the files in the ~/.wapi directory or the problem with the thread_stack_pcs?

2.6
We do have a fix for thread_stack_pcs, we need a fix for the ~/.wapi files.

 

Like written before: Apple criticized in my 2.6 app ONLY the thread_stack_pcs thing. So I uploaded a new build with the new binary today and hopefully the game will be approved shortly. Mmhh, but maybe I just got lucky and my editor did not spotted the ~/.wapi clitch. I will keep you informed.

 

The problem is, steffent wrote that 2.6.1 will fail due to the ~/.wapi files.

So I guess Apple just didn't look at ~/.wapi when testing your app. Maybe you will be lucky, but don't be too hopeful. You could test the ~/.wapi issue before sending your app in:

- start the terminal
- enter "cd ~/.wapi"
- enter "ls -a" and make sure that there are no files in the folder
- start your app
- enter "ls -a" a second time, there should be 2 files in the folder now
- enrage and flame Unity loud and clear, but calm down before posting your result here

 

Have you tested your app locally to see if it's writing files to the directory?

The wapi files are written for inter-process communication between two copies of the runtime from what I can gather. The docs are somewhat vague, mentioning only IO and Threading. Perhaps there are certain things we can avoid in our 2.6 apps, such as WWW/Asych loading until Unity gives us a fixed runtime that respects MONO_SHARED_DIR?

 

Hello everyone,
for today we have following solutions for two major Mac App Store support problems:

For Unity 2.6.x users:
a) Jonas already posted updated Unity Player that addresses "thread_stack_pcs" problem. You can download it here: http://files.unity3d.com/jonas/UnityPlayer.zip
b) Also we prepared mono dynamic library update that addresses "~/.wapi" problem. You can download it here: http://files.unity3d.com/mantas/libmono.0.dylib.zip

NOTE: 2.6.x fixes are beta quality code and you need carefully test your game for regressions.
Short update instructions after you made your final app build with Unity Editor:
1) Extract UnityPlayer.zip. There will be UnityPlayer binary. Copy it over <YourFinalAppName>.app/Contents/MacOS/<binary found there>
2) Extract libmono.0.dylib.zip. There will be libmono.0.dylib binary. Copy it over <YourFinalAppName>.app/Contents/Frameworks/Mono.framework/libmono.0.dylib


For Unity 3.x users:
We have prepared beta release of Unity that addresses "thread_stack_pcs" and "~/.wapi". This build is beta quality and currently won't be distributed outside beta lists, but if you are in hurry and aiming Mac App Store grand opening then please contact me with private message and I will give you download link.

 

Wow, that's some first class support you guys are providing us right there! So great to see that you like us almost as much as we like Unity =)

 

I'm getting some strange behavior when changing resolution in a build made with these modified binaries. I'll put together a tiny repro case and submit the bug, but here's a preview.

From the console:

Code (csharp):

1. Switching to 1280x800 fullscreen
2. Wed Dec 29 10:23:15 Alexs-Computer.local Guns of Icarus[360] <Error>: kCGErrorInvalidConnection: CGSGetWindowBounds: Invalid connection
3. Wed Dec 29 10:23:15 Alexs-Computer.local Guns of Icarus[360] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
4. Wed Dec 29 10:23:15 Alexs-Computer.local Guns of Icarus[360] <Error>: kCGErrorInvalidConnection: CGSSetSurfaceBounds: Invalid connection

Summary of observable problems:
- Windowed mode: a blank window is left behind at the old size
- Fullscreen mode: the drawing surface's size changes, but the screen resolution doesn't (meaning the new resolution occupies either a corner of the screen, or expands beyond it)

EDIT: I should make clear that this a Unity 2.6 project, replacing the binaries post-build as mantas described.

 

That's strange a bit. Which OS X version are you using for testing?

 

OS X 10.6.5

Bug report just finished, it's case 387480

 

My faith in Unity is proven once again.... thanks!
I just PM'd you.

 

I am 100% sure that that is a known issue with 2.6.1 and is not new to this modified binary.

 

Excellent work

 

Great work! Thanks!
PM was sent...

 

In that case, what's the exact cause of this known issue (a combination of Unity 2.6.1 and newer OSX versions?) and is there a workaround?

 

This was a bug in 2.6 when AA was enabled. It was fixed in 2.6.1. You can turn AA off on all quality settings for this to work again... I know it's not ideal, but better than having blank windows left behind everywhere!

Looks like this creeped back into 2.6.1

 

App recompiled with the 3.2 beta and resubmitted to the Mac App Store. Fingers-crossed and hopes are high.

 

My upload finished seconds ago, that's our last chance for a day 1 release guys, let's pray to Steve Jobs that it works this time!

 

Looks like Apple rushed the review for it, since our other three resubmissions are still "waiting for review". This was a 2.6.1 build with both fixes from the thread.

Good luck to everyone else!

 

Congratulations Matthew

 

Congratz, that was fast!

 

facing the same rejectoin with our game Star Shipping. Mantasp - sent you a PM about the beta (i'm in the beta group but all i see there is a build from Dec 20th, so i'm assuming it's a different one)

 

I replied with the link.

 

Thanks to the Unity Technologies and mantasp we managed to solve the problems after the rejection.
Fairy Cubes is 'ready for sale' on the Apple Mac Store. We have used Unity 3.2b2. Thanks for your great support.