Hey folks, Carl here. I've been using NightCafe for a while now, both for personal tinkering and as part of some client demos on creative workflow automation. Generally, I'm a big fan of the platform's capabilities, especially for the price point.
However, I've hit a pretty consistent and frustrating snag over the last few weeks that's starting to feel like a deal-breaker for mobile use. Whenever I try to export a finished image—specifically choosing "Save to Photos" at full resolution—the app hard crashes about 75% of the time. It's not a graceful exit; it just dumps me back to my home screen and the image is nowhere to be found. I've lost a few really great generations because of this.
I'm on a relatively recent iPhone (14 Pro, iOS 17.4.1), so I don't *think* it's a hardware issue. I've done all the standard troubleshooting:
* Force-closed and restarted the app numerous times.
* Reinstalled the app completely (twice).
* Tried exporting on both cellular and strong Wi-Fi connections.
* Ensured I have ample storage space (over 50GB free).
The only semi-reliable workaround I've found is to share it to another app (like Notes) first, and then save from there, but that adds an unnecessary step and sometimes degrades quality.
This feels reminiscent of some data handling bugs I've seen in CRM mobile apps during large file exports—where the app tries to hold too much in memory during the render-and-save process and just gives up. It's the kind of thing that seems minor but absolutely kills user adoption in a professional context.
So I'm curious:
* Is anyone else experiencing this specific crash-on-export issue?
* Have you found a more reliable method or setting that works?
* Does the Android app behave similarly, or is this an iOS-specific pain point?
I'd love to gather some collective data here before I submit yet another support ticket. These implementation bugs are the "battle scars" I talk about with clients—small friction points that can completely derail an otherwise great tool.
Implementation is 80% process, 20% tool.
Ah, that's a real pain, especially when you lose a good generation. I've heard a few similar reports on the community Discord, and it does seem tied to the "Save to Photos" function on recent iOS versions. The workaround you found is what others are using too, unfortunately.
Have you tried checking if it's specific to the full-resolution option? Some folks have had success by exporting at "High" quality instead of "Maximum" first, then saving that to Photos. It's not ideal, but it might be a slightly faster interim step than routing through another app.
It does feel like a bug they need to patch. Have you submitted a ticket through the app's support section? They're usually pretty responsive when a specific, repeatable bug gets flagged by multiple users. The more details they get, the faster they can prioritize a fix.
Trust the data, not the demo.
Seen the same thing on my test device. It's a memory handling bug in their export pipeline, not your hardware.
The workaround you're using is the standard one for now. It's a band-aid, but it works. Definitely file a ticket with your exact steps. They need the crash logs. Without pressure from user reports, these mobile bugs slide down the priority list.
For client demos, I'd stick to the web platform for now. More reliable for critical exports.
Yep, 100% on the memory bug. Spot on about filing a ticket with steps.
It's interesting you mention it's in the export pipeline. That tracks with my own trials, the crash seems to happen when it's assembling the final file, not during the actual save permission. Makes the "share to another app" workaround make more sense.
Good call on the web platform for demos, though. Can't risk a crash during a client presentation. 🥲
Trust the trial period.
Oof, that's a rough one, Carl. Losing those generations is the absolute worst feeling, especially when you've done everything right on your end.
Since you've already gone through the full troubleshooting checklist, I'd really urge you to take the extra minute to submit that ticket. They need the specifics from a recent, stable device like yours. Attach your phone model, iOS version, and mention you've reinstalled. That data is gold for their devs.
It's the kind of bug that can linger in the backlog without those direct reports.
Keep it civil, keep it real.
"Great workflow automation tool, especially for the price point" is doing a lot of heavy lifting there. A client demo tool that loses the output 75% of the time on the final step sounds like a hidden cost multiplier, not a bargain.
You're doing all the user-side troubleshooting, but the actual billable time you and your clients are losing to this workaround is the real metric. The share-to-notes extra step is pure process tax. If this is for client work, have you calculated the extra minutes per export across a project? It adds up.
cost_observer_42
You're right about that "process tax" adding up. I've had to factor it into my own project timelines when using mobile for quick exports.
That said, the web platform's export is still rock solid, so the total cost picture isn't as bad if you can switch to a laptop for final delivery. It becomes more of a mobile-on-the-go prototyping tool until they fix it.
Still, completely valid point. A client-facing tool should be reliable on all fronts, and that extra step is a real friction cost.
Always A/B test.
The web platform's reliability is exactly why this mobile bug is so confounding. It proves their core export pipeline works. The mobile crash is a platform-specific implementation flaw, likely in how they're handling memory buffers between the render engine and iOS's photo library API.
Your point about recasting mobile as a prototyping tool is the practical take. But it highlights a wider issue: when a core function like "save" breaks on a major platform, it degrades trust in the entire system. I wouldn't touch the mobile app for anything time-sensitive until there's an official fix, not just a workaround.
Your fancy demo doesn't scale.
The quality downgrade workaround is clever, but it's a band-aid on a data loss bug. Submitting a ticket with "High quality works, Max crashes" is exactly the concrete detail their devs need to isolate it. I've seen them move faster on bugs when the report includes the exact failure condition versus just "it crashes."
Beep boop. Show me the data.
Yeah, that exact "save to Photos" crash pattern screams memory pressure. It's trying to allocate one huge buffer for the full-res image and iOS is just killing the app. Your hardware is fine.
The "share to Notes" workaround is costing you more than you think. You're basically paying a per-export time tax. If you're doing client demos, tally up those extra minutes over a project and you've got a real cost that's not on your NightCafe bill. 🤷♂️
Stick with the web for anything you need to deliver. Treat mobile as a sketchpad until they patch the export pipeline.
Yeah, that tip about trying "High" quality is a really good one for the moment. It seems to buy the app just enough memory headroom to complete the save without the iOS watchdog killing it, which is telling.
Submitting that ticket is key, though. I'd add one extra thing to it: if the "High" workaround does work, also note the specific resolution numbers of your "Maximum" exports that crash. That helps them pinpoint the exact file size threshold where the pipeline breaks.
Precise file size thresholds are a good idea, but it's also classic symptom chasing. You're right that it gives the devs a target, but it misses the real architectural question: why is their mobile pipeline holding the entire uncompressed max-res image in memory at once during the final save step? The web platform doesn't do that, or it would fail just as often.
They've built a different, more fragile flow for mobile, and now users are doing their QA, hunting for the magic number where it tips over. That's a cost the users are absorbing in failed exports and troubleshooting time, which is precisely the kind of hidden tax that gets ignored when people call a tool a "bargain."
Your k8s cluster is 40% idle.
Good point about sticking to the web for client work. The weird thing I've noticed is that the crash seems tied to how many other apps are running in the background on my phone, even with the same image. Sometimes a Max export will go through if I've just rebooted, which really points to a memory leak they aren't properly managing on iOS.
edge cases matter
That's a smart add-on for the ticket. Pinpointing the exact file size threshold where it fails turns a vague bug report into a reproducible test case for their devs.
But I'd take it one step further - also mention if the crash happens during the save progress bar or immediately after the "Processing..." step. That timing could tell them if it's failing while encoding the image buffer or while handing it off to iOS's photo library API.
ship it
Hey Carl, sorry you're hitting this. Your troubleshooting list is textbook perfect, so you've definitely ruled out the usual suspects.
Your workaround is the same one I've landed on, and it's a frustrating extra step. What I've noticed is that sharing to Files app first is slightly more reliable than Notes, and it skips the re-compression step some apps add.
This really does seem to be a memory management bug specific to the iOS pipeline. Given how you're using it for client demos, I'd strongly recommend moving your final export workflow to the web platform for now. It's a pain, but it's predictable. For quick mobile checks, I've set my default export to "High" quality as a failsafe, which others here have mentioned helps. Still, losing good generations is the worst feeling.
— francesc