Finally I found out that this behaviour is likely to be intended by Apple. Page 24 in WWDC 2012 Session Videos: Privacy Support in iOS and OS X  states for iOS 6:

"If permissions changes, app is quit".

Further on in  App Crashing when I Change "Calendar" Access in Privacy Settings aaron_thompson from Apple answered:

"Fortunately, your app is fine!  The system actually kills your app if the user toggles your app's access to calendars in Settings.  The same applies to any protected dataclass in the Settings->Privacy section"

Working with the supplied patch for the Unity extension I ran into a problem: The workaround works pretty well, thanks for the detailed description BTW. But I get a reproducible crash when I start the app again after having denied access to the camera before. This happens when I change the permissioning in the Settings app while my own app is still running in the background.

Steps to reproduce:

• Deny camera access at the very first start
• Start the app again (I show an UIAlertView with a warning here, and a link to the Settings app)
• Go to the settings app and grant camera access while the app is in then background
• Xcode shows a SIG_KILL after 0.3 sec although the app is still in the background. Stack trace isn't very helpful:
  main.mm, line 29: UIApplicationMain(argc, ..)
  If I run the app without Xcode it restarts too

Setup:

• Unity 4.5.5f1 with no special patches, Vuforia 3.0.9, Xcode 6.1, iOS 8 on iPhone 5
• I have implemented the basic code according to the Unity section in https://developer.vuforia.com/forum/ios/ios-8-xcode-6-and-vuforia-30-compatibility
• Adjustments to the proposed code:
  • I refactored the code to use methods
  • I have set up a while (!CameraCheckDone) { } loop in applicationDidBecomeActive, but only at the very first start i.e. not when my own UIAlertView is shown. Otherwise it would violate Apple's user guidelines
• QCARUnityPlayer::getInstance().QCARInit([orientation UTF8String]) is definitely executed in the crash scenario
• My UnityAppController.mm at gist.github.com

What I have tried:

• In applicationDidBecomeActive instantiate QCARUnityPlayer only if camera access is granted => crash
• In applicationWillResignActive call QCARUnityPlayer::getInstance().QCARPause(true) only if camera access is granted => crash

This is kind of irritating especially regarding the submission to App Store.
My questions:

• Is this SIG_KILL the expected behaviour? So can we rely on that Apple will let pass the app through the review process?
• If not, what am I supposed to do in order to fix this?
   

Thanks Leon, that seems to have done the trick for us. I'll report back if we see reports to the contrary.

i have used the fix as per the forum and done some unity hacks as well.

I made a loading screen and waited it for 3 seconds before loading the AR scene. The Xcode fix will show up the camera authorization dialog in the beginning, and as user agrees to it and pass through loading scene , then only vuforia starts. I think this will remove the chance of black screen in first run when camera is allowed.

HI

Heres a link to the fix we used which seemed to work for us. Also we are using he latest Unity / Vuforia / Xcode and OSX rleleases.

https://developer.vuforia.com/forum/unity-3-extension-technical-discussion/ios-app-rejection-no-camera-detected-after-allowing-cam

regards

Leon

We are also seeing similar behavior. Even if the camera access is granted, on initial launch the user always sees a black screen. On subsequent launches, the camera sometimes opens okay. Is there a fix for this forthcoming? I don't htink it will be a good user experience to force them to relaunch the app when they open it the first time.

Thanks,
Patrick

We have implemented Allesandros fix for the camera permission check and included a popup dialog which prompts the user to resolve the camera permission issue. The pop exits the application and the user may restart the application. Apple seems okay with this ! Finally. 

That's good to hear.

  Though they have failed us for our app not being useful :

Perhaps You may want to consider adding some little "extras" to your app (rather than just starting the AR camera straight at startup);

for example, some introductory page explaining the user the overall context and goal of the app, how to use it, or other little things to enrich the user experience ...  maybe Apple will reconsider it in the next review. Good luck with that.

HI

We have implemented Allesandros fix for the camera permission check and included a popup dialog which prompts the user to resolve the camera permission issue. The pop exits the application and the user may restart the application. Apple seems okay with this ! Finally. 

Though they have failed us for our app not being useful :(  They do not like the inclusion of documents in the application, and feel it should not be similar to a mobile website .

Regards

:Leon

See also complete Guidelines here:

https://developer.vuforia.com/forum/ios/ios-8-xcode-6-and-vuforia-30-compatibility

Yes, this can happen is in your application you go straight to Vuforia (QCAR) initialization (for example doing that in the background, like the native Vuforia samples do).

The iOS Camera access dialog will popup as soon as you try to get camera access (normally this would occur at the time that you call QCAR::CameraDevice::init and /or QCAR::CameraDevice::start).

What happens is that, even if you answer Yes (i.e. you allow camera access), but you are not fast enough, Vuforia will go ahead with camera start (in background thread) before actually getting access granted by the O.S.

So, what you need to do is to proactively trigger the Camera Access dialog by adding this code at application startup time, preferably in the application:didFinishLaunchingWithOptions  method (that you can find in your AppDelegate.m file):

if ([AVCaptureDevice respondsToSelector:@selector(requestAccessForMediaType:completionHandler:)]) {
  [AVCaptureDevice requestAccessForMediaType:AVMediaTypeVideo completionHandler:^(BOOL granted) 
    if (YES == granted) {
             
        NSLog(@"User granted access to camera. OK.");
    }
    else {
      NSLog(@"User denied access to camera");
      // Here you should popup a dialog
      // to Tell the user that he denied camera access,
      // but the app requires camera access
      // for example show a UI dialog explaining the user that he
      // can restore camera access for the app via
      // Settings > Privacy > Camera
    }
  }];
}
else {
   // iOS < 7, camera access always OK.
}

Note that if you run that code on iOS7,  no dialog will be displayed,   because the camera access is automatically granted (so, you will only see a log message saying "User granted access to camera. OK".    And the app will work normally.

On iOS 8, that code (in particular the requestAccessForMediaType function) will do one of the following:

- if the user had already allowed camera access previously (for example in a previous run, or by doing that in the Settings > Privacy > Camera), then no dialog will be shown, and the access will be granted and the app will continue normally.

- if the user had not yet allowed acces (i.e. we are on the very first run), then the Camera Access dialog will be prompted and will block waiting for the user answer. This will make sure the Vuforia does not initialize in the background.

Note that you could also put that code in other places; for example, if your App has a start / splash screen / loading screen / start menu page or similar,   you could also plug the code in there.

The important thing is that you make sure that the Vuforia initialization process does not start until the access has been granted.  If you arenot sure where to put that code, the safest place is always in the application: didFinishLaunchingWithOptions (right at the beginning).

Hope this helps.

A Sticky notice with a summary of this (and others) iOS8 related issues will also be posted soon, but in the meantime you can follow the advice above.

I have the same problem.

But in the first run, even we chose YES for camera usage permission, the screen becomes black and it only works in the second run.

OK great...looking forward to the relesase...

But i like to share an info i found in testing. The app was rejected as:

----- 2.2 -----

We found that your app exhibited one or more bugs, when reviewed on iPad and iPhone 5s running iOS 8, on both Wi-Fi and cellular networks, which is not in compliance with the App Store Review Guidelines.

Your app does not load the camera. Please refer to the attached screenshot/s for more information.

But the actual fact is that in iOS8 when you run an app for the first time,it ask for a camera usage permission, if that is denied, we will get a black 

screen and if yes, it works properly. This can be changed in the settings also. I think in review it was denied and then tested.

We are targeting to have this ready in 1 or 2 days at the latest. Bear with us.

I got my app rejected due to camera not working on ios8. I need to resubmit it quickly resolving the issue. When will be the workaround ready?

thanks in advance

We are preparing a Forum post with guidelines and recommendations (including possible code editing needed in your apps) for upgrading to iOS 8. 

This should become available in the coming days.