Search Issue Tracker


Fixed in 2019.3



Found in



Issue ID




[OSX] Unity fails to ask camera permission and crashes on privacy violation



How to reproduce:
1. Open the "" project
2. Open the "SampleScene" scene
3. Enter Play Mode

Actual result: Unity crashes.

Reproducible with: 2020.1.0a15, 2019.3.0f2, 2019.2.15f1, 2019.2.0a1, 2019.1.14f1, 2019.1.0a10.
Regression introduced in: 2019.1.0a10.
Not reproducible with: 2019.1.0a9, 2018.4.14f1, 2017.4.35f1.

- same crash happens when using Vuforia.
- Reproducible on both OSX Standalone and Editor

  1. Response avatar

    Resolution Note (fix version ):

    Fixed in Hub 2.3.1

Comments (24)

  1. Cef27004c8609075c2c6218747c43d75?d=mm


    Jun 06, 2020 17:01

    For me, both Unity and the Unity Hub are enabled in the camera privacy settings (I can't remember when and how I enabled it, but I'm pretty sure I did not done an advanced gymnastics to do it...)

    My problem was - which is somewhat related to what is discussed here, so I thought I share - the the *built macos application* crashed on webcamtexture.Play.
    Is seems it is also a permission issue.
    When I entered a string in "project settings/Player/Other Settings/Camera Usage descriptor" field, the crash went away - the built app will ask for camera access with whatever text you entered in the mentioned field.

  2. Aa10360a0370a980f58a0e87e5c47a73?d=mm


    May 22, 2020 03:11

    For a standalone mac build
    We've spent some time trying to get voice permissions as well while using Vivox. While it would attempt to join a channel, it would fail silently and not actually allow the microphone to transmit.

    We discovered that in addition to ensuring `NSMicrophoneUsageDescription`
    was in the plist in the mac app bundle package Contents when built, these entitlements also needed to be set:
    Then the signtool must be run (and a cert may be required)

    Both the plist and entitlements must be done. Only modifying the plist may cause the app to crash or fail to open as described above

    This should allow the app to popup a request for microphone permissions

  3. E3f43a13fe08d403ec34f7acd977fdaf?d=mm


    Apr 27, 2020 23:53

    They seemed to have fixed it according to the release notes of the Unity Hub version 2.3.1:
    New Fixes
    For Mac Catalina OS, Hub permissions are now passed for camera and other Unity Editor related features

    After testing it I can confirm the issue is solved on OSX catalina 10.15.4 and Unity 2019.3.11f1, so update unity hub and you should be good to go!

  4. 2030886903c246ac537f370902d15987?d=mm


    Apr 09, 2020 14:45

    @LAUNZONE - no problem, Thanks anyway :-)

  5. E3f43a13fe08d403ec34f7acd977fdaf?d=mm


    Apr 06, 2020 11:00

    This is how I got my 10.15.4 Catalina to workaround this problem :
    1. Move Unity Hub and Unity folder from Applications to Documents( or any other place )
    2. Start your unity editor from Unity/Hub/Editor folder
    3. New camera and microphone permission are asked
    4. When wanting to use unity hub features ( like collab for instance ) move unity hub to Applications again and signin from the unity editor. When done move Unity hub back to documents.

    Maybe this workaround is useful for somebody.

  6. 2c17b4e452db05c8e15d69eaa0d0d67e?d=mm


    Apr 06, 2020 03:29

    @ELMEGREN oh good to know that it can also work with SIP enabled, just wonder why it didn't for me.. glad that this workaround helped some people so far!

  7. 0576f786c90c8502db7c8b4e5fa7cc9e?d=mm


    Apr 05, 2020 10:15


    I just wanted to report that I got it working using @Launzone's workaround *without* disabling the System Integrity Protection (my machine, a work laptop, prohibits me from doing so as it's firmware password protected preventing me from even going into Recovery Mode). "csrutil status" does report that SIP is enabled.

    I'm on Mojave 10.14.6 with Unity Hub 2.3.0 and Unity 2020.1.0b4.

    Thanks for sharing the workaround Launzone!

  8. 2c17b4e452db05c8e15d69eaa0d0d67e?d=mm


    Apr 03, 2020 18:31

    mojave or later I guess

  9. 2c17b4e452db05c8e15d69eaa0d0d67e?d=mm


    Apr 03, 2020 18:29

    @BORWICKA sorry i should have mentioned, this fix is for Mac OS Mojave (I am currently running version 10.14) so i am actually not sure how the situation was on El Capitan. It seems like those permission things changed.

  10. 2030886903c246ac537f370902d15987?d=mm


    Apr 03, 2020 13:44

    @launzone - I tried your method, although I get this response in Terminal at Step #4: "table access has 7 columns but 12 values were supplied". Do you have any suggestions for how to remedy this?! Running OS 10.11.6. Thanks!

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.