URGENT - Problem updating commercial app with Unity opening read-write file on OSX build

Hello,

I've an application for OSX made with Unity. On the last update, using Unity 5.3.4p1 my application was rejected for the following error:

2.30

The application accesses the following location(s):

'/Applications/NONONONO.app/Contents/Resources/Data/sharedassets1.assets.resS'

The majority of developers encountering this issue are opening files in Read/Write mode instead of Read-Only mode, in which case it should be changed to Read-Only.

Other common reasons for this issue include:

- creating or writing files in the above location(s), which are not valid locations for files to be written as stated in documentation

- writing to the above location(s) without using a valid app-id as a container for the written files

Please review the "File-System Usage Requirements for the App Store" of Submitting to the Mac App Store for the locations apps are allowed to write and for further guidance.

I need some support with this problem because it's probably something related to how Unity opens the assets file for reading.

Best regards,

 

@Aurore can you check this issue or help us contact someone from support to see it asap. It is a major issue that will affect everyone that releases OSX apps.

We have always updated our application without this problem, but we just got this rejection with this new version of Unity and no change we could downgrade Unity version and re-submit. There were too many issue fixes on OSX UI on latest updates.

Thanks in advance for your help!

 

@Eric5h5 can you take a look at this and see if you can help us?

 

Are you having same issue as original poster, also have you checked Patch 2 that came out the other day to see if it has anything changelog that fixes the issue.

 

Yes, the same problem. The patch from yesterday has no mentions to OSX =(

The problem here is that there is no way for us to check if a new version fix it or not. It is the Apple process that probably has a tool that can check it. So the best would be for someone on the Unity Player OSX to check it. Or at least check what version of Unity may have changed the way it opens the shared assets file. If we downgrade blindly to a previous version we have two problem: no guarantee that the problem wont occur and we have updated our project for some UI (TextBox, Sprite, etc) fixes provided on latest builds =(

Thanks for the support @MrEsquire

 

Hello @karl.jones,

I saw the updates to this thread and opened a bug report as requested. Here is the link for it:

https://fogbugz.unity3d.com/default.asp?786960_pdbkkge9i5rjeomf

Best regards,

 

Thanks @pedrohba . Thanks a lot for the fast support @karl.jones !

 

This thread is a year old, but I am experiencing the same issue recently on Unity 5.6.2f1 and Xcode 8.3.3. Has it to do with using Resources.Load() ? Any workarounds for this? It's too late for me to rollback since 5.6 required significant changes to my project.

I have been submitting to the Mac App Store before this in early 2017 with no such issue on Unity 5.4.1 and XCode 7.3. So it's either some issue with Unity or Xcode or something else.


Guideline 2.4.5(i) - Performance


Your application accesses the following location(s):

'/Applications/Demolition.app/Contents/Resources/Data/resources.assets'

The majority of developers encountering this issue are opening files in Read/Write mode instead of Read-Only mode, in which case it should be changed to Read-Only.

 

HI @koochy_rat . That's sad news, i am using 5.6.1p4 and just got approved by Apple, so you may rollback to this version. If possible, open a issue report so @karl_jones and Unity team get aware of it.

BR

 

I resubmitted and my app was approved! Just in time for release! The only thing I did was to remove some FBX read/write meshes which were accidentally included in Resources (there was another Resources folder buried deep in my project). Strangely these were always included in the build from day one but were always approved by Apple last year on Unity 5.4.1.

I have submitted Case 926048 for further investigation.