.NET iOS: App sporadically crashes after NFC read when returning a large struct (Data). Changing it to a class fixes it — why?

[alyimran]

Platform / Build

• .NET 9 (net9.0-ios) – Xamarin/.NET for iOS
• iOS 17 (device)
• AOT + UseInterpreter=true
• TrimMode=partial in Release
• App uses CoreNFC (ISO7816) to read a meter, then decodes frames into a big Data type

Symptom

• After an NFC scan, we build up a large Data value type (lots of nested structs/fields).
• Returning that Data from the decode/read path sometimes crashes the app right after the last Console.WriteLine (no managed exception is seen).
• If I instead return new Data() (i.e., don’t return the fully-populated struct), the app never crashes.
• If I change Data from a struct to a class, the crash disappears completely and everything works.
  So the only change that consistently fixes it is turning the large return type from struct → class.

Relevant code (simplified)

// Large result type (originally a struct; switching to class makes crash go away)
public /*struct*/ class Data
{
    public Cap Cap;
    public Types Type;
    public General General;
    public Main Main;
    // ... many nested value types & arrays ...
}

// Decode on iOS
public override Data Read(Modes mode)
{
    var frame = GetFrames();
    Console.WriteLine("[trace] getframes completed.");

    var result = Decode(frame); // ← builds a big Data value

    Console.WriteLine("[trace] decode completed.");

    // If I do this (return the real struct), I get sporadic native crashes:
    // return result;

    // If I do this (dummy), it never crashes:
    return new Data();
}

// The hot function (simplified): fills `Result` then returns it
public virtual Data Decode(MBus.Frame frame)
{
    Result.Cap = Cap;
    // ... many assignments into nested fields ...
    Console.WriteLine("[trace] Returning Result data");
    return Result; // ← returning a big struct
}

If I change Data to a class and update code accordingly, crashes stop.

Minimal native crash excerpt (from .ips)
No managed stack/exception shows. It’s a native abort:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Crashed Thread:  7

Thread 7 Crashed:
0   UltraConnect.iOS          mono_sigsegv_signal_handler_debug
1   UltraConnect.iOS          mono_handle_native_crash
2   UltraConnect.iOS          mono_dump_native_crash_info
3   libsystem_platform.dylib  _sigtramp

So: native SIGSEGV right after we finish building/returning the large struct; no managed exception surfaces.

What we tried

• Verified it’s not UI-thread misuse: crash occurs after decoding completes, on return.
• Added granular logging inside Decode — last log prints; crash happens during/after return path.
• If we read but don’t assign (connectedMeter.Read(Modes.More);) it doesn’t crash. Assigning the returned struct to a variable or passing it onward does (sporadically).
• Switching Data from struct → class eliminates the crash entirely (Android and WPF were always fine).

Question
Why would returning a very large, deeply nested struct from AOT’d .NET iOS code cause sporadic native SIGABRT (no managed exception), while the exact same logic works on Android/WPF — and switching that type to a class fixes it on iOS?

• Is this a known JIT/AOT / marshalling / stack frame issue with large value types on .NET for iOS?
• Are there size/complexity thresholds for value types that can trigger ABI issues during return/copy?
• Any guidance from the runtime/ABI perspective on iOS about returning large structs (copy elision, stack vs. hidden return buffer, interpreter interaction, trimming, etc.)?

Any pointers to best practices (e.g., prefer classes for large DTOs on iOS, use ref struct/in/out patterns, or known fixes/workarounds) would be hugely appreciated.

[hez2010]

From the symptom it can be caused by stack overflow.