Share via

MAUI: An unhandled exception of type 'ObjCRuntime.ObjCException' occurred in Microsoft.iOS.dll

Sreenivasan, Sreejith 740 Reputation points
2026-03-16T11:30:11.42+00:00

I am facing below issue when running the MAUI iOS app to simulator:

Exception has occurred: CLR/ObjCRuntime.ObjCException

  •   An unhandled exception of type 'ObjCRuntime.ObjCException' occurred in Microsoft.iOS.dll    at UIKit.UIApplication.xamarin_UIApplicationMain(Int32 , IntPtr , IntPtr , IntPtr , IntPtr* )   at UIKit.UIApplication.UIApplicationMain(Int32 , String[] , IntPtr , IntPtr )   at UIKit.UIApplication.Main(String[] , Type , Type )   at Inventiva.Program.Main(String[] args) in /Users/sreejith.sreenivasan/Downloads/inv-hnas337-mobile-patient/Inventiva/Platforms/iOS/Program.cs:line 13

Screenshot:
Screenshot 2026-03-16 at 4.19.19 PM

I am not getting the exact issue behind this. I didn't see any error on the output window. How can I find what is the real issue behind this?

Update 17032026

I tried capturing the console logs and tried debugging it. I found an issue with the GoogleService-Info.plist and replaced it with the exact one having the same bundle id of the app. Also updated the .csproj with the GoogleService-Info.plist BundleResource reference. But the issue persists. I tried searching the console log with some keywords but nothing found. So I am adding it below as a text file.

Logs.txt

Please suggest a solution for this issue.

Developer technologies | .NET | .NET MAUI
0 comments
Answer accepted by question author
  1. Adiba Khan 2,345 Reputation points Microsoft External Staff
    2026-03-18T06:43:45.4433333+00:00

    Thanks for reaching out. The exception ObjCRuntime.ObjCException in a .NET MAUI iOS app is a wrapper exception. It typically indicates that an underlying native iOS ( Objective-C) error is being thrown, but not surfaced clearly in managed logs. The stack trace you are seeing (UIApplication.Main) is only the entry point and does not reveal the root cause.

    Root Cause Possibilities

    Since you already:

    • Verified GoogleService-Info.plist
    • Added it to .csproj as BundleResource

    The issue is most likely one of the following:

    1. Incorrect Firebase/plist Integration Even if the file exists, iOS will crash silently if:
      1. Bundle ID in Apple project is not equal to Bundle ID in plist
      2. plist is not included in the final app bundle Verify: 
              <ItemGroup>
      	<BundleResource Include="Platforms\iOS\GoogleService-Info.plist"/>
      </ItemGroup>
        Also confirm:
        1. File Build Action = BundleResource
        2. File is physically present under Platforms/iOS
    2. Missing Required iOS permissions (very common) If your app uses Firebase (especially Messaging/ Analytics), iOS may crash at startup dur to missing permissions. Check your Info.plist for required keys like: 
         <key>NSAppTransportSecurity</key>
   <dict>
   	<key>NSAllowsArbitraryLoads</key>
   	<true/>
   </dict>
   
   <key>NSCameraUsageDescription</key>
   <string> This app requires camera access</string>
   
   <key>NSLocationWhenInUseUsageDescription</key>
   <string>This app requires location access</string>
      Missing permission keys can directly trigger ObjException.
    3. AppDelegate/Firebase Initialization Issue If you are using Firebase, ensure initialization is correct in AppDelegate.cs: 
         Firebase.Core.App.Configure();
      And ensure it is called before using any firebase services.
    4. Unhandled native exception- need full logs The actual error is hidden. You must capture device logs, not just Visual Studio output. Steps to get real error:
      1. Run app on iOS Simulator
      2. Open:
        1. Visual Studio -> View -> Pads -> Application Output
      3. Or use Mac Console: 
              Console.app -> Select Simulator -> Filter by your app
        Look for:
        1. Terminating app due to uncaught exception
        2. reason: (this contains the real issue)
    5. Linking/ AOT issues (MAUI iOS) Sometimes linker removes required assemblies. Try: 
         <MtouchLink>None</MtouchLink>
      Or from settings:
      1. iOS build -> Linker Behavior -> Don't link
    6. Clean/ Rebuild (Important) Corrupted builds can cause this exact issue. Run: 
         dotnet clean
   dotnet build
      Or is visual studio:
      1. Delete bin and obj
      2. Restart IDE
      3. Rebuild solution

    Recommended Action Plan

    1. Verify plist inclusion + bundle ID
    2. Check info.plist permissions
    3. Ensure Firebase initialization is correct
    4. Disable linker temporarily
    5. Capture full iOS native logs (critical step)

    if the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment"

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-03-16T11:30:37.87+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    ObjCRuntime.ObjCException indicates that an Objective-C exception was thrown somewhere in native iOS code and then surfaced into .NET. The stack trace stopping at UIApplication.Main means the real cause is deeper in native code and not visible in the managed call stack.

    To understand the real issue, inspect the original Objective-C exception and how it is marshaled:

    1. Enable full logs in the iOS app run:
      • Run the app without the debugger attached (or attach after launch) so that unhandled exceptions are logged by the runtime instead of being intercepted by the debugger.
      • Check the device/simulator logs (Xcode’s Devices and Simulators window or the IDE’s application output) for an NSException message such as NSInvalidArgumentException, including its reason and any stack trace.
    2. Understand how Objective-C and .NET exceptions interact:
      • When a native API throws an Objective-C exception and the stack unwinder reaches managed frames, the runtime converts that Objective-C exception into a managed exception at the managed–native boundary. This is what produces ObjCRuntime.ObjCException.
      • The original Objective-C exception text (for example, *** setObjectForKey: key cannot be nil) appears only in the native logs, not in the short managed stack trace.
    3. Use exception marshaling behavior to debug:
      • The .NET iOS runtime intercepts calls crossing the managed/native boundary and wraps them in a @try/@catch in Objective-C, converting any NSException into a managed exception. This ensures the app does not silently skip catch/finally blocks but also means the debugger often shows only ObjCException at the boundary.
      • To see more detail, reproduce the crash with native logging enabled and inspect the first NSException thrown; that message and its native stack trace will point to the actual API misuse (for example, passing null where not allowed, invalid selector, bad UI operation on background thread, etc.).
    4. Once the native exception is identified, fix the underlying cause in the MAUI code (for example, avoid passing null to UIKit/Foundation APIs, ensure UI work happens on the main thread, validate arguments before calling platform APIs).

    If the crash persists without clear logs, create a minimal reproduction and compare behavior, focusing on the last managed call that invokes any iOS native API before UIApplication.Main.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.