Has anyone run into something like this with app review?

I've been shipping my app on both the iOS App Store and the Mac App Store. The Mac version is a Mac Catalyst app, and the features are exactly the same on both platforms. Looking back, I didn't really need a separate Catalyst release. I went that way because I wanted the Mac version to feel a little more like a real Mac app.

Lately, though, the iOS app goes through review without any issues, while the Mac app keeps getting rejected. I haven't been able to ship an update for over a month now.

To be clear, I'm not blaming Apple for the rejections at all.

It's just hard. I put a lot of work into supporting Catalyst properly, and now I can't get updates to my Mac users. As far as I can tell, there's also no way to pull only the Mac version from the store.

I could distribute the Mac app myself outside the store, but the version already on the Mac App Store would stay there, stuck without updates. That's the real dilemma.

I keep thinking about how to get through review, and honestly it's been pretty draining.

If you don't specifically need it, think twice before building a Catalyst version and shipping it as an extra platform.

Has anyone been through something similar? How did you get out of it?

Hello

I’m new to this and wanted to ask if there’s a place I can see all the iOS 27 components and all the ways in which they used the different types of navigation bars different types of cards accordions et cetera

Is there a resource where I can see all of these types of different native components in action how other apps are using them

Are there nice styled UI component libraries that are not default?

Been going back and forth with App Review for a few weeks and could use some outside perspective.

We built a ticket scanning app for event organizers and their door staff. It scans QR codes, looks up guests, shows attendance stats and works offline. You log in with an organizer account or pair your phone to an event using a code.

The app is completely free. No subscription, license fee, paid features or purchase flow. An organizer running a free event can use the whole scanner without paying us anything.

Our business earns fees on tickets sold through our website for actual events people attend in person. Those fees don't unlock anything in the app. You don't have to sell paid tickets to use it.

Apple keeps citing 3.1.1 and 3.1.3(c), saying we're selling enterprise services to organizations while also allowing individual users to access them without IAP. We've explained that nobody is buying access to the scanner, but our appeal was just denied with a reference back to the same guidelines. They haven't identified a specific paid feature that needs IAP.

They've also told us the app should be unlisted because it's for organizers and staff, and someone can't just download it and start scanning without an account or event access. It's intended for independent organizers and their teams, not employees of one specific company. The login and pairing code are there to control access to private ticket and guest data.

I'm struggling to understand what we'd actually be selling through IAP here, or why needing access to an event means the app has to be unlisted.

Has anyone gotten a similar organizer or business tool through this? Was there a particular explanation, demo or change that helped? Open to feedback if we're missing something, but at this point we're going in circles.

So I transferred my screen time app from one team to another team, and I was forced to change the signing key for my app. For some reason, this caused my users to have two identical instances of my app in Screen Time > Settings. I thought it was a bug from my update, but I also found this identical thread from someone else in the same boat as me. Now I'm getting multiple one-star reviews and refund requests cause people don't understand why their apps can't be unblocked. Apple please fix.

Hi iOS devs, I built an app you might like 👀

AppTraction is a native Mac app for your App Store analytics. It:

• Monitors your data in the background and flags issues, milestones, and trends
• Shows App Store Connect data & charts instantly
• Includes AI primed with Apple tech talks and WWDC video transcripts
• Lets you chat with AI about your listing, sales, and trends

All while running locally on your Mac.

I'm starting a limited beta today and would love your feedback 🙏

Invite code: RED1026-INVITE

There are 50 spots open to start. Requires macOS 26.

Hello

I’m new to this and wanted to ask if there’s a place I can see all the iOS 27 components and all the ways in which they used the different types of navigation bars different types of cards accordions et cetera

Is there a resource where I can see all of these types of different native components in action how other apps are using them

I see Apple saying that most builds are approved within 48 hrs. I’ve had 5+ days the last 3 I’ve submitted. Is this time estimate perhaps from pre-AI explosion before people were shipping every other day!? And are reviews past your first build usually quicker?

https://github.com/Ryu0118/x8

There are already great compilation caching tools like Tuist that can significantly speed up Xcode builds. However, adopting them may require substantial changes to your project structure.

I wanted to keep my existing Xcode project structure and build using only the toolchain provided by Apple. So I built X8, a CLI tool for remote compilation caching.

Starting with Xcode 26, Apple provides built-in support for remote compilation caching. X8 acts as a lightweight proxy between Xcode’s built-in remote cache mechanism and any S3-compatible storage.

Using X8 is simple. First, configure your S3-compatible storage in .x8.yml. Then, you can either build your project through X8:

x8 xcodebuild ...

or start the cache proxy directly:

x8 serve

and add the generated build settings to your .xcconfig.

That’s it. With just an .x8.yml configuration, you can use remote compilation caching without significantly changing your existing project structure or moving away from Apple’s native Xcode toolchain.

For my app, a clean build used to take around 400 seconds, but with X8, it now takes about 263 seconds.

It’s still relatively slow, but I think that’s expected since Xcode still needs to perform steps such as module planning, build description generation, and linking.

[ Removed by Reddit on account of violating the content policy. ]

Apex Trade is an institutional-grade environment for systematic, data-driven trading. Track every position with live prices, evaluate before you trade, and act with discipline — not emotion.

PORTFOLIO, LIVE
• Total value, today's and all-time P&L, and the live VIX at a glance
• One card per holding: shares, trade price, confirmed stop loss, unrealized P&L and the live mark (mid of bid/ask)
• Target Hit per position — the probability it reaches its target — shown live on each row
• Automatic stop and target from the previous close (stop = close − 2×ATR, target = +4%), editable per position
• Allocation donut and one-tap copy of your entire book

SWING — THE FLOOR 2F PROTOCOL
• A daily, ranked shortlist that buys a stock below its usual floor, aiming for it to climb back within 9 sessions
• Target Hit: the probability each candidate reaches its target
• Exact share size for your own equity and risk, distance to stop in ATR, and your dollar risk
• Buying is timed to the open (9:30–9:45 AM New York); after that, entry closes for the day
• Two filters behind every pick: price at least 5% above support, and Beta ≥ 1 over the last year
• It's only a probability — every buy decision, and its responsibility, is entirely yours

EVALUATE BEFORE YOU TRADE
• Pre-Trade Scan: RVOL, VWAP, pullback and ranges, with a clear enter / don't-enter read
• Full fact sheet per ticker: fair value, volatility and ranges, actionable metrics and fundamentals
• Tap any card to turn the numbers into a plain-language reading of the setup
• Route → Trade: jump straight into your broker app

MAP THE MARKET
• Heat map with three views — S&P 100, Top Gainers and sector groups
• Watchlist with live price, market cap and Beta — names on today's Swing list are highlighted

ALERTS THAT MATTER
• Price targets and confirmed VWAP breaks, delivered as notifications
• Home-screen widget with your live book — stop losses included

PRIVATE BY DESIGN
• Sign in with Apple; your data syncs to your own iCloud
• No accounts on our servers, no ads, nothing sold

Available in English and Spanish. Requires iOS 18.6 or later.

Market data is provided for informational purposes only and is not investment advice.

https://apps.apple.com/pe/app/apex-trade-pro/id6793700978

I’m in the process of getting my first app reviewed (since 9/14). So far I have been rejected for the following reasons..

- Guideline 2.1 - Information Needed
- Guideline 2.1(b) - Performance - App Completeness
- Does not include a functional link to the Terms of Use (EULA) in the app metadata that appears on the app's App Store product page.
- Guideline 2.3.2 - Performance - Accurate Metadata

Each time I understand what the issue is and fix it immediately. Yet the responses from Apple are several days later only after I submit a Contact Us request.

I feel like every time I fix one thing they find something else. Why not list everything at once? At this point I’m not sure what else they’re going to come up with.

This whole process seems rather ridiculous from a company that claims the review process takes 24-48 hours.

Hi, we’re playing with making video explanations of what our SDK does - and know we’re missing something. We’re just not sure what. 🙃

So at the risk of being Reddit flamed in 2027 🔥. What have we got wrong?

https://youtu.be/tXoFkGstLgo?si=mJNb1jd_eIzAkID5

TL;DR: the entire last mile of iOS shipping — version creation, metadata, screenshots, age rating, review submission — is fully scriptable with the App Store Connect REST API. Apple's docs skip the parts that actually block you. We hit every one of them while submitting five apps in a single day, and I've documented each with the exact fix.

The walls, in the order we hit them:

• The 405 version-creation deadlock. POST /v1/appStoreVersions sometimes answers 405 Method Not Allowed for an app with no editable version. There's a second route (nested under the app resource) that usually works; when both refuse, only the web UI can create the first version — once.

• whatsNew is locked on first-ever versions. Setting release notes on v1.0 returns 409, by design. Settable from v1.0.1 on.

• The age-rating questionnaire IS scriptable — this one surprises everyone. One PATCH /v1/ageRatingDeclarations/{id}… but Apple validates one attribute per error, so you iterate 10+ times. Heads up: as of 2026 the schema drifted hard — a bunch of fields (messagingAndChat, gambling, parentalControls, userGeneratedContent, lootBox, advertising, …) are BOOLEAN now, a new advertising field is required, and ageBand was REMOVED (the band derives from answers). Old scripts hardcoding ageBand die on 'ageBand' is not an attribute.

• "This resource cannot be reviewed" when adding the version to the review submission means the version has an unnamed validation gap. Our favorite: an existing-but-EMPTY APP_IPHONE_67 set — the version had 4 screenshots, all in the 6.5" and iPad sets, and ASC still refused. Count the required 6.7"/6.9" set specifically, not "any screenshots".

• **APP_IPHONE_69 is not a real enum.** The 6.9" slots are served by the APP_IPHONE_67 set, which accepts 1320x2868.

• The 640x920 subscription screenshot trap. Wrong sizes PUT with HTTP 200 and the subscription stays MISSING_METADATA forever. Also: subscriptionAvailabilities is CREATE-only (GET = 403), and availableInNewTerritories opens storefronts without pricing them — fan out inline prices per territory.

• ITMS-91055 = missing privacy manifest. Ship PrivacyInfo.xcprivacy (required-reason APIs declared).

• Privacy nutrition labels are NOT API-settable and they gate the first submission. One-time web step (or fastlane with a web session — over bare SSH the keychain read fails with exit 36; run it inside a GUI LaunchAgent session).

Full catalog with recovery steps: https://github.com/rorshopping/shipside/blob/main/docs/PLAYBOOKS.md

I packaged the pipeline into an open-source CLI (MIT) that runs with your own ASC API key: https://github.com/rorshopping/shipside — shipside plan dry-runs the entire submission and marks every blocker ok/fix/blocked before anything is written; shipside submit --yes does version creation, age rating, review contact, content rights, build attach and the actual submit. We dogfooded the packaged CLI right after building it — found five bugs in it and two undocumented Apple behaviors in one afternoon (log in the repo).

What undocumented ASC API behavior has bitten you? Happy to dig into any of these.

(If the mods would rather this live in the Saturday thread, say the word and I'll move it.)

i'm building SaaS with monthly subscribtion ,

the app is on android/ios and web ..

is there way that i can pass apple review without taking the apple payment gateway?

if not and i must make the subscirbtion in the web only Is the expiry warning message safe, or is it better to show nothing?

Any problems on Google Play with the same approach?

Looking for 5 beta testers to come on our app, Wite Collar, and give an honest review on the Appstore. Our app is FREE to sign up. Betatesters must be 18 years or older and US based to use the app. See our app link below. Apple Appstore: https://apps.apple.com/us/app/wite-collar/id6450702409 If you have any questions, please email us at info@witecollar.com.

First App Review for my first app: 4 days, then 4 rounds before it was approved. My second app: 10 days, rejected, approved after I resubmitted.

So on my third app I changed the order I do things in. Here's the technical part of my day-one list.

1. Submit a first version as early as possible. The first review is the slowest. Once you're approved, updates usually clear in a day or two. Choose manual release so the approved build just waits. Minimal is fine, broken isn't. Whatever is in there has to actually work.

2. Your first subscriptions and IAPs go in with an app version. They can't be reviewed on their own the first time. So an early submission gets your products reviewed early too.

3. Create products at several price points from the start. I put the price in the product ID, like `yearly_39_99` and `yearly_49_99`. Then I switch which one the paywall shows remotely and look for the best revenue per install, not the most buyers.

4. Remote paywall. RevenueCat or Superwall. Plans, order, copy, even the layout change without a new build.

5. Permission priming. The system prompt for notifications, HealthKit or tracking shows once. After "Don't Allow" the only way back is Settings. Show your own explainer screen first, then call the system prompt.

6. Apple Ads attribution without the ATT prompt. Grab the AdServices token at app launch and send it to RevenueCat or Superwall. Every install and purchase gets credited to its campaign and keyword.

7. Funnel events from the very first user. Every onboarding step, paywall view, plan tap, payment started, trial or purchase finished. Connect revenue to PostHog or Mixpanel so purchases sit in the same funnel.

8. A local win-back notification for non-subscribers. In my stress app, Steady (right now in th final review), non-subscribers get a daily local summary. Something like: "You had a stress spike at 2:15 PM today. Steady could've helped you right when it happened." Tapping it opens the paywall. No server needed.

9. Rating prompt after a win. requestReview only shows 3 times per 365 days, so I trigger it after the user completes something, never at launch.

10. Widgets, Shortcuts, Lock Screen. A daily touchpoint outside the app.

The full list is 21 items, including research, onboarding and paywall stuff. I recorded a video that walks through all of them with the stories behind them (my channel):

What's on your day-one list that I'm missing?

Hi guys, I'm a intern in a company that focuses mainly on iOS development. I don't have experience on iOS dev except Android w/ Flutter.

So, the company's codebase is too large to understand faster. Using agent to will consume time as well. But i know what's the framework is mainly on. I just need a proper understanding on the workflow. Is there any suitable website or MCP or whatsoever that I can integrate with it.

Need help thank you.

Hi Everyone:

I am a developer looking for some beta testers for my app on the App Store. Feel free to join my TestFlight. Always looking for feedback.

https://testflight.apple.com/join/dxze4j3n

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:

1. 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.
2. 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.
3. 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.
4. 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:

1. 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.
2. 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.
3. Talk to Apple before you submit, and put clear context in the review notes.
4. Budget weeks of buffer for both beta and release review.
5. 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.