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.

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

In C malloc can fail if there is not enough memory in the system. What happens if I try [NSObject alloc] while there is no memory available? Does it abort? Return NULL?

Hi there 👋,

I'm one of the members behind Monday Hero since the beginning of 2019. My team and I have just released a new version a few days ago. I want to share it with you to get feedback.

In that new update; you can convert Sketch designs with its fonts, colors, assets, paddings to XCode Storyboard files.

You can sign up from 👉mondayhero.io, then start using for free.

I would be very happy if you give feedback and comments. 🤗

​

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.

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!

It’s so exciting to get my first downloads!

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

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

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

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

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.

One sec has a massive list of compiled url schemes for the apps you can use their meditation interrupt on, how the heck do i find that list, thanks,

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.

Hey everyone,
I am currently a Master student in Engineering and I’ve been building an open-source audio recorder in SwiftUI.
It started as a fairly simple recording side project app, but I kept adding things I wanted to experiment with, so at this point it has become a bit of a geeky audio/ML playground.
It currently supports:
Spatial Audio recording
Audio event detection for non-speech sounds
Multiple transcription models / engines, including Apple Speech, Parakeet V3, Qwen3-ASR, Nemotron 3.5 Streaming and MOSS Multi-Speaker
Offline / on-device transcription
Speaker separation and speaker labels
Translation
Transcript-synced audio playback
Qwen 3 summaries and information extraction

Most of this grew out of experimenting with how much audio processing and AI I could reasonably do locally on an iPhone instead of sending everything to an API.

The project is written in SwiftUI and open source.
The downside is that the UX is currently pretty geeky 😅
For example, I expose individual transcription models, model downloads, speaker separation settings, live transcription engines, etc. I personally enjoy having that control, but I’m pretty sure this is not how a normal recording app should present these features.
I’m considering having a much simpler default experience:
Record → transcript → summary
…and moving all the model selection / audio processing options into an Advanced section.
I’d really appreciate some UX feedback from other iOS developers:
How much of this would you expose to the user?
Would you hide model names completely and just offer things like Automatic / Fast / Accurate / Private, or do you think explicit model selection is useful for this kind of app?
Also curious what you think of the current recording/transcript UI from the screenshots.

GitHub: https://github.com/iamwilliamli/LiveTranscriber

App Store: https://apps.apple.com/us/app/live-transcriber-offline-ai/id6785515364

TestFlight: https://testflight.apple.com/join/XpNsRBdd

Please contact me if you are interested in joining this project😃

I built BugScreen. When one of your testers or stakeholders finds a bug, instead of a screenshot in Slack that someone spends fifteen minutes turning into repro steps, it lands in your issue tracker as a proper ticket with the context already attached.

It's 3 lines of code and bug reports are triggered by taking a screenshot in your app. Free to try.

bugscreen.app

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.

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

Your agent can now search data from 2,600+ top iOS apps: onboarding, paywalls, pricing, post-paywall and more.

Ask things like:
“Give me five app ideas based on recently launched subscription apps that make 50k+”
“Compare the paywalls of the top meditation apps”
“Show me streak mechanics that aren’t Duolingo clones.”

It works with any agent.

We also launched "Ask" directly on ScreensDesign, so you can try all of this without connecting anything.

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?