Repository navigation
App crashes on startup on macOS 26 Tahoe - panic in did_finish_launching #1171
Description
Describe the bug
TAO applications crash immediately on startup when running on macOS 26 (Tahoe). The crash occurs in AppState::launched() during app delegate initialisation, before any application code executes.
Thread 0 Crashed:
tao::platform_impl::platform::app_delegate::did_finish_launching + 296
Steps to reproduce
- Create minimal TAO application:
use tao::event_loop::EventLoop;
use tao::window::WindowBuilder;
fn main() {
let event_loop = EventLoop::new();
let _window = WindowBuilder::new().build(&event_loop).unwrap();
event_loop.run(|_, _, _| {});
}- Build and run on macOS 26.1 (Tahoe)
- App crashes immediately with
SIGABRT/panic_cannot_unwind
Expected behavior
Application launches normally (as it does on macOS 15 Sequoia and earlier).
Screenshots
N/A - crash occurs before any window appears.
Platform and Versions (please complete the following information):
- OS: macOS 26.1 (Tahoe) on Mac15,6 (M3 Pro, Apple Silicon)
- Rustc: stable (latest)
- TAO: v0.34.5
Additional context
- Builds successfully; only runtime is affected
- Works on macOS 15 (Sequoia) and earlier
- Suspected cause: macOS 26 changed window/app lifecycle APIs (
NSApplicationActivationPolicyorMainThreadMarkerhandling)
Activity
FabianLars commentedon Jan 12, 2026
do you have a more complete crashlog/stacktrace perhaps? Doesn't happen on my end.
traklo commentedon Jan 13, 2026
Just tried on another machine with 26.2. The panic location: tao-0.34.5/src/platform_impl/macos/app_delegate.rs:126 - it's happening in MainThreadMarker::new().unwrap() context
Here's the full stack trace, hope it helps:
Thank you for looking into this.
traklo commentedon Jan 21, 2026
@FabianLars did you manage to reproduce it? Could you imagine any workarounds I can try?
traklo commentedon Jan 26, 2026
I’ve looked into the crash more and might have identified the root cause. The fix is seems available in winit, so perhaps we could apply the same change to TAO?
It looks like macOS 26 (Tahoe) changed several Objective‑C method return types from signed (
'q'= Int64) to unsigned ('Q'= UInt64).The
objc2crate validates these signatures strictly and panics when the runtime returns an unexpected encoding.The upstream winit solved this in v0.30.12 by enabling the
relax‑sign‑encodingfeature inobjc2You can also find more context in the objc2 feature description.
Could it be enough to modify TAO's Cargo.toml to what's in winit? I'll have access to a Mac machine later this week and will try.
greenhat616 commentedon Jan 28, 2026
@traklo We're facing this issue on a couple of machines too.
Have build the program with
releaseprofile? - If it built with--release, the sign encoding assertion would be stripped, and no runtime panic should happens hereIf not this case, maybe we can fork
taoand add std::panic::catch_unwind manually to capture the original panic message. Then, using[patch.crates-io]inCargo.tomlto use the fork to test.Forgive I cannot reproduce this issue on my dev machine.
fix: macOS 26 Tahoe crash — enable objc2 relax-sign-encoding + enhanc…
ahan-bd commentedon Feb 16, 2026
Any updates here ?
fix: resolve macOS 26 Tahoe startup crashes and UI layout issues
chore(release): 1.3.1 [skip ci]
axpnet commentedon Mar 9, 2026
We are experiencing a related but distinct issue on macOS 26.2/26.3 with tao 0.34.5: the main thread deadlocks (rather than panicking) inside
is_zoomed()->set_style_mask_sync()->NSPerformVisuallyAtomicChange. The recursive layout passes inNSPerformVisuallyAtomicChangeblock the main thread permanently.Full call stack and analysis in #1193.
mardelden commentedon Mar 10, 2026
It is interesting that same app launches successfully when starting it from the terminal
/Applications/<app_name>.app/Contents/MacOS/<app_name>So for now I just created an alias
<app_name>() { /Applications/<app_name>.app/Contents/MacOS/<app_name> &>/dev/null & disown; }fix(macos): fix macOS 26 (Tahoe) crash on startup
fix(macos): use extern C-unwind for did_finish_launching
pelby commentedon Apr 19, 2026
Hit this on a production Tauri app after ~7h uptime spanning sleep/wake. Distinct from the
did_finish_launchingangle already discussed — the panic originates in the appearance-change observer, not launch.Environment
tao0.34.6 ·tauri2.10.3 ·wry0.54.4 ·tauri-runtime-wry2.10.1Thread 0 (main), bottom→top:
Trigger:
AppleInterfaceThemeChangedNotificationdelivered viaNSDistributedNotificationCenter. A panic insideeffective_appearance_did_changecannot unwind across the Objective-C FFI boundary, so the runtime aborts the process. The app itself never touches appearance APIs; the observer is installed unconditionally by tao's window delegate.Reproducibility: observed once, after wake spanning an auto light/dark switch. The hook is exposed any time the OS posts this notification — after wake, auto light/dark transition, or manual appearance toggle.
Why this matters for #1171: the existing report centres on a panic reachable from
did_finish_launching. This one surfaces during normal runtime. A fix that catches the unwind at the FFI boundary (e.g., wrappingextern "C"delegate callbacks incatch_unwind) would cover both paths as a defence-in-depth layer.Happy to provide a sanitised full crash report if useful.
fix(macos): patch tao 0.34.8 for macOS 26 startup crash (tao#1171)
JaeAeich commentedon May 9, 2026
Different trigger, same crash site. In my case the panic was caused by a corrupted .icns file (a pre-commit linter treated it as UTF-8 and replaced invalid bytes with U+FFFD). The corrupted icon gets embedded by
tauri::generate_context!()and handed to macOS duringdid_finish_launching. On Tahoe + tao 0.35.2, this panics inside the extern "C" callback → "panic in a function that cannot unwind."Regenerating a valid
.icnswithiconutilfixed it. Adding*.icnsbinary to.gitattributesprevents recurrence.This suggests the did_finish_launching codepath on Tahoe is fragile around icon parsing, worth checking whether the pure-Tahoe variant of this issue is also icon-related.
fix(macos): generate valid app icons — fixes launch crash on macOS 26…
codelogiq commentedon Jun 14, 2026
Adding a concrete data point that corroborates @JaeAeich's icon theory above — in our case it was a zero-size
.icns, and I was able to pin down the exact exception.Root cause for our crash: the scaffolded
src-tauri/icons/icon.icnswas an 8-byte placeholder stub (size{0, 0}). On macOS 26, AppKit throws an Objective-C exception when it tries to render that zero-size image for the Dock/app icon during launch:That throw unwinds through tao's
did_finish_launchingextern"C"callback →panic_cannot_unwind→abort(). The giveaway is that there's no Rust panic message — it's a foreign ObjC exception, not a Rust panic, so chasing theMainThreadMarker::new().unwrap()line is a red herring.How to confirm it's your case (catch the real reason under lldb):
If the printed reason mentions
lockFocus/size zero, it's the icon.Fix: regenerate real icons —
cargo tauri icon <1024x1024 source.png>(oriconutilas @JaeAeich noted). Verify withfile src-tauri/icons/icon.icns(should be hundreds of KB with anic08entry, not an 8-byte stub). Note icons aren't tracked as Cargo build inputs, so force a re-embed:cargo clean -p <crate>ortouch src-tauri/tauri.conf.jsonbefore rebuilding.This also explains @mardelden's observation that launching the binary directly from the terminal works while Finder/LaunchServices doesn't — the Dock icon is only rendered on the bundled LaunchServices launch path.
One dead end to save others the trouble: I briefly suspected
pthread_main_np()returning a transient-1on macOS 26 (objc2 PR madsmtm/objc2#841). That's not it — I reproduced on 26.5.1 andpthread_main_np()returns1at every launch checkpoint, and the current libpthread implementation can only ever return0or1. So thedid_finish_launchingpanics here aren't a main-thread-detection problem; they're foreign ObjC exceptions unwinding through the callback (icons being one common trigger).v0.15.54: Plaid live data loads, macOS 26 crash fix, books polish, li…
#6317: vendor a patched tao 0.35.3 — torn-down window no longer panic…