macos crash on catalina with missing swiftui symbol

[jaredh159]

Hi there, thanks so much for TCA, really appreciate all your work.

I've got a macos app that was already in production with a prerelease of 1.0, and now has been converted to 1.0.0. in a recent release, I've been trying to add support for an older OS, namely Catalina 10.15 (I already support everything from Big Sur and later).

In testing the new Catalina compat, I'm running into a strange crash on launch that seems to be related to TCA, and I'm struggling to make heads or tails of it. The crash is due to a missing SwiftUI symbol. Here's the only interesting part of the crash report:

Symbol not found: _$s7SwiftUI4ViewPAAE15fullScreenCover4item9onDismiss7contentQrAA7BindingVyqd__SgG_yycSgqd_0_qd__cts12IdentifiableRd__AaBRd_0_r0_lFQOMQ

running swift demangle on that symbol produces:

opaque type descriptor for <<opaque return type of (extension in SwiftUI):SwiftUI.View.fullScreenCover<A, B where A1: Swift.Identifiable, B1: SwiftUI.View>(item: SwiftUI.Binding<A1?>, onDismiss: (() -> ())?, content: (A1) -> B1) -> some>>

Why do I think it's related to TCA? Because my app uses zero SwiftUI, so the only swiftui code that should be referenced (I think) should be coming from TCA.

The strange thing is, searching pointfree repos for fullScreenCover turns up some stuff, but the relevant lines seem to be correctly annotated with @available(macOS, unavailable).

It's also add, that I'm not getting the crash on anything macos 11.0 or later, all of which don't support fullScreenCover either (I think).

Admittedly, I'm not a veteran macos or ios developer, so maybe I'm missing something stupid here? Can anyone help me understand what's happening here?

Does anyone have a TCA app building and running successfully on Catalina? Is that something you have a sample app for that could be tested for the crash?

Thanks for any help!

expand for more of the crash report...

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x4] Symbol missing

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Symbol not found: _$s7SwiftUI4ViewPAAE15fullScreenCover4item9onDismiss7contentQrAA7BindingVyqd__SgG_yycSgqd_0_qd__cts12IdentifiableRd__AaBRd_0_r0_lFQOMQ
  Referenced from: /Applications/MyApp.app/Contents/MacOS/MyApp
  Expected in: /System/Library/Frameworks/SwiftUI.framework/Versions/A/SwiftUI
 in /Applications/MyApp.app/Contents/MacOS/MyApp

[mbrandonw]

The demangled symbol you shared does not match the symbol you linked to in TCA. The TCA fullscreenCover has 3 generics and deals with Stores, whereas your demangled symbol is much simpler. In fact, I'm pretty sure it is just the plain, vanilla SwiftUI fullscreenCover.

What was the previous version of TCA your project was building without crashing?

[jaredh159]

I haven't run his project yet, but I'm going to try. I don't have my own Catalina computer, I've been borrowing my nieces off and on and don't have it at the moment. But I'm trying to setup a dual-boot to Catalina right now, or borrow her computer again today. ...sigh, the world of macos development. i'll try to report back what i find repro-ing his test case.

[jaredh159]

ok, i have my hands on a laptop with Catalina now, and have some more info:

1. the test project from the other thread does immediately crash with the same error on Catalina
2. i realized i had a few import SwiftUI statements in my codebase, but they were all just to get symbols that I could also get from AppKit (like NSWindow), so i removed those, built, notarized and tested. ...but sadly, the crash persists.

[mbrandonw]

It seems like the crash should happen with just SwiftUINavigation. No need for TCA at all. I'm wondering if you can slowly remove things from SwiftUINavigation to get a minimal reproduction? Is it just the presence of the fullScreenCover method that is marked as @available(macOS, unavailable) and calls fullScreenCover under the hood?

[jaredh159]

@mbrandonw ok, one final piece of interesting info.

i thought some more about how you said the symbol didn't match the TCA code. you're definitely right, but the TCA code calls out to the vanilla swiftui method that is missing it's symbol here.

like i said, i'm not a macos/ios vet, so instead of bothering you wondering about if that was still somehow the cause, i did an experiment. i forked TCA, commented out that entire file, depended on my fork, rebuilt, re-notarized, and tested.

and the crash is gone!

i have no idea why that would be. like i said, you seem to be correctly annotating it as not available for macos. but there it is. ¯\(ツ)/¯

it honestly feels maybe like more of a xcode bug than something you guys are doing wrong. but, i have a hunch that nothing built with TCA 1.0.0 will launch without a crash on Catalina right now.

i have this Catalina computer for a couple days. is it possibly something easy for you to do to build a sample TCA app for macos with the deployment target set to 10.15, and have it notarized? if you could do that and send me a .zip or .dmg i'd be happy to test it.

[jaredh159]

oh, didn't see your response until i finished my last response. i think you were thinking along the same lines, although i was able to fix it by commenting out just one file in TCA.

[jaredh159]

@mbrandonw ok, so i purchased an old laptop to do Catalina testing (for $70 🤣 ), and I dug into this issue again. here's a couple more bits of into.

As I suspected, it seems that any macOS app importing TCA is crashing on Catalina now. To test this, I made the simplest TCA app I could (the humble counter app, of course!), and verified that I get the same crash on Catalina. The github repo is here.

As a contrast, here's just a hello-world SwiftUI app without TCA, that doesn't crash on catalina.

But, if I add this just this code block to the non-TCA swiftui app:

public extension View {
  @available(iOS 14, tvOS 14, watchOS 7, *)
  @available(macOS, unavailable)
  func testAvailableCrash() -> some View {
    self.fullScreenCover(isPresented: .constant(true)) {
      Text("Unreachable!")
    }
  }
}

...then we're in crash city again. This is basically the minimal code I could figure out to reproduce the fact that for some reason it seems like the @available(macOS, unavailable) annotation is not preventing that codepath from running on Catalina, resulting in the missing symbol crash. That code is basically simulating the one file in TCA that causes the crash.

I'd love to get to the true bottom of this. Do you have any more knowledge about how those @available checks are supposed to work, or if there is some sort of alternate compiler/availability directive that would allow this to still work for the platforms that support it, without breaking Catalina compat?

I'd really hate for you guys to drop Catalina support, I hope you're not considering that! 🤞 (on that note, now that I've got a dedicated Catalina test computer, if we can get this resolved some way in the core library, I'd be happy to do some smoke-testing for you guys whenever you are about to tag a new release, to ensure Catalina is hunky dory -- let me know if that interests you).

[mbrandonw]

And it does prevent the crash on Catalina, but I'm still not sure that's correct. Based on this post it seems like that would be testing the build machine which would always be macOS, since it's evaluated at compile time. at compile time, you'd always be on macOS (unless you're on Linux building a server app or something like that). or am I just majorly misunderstanding that post?

It's not the platform you are building on. Otherwise things like #if os(watchOS) wouldn't make much sense since you are never building on a watch. Instead it refers to the platform you are building for, i.e. the platform you have selected at the top of the Xcode window. We already have a few #if os(…) scattered throughout the library for just this kind of thing.

[jshier]

As far as I can tell, @available(macOS, unavailable) is roughly equivalent to #if !os(macOS), outside of ergonomics.

That's not really true. #if is a compiler directive, so it's a compile-time only construct. #if !os(macOS) means the API won't exist at all when built for a macOS deployment target. @available (in combination with if #available) is a runtime construct. The code is still built and part of the executable but the compiler checks your usage at build time. If this runtime check doesn't work for some reason, you may still see it executed despite @available(macOS, unavailable). You can see this on godbolt.org (using Linux instead of macOS).

@available(Linux, unavailable)
func square(n: Int) -> Int {
    return n * n
}

With this version, the code is still generated, you just can't call it from other function (thought godbolt is letting me, odd). If you instead use #if !os(Linux) you'll see the function isn't built at all. It just doesn't exist.

I don't know the root cause of this bug. If it's a compiler issue, you may be able to get it fixed. But since it only occurs on Catalina it seems likely it's a runtime bug of some kind (or perhaps a compiler bug that only shows up on older runtimes), and that won't be fixed since they aren't updating Catalina anymore, unless the solution is only in the compiler.

[mbrandonw]

I agree with your detailed explanation, but I said roughly equivalent specifically to not go into those details. At the end of the day you cannot call the function and it doesn't even autocomplete in Xcode. So we might as well omit it entirely from the library if it is causing a crash on some platform.

[jaredh159]

ok, thanks, that makes sense, i was just slowly coming to that conclusion from some more googling. the objc version of the same check is #ifdef TARGET_OS_TV which includes the helpful word "target". and i forgot that for a multi-platform app, you're going to be building more than once and emitting different app bundles.

interestingly, i found this (sadly unanswered) post while i was starting to work on a swift form post: https://forums.swift.org/t/available-unavailable-api-unexpected-behavior/38784

whipped up a quick PR, if you'd be up for introducing the os check in this way. tested in my minimal repro, but i'll do one more test pulling in the fork and commit from that PR to double-check. here's the PR: #2385

[jshier]

Sure, it just means every callsite will need to use the same construct, so if you wrap it in #if !os(macOS), anyone with a cross platform build will need to do the same thing (unless they use some other construct to avoid it, like separate platform files).