iOS crash on startup (Unity 2017.1.3p2)

Our iOS app is failing app review because of long startup time (>10 sec). We are using Unity 2017.1.3.p2.


Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, scene-create watchdog transgression: com.ParallelSpace.Cerberus exhausted real (wall clock) time allowance of 10.00 seconds | | ProcessVisibility: Foreground | ProcessState: Running | WatchdogEvent: scene-create | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 20.580 (user 20.580, system 0.000), 73% CPU", | "Elapsed application CPU time (seconds): 5.436, 19% CPU" | )
Triggered by Thread: 0



Callstack for the stall:




Thread 0 Crashed:
0 libobjc.A.dylib 0x000000018501ead4 std::__1::__function::__func<foreach_realized_class_and_subclass(objc_class*, std::__1::function<void (objc_class*)>)::'lambda'(objc_class*), std::__1::allocator<foreach_realized_class_and_subclass(objc_class*, std::__1::function<void (objc_class*)>)::'lambda'(objc_class*)>, bool (objc_class*)>:perator()(objc_class*&&) + 20 (objc-runtime-new.h:0)
1 libobjc.A.dylib 0x0000000185013644 flushCaches(objc_class*) + 232 (functional:1914)
2 libobjc.A.dylib 0x0000000185013644 flushCaches(objc_class*) + 232 (functional:1914)
3 libobjc.A.dylib 0x00000001850163ac _method_setImplementation(objc_class*, method_t*, void (*)()) + 52 (objc-runtime-new.mm:3124)
4 libobjc.A.dylib 0x000000018501b1c4 class_replaceMethod + 84 (objc-runtime-new.mm:5732)
5 libAXSafeCategoryBundle.dylib 0x00000001955ba930 +[UIAccessibilitySafeCategory _installSafeCategoryOnClass:isManaged:] + 116 (AXSafeCategories.m:157)
6 libAXSafeCategoryBundle.dylib 0x00000001955ba674 +[UIAccessibilitySafeCategory _initializeSafeCategoryFromValidationManager] + 64 (AXSafeCategories.m:78)
7 AccessibilityUtilities 0x000000019560ccc0 -[AXValidationManager installSafeCategory:canInteractWithTargetClass:] + 776 (AXValidationManager.m:923)
8 UIAccessibility 0x0000000197166110 __65+[UIAccessibilityLoader _accessibilityInitializeRuntimeOverrides]_block_invoke_5 + 64 (UIAccessibilityLoader.m:905)
9 AccessibilityUtilities 0x00000001956096d4 __121-[AXValidationManager performValidations:withPreValidationHandlerostValidationHandler:safeCategoryInstallationHandler:]_block_invoke + 528 (AXValidationManager.m:177)
10 AccessibilityUtilities 0x00000001955d30f8 AXPerformBlockSynchronouslyOnMainThread + 56 (AXUtilitiesHelperRoutines.m:40)
11 AccessibilityUtilities 0x000000019566c9bc -[AXAccessQueue performSynchronousWritingBlock:] + 64 (AXAccessQueue.m:272)
12 AccessibilityUtilities 0x0000000195609458 -[AXValidationManager performValidations:withPreValidationHandlerostValidationHandler:safeCategoryInstallationHandler:] + 268 (AXValidationManager.m:129)
13 UIAccessibility 0x0000000197166034 __65+[UIAccessibilityLoader _accessibilityInitializeRuntimeOverrides]_block_invoke + 88 (UIAccessibilityLoader.m:895)
14 libdispatch.dylib 0x0000000185746a14 _dispatch_client_callout + 16 (object.m:502)
15 libdispatch.dylib 0x000000018574a240 dispatch_once_f$VARIANT$mp + 60 (once.c:63)
16 UIAccessibility 0x0000000197165fd8 +[UIAccessibilityLoader _accessibilityInitializeRuntimeOverrides] + 188 (once.h:84)
17 UIAccessibility 0x00000001971663fc +[UIAccessibilityLoader _accessibilityStartMiniServer] + 152 (UIAccessibilityLoader.m:954)
18 UIAccessibility 0x0000000197166314 __50+[UIAccessibilityLoader _accessibilityStartServer]_block_invoke + 392 (UIAccessibilityLoader.m:933)
19 AccessibilityUtilities 0x00000001955d3068 AXPerformBlockOnMainThread + 56 (AXUtilitiesHelperRoutines.m:23)
20 UIAccessibility 0x0000000197166180 +[UIAccessibilityLoader _accessibilityStartServer] + 68 (UIAccessibilityLoader.m:926)
21 UIKit 0x000000018f3e9f50 -[UIApplication(UIKitApplicationAccessibility) _updateApplicationAccessibility] + 136 (UIAccessibility.m:373)
22 UIKit 0x000000018f3e9b54 -[UIApplication(UIKitApplicationAccessibility) _accessibilityInit] + 112 (UIAccessibility.m:440)
23 CoreFoundation 0x0000000185d5913c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20 (CFNotificationCenter.c:661)
24 CoreFoundation 0x0000000185d590a0 ___CFXRegistrationPost_block_invoke + 64 (CFNotificationCenter.c:163)
25 CoreFoundation 0x0000000185d6f590 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20 (CFRunLoop.c:1840)
26 CoreFoundation 0x0000000185d6ee60 __CFRunLoopDoBlocks + 288 (CFRunLoop.c:1881)
27 CoreFoundation 0x0000000185d6d0c8 __CFRunLoopRun + 2436 (CFRunLoop.c:3176)
28 CoreFoundation 0x0000000185c8cc58 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3245)
29 GraphicsServices 0x0000000187b38f84 GSEventRunModal + 100 (GSEvent.c:2245)
30 UIKit 0x000000018f3e55c4 UIApplicationMain + 236 (UIApplication.m:3956)
31 Cerberus 0x0000000100bcf620 0x100bc8000 + 30240
32 libdyld.dylib 0x00000001857ac56c start + 4


Cerberus is our bundle. I'm having trouble figuring out how we can control the callstack, and can't seem to find info on the related UIAccessibilityLoader and AXValidationManager.

It would seem the tester is using Airplay. I cannot reproduce with Airplay on my devices, and we have selected this unity version specifically because it fixes another airplay related crash (https://issuetracker.unity3d.com/is...launching-app-from-url-with-airplay-connected)

Are there others with this issue? Any ideas for how to avoid calling into the offending functions in the first place?

 

Hi Andre,

We're in the same boat - any news on this new breed of rejection?

Do you also have this big 7 second gap in the tester's log?

2018-03-13 05:02:15.3915 -0700 0x44d2 1024 0x0 1061 FrontBoardServices: [FBSScene] [com.curious.wordgenius - AirPlay] Created client agent: <UIApplicationSceneClientAgent: 0x10ce0a0b0>
2018-03-13 05:02:22.9869 -0700 0x456f 1024 0x0 1061 CoreMotion: #Warning Error reading file //private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist: Error Domain=NSCocoaErrorDomain

 

I'm having a very similar issue, but on my case is when the app comes back from being on the background.
I'm using Unity 2017.2

 

Having similar issue - got rejected today - with

Termination Description: SPRINGBOARD, scene-create watchdog transgression: com.Sunscool.Sunscool exhausted real (wall clock) time allowance of 10.00 seconds | | ProcessVisibility: Foreground

The crashed thread stack says we were in DisplayLinkItem:update_link, which is called every frame refresh, and then it realized some resource that it needs (SourceList or CFPrefs?) is locked and started waiting for it, and 10sec elapsed while it was waiting.

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x0000000184837568 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x00000001848373e0 mach_msg + 72 (mach_msg.c:103)
2 libdispatch.dylib 0x00000001846d8890 _dispatch_mach_send_and_wait_for_reply + 644 (mach.c:831)
3 libdispatch.dylib 0x00000001846d8d3c dispatch_mach_send_with_result_and_wait_for_reply$VARIANT$mp + 56 (mach.c:1958)
4 libxpc.dylib 0x00000001849a7d7c xpc_connection_send_message_with_reply_sync + 196 (connection.c:802)
5 CoreFoundation 0x0000000184cdf290 __80-[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:]_block_invoke_3.143 + 40 (CFPrefsSearchListSource.m:935)
6 CoreFoundation 0x0000000184d87538 -[_CFXPreferences withConnectionForRoleerformBlock:] + 48 (CFXPreferences.m:1168)
7 CoreFoundation 0x0000000184cdf25c __80-[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:]_block_invoke_2.142 + 124 (CFPrefsSearchListSource.m:934)
8 libsystem_trace.dylib 0x0000000184988b54 _os_activity_initiate_impl + 60 (activity.c:123)
9 CoreFoundation 0x0000000184cdf1b4 __80-[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:]_block_invoke.140 + 124 (CFPrefsSearchListSource.m:0)
10 CoreFoundation 0x0000000184cdecd4 CFPREFERENCES_IS_WAITING_FOR_SYSTEM_CFPREFSD + 48 (CFPrefsSearchListSource.m:826)
11 CoreFoundation 0x0000000184cdef0c -[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:] + 184 (CFPrefsSearchListSource.m:962)
12 CoreFoundation 0x0000000184cdf7c0 -[CFPrefsSearchListSource alreadylocked_copyDictionary] + 384 (CFPrefsSearchListSource.m:1031)
13 CoreFoundation 0x0000000184cdda60 -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 88 (CFPrefsSearchListSource.m:553)
14 CoreFoundation 0x0000000184d7c218 -[CFPrefsSource copyValueForKey:] + 64 (CFPrefsSource.m:809)
15 CoreFoundation 0x0000000184d862b4 __76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke + 40 (CFXPreferences.m:880)
16 CoreFoundation 0x0000000184ce12f0 __108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURLerform:]_block_invoke + 268 (CFPrefsSearchListSource.m:1531)
17 CoreFoundation 0x0000000184ce0b0c normalizeQuintuplet + 356 (CFPrefsSearchListSource.m:63)
18 CoreFoundation 0x0000000184ce11d8 -[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURLerform:] + 108 (CFPrefsSearchListSource.m:1409)
19 CoreFoundation 0x0000000184d8624c -[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] + 124 (CFXPreferences.m:876)
20 CoreFoundation 0x0000000184d88e14 _CFPreferencesGetAppIntegerValueWithContainer + 128 (CFXPreferences.m:1627)
21 IOMobileFramebuffer 0x0000000187bfa9c0 _ioMobileFramebufferAlloc + 348 (IOMobileFramebufferLib.c:4630)
22 IOMobileFramebuffer 0x0000000187bfa380 IOMobileFramebufferOpen + 52 (IOMobileFramebufferLib.c:4713)
23 IOMobileFramebuffer 0x0000000187bfd868 IOMobileFramebufferGetDisplay + 216 (IOMobileFramebufferLib.c:5148)
24 IOMobileFramebuffer 0x0000000187bfdbf8 iomfb_populate_display_infos + 416 (IOMobileFramebufferLib.c:5218)
25 IOMobileFramebuffer 0x0000000187bfddd4 IOMobileFramebufferOpenByName + 44 (IOMobileFramebufferLib.c:5540)
26 QuartzCore 0x0000000188c752b4 CA:isplay::IOMFBDisplay::new_display_link(__CFRunLoop*, X::List<__CFString const*> const*) + 100 (CADisplay.mm:1035)
27 QuartzCore 0x0000000188c71998 CA:isplay:isplayLinkItem::update_link(__CFRunLoop*) + 312 (CADisplay.mm:1157)
28 Sunscool 0x00000001001a794c 0x10019c000 + 47436
29 Sunscool 0x00000001001b4ae8 0x10019c000 + 101096
30 Foundation 0x0000000185727d58 __NSFireDelayedPerform + 412 (NSRunLoop.m:620)
31 CoreFoundation 0x0000000184cebdc0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28 (CFRunLoop.c:1832)
32 CoreFoundation 0x0000000184cebae4 __CFRunLoopDoTimer + 864 (CFRunLoop.c:2415)
33 CoreFoundation 0x0000000184ceb2e4 __CFRunLoopDoTimers + 248 (CFRunLoop.c:2562)
34 CoreFoundation 0x0000000184ce8ecc __CFRunLoopRun + 1928 (CFRunLoop.c:3083)
35 CoreFoundation 0x0000000184c08c58 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3245)
36 GraphicsServices 0x0000000186ab4f84 GSEventRunModal + 100 (GSEvent.c:2245)
37 UIKit 0x000000018e3615c4 UIApplicationMain + 236 (UIApplication.m:3956)
38 Sunscool 0x00000001001a1880 0x10019c000 + 22656
39 libdyld.dylib 0x000000018472856c start + 4

I have just moved to 2017.1.3p2, because with an earlier version of Unity I got rejection as well - but that time with a different problem - Unity framework code was crashing if there's an AirPlay device connected and we have 2 displays instead of one. That was a known crash and supposedly it was fixed in 2017.1.3p2. The issue is being discussed here:
https://stackoverflow.com/questions...-app-review-team-crash-unity-app-with-vuforia
and patches for it are still being back-ported to some older Unity versions here:
https://issuetracker.unity3d.com/is...om-url-with-airplay-connected?page=1#comments


I wonder if this new crash is still somehow related to the fact that Apple started doing review tests with AirPlay connected...

 

We're seeing the same thing, with a new build generated by 2017.3.0p4, which we moved to (from 2017.3.0f3) to get around the AirPlay crash-on-launch bug we've all been bitten by. We have yet to be able to get our app into the store because of this string of issues. Starting to feel like Unity iOS apps shouldn't be considered officially supported, since it's proving impossible for us to get one approved...

 

We are also having this issue, with Unity 2017.2.1f1 (We are manually fixing the AirPlay issue)
We are trying to push a critical feature on a tight deadline and this is massively worrying.

Has anyone logged a bug for this?

 

Frustratingly we have the same model iPad on the same kind of network, we even streamed on airplay, we can't reproduce the error.
I wonder what variable they have in their testing setup that is causing the issue.

 

I have submitted a bug report, waiting for it to show up on the issue tracker

 

Note that none of the call stacks we have here are likely related to the issue. The major delay could have happened before the code shown in the callstack was being hit. For that reason, it's probably a waste of time to file a bug report without repro steps. If anyone has (semi)reliably reproduced this, please post here. Airplay has likely something to do with it.

@totsboy your call stack is probably enough to file a bug with Unity. Seems like a blocking www connection on termination and they simply should not be doing that. Perhaps you can prevent it from your scripts if it's caused by your custom WWW calls. I doubt this is related to the other problems (our problems are on scene-create, yours on process-exit).

@ThomasLightweave how were you able to manually fix the airplay issue? Does the fix require source access? Were you able to reproduce the crash in the first place?

 

@andreasp We manually comment out a line in the resultant xcode project, this was a fix before the proper bug fix came out. Really I should just move the project over to a newer patch but I was not wanting to introduce new possible issues.

We have not been able to reproduce the crash, we are using the same model iPad on a ipV6 network, we have tried streaming on Airplay at the same time.

We also tried opening the app with the device connected to a router without internet access.

Each time it worked fine, though perhaps it might have opened slower.

 

Possible related bug being discussed on the Vuforia forums
https://developer.vuforia.com/forum...review-vuforia-7047-and-unity-201731f1?sort=2

 

Is anyone having this bug who is *not* using Vuforia?

@andreasp @mikebev-ik @abkairov @totsboy are any of you using vuforia?

 

@ThomasLightweave I'm not.

@andreasp You're right, but while trying to reproduce this bug I caught another crash that is scene-update, maybe this one is related?

 

Well at least that means we know the issue is not with vuforia then, what I would like to work out is what point of commonality there is between our app that might be the cause of the issue.

Surely not everyone using unity is having the same rejection otherwise I would imagine there would be more outcry.

For what it's worth apple rejected our app again, I have attached our crash dump.

And thus far the bug report is not being massively productive, it is not going to the developers until it is reproducible but by definition it is not reproducible

 

In my case we are not using vuforia.

BTW, update on our App Store review progress: I appealed the case yesterday, with the same binary that was reported crashing - and it went to review today and got approved.

@ThomasLightweave did you get the issue # or link for your bug report to Unity?

 

Good to hear, would you be able to share what you said in the appeal? It would be good to know how to phrase "We know it's crashing but we are pretty sure it is a problem with your testing environment"

The case ID is "Case 1014024"

 

ha, I didn't realize that I can't access that exchange anymore from itunesconnect - it's gone. But it was something like:

*********
could you please verify this app once again manually, as I'm not able to reproduce this crash on my side, and the crash dump is not helpful - it actually indicates that the stall happens inside of Apple's framework. This seems to be due to some recent change in App Store's test framework, as I can see many other developers started getting rejections because of this issue/crash just in the past few days, as you can see here f.e. - https://forum.unity.com/threads/ios-crash-on-startup-unity-2017-1-3p2.521666 . I wonder if it's possibly related to the way test framework uses AirPlay service.
***********

 

Cheers mate, I'll give that a go.

 

I had same issue. Yesterday I appealed referencing this forum thread. This morning they rejected the appeal, then an hour later approved the app

 

I have just got a rejection note from Apple as well. Same 7sec gap as
@jtokash mentioned and the issue not replicable on my end. I asked for replication steps and referenced this thread ... lets see what happens next. Using 2017.3p3, not using Vuforia.

 

Our app was approved upon review.

 

One question, despite not using vuforia, do any of your apps require camera permission?

 

not in our case. The only permissions we require is Push Notifications.

 

We have the same issue and unfortunately apple rejected our app after appeal as well.
So let me repeat jtokash's question: do everyone who experienced this issue have this big gap in apple's call stack?

Code (CSharp):

1. 2018-03-17 19:48:46.4193 -0700    0x388af 1024 0x0 17167 libsystem_network.dylib: nw_endpoint_flow_protocol_connected [4.1 50.19.233.141:443 ready socket-flow (satisfied)] Output protocol connected
2. 2018-03-17 19:48:46.4194 -0700    0x388af 1024 0x0 17167 libsystem_network.dylib: nw_endpoint_flow_connected_path_change [4.1 50.19.233.141:443 ready socket-flow (satisfied)] Connected path is satisfied, viable
3. 2018-03-17 19:48:54.6402 -0700    0x3898c 1024 0x0 17167 CoreMotion: #Warning Error reading file //private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist: Error Domain=NSCocoaErrorDomain Code=257 "The file “com.apple.CoreMotion.plist” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=//private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist, NSUnderlyingError=0x14d7acf80 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

 

@madfatcat yes. Same gap.

I wonder it anyone is having this issue on 2018.1 beta? Or is beta still an early one and surely not ready for use in production yet?

 

Same for me, even after updating to 2017.3.1p4, though the delay is not so huge as in your case:

Code (CSharp):

1.  
2. 8-03-18 16:21:21.6625 -0700    0x12f5e 1024 0x0 4694 libboringssl.dylib: Function boringssl_context_build_peer_trust: line 1242 [0x10cb81de0] SecTrustCreateWithCertificates result: 0 0x10cb85400
3. 2018-03-18 16:21:24.1622 -0700    0x12f53 1024 0x0 4694 FrontBoardServices: [FBSScene] [com.pandastic.oceanblast - AirPlay] Created client agent: <UIApplicationSceneClientAgent: 0x10c7494a0>
4. 2018-03-18 16:21:26.8714 -0700    0x12fdc 1024 0x0 4694 CoreMotion: #Warning Error reading file //private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist: Error Domain=NSCocoaErrorDomain Code=257 "The file “com.apple.CoreMotion.plist” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=//private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist, NSUnderlyingError=0x10ca9f3a0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
5.  

 

Don't make any blocking or synchronous calls. Apple will test on a connected network that has unreachable internet - so blocking calls will wait for the timeout in those cases and I would guess is more than 10 seconds.

Callstacks from apple in the case of a SIGKILL crash is likely not helpful - it's not a real crash but an application kill by the OS.

My team had to change to async calls to our network on startup.

 

Thanks for advice @TheJimz

The only network related calls I have are from Unity, Admob and Firebase. I have just checked with a router that had no Internet connectivity and the app started just fine. Seems its not a blocking network call

 

@pandastic_games @madfatcat @abkairov @ThomasLightweave - are you using Firebase Analytics? or anything else from Firebase? how about Admob?

 

We are using firebase, but we also tested having it connected to an network (ipv6) without internet connectivity, the app worked fine and popped up it's not internet connection message.

Update on the unity bug report, they are not seeming to quite understand that the problem is only replicable in the apple testing environment. They want me to attach our project but it is really not suited for testing as it is a huge complicated beast of a thing that requires lots of extra steps in XCode to actually compile.

Seeing that the issue is with apple's testing environment I wonder if we could work out the smallest functional project that will replicate the issues without being rejected for any number of other app completion issues.

 

our project is not using Firebase, for the AdWords we still use Google's older SDK which is being obsoleted now. But we didn't change anything there for the last 1 year, and approvals were never a problem. We also use Amplitude, Crashlytics, and PacketZoom - and have the same problem that our Xcode project has a few modifications, and the Unity project is big.

That was my original hesitation about filing a bug report with Unity because it may be hard to create such a project and distill it to the minimal size which still causes this rejection - as it may happen only for big projects, when lots of resources are loaded at startup, f.e.

I am curious if Unity can still open that as an issue - since it is a real issue that affects many people already - and use that as a placeholder to collect the crash reports and then be able to triangulate between them and find the common patterns. Can you suggest that to them?

 

@madfatcat what you quoted is not a call stack but an events log. Please, do look at your call stack and see which thread is considered crashed (or stalled) - and what's the call stack there. See my earlier post for the call stack that we had.

As for the events log, it's also interesting - in my case, I have similar lines (with CoreMotion error when reading a plist file, see the first part of logs), but that error is not the last line in the events log by far - the app keeps going for 2 more seconds before the log stops. However, what's very noteworthy, is that in my case the line after which there's a stall of around 8 sec is the line when AirPlay client agent is created - and then there're no new events on that thread (0x762c) for 8 sec (see the 2nd part of logs). The CoreMotion runs on a different thread (0x76c9), so it's not indicative of whether the main thread got stalled or not.

 

Yes, I doubt that the crash is due to any new code on our part, rather that it is a change in the testing environment in Apple, I am quite sure that if you submitted builds that had previously been accepted they would still be rejected.

 

There has been some interesting developments in the thread linked above where people using vuforia were having a related issue. The issue is that the apple testing environment is dismissing permission popups, not actually accepting or denying them.

"

From my understanding of the issue, on iOS the camera permission can take one of three states: Allowed, Not Allowed, and Unknown. The first time an app is run, the camera permission is unknown. When permission is requested, the permission dialog pops up, and the user is given the option to select Allowed or Not Allowed, at which point the state is changed.

It would appear that in Vuforia.Init, Vuforia would request camera permission, and then halt the main thread until the camera permission state was anything but "Unknown". Normally this works fine, as the user must select either "Allowed" or "Not Allowed". However it seems during testing, Apple now disables the pop up, meaning that it remains in the "Unknown" state. This means that Vuforia halts the main thread waiting for something which will never happen, and after 10 seconds the Apple automated testing environment kills the app as it assumes it has hung.​

"

 

FYI - here is another issuetracker entry where people report the issue: https://issuetracker.unity3d.com/is...launching-app-from-url-with-airplay-connected

@ThomasLightweave - I do not use Vuforia, my only permission check code is ultra simple:

extern bool IsStoragePermissionGrantedIOS(){

    PHAuthorizationStatus status = [PHPhotoLibrary authorizationStatus];

    if (status == PHAuthorizationStatusAuthorized){

        return true;

    }

    else {

        return false;

    }

}

and I actually do not call it on app start. I use https://assetstore.unity.com/packages/add-ons/services/billing/simple-iap-system-12343 and have it make a call on app start to check if the purchases (subscription) is still valid. Will check how it behaves in a "no connection" situation but from last test I recall it was working just fine.

 

@ThomasLightweave FYI we do not ask for any permissions at app startup currently.

 

Regarding rejections and approvals - we've been rejected for this watchdog issue twice, for 2 different versions of the app. We were able to get approved after both rejections via 2 different methods.

The first time, we just resubmitted with a new (relatively unchanged) binary. That binary was approved.

The second time, I replied to the reviewer with the following text and we were approved the following day. Upon rereading, the middle sentence sounds harsh, but I was merely attempting to be specific and brief.

Thanks for reviewing!
The watchdog wall clock transgression issue seen in this crashlog is coming up a lot during app review of games by other devs and seems to be specific to some internal airplay-based system that app review is using. Please either approve this version or give me very specific instructions on your setup so I can reproduce the issue. Our app works fine over airplay to all existing AppleTV hardware.
Thanks!
John

 

Looking at our crashlogs, I now notice that not only is there a 7 second delay between 2 lines in the syslog, there are 2 other adjacent delays - 1 of 1 second and 1 of 1.5 seconds. Relevant lines below:

2018-03-13 05:02:12.8401 -0700    0x44d2 1024 0x0 1061 libsystem_network.dylib: nw_endpoint_handler_cancel Handler already cancelled, ignoring cancel

--- 1 second gap ---

2018-03-13 05:02:13.9136 -0700    0x451b 1024 0x0 1061 AudioToolbox: 1683: AURemoteIO@0x103006440: IOThread starting

--- 1.5 second gap ---

2018-03-13 05:02:15.3915 -0700    0x44d2 1024 0x0 1061 FrontBoardServices: [FBSScene] [com.curious.wordgenius - AirPlay] Created client agent: <UIApplicationSceneClientAgent: 0x10ce0a0b0>

--- 7 second gap ---

2018-03-13 05:02:22.9869 -0700    0x456f 1024 0x0 1061 CoreMotion: #Warning Error reading file //private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist: Error Domain=NSCocoaErrorDomain Code=257 "The file “com.apple.CoreMotion.plist” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=//private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist, NSUnderlyingError=0x1083eb9d0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

 

Unlike few lucky guys in this thread, our app can't get to app store for more than 2 weeks. We tried all patches mentioned here with no success and our appeal was rejected as well with no comments. We have to find a way from this deadlock. I'd appreciate if everyone who was affected by these weird rejections will answer the following questions:

1. Is your app approved by now?
2. Do you experience this issue with new submission or with an update?
3. On which device does the crash happen according to apple's crashlog?
4. Which analytics do you use?
5. Which ad networks do you use (if any) ?
6. Do you have this warning message in your event log and big time gap before it? "CoreMotion: #Warning Error reading file //private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist"

 

@madfatcat - yes, my app was approved after few rejections. I did a new build as there were some artwork fixes while the app was stuck in review, entered a "please do not reject again, I cannot repliacate the issue" note and ... this time it went through. I will be having another update in few days so possibly I will get the same loop again.

• The crash info from Apple was always referring an iPad.
  
• It was for an update
• I use Firebase (and Unity Analytics)
• I use Admob
  
• Yes - same log entry and a 7sec gap in front of it.
  
• Here is the app: https://itunes.apple.com/us/app/coloring-book-free-app/id1052076567?mt=8

fyi @brightonrich

 

Does anyone know if apple tests on real devices or a emulator?

 

I'm running into the same issue with 2017.3.1p1. My app just got rejected for the same reason caused by AirPlay.

2018-03-25 09:40:03.9124 -0700 0x1915c 1024 0x0 7848 FrontBoardServices: [FBSScene] [com.xxx.xxx- AirPlay] Created client agent: <UIApplicationSceneClientAgent: 0x102f18da0>

2018-03-25 09:40:11.2921 -0700 0x19205 1024 0x0 7848 CoreMotion: #Warning Error reading file //private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist: Error Domain=NSCocoaErrorDomain Code=257 "The file “com.apple.CoreMotion.plist” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=//private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist, NSUnderlyingError=0x10d465800 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

1. Is your app approved by now? - (Update) Approved after appealing with reference to this thread.
2. Do you experience this issue with new submission or with an update? - An update. Previous uploads worked fine and I didn't add anything major features.
3. On which device does the crash happen according to apple's crashlog? - Hardware Model: iPad4,4
4. Which analytics do you use? - Unity Analytics
5. Which ad networks do you use (if any) ? - Unity Ads
6. Do you have this warning message in your event log and big time gap before it? "CoreMotion: #Warning Error reading file //private/var/Managed Preferences/mobile/com.apple.CoreMotion.plist" - Yes

 

Is it always iPad4,4 in the crash logs provided to you by the review team?

 

1. No, we just got rejected.
2. Update
3. iPad4,4
4. Unity Analytics
5. ironSource, Unity Ads and Vungle.
6. Yes.

 

We have this too

 

Unity 2017.1.3p1

1. No
2. Update
3. iPad4,4
4. Facebook , Mixpanel, Flurry
5. None
6. Yes

 

We've just had a similar rejection for an ARKit game built with Unity 2017.3.1p3 which has absolutely no network access in it at all. Yet again iPad 4,4 (which shouldn't even be able to install the game).

 

We've been rejected twice now for this crash. Our app is built with Unity 2017.2.1p4. Apple was using an iPad4,4 the first time and an iPad4,1 the second time. On both occasions they used iOS 11.2.5.

Will try to appeal for approval now and reference this thread.