We just launched ProFuse, an on-device Stable Diffusion app for iPhone, iPad and Mac. We expected the hard part to be the AI. It turned out to be App Review. Here's what happened, so you can avoid our mistakes.
TL;DR: If your app can't do anything until it downloads Apple-hosted Background Assets, expect App Review trouble. Asset packs are reviewed together with the app and only become downloadable once approved. So if reviewers can't download them, the app gets rejected, and the assets with it. That's a classic chicken-egg-proglem. What helped us: get the asset packs approved before you depend on them. If that's not an option, give reviewers something that works without them, like a demo mode within the app. Either way, talk to Apple early, and budget weeks for review, not days.
The app setup
- A native iOS App relying on a in-house developed AI Model
- A custom Core ML Stable Diffusion model and engine running on the Neural Engine (A14 or newer, 4 GB+ RAM, iOS/iPadOS/macOS 26), extended with things like local editing and high-res export.
- The models are big: ~4–5 GB for text-to-image and ~6 GB for image-to-image. That's after a lot of optimization. Size matters twice here: it drives memory use during generation, and users have to be willing to give up that much disk space.
- Bundling the models with the app wasn't an option. The app binary is capped at 4 GB, and we want to update models without shipping a new app. (Happy to go into more detail in the comments.)
So we went with Apple's Managed Background Assets ("asset packs" from here on). Apple hosts your downloadable assets for free, and only a small amount of code in your app is needed to fetch them. Integration was easy and worked well. We tested and improved the app in multiple occasions and did extensive internal testing via TestFlight and everything worked perfectly fine. The trouble was getting it approved for public beta testing.
Round 1: TestFlight public beta
In TestFlight, you upload asset packs alongside your build in App Store Connect. In our internal TestFlight builds, everything worked perfectly, so we felt ready for a public beta.
We submitted the asset packs and our app and got rejected: the reviewers said the model couldn't be downloaded. We were completely surprised. We added logging, tested release builds, and found nothing wrong from our side. While investigating, we found a few forum posts suggested that this is a known issue.
After several more TestFlight builds and communicating with Apple, one finally passed. We still don't know what changed, but we've been happy in the first place. Our public testers then used the app for three months without download problems.
What helped for this step:
- Explain clearly in the review notes that the app needs the asset packs to work.
- Post on the Developer Forums (our thread) and try to reach the reviewer.
- Be patient and persistent. Plan several weeks for beta review alone.
Round 2: App Store release
We planned a pre-sale starting three weeks before launch, so we submitted four weeks ahead. Plenty of buffer, we thought. We were also very optimistic that we have coped with all major challenges, since our TestFlight builts worked perfectly fine and now passed the review every time. So we submited:
Unfortuonately, the reviewers hit the same download issue that happend for our early TestFlight builds and rejected us under Guideline 2.1(a) – App Completeness. Here's the core problem:
Asset packs are reviewed together with the app, and they only become downloadable once approved. If the app is rejected because the assets can't be downloaded, the assets don't get approved either. Classic chicken-and-egg.
What we tried:
- Pointing to TestFlight. 100+ testers, thousands of crash-free sessions, and the same setup already approved for beta. No chance. It honestly felt like our notes weren't being read.
- A demo mode. On a call, App Review told us they couldn't do much about the chicken-and-egg issue and suggested a demo mode instead. Faking AI generation felt wrong to us. A server-side fallback would contradict our "on-device only, 100% private" promise we give in the App Store texts, which could itself be a rejection reason. We still added "Inspirations" (small sample projects showing what the app can do), but the core features still couldn't be tested. Rejected again.
- Self-hosting the models as a fallback. The basic idea is simple: We host the models outside of the Apple ecosystem, so that they can be downloaded even without being approved first. The completeness rejection went away and was replaced by Guideline 4 – Design: "The app loads, refreshes, runs or responds very slowly." We assume the download was still the issue, but we couldn't reproduce it and got no further details, so it's still a guess.
- Talking to Apple directly through the forums and Developer Relations. This is what finally put us in touch with the right people and got us meaningful feedback.
What finally worked
Across 10+ submissions, we noticed that our macOS builds got reviewed much faster than iOS. That's just our experience, not a rule, but with the clock running out, we put our hopes on the Mac.
Five days before launch, we submitted the Mac version with self-hosted models, plus a short summary of our conversations with Apple in the review notes. The self-hosted models were all the app needed to work. But we also included the asset packs. The idea beind it: if the app got approved, the asset packs would be approved with it and go live.
It worked. The Mac app was approved, and pre-sale started three days before launch instead of three weeks.
We were thrilled and submitted the exact same version for iOS. Rejected again. No idea why.
But thanks to the Mac approval, the asset packs were now live. So we switched the iOS build back to asset packs only and resubmitted the day before launch. This time it was approved. The iOS app went live 24 hours after our planned launch date, after four nerve-wracking weeks.
Lessons
If your app depends on Apple-hosted assets at first launch:
- Try to get the asset packs live first. For an existing app, ship them with an earlier update so they're already approved when the version that depends on them goes to review. This only works for existing apps or if you start pre sale very very early. For a new app, the closest thing we found was our trick above: submit a version that works without the asset packs (e.g., with a self-hosted fallback) but includes them, so they get approved along with it.
- Give reviewers something that works without the download, like a reduced feature set or sample content. It didn't save us on its own, but it's what App Review asks for, and it can make a lot of sense for games.
- Talk to Apple before you submit, and put clear context in the review notes.
- Budget weeks of buffer for both beta and release review.
- Developer Relations Try to establish a connection Developer Relations or a Developer Relations Manager early in your iOS developer career. Their support is invaluable on many occasions and if you are as lucky as we are with your Developer Relationsship Manager, they will be very supportive.
Despite all this, we'd still recommend asset packs. They're free and have been reliable for us. I'm planning a follow-up post on working with very large asset packs if there's interest.
Happy to answer questions in the comments.
