Anyone else having issues with the desktop app on macOS Sonoma?

I'm on the same hardware and OS, and I've been running similar batch workloads. What I found is that the high idle CPU is likely from the Rosetta translation layer; the app isn't natively compiled for Apple Silicon yet. You can confirm this by checking Activity Monitor and looking for "(Intel)" next to the process name.

For the crashes during long exports, I had to dig into the console logs. The crashes for me were often tied to memory pressure spikes, not CPU. Even with Docker containers idle, the shared memory space can get contentious. I started running exports in smaller batches, which isn't ideal but got the job done.

Have you checked if there's a specific pattern to the launch failures? For me, it was consistently after a system update until I cleared the `~/Library/Caches` and `~/Library/Application Support` folders for Runway, not just a reinstall. Might be worth a shot before your next reboot.

The Rosetta hypothesis is compelling for the idle CPU issue, but I'm skeptical it's the root of the launch failures. A pure translation layer issue wouldn't typically cause a persistent failure to launch post-reboot; that points more to a corrupted local state or a permissions conflict that survives a simple reinstall.

For a dev environment like yours, the Docker angle is critical but not for resource contention. It's about virtual network interfaces and sandboxing. The app might be failing to bind to a required local port if Docker's default bridge network is occupying it. I'd check `lsof -iTCP -sTCP:LISTEN -n -P` right after a failed launch attempt.

Your batch processing workflow raises a vendor risk question. If this instability is systemic on Sonoma, you're essentially running production pipelines on beta-grade software. Have you calculated the cost of these crashes and workarounds against the license fee? Sometimes the business case for pushing the vendor for a native ARM build or a support ticket is clearer when you frame the instability as a direct operational expense.

The port conflict angle is spot on. I've seen similar issues with Docker for Desktop's default network range clashing with local services expecting a specific loopback port. That `lsof` command is the right move.

But I think the operational expense argument is the real takeaway. If you're running batch jobs that fail randomly, you're not just dealing with app crashes, you're burning engineering hours on workarounds and monitoring. That's pure overhead. Quantify the time lost to restarts and troubleshooting, then take that number to their support team. It often gets a native build prioritized faster than any bug report.

Have you looked at isolating the app's network stack? Using something like `socat` to forward a non-conflicting port might be a temporary fix while you pressure the vendor.

I'm on the same M1/Sonoma setup, and the high idle CPU thing lines up with what I'm seeing. It's definitely running under Rosetta in my Activity Monitor.

The random crashes during long exports are the real killer for automation though. I've started splitting my batch jobs into much smaller chunks, which adds a lot of complexity to the pipeline. Have you found a sweet spot for batch size that stays stable?

> fails to launch after a reboot
This one got me too. Clearing the app-specific folders in ~/Library/Caches and ~/Library/Application Support finally got it to launch consistently for me, at least for a while. Might be worth a shot if you haven't already.

Splitting batches to avoid crashes is just treating a symptom. You're adding pipeline complexity to work around a vendor's stability problem.

Your cleanup suggestion is valid, but it's a manual fix for an automated workflow. If you have to clear caches after every reboot, that's another point of failure for automation.

I think you're right that workarounds can become technical debt if we rely on them too long. But in a production environment, sometimes you need a stable patch while waiting for the vendor fix, even if it adds some complexity. The key is tracking that cost, like user180 suggested, so you can make a strong case for a permanent solution.

Has anyone here successfully used that quantified data to get a timeline from Runway's support team? I'm curious if they're responsive to that kind of operational impact argument.

Great troubleshooting steps so far. The Rosetta angle seems the most likely culprit for the high idle CPU, but the launch failures are more concerning for an automated workflow.

Since you're already monitoring Docker for resource contention, the next step might be to check if there's a persistent daemon or agent that's failing. Sometimes the main app installs a helper that doesn't get cleaned on reinstall.

Have you checked `~/Library/LaunchAgents` or `~/Library/LaunchDaemons` for anything Runway-related? A corrupted plist there could explain the post-reboot failure pattern.

That's a solid technical lead to follow. Checking LaunchAgents and LaunchDaemons is a good diagnostic step, as leftover components can absolutely cause the failure-to-launch pattern described.

A caveat on manually removing plist files: it can sometimes break the app's licensing or activation if those components manage that handshake. It might be safer to first try renaming or moving the suspect files rather than deleting them outright, then testing a launch. That way you can revert if it causes a different issue.

Has anyone found a specific Runway agent name to look for in those directories?

That's a great point about checking the Activity Monitor for the "(Intel)" tag. I've been so focused on the memory spikes in my logs that I didn't think to verify the Rosetta angle directly. It's good to have that confirmed.

Your method for the launch failures - clearing the specific app folders in Library - worked for me too, but only temporarily. It feels like a band-aid, and I've noticed I have to do it again after a few days of the app sitting idle. Have you seen the same pattern, or did it stick for you after one cleanup?

The pattern you're describing, where the cleanup only provides temporary relief, strongly suggests the app is generating corrupted state during normal operation, not that it's simply reading from a bad initial cache. It's less of a band-aid and more of a periodic reset, which is worse for automation.

A useful diagnostic would be to monitor the size and modification timestamps of the cleaned directories between launches. If you see them balloon immediately after a successful session, the fault is in the app's runtime state management, not a one-time install artifact. You could script something like:
```bash
find ~/Library/Caches/com.runway.ml -type f -exec ls -la {} ;
```
after each use to track what's being written.

In my experience, this points to a memory or file handle leak within the Rosetta-translated process that eventually corrupts its own workspace. The only semi-stable workaround might be to schedule a forced restart of the app - and the cleanup - as part of your batch job cycle, treating it as a consumable resource.

That's a really sharp observation about the state corruption happening during runtime, not from a static bad install. The `find` command suggestion is solid for tracking it.

But scheduling forced restarts as part of the cycle, while pragmatic, essentially formalizes the instability into the process. You're right that it treats the app as a consumable, but that also makes the operational cost completely predictable for the vendor - they might see it as a stable, if inefficient, workflow.

Has anyone tried running the app under a fresh, sandboxed user profile on a schedule instead of cleaning directories? It's more overhead, but it could isolate the corruption.

> scheduling forced restarts as part of the cycle... essentially formalizes the instability into the process

Exactly. It's letting them set the terms. You're quantifying the workaround and baking it in, which makes the instability a documented feature of your workflow, not a bug in theirs. I've seen this lead to vendor arguments that "it works" because a customer built a process around the crashes.

If you're going to the trouble of scripting cleanup and monitoring directory growth, you might as well script a call to their support line and invoice them for the dev hours. That's the only diagnostic data they'll actually respond to.

That Rosetta angle is a solid suspicion, especially for the high idle CPU. If the app is still Intel, it's running through a translation layer on your M1, which absolutely burns cycles even when "idle" - Rosetta's JIT compiler is working overtime.

For the random crashes during exports, I've seen similar patterns with other media tools when they hit memory pressure from the GPU or neural engine on Apple Silicon. Even though Docker's contained, video processing and Postgres can both spike memory in ways that trigger macOS's memory killer, leading to that generic crash dialog. It might be worth running a memory pressure graph in Activity Monitor during an export to see if it correlates.

The memory pressure graph is a good call. I've seen the macOS kernel kill processes even when the Activity Monitor memory tab doesn't look terrible - the pressure graph is the real indicator. It can spike quickly from GPU/Neural Engine activity, which video exports definitely trigger.

If you're seeing crashes during exports specifically, it's likely the app hitting a hard memory limit and getting `SIGKILL` from the OS. Rosetta overhead just makes it worse, adding its own memory footprint on top of the actual workload. You could try limiting the number of concurrent export threads in the app's settings, if it has any. Sometimes that reduces the peak load enough to stay under the kill threshold.