maui: iOS Release builds stopped working after last update

I’m expremely pressed for time, and I don’t know if I can do this in the timeframe required. Meanwhile, I’m deploying debug builds to the AppStore, while looking into a way to use an older version of Maui in my iOS pipeline.

There’s a number of serious bugs I’ve simply skipped reporting because of this open-repo requirement. It’s too much work I don’t have time for, and it doesn’t really feel like the team takes bug reports seriously anyway.

Maui is not production-ready (unfortunaly for me, given that I’m developing a major project using it).

Actually it seems disabling linker on iOS Release builds does not resolve this issue, making this is a much more serious issue. But positively removing our DataTrigger does prevent the crash, so hopefully a pointer in what to test for a repro and fix.

This has started to affect us in one of our major ongoing Maui projects also after a VS update. Disabling linker will get us away for now, but we can’t go to production until this issue is fixed… Would be good to see some priority given to this.

From looking at line numbers in the exception, assuming it relates to Xaml, I think it is occurring for us in a Data Trigger on a Button Text Property:

<Button Command="{Binding NextCommand}"
      Text="Next">
      <Button.Triggers>
          <DataTrigger
              Binding="{Binding IsSubmitBusy}"
              TargetType="Button"
              Value="True">
              <!-- Exception happening on this line -->
              <Setter Property="Text" Value="" />
          </DataTrigger>
      </Button.Triggers>
  </Button>

Building a repro for this is extremely hard as so far it clearly only manifests with a non trivial app and requires a full loop through the Apple App store to push out a release build and test it.

You should be able to install a release build locally by using the same codesigning identity + provisioning profile you use for debug builds.

There are loads more areas to dig here anyway, for example what gave @rolfbjarne the idea to enable the interpreter in the first place?

Similar-sounding issues with exceptions during release builds (and the knowledge that by default the interpreter is enabled for debug builds in MAUI, but disabled for release builds).

That smells of something known about, what does that interpreter flag do specifically? I’ve read the documentation and get the gist, but still can’t grep the finer details. More info would help guide us non MAUI developers towards helping build a targeted repro.

On iOS, it’s not possible to generate executable machine code at runtime (i.e. JIT compile code), because Apple doesn’t allow it. Thus we use an Ahead-Of-Time compiler, which compiles everything to native code at build time - but this has a few limitations (there’s no support for System.Reflection.Emit for instance). We developed an interpreter to get around these limitations, and incidentally the interpreter is also required for a few debug features (hot reload for instance), and it’s thus enabled by default for debug builds. The downside is that it’s fairly easy to end up with a dependency on the runtime features of the interpreter - because it just works during debug.

Why aren’t we enabling the interpreter for all build configurations? Because there may be performance concerns in some cases, but we’re investigating this and may end up doing exactly that (enabling the interpreter for all build configurations).

and be more assured as to the quality of the final binaries?

The best way to do this is to create a Release build, but with the codesigning identity + provisioning profile you use for a debug build, and install and test it on a device. You won’t be able to attach a debugger, but you’ll be able to verify that a release build works as expected.