Hello all,

I have posted an update to the package we have stickied here to include the updated code @adrianj has provided. Thanks again for your assistance with this issue Adrian!

Thanks,

Vuforia Support

Hello Elvis,

The iOS 11.3 issue is a separate issue from what Adrian's code addresses. I'm working on getting information to share related to this issue.

Thanks,

Vuforia Support

Hi Adrian

My app has the same problem and has been rejected for 3 times.

I tested your camaraworkaround project and got following results.

1. It doesn't works on iPhone 6 plus which running iOS 11.3(15E216). The camera can't be open after vuforia initialized.

2. It works on iPhoneX running iOS 11.2.5

3. I upgrade iPhoneX from 11.2.5 to 11.3(15E216) and reinstall the cameraworkaround. The camera goes black as iPhone 6 plus did

4. It works on iPad running iOS 11.2.5(15D60)

5. It works on iPad running iOS 11.3 as well

It seems that the workaround is not working on iPhone running iOS 11.3. And the workaround became a real bug on iPhone in iOS 11.3.

This bug is killing me. @Vuforia Support We need the patch ASAP.

Unity 2017.4.0f1

Vuforia 7.0.74

XCode 9.3(9E145)

Best regards

Elvis

Hi everyone,

First of all I want to say thank you to everyone who has messaged here or private messaged me to say thanks for the work around, I'm glad that it seems to have resolved the Apple review failures and people are able to update their apps once again. 

Unfortunately I found a bug this morning caused by the work around, but fortunately it's an easy fix to resolve. The bug occurs on "Development Builds" of apps using the work around, and causes the app to crash on startup. This crash is due to Vuforia calling "get_unityVersion" during initialization on Development Builds, and the fact that this function must be called from the Unity main thread, while the work around starts initialization in a thread created by the Camera Permissions callback.

** Please note that this bug shouldn't affect any apps you've already submitted/had approved, and only occurs in Unity's "Development Builds" - for example builds created for profiling your application's performance **

The fix is simple, and just involves making sure Vuforia's Initialization is called from Unity's main thread (in this case the Update function), and setting a boolean in the callback which starts the process.

I have updated the zip files containing the original work around in my earlier post, if you have already implemented these in your projects (or used the .unityproject file @medabit linked in this thread and in the separate pinned thread), you can just download this updated VuforiaInitialization.cs file and overwrite the old one:

 https://www.dropbox.com/s/ad79mm2n6iudxhi/VuforiaInitialization.cs?dl=0

Cheers,

Adrian

Hello

I can confirm that the instructions provided by adrianj worked for us. App now approved and on the store.

Thanks to all but kudos to adrianj

Hello,

Attached is Vuforia’s version of the app-level fix scripts provided by @Adrianj (many thanks!). This can be used immediately with SDK 6.5 (Unity 2017.2), SDK 7.0 (Unity 2017.3) and SDK 7.1 (Unity 2018.1).

Here are the recommended steps for installing and enabling:

1. Back up your project
2. Import the attached DelayedVuforiaInitialization.unitypackage
3. In the first scene that uses Vuforia, attach the VuforiaInitialization.cs script to any active game object, e.g. the ARCamera
4. In the Vuforia configuration (Menu: Window -> Vuforia Configuration) and check “Delayed Initialization”

IMPORTANT: In case your application logic relies on Vuforia being initialized and started at scene startup, you may have to adapt that code. The best way to do this is to listen for the VuforiaStarted callback using: VuforiaARController.Instance.RegisterVuforiaStartedCallback(…);

We are also working on rolling out a similar fix via patch releases for SDK 7.0 and 7.1. Note that for 7.0 patch availability, we are reliant upon Unity's timing for releasing updates. Patching Vuforia 7.1 SDK will be done via installer functionality built into the Editor.

Lastly, contrary to previous Vuforia communications, we *will not* be providing patch releases for SDK 6.2 and 6.5. This is due to multiple factors, including Unity not providing long-term support for Unity 2017.2 (SDK 6.5) and earlier versions. We recommend that you follow similar app-level logic in the attached scripts.

Thanks,

Vuforia Support

Hello,

We successfully made contact with Apple support to inquire about the recent app submission failures, and the relationship to Vuforia. Based upon Apple's feedback, we believe the proposed patch (7.0.52 distributed privately here) did not address the root issue, and thus we will be putting the patch releases discussed below on-hold as we re-evaluate a fix.

Current direction is to test a fix very similar to the one provided by @Adrianj previously in this thread. As this is an 'app layer' fix, there is no need to wait for a formal Vuforia patch if you are under time pressure to get your app approved. We suggest implementing what has already been provided which, simply put, invokes the camera permission dialog on a separate thread and delays the initialization of Vuforia until that has been confirmed.

Vuforia is still evaluating, reviewing and testing this latest fix. We'll continue to update this thread with the latest information as it becomes available.

Thanks again for your patience in this matter.

-Vuforia Support

Hello,

We do have a preliminary patch artifact available, but it is not yet in the form of an official patch release. If you'd like access to it, please DM me.

Unfortunately, the preliminary patch fix has not been 100% successful for all devs who have resubmitted their apps using it. Additionally, even the recent data from these resubmissions (with additional logging enabled) has yet to reveal any new information as to why the apps are failing Apple's testing.

However, as there has been successful resubmissions with the preliminary patch fix, we are going to move forward with official release artifacts for SDK 6.5, 7.0 and 7.1 over the next few days. Priority will go to 7.0, with 6.5 and 7.1 releases soon to follow.

To recap current our current investigations findings:

medabit wrote:

At this time we believe the source issue may be related to special entitlements that Apple can use to turn off the camera pop-ups for the purposes of test automation, and how Vuforia handles the response from that permissions check (synchronously+single-threaded, or ansynchronously+multi-threaded). Our code is written with the assumption that this callback will arrive asynchronously on another thread, and there is potential for deadlock if this assumption is violated.

Unfortunately, we have challenges testing this theory (by setting the special entitlements) as the application installation fails with "invalid entitlements" - not surprising, as Apple doesn't want people to circumvent the dialog! This also fits well to explain why this issue is not seen during dev testing or in the wild.

Please note that this is only meant to update you on the current state of the investigation. Although this is a promising lead, Apple's app approval testing setup and workflow is a black box for which Vuforia has no insight. So, it is only a theory for now.

Please also be aware of the workaround shared by @Adrianj (further down in this thread) in addition to/as an alternative to the Vuforia patch.

Thank you for your patience and understanding.

-Vuforia Support

Hello,

Are there any news about the upcoming patch that would fix the issue? As you might know, this patch is mandatory for a lot of Vuforia developers since it blocks the Apple Store review.

I can't manage to validate a review for a client app I'm working on even if I send a link to this thread to the review team. Can you tell us at least if the patch will be available in the next few days?

Thank you for your hard work. 

Thank You adrianj !  I've applied the Patch and finally my app was approved by Apple. Many thanks for you contribute to fix this issue.  Thanks also to medabit and Strasza that working hard to release a stable fix for the Vuforia 7.

Bye

Thank You adrianj !  I've applied the Patch and finally my app was approved by Apple. Many thanks for you contribute to fix this issue.  Thanks also to medabit and Strasza that working hard to release a stable fix for the Vuforia 7.

Bye

Hi there,

We just received the same "iOS 11.2.5 using iPV6 Network" rejection from Apple with the patch integrated. The error report shows the same "springboard" error as before.

Though we included a link to this thread and explanation in our submission notes, I'm attempting to appeal the decision by linking to this thread once more. Is there any recommendation on how to communicate with Apple regarding this issue? It looks like the patch did not work for our submission. Are there any other recommendations on how to proceed? 

Hello,

Based upon feedback from developers who've successfully passed Apple's process using fixes from the private patch, we will be moving forward with official patch releases for SDK 6.5, 7.0 and 7.1. 

Additional details on when these patches will be made available and how to get them will be posted on this thread.

Thanks,

Vuforia Support

I put the link in the discussion thread inside the resolution center

Same here, my two apps has been approved, but without any clear answer, no answer in fact. So they are approved, however I don't know what will happen in the next release which is awful to don't have the control of what is happening.

update: our second App has been approved!

we added an answer in the resolution center linking this thred.

they reviewed the App and approved it.

we are safe.. until next release :(

Still having the issue

Symbolicated crash log below

Thread 0 Crashed:

0   libsystem_pthread.dylib         0x0000000181a377cc pthread_mutex_lock$VARIANT$mp + 104 (pthread_mutex.c:178)

     0x00000001016538e0 Vuforia::init+ 20887776 () + 260

     0x000000010153e910 initQCARiOS + 19753232 (VuforiaUnityPlayer.mm:83)

     0x00000001008550d8 IOSUnityPlayer_InitializeVuforia_m2342214426 + 6213848 (Bulk_Vuforia.UnityExtensions_1.cpp:29560)

     0x000000010088b300 VuforiaRuntime_InitVuforia_m64948871 + 6435584 (Bulk_Vuforia.UnityExtensions_2.cpp:37421)

hi,

yes please.. tell us how to communicate with Apple.

I wrote 10 answers in resolution center and all of them are still unanswered.

Yesterday they rejected our second App for the 7th time.

the other one has been approved using the Vuforia patch.

let me know.

thanks

scognito wrote:

Apple reviewed his decision after linking this thread!

How do you link them? just put the link in notes?

Hi,

apple rejected again our App, even using the fix provided by Vuforia support team.

the crash log reports the same problem about “springboard”

damn...

Hello,

Thank you @adrianj for the investigation, feedback and workaround! This truly embodies the purpose of the forum - for developers to come together and help one another.

Vuforia continues to receive feedback on our app submission tests for the 7.0 patch, and initial results are very positive. We are working on patch release plan but please be patient as we'll likely need to patch multiple versions.

Here is my recommendation. If you cannot wait for an official patch release (dates TBD), then move forward with @adrianj's workaround. If you're absolutely stuck and need a patch for Vuforia 7.0 immediately, DM me and we'll work out the details.

For those of you working with 7.1.27 SDK (i.e. Unity 2018.1.0b10), we will be officially patching this release soon. Will post additional details as they become available.

Thanks, 

Vuforia Support

Apple reviewed his decision after linking this thread!

Hello,

Our company also got our app rejected because of the same problem, Unity 2017.3.1f1 and Vuforia 7.1. We replied to apple, referring to this thread and the day after we got a response telling us that the app no longer crashes and that we passed the review.

Cheers,

Fredrik

Hi everyone,

While waiting for Vuforia's official fix to this problem, yesterday I was able to create a simple work for the assumed problem , and I'm very pleased to say our app passed review today! The especially great this about this fix is it should work with all versions of Vuforia - we have tested and confirmed it working on Vuforia 6, but it should fix the problem with Vuforia 7 as well.

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.

What this work around does is jump in before Vuforia.init is called, and request camera permission, with a callback when the user selects "Allow" or "Not Allow". This callback is only fired when one of the buttons is pressed, and only then is Vuforia initialized. When Vuforia comes to check the camera permission, it will be in one of these two states, and everything will continue on happily. In the mean time, if the dialog is disabled, the app continues without Vuforia, and the Apple test environment doesn't see it as having crashed.

I've uploaded the work around scripts here:

https://www.dropbox.com/s/c4xq409geb3zm5z/VuforiaCameraWorkaround%20%28Scripts%29.zip?dl=0

There are two scripts, VuforiaInitialization.cs, which must be attached to a GameObject in your scene, and CameraPermissionCheck.mm, which is a script which shows the camera permission dialog and calls the callback in VuforiaInitialization.cs when the user selects an option. In order for this to work, you must open the VuforiaConfiguration asset in the resources folder and enable "Delayed Initialization".

I've uploaded a project here which you can use to test for yourself:

https://www.dropbox.com/s/fdxydapjgwk6fe4/VuforiaCameraWorkaround%20%28Project%29.zip?dl=0

You'll need to provide your own App License Key.

The scripts should work as is in simple applications (if you remember to enable delayed initialization and add the script to a game object), however if your app does anything which relies on Vuforia being started straight away, you may need to modify your code so that only happens after the callback is fired. The simplest way around it is to simply create a new scene which loads on start up and then once Vuforia is initialized load your main scene.

Please note this code is in no way supported or endorsed by Vuforia, and I hold no responsibility for anything that happens as a result of using this code. In saying that, it is all open source, so you can see for yourself what it does. Also I cannot guarantee that this code will get your app through the review, although it did for us, after half a dozen failures.

Vuforia Employees - I hope everything in this message is okay, if there are any issues please feel free to delete it.

Cheers,

Adrian

Hi

We have developed an app using the legacy version of the SDK (v6.2.10) for earlier versions of Unity and have also received a rejection from Apple for a crash on iOS 11.2.5

Please can a patch be provided for the legacy SDK too.

Thankyou

Hello,

Latest update is that we are in the process of testing a patch for Vuforia 7.0. Determining whether or not the fix has successfully resolved the issue depends upon a limited number of app submissions, and subsequent feedback from Apple.

Thank you for your patience. We will continue to update this thread with the latest information.

-Vuforia Support

Hello,

I also received a rejection has come from the Unity 2017.2.1.p2, where the bug with AirPlay should be patched. It looks like it's something else. Since 26.02.2018 I can't publish any version my app.

JohnyG wrote:

I am unable to reproduce the issue on multiple computers with multiple versions of Unity, multiple versions of Xcode, on multiple physical iPhones, with multiple iOS versions... Even tried to set up and AirPlay environment, and cannot crash it whatever I do. What is going on? I

Hello,

We certainly feel and understand your frustration. Here is the current theory being pursued by the Vuforia team, with details from my previous post below:

medabit wrote:

At this time we believe the source issue may be related to special entitlements that Apple can use to turn off the camera pop-ups for the purposes of test automation, and how Vuforia handles the response from that permissions check (synchronously+single-threaded, or ansynchronously+multi-threaded). Our code is written with the assumption that this callback will arrive asynchronously on another thread, and there is potential for deadlock if this assumption is violated.

Unfortunately, we have challenges testing this theory (by setting the special entitlements) as the application installation fails with "invalid entitlements" - not surprising, as Apple doesn't want people to circumvent the dialog! This also fits well to explain why this issue is not seen during dev testing or in the wild.

In the past, this type of rejection was infrequently reported to Vuforia - maybe once per year. And the typical outcome was that if the developer resubmitted the same app, it would pass and be published. It seems that Apple has somehow changed either their testing process, coverage, or both that has led to this unexpected and impactful event.

This is still a P1 (P0) issue for the Vuforia team and we are working hard to provide a resolution. Many apologies for the inconvenience.

-Vuforia Support

I've been rejected 6 times, my client is losing money on such a simple port of Android app, Apple is not responding, and I am unable to reproduce the issue on multiple computers with multiple versions of Unity, multiple versions of Xcode, on multiple physical iPhones, with multiple iOS versions... Even tried to set up and AirPlay environment, and cannot crash it whatever I do. What is going on? Is there any manual workaround for that? Just turning off AirPlay in the built Xcode project? Just anything? The app can only be used within a national park anyway, so I don't think that people will get their TV sets and Apple TVs in their bags...

Hi, 

Apple also rejected our app now a second time for this reason. 

On 08.03.2018 we did successfully passed the review process of apple, but there was a small mistake in the color of a material, so we changed only the color value and send it to review again. Since then the app is rejected 2 times.

here te relevant parts of the symbolicated crash report where the app was rejected the first time. 

## Apple Review ##

Von Apple

2. 1 Performance: App Completeness

Guideline 2.1 - Performance

Your app crashed on iPad or iPhone running iOS 11.2.5 connected to an IPv6 network during our review.

We have attached detailed crash logs to help troubleshoot this issue.

Next Steps

To resolve this issue, please revise your app and test it on a device to ensure that it runs as expected.

## CRASH LOG ##

[...]

Hardware Model:      iPad5,1

Device Model:        J96AP

Version:             6 (1.8)

Code Type:           ARM-64 (Native)

Role:                Foreground

Date/Time:           2018-03-09 11:03:09.3714 -0800

Launch Time:         2018-03-09 11:02:51.9094 -0800

OS Version:          iPhone OS 11.2.5 (15D60)

[...]

Exception Type:  EXC_CRASH (SIGKILL)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note:  EXC_CORPSE_NOTIFY

Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d

Termination Description: SPRINGBOARD, scene-create watchdog transgression: com.example.ExampleName 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): 21.810 (user 21.810, system 0.000), 63% CPU", | "Elapsed application CPU time (seconds): 15.601, 45% CPU" | )

Triggered by Thread:  0

[...]

2018-03-09 11:02:59.3127 -0800 0x1a14f 1024 0x0 6893 FrontBoardServices: [FBSScene] [com.example.ExampleName - AirPlay] Created client agent: <UIApplicationSceneClientAgent: 0x1c0200220>

Thread 0 name:  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:

0   libsystem_pthread.dylib        0x0000000184b0b764 pthread_mutex_lock$VARIANT$mp + 0 (pthread_mutex.c:878)

1   ExampleName                    0x00000001013e68b4 Vuforia::init+ 17262772 () + 260

2   ExampleName                    0x00000001013ba84c initQCARiOS + 17082444 (VuforiaUnityPlayer.mm:83)

3   ExampleName                    0x00000001007b4e28 IOSUnityPlayer_InitializeVuforia_m2342214426 + 4476456 (Bulk_Vuforia.UnityExtensions_1.cpp:29560)

4   ExampleName                    0x00000001007eb1a8 VuforiaRuntime_InitVuforia_m64948871 + 4698536 (Bulk_Vuforia.UnityExtensions_2.cpp:37421)

5   ExampleName                    0x0000000100a49ff0 RuntimeInvoker_Void_t1185182177(void (*)(), MethodInfo const*, void*, void**) + 7184368 (Il2CppInvokerTable.cpp:33085)

6   ExampleName                    0x00000001013b0e20 il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) + 17042976 (Runtime.cpp:469)

7   ExampleName                    0x0000000100dd6070 scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool) + 10903664 (ScriptingApi_Il2Cpp.cpp:216)

8   ExampleName                    0x0000000100ddd624 ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool) + 10933796 (ScriptingInvocation.cpp:329)

9   ExampleName                    0x0000000100d26d40 RuntimeInitializeOnLoadManager::ExecuteInitializeOnLoad(std::__1::vector<int, stl_allocator<int, (MemLabelIdentifier)13, 16> >) + 10186048 (RuntimeInitializeOnLoadManager.cpp:363)

10  ExampleName                    0x0000000100d26c04 RuntimeInitializeOnLoadManager::ExecuteInitializeOnLoad(RuntimeInitializeLoadType) + 10185732 (RuntimeInitializeOnLoadManager.cpp:356)

11  ExampleName                    0x0000000100d42f18 LoadSceneOperation::IntegrateMainThread() + 10301208 (LoadSceneOperation.cpp:395)

12  ExampleName                    0x0000000100d43d54 PreloadManager::UpdatePreloadingSingleStep(PreloadManager::UpdatePreloadingFlags, int) + 10304852 (PreloadManager.cpp:459)

13  ExampleName                    0x0000000100d442a0 PreloadManager::WaitForAllAsyncOperationsToComplete() + 10306208 (PreloadManager.cpp:542)

14  ExampleName                    0x0000000100d460cc RuntimeSceneManager::LoadScene(core::basic_string<char, core::StringStorageDefault<char> > const&, core::basic_string<char, core::StringStorageDefault<char> > const&, core::basic_string<char, core::StringStorageDefault<char> > const&, UnityGUID const&, int, RuntimeSceneManager::LoadingMode) + 10313932 (SharedObject.h:110)

15  ExampleName                    0x0000000100d18b50 PlayerStartFirstScene(bool) + 10128208 (Player.cpp:492)

16  ExampleName                    0x0000000100b45558 UnityLoadApplication + 8213848 (LibEntryPoint.mm:209)

17  ExampleName                    0x000000010038bfcc -[UnityAppController startUnity:] + 114636 (UnityAppController.mm:133)

18  Foundation                     0x00000001858c3d58 __NSFireDelayedPerform + 412 (NSRunLoop.m:620)

19  CoreFoundation                 0x0000000184e87dc0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28 (CFRunLoop.c:1832)

20  CoreFoundation                 0x0000000184e87ae4 __CFRunLoopDoTimer + 864 (CFRunLoop.c:2415)

21  CoreFoundation                 0x0000000184e872e4 __CFRunLoopDoTimers + 248 (CFRunLoop.c:2562)

22  CoreFoundation                 0x0000000184e84ecc __CFRunLoopRun + 1928 (CFRunLoop.c:3083)

23  CoreFoundation                 0x0000000184da4c58 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3245)

24  GraphicsServices               0x0000000186c50f84 GSEventRunModal + 100 (GSEvent.c:2245)

25  UIKit                          0x000000018e4fd5c4 UIApplicationMain + 236 (UIApplication.m:3956)

26  ExampleName                    0x0000000100377790 main + 30608 (main.mm:33)

27  libdyld.dylib                  0x00000001848c456c start + 4

[...]

Apple rejected 2 new build of our Apps, with the same error.

Exception Type:  EXC_CRASH (SIGKILL)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note:  EXC_CORPSE_NOTIFY

Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d

Termination Description: SPRINGBOARD, scene-create watchdog transgression: com.ferrero.magickinder.cacciaalleuova 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): 21.010 (user 21.010, system 0.000), 67% CPU", | "Elapsed application CPU time (seconds): 14.295, 45% CPU" | )

Triggered by Thread:  0

Damn...

Hello,

We are having the same issue, I attach the crash report that Apple Team Review sent me. I hope it can help to figure out how to solve this :( 

Hi Strasza,

I have just private messaged you and medabit the crash logs, it's for a client application so I thought I better not share publically.

What is interesting about this latest build is that we reverted to Vuforia 6.2.10 for it (still using Unity 2017.3.1 because of the airplay crash), to see if the issue was something which had been added to Vuforia 7. Unfortunately this had the exact same crash in the exact same function. It would seem there is some Mutex Lock request in Vuforia init which is now no longer being granted by the new iOS app test environment, and as this is running in the main thread it's causing the app to hang and after 10 seconds the test environment kills the app for hanging. One solution may be to run whatever part of the code is calling this mutex in another thread, so that if it does hang at least it's not the main thread.

I have submitted an appeal to the review board, but unfortunately if this is not granted we are very likely going to miss this client deadline :(

Hello,

Thank you for all the additional data. It has been very helpful to our investigation.

At this time we believe the source issue may be related to special entitlements that Apple can use to turn off the camera pop-ups for the purposes of test automation, and how Vuforia handles the response from that permissions check (synchronously+single-threaded, or ansynchronously+multi-threaded). Our code is written with the assumption that this callback will arrive asynchronously on another thread, and there is potential for deadlock if this assumption is violated. 

Unfortunately, we have challenges testing this theory (by setting the special entitlements) as the application installation fails with "invalid entitlements" - not surprising, as Apple doesn't want people to circumvent the dialog! This also fits well to explain why this issue is not seen during dev testing or in the wild.

Please note that this is only meant to update you on the current state of the investigation. Although this is a promising lead, Apple's app approval testing setup and workflow is a black box for which Vuforia has no insight. So, it is only a theory for now.

Mostly, I want you assure you all that we are working to resolve this issue with highest priority.

Thanks,

Vuforia Support

adrianj wrote:

One of our apps just failed review again for a third time, once again because the main thread was paused too long in the Vuforia.Init method :(

Could you share a symbolicated crash log with us? Are you on native or Unity?

Thanks,

Vuforia Support

One of our apps just failed review again for a third time, once again because the main thread was paused too long in the Vuforia.Init method :(

I uploaded my app for a new review, in my last review that got rejected I had the same problem as everyone and Apple sent this report.

Unity 2017.3.0p4 Vuforia 7.0.47

Uploaded a zip file with the crash log

Same issue here, app works fine in all conditions, but crashes when in app review with the same crash log. Using Unity 2017.3.1f1 and vuforia 7.0.47

As per message yesterday rejected with 2018.1.0b10 and Vuforia 7.1.

Crash file from Apple attached

Attached my crash report unity 2017.3.1f1, app rejected.

Hi @medabit,

We believe that the issue is not IPV6-related and that this error message is just plain unspecific meaning: Apple Review tested the app in an IPv6 network and it failed, but not necessarily due to IPv6.

Please forward attached symbolicated crash log by Apple to your engineers.

Thanks @medabit for your reply. I will try resubmitting the apps again and if they fail I will refer Apple to this forum thread.

I do wonder however if the IP6 thing is just a red herring and has no relevance to the actual problem. It would seem the actual failure is due to the main thread pausing for longer than 10 seconds. In the callstack I initially posted from the Apple Crash log, it appears that Vuforia.Init is requesting a Mutex Lock which something else is holding, and whatever is holding the mutex isn't releasing it for over 10 seconds. Perhaps the engineers could see if there's anything in the init method which uses mutexes, and perhaps this could be moved to a separate thread so as not to block the main thread.

We just had one of our app approved today after 2 weeks of constant rejections.

This is app review team's response to us via the resolution centre ~2 hours prior to the approval:

Quote:

Hello,

Thank you for your response. Upon further review, it appears that the crashing issue is no longer present.

We will proceed with the review, and will notify you if there are any further issues.

Best regards,

App Store Review

We just resubmitted another app that was rejected for the same reason and is currently in review.

Hello,

Thank you for all the detailed reports. Vuforia has thoroughly investigated Apple rejecting apps due to the "IPv6 crash" on multiple occasions, including with Vuforia SDK 6 and 7. Our procedures followed Apple's instructions on how to configure an IPv6 test environment in the hopes of replicating the issue. However, to date, we have yet to be able to successfully reproduce any crash in Vuforia due to IPv6 networking. What makes this situation even more ambiguous is the fact that the apps previously rejected (and then investigated by Vuforia) have passed upon resubmission.

Please note that Vuforia does not have independent network stack components as part of the SDK. We utilize native iOS APIs for all networking functions which further adds to the confusion when trying to isolate the root cause of the rejections.

Core engineering has been made aware of this thread, and will review it for any additional details that may help us further isolate the issue. If you have the dump file provided by Apple, please either attached it to this thread or IM it to @medabit or @Strasza directly (if you're concerned about privacy).

We appreciate your patience in this matter.

-Vuforia Support

I am having the same problem with my app being rejected, please if any one can help in this matter.

Exception Type:  EXC_CRASH (SIGKILL)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note:  EXC_CORPSE_NOTIFY

Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d

Termination Description: SPRINGBOARD, scene-update watchdog transgression: com.deanalytics.quitoareciclar exhausted real (wall clock) time allowance of 10.00 seconds |  | ProcessVisibility: Foreground | ProcessState: Running | WatchdogEvent: scene-update | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 33.010 (user 33.010, system 0.000), 59% CPU", | "Elapsed application CPU time (seconds): 24.128, 43% CPU" | )

Triggered by Thread:  0

We're having exactly the same problem as everyone else here, recently upgraded to 2017.3.1 because our apps started failing due to the Airplay crash, and now we're getting the Springboard crash. Have tried reaching out to some people at Vuforia but no luck yet, and there doesn't seem to be an obvious way to directly contact support. Hopefully someone from Vuforia sees this thread and is able to offer some suggestions, it would seem at the moment that there's no way to submit or update a Vuforia app for iOS anymore.

Thanks @shoutrlabs for pointing me to this thread. I made a post here App rejection.

We are having exact same issue as @adrianj and it has driven us crazy because of the time and backtracking that has been involved thus far without a solution.

In our case, we are using Unity 2017.2.1p3 and Vuforia 6.5.25.

hi,

same error here..

they approved the previous version of our App using unity 3017.3p3 and they rejected a new build, made with the same unity version.

very strange..

Same error here. App got rejected twice with Unity 2017.3.1f1. 

Termination Description: SPRINGBOARD, scene-update watchdog transgression

We are now trying with 2017.3.1p4, altough the release notes do not mention the issue.

BTW: Is there actually an issue on the issue tracker for this?

We have exactly the same error. Just submitted today with 2018.1.0b10 and Vuforia 7.1 to see if it fixes this problem. 

There seemed to be some discussion on downgrading might fix the issue on other threads. We couldn't downgrade as we then hit the Unity issue that the submission fails with the airport mirroring issue that was fixed in 2018.1

There was also some discussion on whether setting Airplane Mode replicated the crash. However none of that works for us.

Someone also suggested that contacting the app review team to appeal an app rejection with this form :https://developer.apple.com/contact/app-store/?topic=appeal worked for them.

We'll try a few more times and then try the appeal route