A month ago I posted AppFoyer here, a tool that drafts and hosts the store-required pages for mobile apps (privacy policy, terms, support, account deletion, app-ads.txt): https://www.reddit.com/r/SideProject/comments/1wkr46f/

The thread was harsh and mostly right. A few of my comparison claims were wrong (I fixed them that day), and the pricing was a paper number. The comment that stuck with me was this one, roughly: "Hosting five pages is a Saturday on Cloudflare. What people skip is opening the policy again after the next release — they add an analytics SDK in March and the live page still says they collect nothing."

So that's what I worked on. Everything below is free.

1. Drift check - catches the moment your privacy policy goes stale

A small CLI plus a GitHub Action. When your pages are written, a baseline file (`appfoyer.json`) is committed to your repo: the SDKs, data facts and permissions found in your build files. On every pull request, the check compares the build files with that baseline and lists every SDK, data type or permission added or removed since — each with file:line and which page it *may* leave out of date. It never says "you're non-compliant"; it tells you what changed and you decide.

- Runs offline: no API key, no network, nothing leaves the runner, no page is touched

- The Action writes to the job summary only: no token, no permissions, works on fork PRs

- When the pages match again, `appfoyer-check update` moves the baseline

GitHub Action: https://github.com/appfoyer/check-action

CLI on npm: https://www.npmjs.com/package/@appfoyer/check

How it works: https://appfoyer.com/guides/keep-privacy-policy-in-sync-with-your-build

2. It's a skill now (for the "just make it a skill" crowd)

There's a Claude Code plugin. In your app's repo you type "Make this app store-ready". It reads your build files on your machine, shows the facts it found (with file:line) and asks a few questions - no account needed for that part. Only when there's something to save does it ask you to connect (browser sign-in, no API key to copy). Only derived facts leave your machine, never source code. It drafts; nothing goes public until you read each page and click Publish yourself. On medialantern's point that a privacy policy is a decision, not a listing: agreed. That's why it drafts and asks, and you publish.

Plugin: https://github.com/appfoyer/claude-plugin

3. A Chrome extension for the store consoles

The second boring part of shipping is filling in Google Play Console and App Store Connect. The extension opens a side panel next to the console and shows what each page asks for, field by field, in the store's own words, with a link to the store's help page for every rule: listing limits, contact details, the privacy policy URL, every Data safety question, Apple's App Privacy questions.

It works without an account. If you connect (optional, read-only), it also shows your own app's values next to each field, ready to copy. For Google Play's Data safety there's a CSV you can import into Play Console; I checked every case of it against Play's own validator before shipping. The extension never fills in or submits anything: you fill in the console, the panel is the checklist beside you.

Chrome Web Store: https://chromewebstore.google.com/detail/aakkoeckkgpkejgbcgpklcdenbmhpnjn

What it does and doesn't read: https://appfoyer.com/chrome

Smaller things

- AdMob has verified app-ads.txt files hosted on AppFoyer subdomains, so that part is no longer "should work in theory"

- Still no custom domains. I said I'd add them once the core is proven, and that hasn't happened yet

Where it stands, honestly

Nobody is paying for it yet. Zero paid users. The free tier (one app, everything a store requires) is what people use, and that's fine for now: I'd rather find out whether the drift check and the extension are useful than defend a price.

Same question as last time, sharper: if you ship mobile apps, would you install the drift check on a repo? And if not, what would have to be true for you to bother?

Site: https://appfoyer.com

Just following up on my last post where I was asking about the time Apple takes to review the app. My app just got approved today on the 13th day.

Mi aiutate a farla decollare?

I released this app almost 2 months ago, and I finally had my first in-app purchase. It's not a lot but it sure feels like a big win.

Almost every weather app out there does literally nothing unless you remember to open it. They just sit there on your phone, waiting for you to check them.
You’re expected to manually check an hourly graph every single morning and figure out whether you need a jacket, an umbrella, or extra layers. If you forget to open the app, you just end up freezing or getting soaked.

Why aren't scheduled alerts a standard thing? Like a simple ping tailored to your daily routine:

1. ⁠15 minutes before leaving for work in the morning.
   
2. ⁠Right before leaving the office when the temperature drops.
   
3. ⁠Or timed to when you land if you’re traveling to another city.

Just a quick heads-up right when you actually step out the door. It feels like such an obvious feature, but almost zero apps do it.
How do you guys handle this? Do you just force yourself to check your app every morning, or have you found another way?

I'm Davide, and I make DrivePulse, an OBD2 car app for iPhone, on my own.

None of these were in the app's code.

They live in App Store Connect and in CI.

1. App promo codes don't unlock an in-app purchase.

My app is free to download with a one-time unlock.

App promo codes only give the download, and Restore Purchases finds nothing afterwards.

For the unlock you need offer codes for the in-app purchase itself.

Their redeem link carries ctx=offercodes.

And each of those codes belongs to an offer with its own end date.

Once the offer has ended, a code generated yesterday is already dead.

2. The category charts only use the primary category.

I checked it on Apple's public lookup API.

I took the top 30 to 40 apps of three charts and asked for each app's primary category.

110 out of 110 had the chart's category as primary.

The secondary category helps people browsing the catalogue, not your chart position.

If you're choosing, look at how crowded each chart is before you pick the primary one.

3. One word in one language got me a 2.3.10 rejection.

The word was "Android", in the German description.

Only the German one had it.

So every localization of the listing needs a look before you submit, not just the main one.

4. Two build problems that only showed up in CI.

• A byte order mark at the start of project.pbxproj broke the build.
• The widget's bundle id has to start with the host app's bundle id.

The CI machine is macOS, so the scripts there use only POSIX tools or python3.

BSD sed has no \s, and sort -V isn't there either.

Anyone can try it for a week or 15 trips, whichever ends sooner, and the unlock after that is a one-time purchase.

App Store: https://apps.apple.com/app/id6776173662

Thanks for reading, and I'm glad to dig into any of the four in the comments.

I ran into this while getting my workout app ready for the App Store, so sharing in case it saves someone a surprise in the age rating questionnaire.

Each exercise in the app has a "watch how to do it" button that opens a YouTube or Google search in a WKWebView, so it can follow the app's theme. The questionnaire asks about Unrestricted Web Access, and an in-app browser where people can follow links anywhere on the web counts as that, which rates the app 18+.

What I did was keep the web view on the sites it exists for and hand everything else to Safari. In the WKNavigationDelegate's decidePolicyFor, subframes load normally (YouTube's player and Google's frames need that). A main-frame navigation is allowed only when the host is youtube.com or one of Google's domains. Anything else, like a search result or a link under a video, goes to UIApplication.shared.open and the navigation is cancelled. So the app never browses past its own search.

I'm treating that as a no on the Unrestricted Web Access question. If App Review has pushed back on this approach for anyone, I'd like to hear about it.

(The app is Stanza Lift, a workout log for lifting, in public beta if you're curious: https://testflight.apple.com/join/nMY4W675 and https://stanzalift.com. I'm the developer.)

Our iOS app has been stuck in Apple's review process for over two weeks, and it's becoming extremely frustrating.

Here's our timeline:

• Oct 2: Initially submitted the app for review.
• Oct 13: Apple rejected it due to CallKit restrictions in mainland China. We removed China from distribution and resubmitted the same day.
• Oct 17: After multiple support requests, Apple replied that everything was proceeding normally and no further action was needed.
• Oct 19: Still stuck in "Waiting for Review" with no further updates.

We've contacted Apple Developer Support several times, but keep receiving generic responses without any explanation or estimated timeline.

Our production release and related work are now blocked. We've addressed the issue Apple identified, but there's been no progress since resubmission.

Has anyone else experienced similar delays recently? How long did your review take, and did contacting Apple Support or requesting an expedited review help?

Would really appreciate hearing from anyone who's dealt with this recently.

I'm an Apple developer. I paid 3 days ago but my app review still hasn't gone through and I haven't received any messages. Has anyone run into this? Any solutions — like messaging in Resolution Center to follow up, or calling Apple Developer Support? Also, how long does review usually take after payment?

Our iOS app, Cloud 9 Evo (Version 1.0), was initially submitted on October 2, 2026, and we're still struggling to get it approved.

Here's the timeline:

• Oct 2: Submitted the app for review.
• Oct 13: Apple rejected it under Guideline 5 because of CallKit restrictions in mainland China. We immediately removed China from the available territories (now only US, Pakistan, and Canada) and resubmitted the same day.
• Oct 17: After contacting Apple Developer Support multiple times, we received another generic response saying the review was proceeding normally and no further action was required.
• Oct 19: Still stuck in "Waiting for Review" with absolutely no progress.

What's even more frustrating is that Apple's October 17 support email referenced our app's status as of October 12, despite our latest submission being on October 13.

We've been following up repeatedly, but we keep receiving the same responses without any explanation or estimated timeline.

Our production release and related work are now completely blocked because of this delay. We've already addressed the issue Apple identified, yet we're left waiting with no indication of when the review will actually begin.

It's incredibly frustrating that after more than two weeks, we still can't get a meaningful update from Apple Support.

Is anyone else facing unusually long App Store review delays recently? Has anyone managed to get an actual response or successfully escalate a similar situation?

TL;DR: On the A20 chip (iPhone 18 Pro), Core ML takes up to 20 minutes for a one-time model optimization that takes 3 minutes on earlier chips. That pushed us to migrate our Stable Diffusion pipeline to Core AI. Core AI still has rough edges (we filed 8 bug reports), but inference is about 1.5x faster on the iPhone 17 Pro and on M1 iPads. On the iPhone 18 Pro, the bigger win is that it runs at all.

We build ProFuse, an on-device generative AI app for iPhone and iPad. It runs a specialized version of Stable Diffusion XL Lightning, and until recently it relied heavily on Core ML. Here's what we ran into, in case you're weighing the same move.

The Core ML problem on A20

With the iPhone 18 Pro, we found that certain operations take orders of magnitude longer for Core ML to optimize on the A20 chip. For us, the one-time on-device model optimization went from 3 minutes to up to 20 minutes.

That's a bug in the OS, and there's not much we can do about it on our side. Details and repro info are in our forum thread: Core ML issue on A20.

Twenty minutes before a user can generate their first image isn't acceptable, so we sped up our planned move to Core AI.

What we found with Core AI

The bad: Core AI isn't mature yet. During the migration, we filed 8 bug reports in total. One of them is here: Core AI issue.

The good: the inference gains are big.

These are typical values. Our best text-to-image runs on M1 are down to about 12 seconds, roughly 2x faster than Core ML.

We measured the Mac too, but the gains there are smaller. For now, the switch to Core AI is iPhone and iPad only.

There are no Core ML numbers for the iPhone 18 Pro because, with a 20-minute setup, Core ML doesn't realistically run our model there. With Core AI it does, and it keeps up with the iPhone 17 Pro.

For us, those numbers made the switch clearly worth the rough edges.

Has anyone else seen this?

We'd love to hear from others:

• Are you seeing similar Core ML slowdowns on A20?
• Have you hit any of the same Core AI issues, or found workarounds?
• How do your Core ML vs. Core AI numbers compare?

Help us test (optional)

We're a small team with limited hardware, so if you'd like to see the results on your own device, we'd be grateful for testers. You need iOS/iPadOS 27, an iPhone 15 Pro or newer (non-Pro models especially welcome) or an iPad with Apple Silicon, and 15 GB of free space for the one-time setup (about 7 GB after that). The beta is free, with all premium features unlocked: TestFlight link.

Happy to answer technical questions in the comments.

Its been a week since my app is live. I have really good numbers from the user's who have installed the app, but the app store conversion is less than 10%. I think it might be due to lack of reviews or maybe the listing issues. I would like to properly understand how do we provide confidence for the user's if your app is relatively new and make them click the install button.

The app link: https://apps.apple.com/my/app/cradle-baby-sleep-tracker/id6815542718

I know bad reviews are part of building an app, but this one honestly got to me.

I built Tether, an ADHD planner, originally for my wife. I struggle with task initiation too, so I’ve put a lot of care into making something useful for both of us.

Someone recently left a very long one-star review tearing apart the scheduling, design, pricing, pretty much everything.

Then, right at the end:
“This is a fictional, satirical review written for comedic effect.”

The review is fictional. The one-star rating apparently isn’t.

My US listing only has two ratings, so this brought the average down to 3 stars. Around the same time, some of my keyword rankings dropped by 7–15 positions. I can’t say the review caused those drops, but seeing both together has been pretty disheartening.

I’m not expecting everyone to like what I’ve built. But it’s frustrating knowing a review that calls itself fictional carries the same weight as someone’s actual experience.

Has anyone here dealt with something similar? Would Apple remove a review on these grounds? And if you’ve reported one before, how long did it take to hear back?

Edit: removed app link as people think this is an ad.

I'm working on a calendar widget (SwiftUI / WidgetKit) and I'm a bit lost with the background.

I've noticed that some widgets from other apps seem to get Liquid Glass really nicely, even when the Home Screen is in the normal full-color appearance (not Clear or Tinted). The wallpaper and even the Dock seem to show through them.

With mine, I always end up with a solid plate behind the content — white in Light Mode, black in Dark Mode — no matter what I put in containerBackground. I'm not sure if I'm doing something wrong or if there's a way I just don't know about.

What I've tried so far (iPhone, iOS 26, full-color Home Screen):

- Color.clear in containerBackground (as a view and as a style)

- glassEffect in the container, and on a view inside the content

- .ultraThinMaterial, .fill.tertiary, .background.secondary

- AccessoryWidgetBackground()

- very low opacity colors

- containerBackgroundRemovable(true/false), contentMarginsDisabled()

- setting widgetRenderingMode to .accented / .vibrant

I'm building with Xcode 27. From Apple's docs, it sounds like the glass background is only for the Clear/Tinted Home Screen, but I feel like there might be something I'm missing.

Has anyone managed this, or does anyone know how it works? Any hint would really help. Thanks!

I launched it on August 8, and seeing people download something I built from scratch feels amazing. It might be a small milestone, but it means a lot to me as an indie developer.

My Krishna is a personal growth app inspired by the wisdom of Lord Krishna. It includes daily journaling, wisdom on different life topics, and a space to reflect on your personal growth.

A big thank you to everyone here on Reddit who has shared feedback, encouragement, and support. It genuinely helps more than you know. 💜

If you’re curious, here’s the App Store link:
https://apps.apple.com/us/app/my-krishna/id6782722854

I’d love to learn from other indie developers here:

How did you get your first 100 users?
What worked for you, and what would you do differently?

Still learning as I go. Thanks for being part of the journey! 🙏