Exception has occurred: CLR/ObjCRuntime.ObjCException

ObjCRuntime.ObjCException means an Objective‑C exception was thrown by iOS native code and then marshaled into a managed exception at the boundary between .NET and UIKit.

In a .NET for iOS / .NET MAUI app, the managed Program.Main calls UIApplication.Main, which in turn calls the native UIApplicationMain. If any native API (for example, a UIKit or Foundation call) throws an Objective‑C exception during startup, the exception is converted to a managed ObjCException when it crosses back into managed code. That is why the stack trace only shows UIApplicationMain and Program.Main and not the actual failing native call.

Key points from the runtime behavior:

• Managed and Objective‑C exception systems are different. When an Objective‑C exception unwinds through managed frames, the Objective‑C runtime cannot execute managed catch/finally blocks, which leads to undefined behavior such as crashes or leaks.
• To avoid this, .NET for iOS intercepts calls into Objective‑C (for example, objc_msgSend) and wraps them in a @try/@catch block. When an NSException is caught, it is converted to a managed exception and rethrown as ObjCRuntime.ObjCException in managed code.
• On the main thread, UIApplicationMain itself is typically wrapped in an Objective‑C @try/@catch that logs and aborts on unhandled exceptions. When interception is enabled, the runtime converts such Objective‑C exceptions to managed exceptions at the managed/native boundary so they can be observed as ObjCException.

Because of this design, the ObjCException in Program.Main does not originate there; it indicates that some earlier native call (often a UI or platform API used during app startup) threw an NSException. To diagnose the root cause, it is necessary to inspect the native exception details (message such as NSInvalidArgumentException, selector name, etc.) and the native stack frames, which are not shown in the snippet.

If needed, the behavior of this marshaling can be adjusted via the MSBuild properties MarshalManagedExceptionMode and MarshalObjectiveCExceptionMode, which control how managed and Objective‑C exceptions are intercepted and converted at build time. However, changing these modes only affects how exceptions are propagated; it does not fix the underlying native error that caused the ObjCException.

References:

• Exception marshaling

Hi @Sreenivasan, Sreejith ,

Thanks for your question.

The ObjCRuntime.ObjCException you are seeing is a generic wrapper for a native iOS exception. It typically occurs when an issue happens in the underlying UIKit layer before .NET MAUI can surface a detailed managed exception.

The stack trace pointing to UIApplicationMain indicates that the crash is happening during app startup, and the actual root cause is likely logged earlier in the output.

To isolate the issue, I recommend:

1. Reviewing logs prior to the exception
   • Run:

       dotnet build -t:Run -f net8.0-ios
   

   • Watch terminal output
   • Scroll Up
   • Look for: exceptions, xAML errors, resource errors.
2. Temporarily simplifying the MainPage In App.xaml.cs, replace:

       MainPage = new AppShell();
   

   with:

           MainPage = new ContentPage
       {
       Content = new Label
       {
       Text = "Test OK",
       HorizontalOptions = LayoutOptions.Center,
       VerticalOptions = LayoutOptions.Center
       }
       };
   

• In case app runs successfully, problem may be in: XAML, CollectionView, Popup, Custom controls,...
• In case app still crashes, problem may be in: start up code, MauiProgram.cs, dependency injection or app configuration,..

3. Removing third-party components to check if crash is caused by external libraries. If you are using third-party UI libraries, I suggest commenting some external libraries which you are using. If crash disappears -> root cause comes from third-party control. If not, problem is in your own code or MAUI.
4. Adding global exception logging

Ask them to add this in MauiProgram.cs:

AppDomain.CurrentDomain.UnhandledException += (sender, e) =>
{
    System.Diagnostics.Debug.WriteLine("UNHANDLED: " + e.ExceptionObject?.ToString());
};

TaskScheduler.UnobservedTaskException += (sender, e) =>
{
    System.Diagnostics.Debug.WriteLine("TASK ERROR: " + e.Exception?.ToString());
};

And in App.xaml.cs:

public App()
{
    try
    {
        InitializeComponent();
        MainPage = new AppShell();
    }
    catch (Exception ex)
    {
        System.Diagnostics.Debug.WriteLine("APP INIT ERROR: " + ex.ToString());
        throw;
    }
}

These steps should help identify the underlying cause, as the current exception itself does not contain sufficient diagnostic detail.

I hope this addresses your question. If this response was helpful, please consider following the guidance to provide feedback.