I hadn't considered the memory pressure graph, that's a good tip. I usually just watch the main memory tab and get confused when the numbers don't seem that high but the app still quits.
> limit the number of concurrent export threads
I don't see a setting like that in my version of the app. Is that something you usually find in a preferences pane labeled "performance" or "advanced"? Or would it be buried in a config file? I'm not super technical on that front.
Right, it's often not in an obvious menu. For this kind of app, those settings are sometimes only exposed as command-line flags or environment variables. If you're up for a small terminal adventure, you could try launching it from the command line with something like `--max-threads 2` to see if it accepts it.
Otherwise, try looking for a hidden `.config` folder in your home directory or inside the app's own Application Support folder. The naming can be cryptic, but sometimes there's a `preferences.json` or similar.
Pipeline Pilot
> Has anyone here successfully used that quantified data to get a timeline from Runway's support team?
I've tried a similar approach with a different vendor, logging the hours spent on workarounds and stability scripts. It got me a faster response, but not a faster fix. They acknowledged the impact but said the underlying issue was "scheduled for a future release."
The real value wasn't in getting a timeline, it was in having the data to justify an immediate, temporary budget increase for a different solution. When I could say "This is costing us X hours per week," it unlocked approval to bring up a parallel service with a different tool while we waited.
Latency is the enemy, but consistency is the goal.
That's an interesting approach with the sandboxed user profile. It could isolate the corruption, as you said, but you'd still have to manage the state transfer for any user-specific settings or API keys between sessions. That might just move the cleanup problem instead of solving it.
I've seen similar workarounds for other apps where we'd script a fresh macOS 'guest' user for a specific task, but the overhead of copying the necessary credentials and config files back and forth ended up being just as much maintenance as the cache cleanup.
The core issue, as user638 points out, is that it lets the vendor off the hook by making the instability part of our standard operating procedure. If we're going to that length, we might as well build the case that the app is unfit for scheduled, unattended work.
The right tool saves a thousand meetings.
Yeah, that's a good point about moving the problem around. If you're scripting a user profile swap and credential transfer, you're basically rebuilding the app's session management for them.
Makes me think, could you containerize it? Like, use something like Docker on macOS to package the app with its config? Then you just blow away the container. I'm new to this side of ops, is that too heavy for a desktop app?
Still learning
Hey user67, welcome to the joys of Apple Silicon transitions 😅. Your setup sounds a lot like mine. That high idle CPU is almost certainly Rosetta 2 overhead if the app is still Intel. Have you confirmed it's actually running native? You can check with Activity Monitor's "Kind" column.
For the random crashes during exports, that could be memory pressure from your Docker stack (Postgres/Redis) and the video processing fighting over the Neural Engine/GPU. Try running a memory-intensive export with those containers stopped, just as a test. It's annoying, but it might isolate the culprit.
Sometimes these apps also leave corrupt state in ~/Library/Application Support. When you reinstalled, did you nuke that folder too? A full purge is the only thing that's helped me with similar launch failures.
ship it
> Try running a memory-intensive export with those containers stopped
That's a good isolation step. If you do find it's the containers, you can try setting explicit memory limits in your Docker Compose file instead of stopping them entirely. Something like:
```yaml
services:
postgres:
deploy:
resources:
limits:
memory: 512M
```
It's a bit of a band-aid, but it can keep your stack running while preventing it from starving the host during a big export.
On the corrupt state point, I've been burned by that too. Just a heads up, some apps keep licensing or API key material in those Application Support folders. I usually move the folder to a backup location instead of deleting it outright, just in case.
Latency is the enemy, but consistency is the goal.
Yep, that pressure graph is the truth-teller. The Activity Monitor numbers are just a polite suggestion, but the graph shows when the kernel starts getting stabby.
> Rosetta overhead just makes it worse
It absolutely does. I've run some unscientific tests during quiet night shifts. An x86_64 app under Rosetta can add 20-30% more memory pressure for the same task compared to its native version. It's not just the extra memory, it's the translation work fighting for CPU time with the actual workload.
Makes you wonder if any of these app devs are actually testing on base-model Macs with 8GB of RAM. Feels like they're all developing on maxed-out Studio rigs.
NightOps
> Rosetta overhead just makes it worse
You're spot on. That overhead is killer, especially when you're pushing the memory envelope. It's one reason I always check if there's a native build before installing anything heavy now.
Your comment about base-model testing hits home. I sometimes wonder if they're only validating on the M1 Max with 64GB. The pressure graph goes from "fine" to "stabby" so much faster on an 8GB Air.
Infrastructure as code is the only way
Totally. That overhead is one of those hidden costs that only shows up under real load, which devs on beefy machines might never hit.
I've started running everything through `file` on the binary to check the architecture before I even download. It's become a reflex. The crazy thing is when an app's installer package bundles both versions but the launch script picks the wrong one.
And your base-model comment - I swear some devs treat memory pressure as a hypothetical. I'd love to see a dev stream where they have to dogfood their app on an 8GB MacBook for a week while running Slack and a browser. That pressure graph would tell a different story.
Pipeline is king.
> splitting my batch jobs into much smaller chunks
That's the exact approach I took. My sweet spot ended up being around 30-45 minutes of processing per batch on my M1. Any longer and the memory pressure graph would start climbing towards the yellow zone, and that's usually when the app would just... let go.
But the worst part isn't finding the stable chunk size. It's that the app's memory usage seems to drift upward over time, even during a single job. So a batch size that worked yesterday might fail halfway through today, which makes scripting a nightmare.
~Harry
Yeah, welcome to the "pro" app experience. These electron-adjacent tools are always a mess on the first few silicon transitions.
Your setup is fine. It's the app. The reinstall dance after a reboot is the classic sign of garbage state management. They're probably writing something broken to ~/Library/Application Support and not handling the read on startup.
> ensuring no other heavy Docker containers are hogging resources
You shouldn't have to do that. It's a desktop app. If it can't coexist with a standard dev stack, it's broken. Setting memory limits is just putting a band-aid on their memory leak.
I've seen this script before. Wait for a few point releases or give up and use the CLI if they have one. More stable, and you can actually monitor it.
If it ain't broke, don't 'upgrade' it.
Oh man, that reinstall-after-reboot cycle is the worst. It screams of a corrupted preferences file or a bad cache. Since you've already reinstalled the app, try this: before you restart, manually quit the app. I've seen apps like this that don't shut down cleanly on logout/reboot, and they corrupt their own state on the way out.
On the Rosetta front, it's definitely worth checking if you're actually running the ARM64 version. The idle CPU spike you're describing is classic for an Intel binary running under translation, especially if it's doing any background polling.
Docs save time
You're absolutely right about always checking for a native build first. I do the same thing now, but sometimes the app's download page isn't clear about architecture. I've had to dig into release notes to find out.
On that note about base-model testing, I completely agree. It's like they optimize for the ideal scenario. Has anyone seen a genuine comparison of how this kind of desktop app performs on an 8GB Air versus a 16GB Pro? I'd be curious to see if the pressure graph difference is as dramatic as it feels, or if the performance cliffs are more about specific tasks.
Oh, finding a genuine comparison is tough. Most reviews either test on a maxed-out MBP or just benchmark raw CPU tasks, which misses the point entirely.
The performance cliffs feel very task-specific in my experience. My main machine is a 16GB Pro, but I have an 8GB Air as a travel machine. The pressure graph is wild. For something like a dev tool compiling code, they're often neck-and-neck until the memory fills up, then the Air's graph just spikes into the red and everything stalls. But for a chatty Electron app? The Air's pressure graph starts climbing the second you open it and just... never comes back down.
You'd think app developers would have a lab with a row of base-model Macs for exactly this reason, but I guess it's not as fun as testing on the fancy hardware.