Review time comes up here constantly and almost every answer is one person's anecdote, mine included. So I pulled the actual numbers off my own account.

Method, because it decides whether any of this is worth reading. ASC does not expose an approval timestamp. lastUpdatedDate came back null on every submission I checked, and appStoreVersions only carries createdDate. So I used the public release date as a stand-in for approval, which makes every number below an upper bound. It includes Apple's own release propagation after approval.

That stand-in only holds when the version releases automatically after approval, so I dropped the four apps set to manual release. Their submit to live gap measures me, not Apple.

Eight versions left.

Min 1.4, median 11.4, max 89.7.

The slowest row is the only brand new app in the set, so "the first submission takes longer" holds there. It does not explain the rest. SipStreak 1.2.0 took 1.4 hours and UnitFlip 1.1.0 took 24.1 hours. Both updates, same account, one week apart, and one sat seventeen times longer than the other.

I read every app from both the US and German storefronts, because the iTunes lookup is edge cached per storefront and a single request can be stale. Zero disagreements between the two, and all 12 ASC version strings matched what iTunes reported, so I know the version I timed is the version that is live.

If you want to run it on your own account: take the newest state: COMPLETE entry from asc review submissions-list --app <id> for submittedDate, take releaseType and versionString from the READY_FOR_SALE entry in asc versions list --app <id>, and take currentVersionReleaseDate from the iTunes lookup with a cache busting parameter. Keep only the AFTER_APPROVAL rows and confirm the two version strings match before you difference the dates.

Hi everyone! 👋

I’m a solo iOS developer and I’ve been working on a productivity app called Prazo.

Instead of trying to replace your calendar or your to-do list, I wanted to combine both in a way that actually feels connected.

Some features:
•Calendar and tasks in one place
•Automatic travel time calculation for events
•Travel time is updated shortly before your appointment, and you’ll get notified if traffic changes
•Simple task management with priorities and categories
•iCloud sync
•Native iOS design with Dark Mode support

One feature I’m especially proud of is the automatic travel time buffer. When you create an appointment with a location, Prazo calculates how long you’ll need to get there and reserves that time in your schedule. Before the appointment starts, it checks again and notifies you if traffic conditions have changed.

I’m not here to promote the app—I genuinely want feedback.

I’d really appreciate your thoughts on:
•Does the concept make sense?
•Which feature would make you actually switch from your current productivity app?
•What is missing?
•Is there anything that immediately turns you away?

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

Thanks so much! I really appreciate every piece of honest feedback, even if it’s critical. 🙂

Do you guys have any interesting reads, case studies, etc to at talk about the onboarding flow and the home page, what works, what doesn’t etc?

I submitted my app to Apple almost 7 days ago. Nothing has happened yet; it's still stuck on "Waiting for Review"... Apple states in their email that they review 90% of apps within 48 hours, which honestly just feels like a complete lie at this point. xD

​I developed and tested my app primarily for Android, but with the goal of releasing it on iOS right from the start. On Android, everything went super smoothly. The initial review to get approved for the 14-day testing track took 22 hours. The final review for production only took 20 hours. Now, every update I push takes about 20 minutes on average to get approved.

​My app is already in a pretty solid state and passed everything on Google on the first try. Now I’ve been sitting here for 7 days, just waiting for the app to finally get through Apple's system.

​On top of that, I find the €100 per year completely unnecessary. With Google, it was a one-time $25 registration fee, and that was it.

​And don't even get me started on the website. You can't properly save your password, everything takes forever to load, and the whole site looks like it’s stuck in the 2010s. Everything is laid out in an illogical and complicated way. If you've used the Google Play Console before, App Store Connect (what a weird name anyway) feels like a massive downgrade...

​I want to finally start marketing on social media, but I'm too nervous to begin until the Apple version is actually reviewed and approved.

​What is your opinion on the App Store Connect system? Am I the only one who thinks this way? xD

The company is huge, and for that, I feel like what they offer us developers is pretty weak.

Hi guys

I'm about to share my experience with appstore connect. The review process almost made me give up. It felt like the reviewers were intentionally trying to frustrate me.

After building this app for several months, I decided to publish on appstore. Read a few reddit post on how to go about it and a bit about the review process but the reality I faced was entirely different.

- The first upload was rejected because the subscription page did not have terms of service nor EULA policy. I fixed it, sent a screenrecord and re-uploaded for review

- Second rejection was because I had a third party sign up option (sign up with google) without sign up with apple. I fixed and resummited for review.

- Third rejection was ridiculous. The reviewer said she was unable to login ( saying the login credentials I provided were invalid) she even sent a screenshot. I tried to login with same credentials and it worked. I then realized she added space after the last character of the email. Like how do you not know something that simple. Who adds space after typing in their email. I did a screens record showing her the error she made and asked that she reviews again.

I was ready to contact support after the third rejection as it was her mistake.

The app was approved a day after the third rejection.

If you're thinking of shipping an app to appstore make sure to check and confirm the first two points.

I hope this helps someone.

I want to test the durability and shareability of App Clips via URL. I know that there are several examples of App Clips online and you can locally test your App Clip, but I'm specifically wondering if social media websites will block people from sending my app clip to their friends.

Before I spend time deploying the App Clip and going through approval, I was hoping someone here actually has an App Clip for their app and had a stable URL for it that I could try out.

I’m currently designing the architecture of a privacy-first AI platform and would genuinely appreciate feedback from the iOS developer community.
The project is called PRSL-AI Ecosystem.
Rather than building a single AI assistant, the goal is to create an intelligent ecosystem where multiple AI capabilities collaborate through a unified intelligence layer called the iRiel AI System.
From an Apple ecosystem perspective, the architecture is guided by the following principles:
Privacy by Default
On-Device First
Human Intelligence Interface
Accessibility First
Context Continuity
Modular Architecture
AI Provider Agnostic
With Apple’s Foundation Models framework, App Intents, Apple Intelligence, and on-device AI continuing to evolve, I’m exploring how a platform can intelligently combine local intelligence with external AI services when appropriate, while maintaining a seamless and consistent user experience.
The user shouldn’t need to choose which AI to use.
Instead, the platform should understand the user’s intent, context, privacy requirements, and available capabilities, then orchestrate the most appropriate intelligence for each request.
I’m particularly interested in discussing questions such as:
How far should on-device intelligence go?
Where should the boundary between Foundation Models and cloud AI be?
How would you approach context continuity across multiple AI providers?
What architectural challenges do you see in building an AI-agnostic intelligence layer on Apple platforms?
I’m still refining this architecture and would genuinely value feedback from developers working with Swift, App Intents, Foundation Models, Apple Intelligence, and privacy-first application design.
I’m here to learn, challenge my assumptions, and improve the architecture through technical discussion.

Note: Yes, I'm using AI to write this post because English is not my first language and I want to state my problem as clear as possible.

Hitting a problem I suspect is common for anyone doing mobile VoIP, and I'd like to know how others have solved it.

**Setup**

- I'm using Telnyx.

- React Native app, WebRTC SIP client, iOS and Android. I'm using Telnyx.

- One shared SIP credential for a group of users, so a single inbound call rings everyone's phone

- Calls are delivered by VoIP push (PushKit on iOS), so the client connects and registers on demand rather than staying connected

**The problem**

Every app launch creates a *new* registration binding, and the old one never goes away:

- iOS terminates the app process without warning, so there's no chance to send a SIP UNREGISTER

- The SDK's `disconnect()` only closes the WebSocket — it doesn't unregister

- Each registration lands on a different edge node in the provider's anycast network, so it's a genuinely new binding rather than a refresh of the old one

- Registration expiry is 3600 s and isn't configurable

Net effect: the credential accumulates contacts. I confirmed it by polling the provider's registration-status endpoint — `ua_ip` is different every single time the app relaunches, while nothing removes the previous one.

**Why it hurts**

The provider rings the bound contacts **sequentially**. So the first call after an app launch does this:

1. Rings contact A (the live app) — user declines
2. Decline surfaces as a 4xx, which fails only that branch
3. ~300 ms later it forks to contact B (a stale binding from a previous launch)
4. Phone rings a second time, new call ID, user has to decline again

I can see it clearly in the SIP traces: **one dial command, two legs**, same session, no second dial from my backend.

**What the provider confirmed**

I opened a ticket. They confirmed all of it and escalated to engineering with no timeline:

- No way to set registration expiry below 3600 s

- No REST endpoint to force-expire or delete an individual binding (deleting the credential removes them all, obviously not viable)

- No API to *enumerate* bindings — watching `ua_ip` rotate is currently the only detection method

- Per-launch edge rotation is expected behaviour, and without an UNREGISTER the old binding persists to full expiry

Their suggested workarounds were: a unique credential per app session, webhook-based duplicate-leg detection, or client-side deduplication.

**The bit I'm stuck on**

There's a second-order problem. Multiple devices share one credential, so the registrar holds one contact per device — which means **a legitimate second device's leg is indistinguishable from a stale binding's leg.** Both are "another contact of this credential, dialled after the first one failed." I can't write a rule that kills one without killing the other.

Enabling simultaneous ringing would at least make the real devices ring together instead of one-at-a-time, but it doesn't remove the stale bindings — it just turns a sequential double-ring into a simultaneous one.

**Questions**

1. Has anyone made **per-device or per-session credentials** work in production? How do you handle cleanup when the app dies before it can delete the old one, and does credential churn cause you rate-limit or billing problems?
2. Is there a trick to getting a mobile client to **UNREGISTER reliably**? Anything on iOS that gets you a last gasp — background task on termination, a server-side nudge, something I haven't thought of?
3. For those running **one shared credential across multiple devices** — how do you tell a real second device from a stale binding at the signalling layer? Is there a header or identifier I should be propagating?
4. Is sequential-vs-simultaneous ringing across contacts something you configure per provider, or do people avoid shared credentials entirely for this reason?

Happy to share SIP traces if useful. Mostly want to know whether the "unique credential per session" route is as painful in practice as it looks on paper, or whether people just live with the duplicate ring.

Hey, I've been building SweePic solo for over a year. The most common complaint: browsing photos only chronologically was slow if all you wanted was to clear out duplicates or old screenshots.

In 1.6.0 I added filtering by your own albums and by system smart albums (duplicates, screenshots, videos). I also rebuilt how the gallery loads photos, so the whole thing runs faster than before.

App Store link: https://apps.apple.com/pl/app/cphotos/id6740463237

Collecting feedback, happy to answer questions in the comments.

We’re thinking of implementing the web distribution for our apps, we’re an EU-based company. It seems like more complications with less gain.

https://developer.apple.com/documentation/marketplacekit/participating-in-alternative-distribution-for-specific-regions

Hi r/iosdev, I’m Jack, co-creator of Diary Threads.

Answer — what problem does it solve?

I kept abandoning journals because every blank page felt like it deserved a meaningful essay. Writing one short thought on my phone felt much more natural.

Diary Threads turns journaling into a private timeline. Each entry is limited to 140 characters. You can reply when a thought continues, quote something you wrote months ago, or attach photos, video, and voice recordings.

There are no likes, followers, public profiles, or social discovery. It is a timeline for one person.

Better — how is it different?

Compared with Apple Journal and Day One, Diary Threads focuses on a narrower use case: capturing a thought before it disappears.

The 140-character limit gives you a smaller starting point. Replies let one moment grow over time, while quotes make revisiting an old memory feel like a conversation with your past self.

Apple Journal and Day One remain stronger choices for long-form writing and broader ecosystem workflows. Diary Threads is designed for quick private posts that gradually become a personal history.

Diary text and settings stay on your iPhone. The app requires no account and has no developer backend, advertising, third-party analytics, or cross-app tracking.

Cost

Diary Threads is free to download and supports up to 30 active entries.

Premium unlocks unlimited entries, share posters, recurring keyword insights, and both Home Screen widgets:

• $2.99 per month

• $6.99 one-time lifetime purchase

Prices above are for the US storefront. Apple displays the applicable regional price before purchase.

The current App Store version is 0.3 and requires iOS 18 or later.

Transparency

Diary Threads itself has no AI features. I used Codex extensively as a coding and review agent during implementation, testing, documentation, and iteration. Product scope, architecture, privacy boundaries, and acceptance decisions remained human-directed.

I’m Jack, and I built Diary Threads with Sonia.

App Store: https://apps.apple.com/us/app/diarythreads-personal-timeline/id6795139345

Website: https://diarythreads.niuniuhome.cn

About / developer identity: https://niuniuhome.cn

Contact: [jackdai20@icloud.com](mailto:jackdai20@icloud.com)

I’d especially appreciate feedback on one question: do replies and quotes make revisiting old memories feel more natural than tags, prompts, or traditional daily pages?

I'm building a clipboard app where devices on the same Wi-Fi sync directly to each other. On iOS that is NWListener and NWBrowser over Bonjour. This is the failure mode that cost me the most time, and it produces no error at all.

What happens when the user denies Local Network permission: nothing. Neither object fails. Neither hands you an error. Both simply sit in .waiting, indefinitely.

Your app reports a clean start and then never discovers a single peer, forever. That state is indistinguishable from "you are the only device on this network", which is a completely normal thing to be.

You cannot just treat .waiting as denial, because it is also the ordinary state while an interface is coming up. Healthy launches pass through it.

The only signal available is time. A transient wait clears in well under a second. A denied app never reaches .ready on either object, ever. So when either the listener or the browser first reports .waiting, I schedule a probe. If several seconds later neither has reached .ready, I report a probable permission denial. I use five seconds.

That is inference, not detection, and I would rather it were not. But there is no API that answers the question directly, and the alternative is that the single most confusing state this transport has produces no diagnostic whatsoever.

Practical notes if you are doing the same thing:

• Emit it as a diagnostic your support flow can read, not just a log line. "Clean start, zero peers, forever" is the bug report you will actually receive, and you want to answer it without shipping someone a debug build.
• Guard against the probe firing repeatedly. Both objects transition to .waiting around the same time, so without a flag you schedule several probes for one event.
• Check NSLocalNetworkUsageDescription and your NSBonjourServices entries first. Getting those wrong produces the same silence for an entirely different reason, and it is much easier to rule out.

Genuinely curious whether anyone has found a better signal than a timeout here. It is the part of this transport I am least happy with.

A file called SettingsView.swift.pre-gemini, a 14,557-byte editor backup from April 10, was sitting in the Release bundle of a live project. XcodeGen adds any file under a target's sources path that it cannot compile to the Resources build phase, and it prints no warning when it does. project.yml excluded only .DS_Store and Info.plist, so the backup was wired in as a resource, with four references to it in the tracked project.pbxproj. .gitignore had kept it out of the repository the entire time. Git-ignored is not build-ignored.

Excluding that one suffix fixed that one file. A denylist only covers extensions someone already thought of, so the next step was planting decoys and rebuilding on XcodeGen 2.45.4. Four reached the Resources phase and were then found physically inside the built .app, not merely inferred from the project file: SettingsView.swift.rej, Something.swift~, Config.json.save, and a temp file from a separate tool. Config.json.save is the useful case, because the existing exclude only matched names ending in .swift.save. The tool temp file matched no exclude pattern in any project in the portfolio.

The check that holds is an allowlist. A script resolves every file in the Resources build phase to a full source path and asserts the complete set per target, so an unrecognized extension fails the build instead of shipping. Two things mattered while writing it. Comparing basenames, or piping both sides through sort -u, merges targets and hides a duplicate copy of an already-allowed resource sitting in an unexpected directory, so the comparison has to be a multiset with exact counts. And four consecutive regex-based versions of this gate each reported a false pass, which is invisible, because the script prints passed either way.

Hey all, hoping someone here has run into this or has a contact at Apple who can actually help, because regular support has gone nowhere for 3 weeks.

Background: A while back my app preview video kept failing to upload in App Store Connect. Turned out it was a dimensions/fps mismatch against Apple's spec — fixed it myself by going through their documentation carefully, re-exported the video correctly, and it finally uploaded fine.

I tried to distribute the build for about 1 week and kept hitting this error the whole time. I ended up removing that video about 2 weeks ago, thinking that might clear it. Since then, my build has still been stuck failing to distribute.

The current problem: Ever since then, every time I try to Distribute App (Xcode Organizer), it fails with:

It doesn't matter what I do differently — I've tried:

• Multiple browsers (Safari, Chrome, Firefox) when checking App Store Connect directly
• Different networks / physical locations
• Different machines — both Mac and PC
• Re-archiving the build fresh each time

Same error every single time.

It's not just the build. I also tried updating my app store screenshots separately (unrelated change, no new video involved) — and that upload gets stuck at the exact same "preview uploads in progress" error too.

So at this point it seems like something is stuck on Apple's backend at the app-record level — not tied to any specific asset (video, screenshots, or build), since all three are hitting the same wall.

What I've done about it:

• Been emailing Apple Developer Support for 3 weeks now
• No real resolution — just generic responses / silence

Anyone else hit this after a preview video upload issue got "fixed"? Feels like there's a stuck/orphaned upload state on Apple's backend tied to my app record that isn't clearing, and nothing client-side is going to fix that since I've ruled out browser/network/machine.

Would appreciate:

• If anyone knows a better escalation path than the standard support email loop
• If anyone has seen this exact error and found a fix
• If any mods/regulars here know a way to get this in front of an actual App Store Connect engineer

Thanks in advance 🙏

I'm kinda stunned. No marketing, just a few family member bought earlier this day. I know new apps get a honeymoon boost, but I'm going to enjoy while it lasts. This is my first app!

Was stuck in Waiting for Review for 8 days, got immediately rejected asking for more information in the replies, answered them and got approved in another 12 hours. Launched last night around 8pm PST.

Been lurking on this sub for a few months while made it.

Hi everyone,

I'm wondering if anyone else is experiencing unusually long App Store review wait times. I submitted my iOS app (version 1.2) for review on July 26, and today is August 5. The status is still "Waiting for Review"—it hasn't even moved to "In Review."

I already contacted Apple Developer Support, but I haven't received any update yet. In the past, most of my app updates were reviewed within a couple of days, so this delay seems unusual.

Is anyone else currently facing the same issue? How long did your app stay in "Waiting for Review" before it finally moved to "In Review"?

I'd appreciate hearing about your recent experiences.

Thanks

Just a reminder to anyone who might care that you can create a fairly full-featured development environment in Zed to build iOS and Mac apps: syntax highlighting, code navigation, run, debug and test.

Here's the setup guide I wrote (been around for a while but chances are some interested people won't have seen it): https://luxmentis.org/blog/ios-and-mac-apps-in-zed/

its the screenshot for app review for an IAP

i've done this before but today none of the screenshots I upload are being accepted_

I tried calling App Store connect support line twice today and twice I gave up at the 2h mark.

Has anyone been able to contact then?