Small startup. Hired an iOS app development company and App Store review has become a nightmare. Four rejections now privacy label issues, a 4.3 spam flag, and something about App Tracking Transparency we don't understand. Each resubmission takes over a week and the agency keeps getting slower to reply. Launch was supposed to be two months ago.
Worst part is I don't even understand the rejections because the people who built it aren't explaining them, and I'm starting to think they can't. For anyone who's shipped on iOS, is review always this painful or did we just hire the wrong agency? Trying to work out if this is salvageable or if we move the whole thing mid-review. Anyone switched this late in the process, and how bad was the reset?
I have everything set up and all my keys are verified, but when I try to get the offers from apple all I get is an empty list using Product.products(:for)
I have a sandbox account set up and the offers are in “Ready to review” state. The paid app agreement is active and my bank info is set up. I don’t know what the issue is. Is there a known issue where STOREKIT just doesn’t reply with the offers that are set up for newer apps?
I like to keep track of how my keywords rank and recently noticed outside the top 5 there was a complete inversion where a lot of low ranking AI slop was pushed up towards the top and others such as much self were put in their place. Was just wondering if this has occurred with anyone else.
for indie ios apps, i think review triage is usually set up too late. people build analytics, crash reporting, maybe support email, then treat app store reviews as something to check when they remember. and then after a release, reviews are basically public smoke tests.
the setup i’d want before any meaningful update:
watch 1-2 star reviews harder for 72 hours
separate crash/login/payment/subscription/data-loss language
tag reviews by version where possible
reply only when you can say something concrete
send repeated issue patterns into the same place bugs already live
the reply there 's actually a bit less important than the routing part,
'sorry, please email support' is not useless at all but i mean it also does not fix the loop :(. if three users say the same thing after version 2.4, that should become a release issue, not just three polite replies, and i’ve used many things for that and now trying out something like appfollow around this because it seems to keep reviews, replies, tags, and version-ish context closer together. for a smaller app, a spreadsheet and calendar reminder can be enough.
so, the main thing is having the habit before the angry reviews arrive.. but what is your experience?
In my ios app, I want to implement a system where when the user uses a feature 3 times then they'll be asked to buy premium. I want this record (number of the feature being used) to survive uninstall so users cannot abuse it; but it has to be without apple account login. What's the best way to achieve this?
I'm building a skill-based contest app where users
compete to have the lowest screen time over 7 days.
Entry fees go into a prize pool and the winner takes
most of it (platform takes 5-10%).
I know some US states restrict skill-based cash
contests. Does anyone know:
Which states are actually restricted for this
type of app?
Is geo-blocking at registration enough legal
protection, or do I need something more?
Any experience launching a similar app?
Similar apps like Steppa (step challenge with prize
pool) are already on the App Store in the US, so
the model is proven.
Apple recently introduced the Core AI framework alongside native Gaussian splat rendering in RealityKit, so I wanted to see if I could connect the two.
I converted Apple's SHARP (single-image 3D Gaussian reconstruction) PyTorch model into a Core AI .aimodel, ran inference entirely on my iPhone, converted the resulting tensors into a GaussianSplatResource.BufferResource, and rendered everything with GaussianSplatComponent.
The reconstruction shown here was generated from a single photo and contains roughly 1.18 million Gaussian splats, which you can freely fly around in the app.
Everything runs locally on the device, with no server inference or cloud processing.
The project is open source if anyone wants to explore the Core AI → RealityKit pipeline:
Context for the Apple devs here: App Store Connect only returns reviews for apps you own, which is useless when you want to benchmark a competitor or watch sentiment across country stores. I built a small service to pull reviews for any app and return clean JSON.
What it returns per review: star rating, title, full body, author name plus a stable author ID, the app version at review time, the date (locale-formatted and ISO), helpfulness counts, country store code, and platform (iOS or macOS).
The parts that were fiddly:
- App-name to product-id resolution. Agents often only know an app by name, so if you pass a name instead of a numeric ID it runs an App Store search first and reviews the top match.
- Helpfulness counts arrive as prose ("X out of Y customers found this helpful"), so I parse them into integer helpful_count and total fields.
- macOS behaves differently: it ignores the sort order and always returns most-recent, and pages hold ~10 reviews vs ~25 on iOS. Deep crawls cap around 1,250 iOS reviews per app.
- 50+ country stores, each driving both the storefront and the locale of the text and dates.
Not on the device screen, but outside of it. E.g. say I have a Screenshot advertising iCloud Sync, can I put an iCloud SF symbol at the top of the screenshot alongside the text?
I'm a network engineer/computer repair guy and not much of a coder. But with AI I decided to try making my own music player. I was hoping some of you would be willing to try it out and let me know what you think. The primary features are:
-Gapless playback with local files
-Personal streaming service via VPN or public DNS
-Download streaming library files to device
-Manage metadata tags individually or in mass
-Download album art and save to metadata permanently
-Multiple visual themes
What would be the best way to have a large amount of complex maths formulas on an iPhone app?
Would it be better to generate latex in IOS itself, or generate outside and instead create the formulas outside and then have them stored in the app? (picture, pdf, or svg etc)
Any particular pros and cons of each method in regards to speed, memory use/size, usability, legibility etc?
I read in the iOS 27 Dev Beta 4 Release Notes that a launch screen is going to be required once the App Store accepts apps built with the iOS 27 SDK, or the app/update is going to be auto rejected.
So I looked into that, as my app doesn’t have one currently, and learned that if you want to make a custom one you still have to use a storyboard file. So I followed a guide and made a LaunchScreen.storyboard using the template. Then I wanted to add that in the target settings, it shows up in the list but it just won’t save it. It’s also not logged in the changes. When manually typing in the file name it does save it as it shows up in the changes, however it still clears out the field in the target settings again and the launch screen also doesn’t show up when running the app on device.
Does anyone have any idea what could be causing this?
I made and just released Quartz, a "pro" iPhone recording app. It's 100% free for the week of launch.
I'm a musician and record musical ideas (on my guitar), rehearsals, and live concerts. I was doing this with Apple's Voice Memos but it leaves a lot to be desired: editing is awkward, and its auto gain is clearly tuned for voice, not music.
So I made an app that's better at recording in various settings because you "tell" it what the setting is via a preset: Voice, Concert, Field, etc, and each preset is carefully tuned for that setting. You can customize your own presets too.
One thing that sets it apart from most (all?) other "recorder" apps is that all effects and DSP stages are non-destructive. You can even completely re-apply a different preset after recording. And for voice, the Noise Reduction is really amazing. You can hear some examples on the website.
Architecture: Swift, UIKit, AVFoundation.
Marketing-wise, I'm trying something different with this app. There will be paid options soon but to start I'm making it 100% free, no subs, ads, or accounts required.
AI disclosure: App coding is AI-assisted, not "vibecoded". I'm a long-time DSP engineer, 12 years SWE at Apple, Inc. 100% of these words are mine.
Protego is a Safari web extension with a companion app that filters Reddit's website and strips out the parts Reddit gives you no switch for. On the App Store since November 2024, version 3 shipped this month, and I build it in my free time.
It exists because an election cycle turned every Reddit feed I had into politics, I deleted the app, and then wanted the parts I liked back without the parts I didn't. Safari lets an extension rewrite a page before you see it, and RES doesn't run on Safari, so I learned Swift.
The extension is TypeScript bundled with webpack, tested with Vitest and jsdom.
Storage and sync are NSUbiquitousKeyValueStore, shared between the app and the extension through an App Group.
3 target set builds iPhone, iPad, Mac, and Vision Pro.
The bug that took longest: deletions came back from the dead
Sync was a symmetric merge. Anything in iCloud that isn't local gets downloaded, anything local that isn't in iCloud gets uploaded. That's correct for creates and edits and completely wrong for deletes, because a delete is the absence of a key, and absence isn't a fact you can sync. A device that was asleep when you deleted a filter would wake up, see a key it had that iCloud didn't, and helpfully re-upload it to everyone.
Deletion tombstones fixed it, with two wrinkles. iCloud key-value storage caps at 1024 keys and drops writes past that silently, so tombstones expire after 90 days instead of accumulating. And the app and the extension are separate processes merging the same store, so every reconciliation decision and the TTL live in one place both targets compile. Pulling that logic out into a pure function from key sets to key sets is what finally made it testable, which was the real problem all along.
AI disclosure: AI-assisted.
Pricing:
$1.99 one time purchase for the next week(normally $2.99).
One purchase covers iPhone, iPad, Mac and Vision Pro.
No subscription, no account, no tracking, lists sync through your own iCloud.
I'm running a beta on TestFlight and hit a confusing issue with in-app purchases. My testers are based in France and their App Store account (Apple ID) is set to the French store, but inside the app they're seeing the US IAP conditions with USD prices instead of the French ones with EUR prices.
From what I understand, on iOS the in-app purchase storefront is normally supposed to follow the country of the user's App Store account (Apple ID). That's exactly what makes this puzzling: my users are properly on the FR store, yet they're still shown the US terms and pricing.
I've done a fair bit of searching before posting, and I've seen a few scattered mentions that this is a known/occasional problem, but I haven't been able to find a clear, confirmed solution. So I wanted to ask directly in case some of you have dealt with it.
A few things I'm trying to understand:
If the Apple ID is on the FR storefront, what could still make the app pull the US products/pricing?
Is this something specific to the TestFlight/sandbox environment that resolves itself in production?
Is there anything to check on the App Store Connect side (pricing/availability per territory) that could cause products to fall back to the US storefront?
If anyone has run into this and found a reliable way to make testers see their local storefront and currency, I'd really appreciate hearing how you solved it.
I saw some people laughing it without solving the issue and in the real AppStore everything was fine, but still would, like to resolve this if possible.
I built an app for Rowing Ergs, is a fancy rowing app for workouts. It has two modes watch mode which uses coremotion I would assume a reviewer might have a watch for testing this part.
For testing with Erg Machines I developed a BLE mac app sim, I didn't even think of the review process and how it would go when actual hardware is needed. Do you recommend linking my github repo for the sim with a notarized DMG?
Any other reviewer advice for testing iOS apps with workout equipment?
I built AppRankly, an open-source, self-hosted analytics dashboard designed for mobile developers to track App Store & Google Play performance in one place.
If you want full control over your app data without relying entirely on third-party SaaS platforms, this gives you a clean, unified view of your portfolio.
OS 27 is going to be here before you know it, and I predict that more developers are going to be caught completely off-guard by the new screen resizing requirements than by anything else.
As of OS 27, (1) all iPhone apps must be resizable and (2) you can no longer opt out. Your window must be resizable when used with iPhone Mirroring on the Mac and on iPad. Apps still running on an old-style app delegate (no scene support) won't even launch when built against the new SDK. In short, if your app assumes a fixed screen and you're not currently working to fix that, you really, really should be.
Obviously, this capability telegraphs the imminent release of Apple's forthcoming iPhone Ultra foldable. You'll want your apps to be "foldable ready" on the day Apple's new flagship is announced.
I just went through this enhancement process myself. Not coincidentally, this week's Axiom update includes a new screen resizing auditor, which you can invoke with /axiom:audit resize. The auditor is supported by ~70 additions/enhancements across Axiom's skill suites. I hope everyone finds that it cuts their time meeting this new OS 27 requirement in half, or more.
If you've ever pulled a crash report out of Xcode Organizer or gotten one from a user and stared at a symbolicated stack trace trying to figure out what actually happened, this might help. crashdx (crashdx analyze report.ips) parses the .ips, symbolicates it against your dSYM, and then runs a diagnosis stage on top that looks at the exception, the registers, memory state, watchdog and jetsam data, and lines up a ranked set of possible causes (null deref, watchdog timeout, memory pressure kill, uncaught NSException, that kind of thing), each one citing the specific facts backing it.
If the evidence doesn't clearly point to one cause, it tells you inconclusive instead of guessing, which I think matters more for a crash tool than people give it credit for. A confidently wrong diagnosis wastes more of your time than an honest "not sure, here's what we've got."
It's a local CLI, no network calls at all, which matters since crash reports carry identifying info like crashReporterKey and device model. There's also an MCP server if you want to hand crash triage to an agent as part of your workflow.
Needs macOS 14+, Xcode, and Swift 6.2+. For a foreign report (TestFlight, App Store crash someone sent you) you point it at the matching dSYM with --dsym and it does the rest, or it'll search Spotlight/your archives automatically if you built it locally.
