Camera crashing the app

[thiagomachado1998]

Terminating app due to uncaught exception 'NSGenericException', reason: '*** -[AVCaptureSession startRunning] startRunning may not be called between calls to beginConfiguration and commitConfiguration'
*** First throw call stack:
(0x197bfb994 0x194b15814 0x1bdbec460 0x10de3599c 0x10ced8c18 0x1cff94adc 0x1cffae7ec 0x1cff9d468 0x1cff9df44 0x1cffa83ec 0x1cffa7ce4 0x1f3b9e3b8 0x1f3b9d8c0)
libc++abi: terminating due to uncaught exception of type NSException

react native 0.79.6
react native camera kit 16.1.3

This error occurs when you open and close the camera quickly.

[scarlac]

Hi @thiagomachado1998 I'm very curious how to resolve this. I am able to reproduce but the message does not make any sense. From my logs it seems we are calling begin and commit as per the Apple documentation. The issue seems worse in iOS 26, for some reason.
Can you confirm if you are using iOS 26, or do you have any idea why this could be happening? All attempts to search for this issue have led me to the same defensive coding strategies that all don't work (including Gemini 3 Pro, Claude 4.5 Opus, and GPT-5.1-Codex-Max).

[thiagomachado1998]

@scarlac iPhone 16 iOS version 26. This error apparently occurs because the camera is being opened while a camera shutdown process is running, meaning that if you close the camera and then quickly open it again, you run the risk of encountering this problem. I didn't try to fix it, I just went back to using version 16.0.1 of the library, which is working perfectly.

[thiagomachado1998]

@scarlac Thanks for checking this and for reproducing it.

I agree that this does not look like an incorrect beginConfiguration / commitConfiguration ordering inside a single AVCaptureSession. From what I can tell, this behaves like a lifecycle race condition when the camera is opened and closed very quickly.

My suspicion is that stopRunning() and teardown are still in progress when a new session is created and startRunning() is called. Since stopRunning() is async and AVFoundation holds internal locks on the capture device, a second session starting immediately may trigger the “startRunning between beginConfiguration and commitConfiguration” exception, even though the code order is correct.

This would also explain why the issue is much more frequent on newer iOS versions and faster devices. Delaying reinitialization by a few hundred milliseconds or reusing the same AVCaptureSession instead of recreating it avoids the crash entirely on my side.

It might be worth testing:

• Serializing all session configuration, start/stop, and teardown on a single session queue
• Ensuring the previous session has fully stopped and released the device before creating a new one
• Or keeping a single session alive and pausing/resuming instead of destroying it on unmount

Happy to help test any changes or provide a minimal repro if useful.

[scarlac]

Interesting. I don't see how that can happen, as we have several variables that are effectively shared across sessions, and a shared session dispatch queue, but I actually have a stress test branch locally. Let me try and add a static init variable that persists and see. I tried adding instance variables last time, so perhaps that wasn't enough.

[scarlac]

I should add that I also tried logging ALL begin/commits/startRunning and they are in correct order of each other, across sessions. When a crash happens, I see no change in ordering.

[scarlac]

Even with a mutex / NSLock on the entire RealCamera class, it does not fix the issue, which suggests we aren't actually doing anything wrong here.
What's worse is that I was just able to reproduce the issue on the first attempt to open the camera. App was built in Release mode, then launched, then test was initiated, but on the first open it crashed. The log statements are:

1. locked
2. beginConfiguration
3. commitConfiguration
4. startRunning (setup)
5. crash: *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** -[AVCaptureSession startRunning] startRunning may not be called between calls to beginConfiguration and commitConfiguration'

You'll notice that there's an absence of:

1. 'unlocked'
2. A second session

So unless I'm missing something, I'm not sure this is even a bug in our code? This seems like an iOS bug. Our code isn't starting a second session, which means iOS ran our function calls out of order.

When I compare Console.app output from a non-debugged app, I do see them coming in out of order in log statements from AVFCapture, which suggests that iOS processes commitConfiguration asynchronously. This would be undocumented behavior but that's pretty normal for iOS (it's full of undocumented behaviors and rules):

I feel somewhat validated by the following source code:
https://github.com/aws/amazon-chime-sdk-ios/blob/master/AmazonChimeSDK/AmazonChimeSDK/audiovideo/video/capture/DefaultCameraCaptureSource.swift#L165

Conclusion seems to be that this is an iOS bug, and Apple made it worse in iOS 26. I will submit a feedback report, but don't hold your breath on this.

I will attempt to introduce a 100ms delay to see if it helps, but it's obviously super flaky and it's not clear what value to use for iOS 26 versus iOS 18.

[thiagomachado1998]

@scarlac Honestly, at this point it really looks like this is outside the library’s control and deep inside AVFoundation.

Given everything you’ve tested (locks, single session, correct ordering, release build, first-open crash), a small post-commit delay doesn’t feel like a hack anymore — it feels like a pragmatic mitigation, especially since AWS and other production SDKs ended up doing the same thing.

Even if it’s not ideal, it’s probably the safest and most honest solution for users right now. This definitely doesn’t look like a bug in the library itself.

[thiagomachado1998]

I hope this works. Once you confirm, I will update to the latest version again and run the tests.

[scarlac]

@thiagomachado1998 Merged it into master now.
Feel free to test it if you can. The stress test UI was also added to the example project for now. With the 100ms delay on starting the camera, I was unable to reproduce the crash anymore. However, if it runs for long enough other issues start to occur it seems. I saw a situation where the camera started lagging behind and took a long time to catch up, but it seems to be beyond what this library can resolve and a side effect of the stress test.
Simply upgrading should suffice, but you can try passing iOsSleepBeforeStarting={100} (100ms) or any other value to see what works best for you.

[scarlac]

Released in v16.2.0