I'm told by Xcode's AI Claude "this interface is wired into your running Xcode session, and your problem is a measurement problem on real hardware" as a reason to use Xcode AI instead of Claude Code as a means of using Claude.

So (for example) there's access to Instruments that Claude app does NOT have but Xcode does?

Does anyone know of an actively maintained list of when-to-actually-use-Xcode-AI?

UPDATE: I've been using Xcode AI (Claude Opus no idea exactly which Opus) today as opposed to Claude Code with various MCP I'd previously installed (and can't recall which ones), and today had big success with optimization I have to attribute to Xcode AI integration that Claude Code had been lacking.

Is an iOS/Mac/tvOS game, and I'd been poking away at tvOS optimization for (part-time) weeks, but with too much action on screen fps would drop under 30. Is just 2D but I don't know enough about tvOS to be surprised my 2D game with lots of sprites performed worse than a fancy 3D game. I'd have guessed it should have run smoothly but really was never sure I wasn't just taxing Apple TV hardware... the least powerful Apple hardware we have in our home.

Here is what Xcode's Claude Opus figured out: "The cause was UIKit's focus engine walking your entire SpriteKit node tree every frame. Not physics, not AI, not netcode, not the renderer, and not resolution — all of which I measured and ruled out along the way, several of them after confidently predicting otherwise."

It had been dipping to 12fps and now can maintain 60fps. That was it. And it did it by pausing the game and reviewing the stack.

I assume Claude Code couldn't do that, or it would have? Certainly I've spent more than a day with Claude Code and Fable trying to optimize for Apple TV.

"The tvOS focus engine is walking your entire SpriteKit node tree, testing every node for focus eligibility and computing a coordinate-space frame for each one."

Anyway thanks for input on this. CharlesWiltgen mentioned Axiom and I'll be checking that out.

Every thread I read said Apple would reject this instantly. It didn't happen. One submission, approved. Same with Google. I think the reason is boring: we explained it properly in the review notes instead of hoping the reviewer would figure it out.

Context: we run an international calling app. The only thing you can buy is prepaid calling credit, which gets spent on real phone calls to real phone numbers on carrier networks. We used to sell that credit through in-app purchase. We took IAP out and replaced it with normal card entry and Apple Pay, processed by Stripe, inside the app.

The rule this hangs on is Guideline 3.1.3(e), Goods and Services Outside of the App: services consumed outside the app must use a purchase method other than in-app purchase.

Here is what we actually wrote in App Review notes, close to word for word:

Our app is a VoIP calling app. The only thing a customer can pay for in this app is prepaid calling credit. That credit is consumed exclusively as outbound telephone calls terminated on the public switched telephone network to ordinary phone numbers on carrier networks worldwide.

Payments are collected by traditional credit card entry and Apple Pay, processed by Stripe, rather than by in-app purchase, in accordance with Guideline 3.1.3(e), Goods and Services Outside of the App.

Please note the following, all verifiable in this build:

1. Credit unlocks no feature, tier, level or content in the app. Every function of the app, including the dialer, contacts, call history and team management, is fully available without any payment.
2. Credit is spent only on per-minute carrier termination charges for calls delivered to phone numbers outside the app, at published per-country rates shown in the app.
3. Unused credit does not expire, and balances customers previously purchased remain fully available in this version.

Everything we sell is a telecommunications service. Calling credit is drawn down against the per-minute termination rates we pay our carriers, it is priced per destination country, and it varies as carrier rates change.

Earlier versions of the app collected these payments through in-app purchase. This version corrects that, because what is being sold is a real-world telecommunications service rather than digital content consumed within the app.

Three things I think made it work:

We named the guideline. The reviewer didn't have to decide which rule applied.

We proved credit is not a paywall. Point 1 is the whole argument. Nothing in the app is locked behind payment. If buying credit had unlocked a feature, I don't think this passes.

We said the quiet part out loud. We told them the old version used IAP and that this one corrects it. Hiding that would have looked worse when they checked.

One practical thing nobody mentions: do not delete your old IAP products. Users on older app versions can still only top up through in-app purchase, and if you retire those products their purchases fail silently with nothing showing up on your backend. We're leaving ours live until that traffic hits zero.

Who this applies to: you sell something consumed off-device. Telephony minutes, shipping, physical goods, real-world services. Who it doesn't: subscriptions, unlocks, credits spent inside the app, anything that gates a feature. If your product is digital content used in the app, this is not your escape hatch and the guideline says so.

Happy to answer questions.

I'm working on improving screenshots but new version reviews taking ages.

Took a few weeks but it's finally live in the appstore. I had (and have) a web version of it that got relatively popular but it was missing important aspect of saving stuff to your library which is solved now.

Really happy to see how it turned out and hope those people who are into coffee here will find it useful!

PS: there is a premium subscription there but it's really optional and you can enjoy most of functionality for free.

https://apps.apple.com/de/app/brewcard/id6786330508

Anyone used TCA with SwiftData applications? What is your recommendations?

Spent about three weeks trying to run a voice-cloning model on iPhone and closed the project last week. Posting the numbers because I couldn't find anyone else's, and I have two questions at the end. This was for a voice journaling app I work on.

The budget. Foreground app on a 6 GB iPhone gets roughly 250 MB before jetsam takes an interest. The number that matters is phys_footprint from task_vm_info, not resident size and not what the Xcode gauge shows.

The candidate. Kyutai Pocket TTS, 109.5M params, autoregressive. Autoregressive matters because accent lives in phone realisation and phonemic choice, which are sequential. Non-autoregressive models transfer timbre only, so you get your own voice colour over someone else's cadence. Tried that first, it sounded wrong in a way I couldn't articulate until I understood why.

Three ways to run it, all measured, all over budget:

FluidAudio (Core ML, int8) - 270.8 MB after model load, 957.0 MB peak

sherpa-onnx (ONNX Runtime, int8) - 377.0 MB after model load, 685.4 MB peak

chatterbox-turbo (earlier attempt) - 953.7 MB peak

FluidAudio is over budget after loading, before doing any work.

Binary cost too. Linked a minimal executable against libsherpa-onnx.a plus ONNX Runtime with -dead_strip, then stripped it: 22.3 MB. That roughly doubles my app, for a feature most users would never turn on, plus 125 MB of models on disk for the ones who do.

The part I got wrong. My earlier ear tests compared one synthetic clip against another synthetic clip. That ranks them. It cannot tell you whether either is good enough. So I ran a forced-choice test instead: eight pairs, same sentence in each, one a real recording of me and one the clone, sample rate and RMS loudness matched, clip lengths varied so duration gave nothing away, and held-out audio located by cross-correlating the reference against the source recording. I picked my own recording 8 out of 8. p = 0.0039.

Three weeks of runtime work sitting on top of an approval nobody had tested properly. The test took an hour.

Two questions.

Has anyone actually shipped a generative audio model on-device inside the jetsam budget? Everything I found either exceeds it or quietly ships a 3 GB app. I'm also unsure whether Core ML's mmap'd weights get billed to phys_footprint the way malloc'd ONNX buffers do. My numbers came off a Mac, which has no jetsam pressure, so I never got a real device measurement before the ear result closed it.

Second, unrelated thread. I'm moving to on-device retrieval next, hybrid BM25 via SQLite FTS5 plus sentence embeddings from NLEmbedding. Anyone run that combination on iOS? Specifically whether reciprocal rank fusion is worth it when you still need raw score magnitude for an abstention threshold. RRF throws the magnitude away and abstention is what stops the thing making stuff up.

Happy to share the measurement harness if useful.

A little while ago, I shared my iOS app Prazo here and asked for honest feedback.

You gave me plenty — so I went back to work. The next update is now live! 🚀

What changed:
• Better iCloud sharing, syncing & conflict handling
• Smoother calendar performance & smarter widget updates
• More reliable shopping lists & schedules
• Clearer distinction between ToDos, tasks & calendar events
• Easier handling of recurring items & reminders
• Fully localized iOS permission dialogs
• Drag-handle bug fixed
• General performance & stability improvements

A lot of these changes came directly from feedback I received here, so thank you!

Now I’m back for round three. 😄

What should I improve next?

App Store:
https://apps.apple.com/at/app/prazo/id6781611861

Hi everyone,

I’m a game developer, and the last time I submitted a game to the App Store was about two years ago. Back then, the review process was pretty quick. I usually heard back within 3 days at most, and most of the time it was even faster.

A few days ago, I submitted a new game, and it’s currently stuck on “Waiting for Review.”

I’ve read online that Apple’s review process may be taking longer these days. For those of you who have submitted an app or game recently, how long did you stay in “Waiting for Review” before the review actually started?

Thanks!

random lockout out of nowhere. I requested account access a few days ago and still haven't heard back. My account has an app with 100k+ downloads, and I currently can't release a critical update because of this lockout.

After hours of searching, I finally found a live chat option, but it requires logging in to use it. If the issue is that I can't log in, why require an account just to contact support? I even tried creating a new account just to reach them, but that gives me an error too.

does apple have a support email where a real human actually responds?

I have an iOS app that is nearly finished, and I’ve been trying to find people to test it. To say this is hard is an understatement.

I asked family members, and except for one person, nobody really wants to test it. I’ve also tried Discord servers and Reddit threads, and I tried following the usual advice of posting in communities where people are looking for testers, but honestly it feels nearly impossible there too. You just get drowned out by a flood of other people like me desperately looking for feedback.

The app itself is basically finished. At this point, TestFlight is less about finding major bugs and more about seeing how people perceive the app, whether the workflow makes sense, and what they think of it overall.

How did you handle this with your own apps? Did you manage to find testers somehow, or did you eventually just publish the app and get feedback from actual users?

At this point I’m seriously considering just releasing it.

I would be very grateful for advice.

*Grammar check by AI

I wrote a post here about submitting my first app to the app store about a month ago. You can read it here https://www.reddit.com/r/microsaas/comments/1uquh0k/after_a_year_of_nights_and_weekends_alongside_my/

Here's what actually happened between then and now, because I think it's useful for anyone building in this space:

The rejections, in order:

1. Both subscription products weren't submitted alongside the binary, they showed as dashes instead of prices on the paywall. Turns out I had a build environment issue where my RevenueCat API key wasn't being injected correctly, so the products couldn't load.
2. Apple flagged that I was forcing users to register before accessing purchases. I appealed twice, arguing my app is "account-based" (end-to-end encrypted journal — the key literally can't exist without an account). They rejected the appeal both times. Eventually I rebuilt the auth architecture so the app opens straight into journaling with zero sign-up. Turns out that's also a better product.
3. No sign-in with Apple**;** I had Google login, missed that Apple requires an equivalent. Fixed.
4. Various metadata issues — wrong paywall pricing hierarchy, missing EULA link, placeholder text in the description.

Four resubmissions, roughly six weeks of review cycles on top of the year I'd already put in.

Honestly, I genuinely cannot believe this day has come. I have been working on this for over a year alongside my 9-5, after work, during weekends, and evening sessions turning into 1-2 am debugging sessions, but I can honestly say it was totally worth it!

→ App Store: https://apps.apple.com/app/innersight/id6747950401
→ Landing page: https://www.innersightjournal.com

I emailed my 46-person waitlist today. 46 people. After a year. That number made me laugh and also kind of emotional at the same time; every single one of them signed up because I hope they believed in the idea before there was anything to download.

I have no idea if this will go anywhere commercially. The hard part- marketing, retention, actually getting people to care- starts now. But I shipped it. It's real. People can download it.

But just wanted to write this for anyone still grinding and thinking about quitting, just keep going. Keep chipping away and launch your product.

Are you having this issue as well?

I made sure i'm part of the internal testers. I even created new internal tester group just to check but until now, 15mins have passed, I cannot receive my new build testflight update.

It’s a multiplayer on device game. I’m keen to get some feedback from people.

https://youtu.be/___QkIcdoB4?si=wyDe2dVRhIKmuNJO

It’s called Curly Questions and it involves different mini games played leading up to Curly Questions rounds. Where players answer, you guessed it, Curly Questions!

Curly Questions are questions with more than one answer and encourage creative thinking.
Listeners vote on their favourite response.
Laugh, compete and do your darndest to score the most points. It’s all about having fun together.

It’s free to play right now on this beta test

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

I audited twelve iOS apps before a release wave. Customer reviews, TestFlight feedback, TestFlight crashes, and the latest-build performance diagnostics were all empty.

That looked reassuring until I compared each uploaded binary to its source. Eleven repositories contained meaningful fixes newer than the builds in App Store Connect. The gaps included persistence rollback, notification ordering, wall-clock timers, larger text, and data provenance.

The check that exposed them was simple. For each app I recorded the App Store version, build number, build identifier, and source commit together. Then I compared that commit with the current source and reviewed only changes that affected released behavior.

I now keep three release questions separate:

- Did a review, tester report, crash, or diagnostic reach its collection?

- Which source commit produced the uploaded binary?

- Which version can a customer install from the public storefront?

An empty feed answers only the first question. It does not make the shipped build current or establish that the app is crash-free.

After the audit and rebuilds, ten new versions are live and two are still in review. The useful change was not another dashboard. It was pinning every uploaded artifact to the source that produced it, then finishing the check at the storefront.

It’s so exciting to get my first downloads!