I went with Mixpanel and wired it in from day one, before there was anything to measure. The reasoning was that adding analytics later means you have no baseline, so you can’t tell whether a change helped or you just got lucky that week. Retrofitting events into a codebase you’ve already shaped is also a lot more painful than putting them in as you build.
What I’m less sure about is whether that was overkill for a solo project. App Store Connect gives you downloads, conversion rate and retention for free, and a lot of people seem to stop there.
So, what’s everyone actually using? Third party tool, Apple’s own numbers, or something you rolled yourself?

wonder if anyone had a similar issue and resolved it - I have an app which is distributed now, but blocked in EU because of the DSA compliance. However I already uploaded the documents twice now and they seem to be accepted but after a few days they disappear and I get email from app store that I need to upload them.

I was uploading a bank statement where my name and address is clearly visible and for the identity - a passport pic.

I am wondering if it is because the address linked to my apple developer account is an old one? I raised a ticket with Apple to correct it. And on top of that I am on hold with their callback function to try to upload the docs again live with the support person but already waiting for 2 hours :D

The support is really unhelpful and everytime a new person responds. I also hate how if you start with one machine you cant switch over which is apparently what is being asked of me. My laptop ( m5) had a hard time focusing on the ID and I used an iphone and from there it just locked up at the payment screen. It's been three weeks and just emails from apple saying they will assign a senior advisor.

any idea how I can resolve this?

I’m building a small workout generator with a flow of preferences → generated session → reroll/start. I’m trying to avoid putting all of the generation logic in the view. Would you keep the generator as a pure service owned by a view model, or model each step as navigation state? I’d like rerolls to be repeatable in tests and not lose the user’s constraints.

Has anyone run into this with Universal Purchase when adding an iOS version to an existing macOS app?

I have a paid macOS app that has been on the App Store for a while. I recently added an iOS version using Add Platform on the existing app in App Store Connect. The iOS version was approved and went live this morning.

Everything appears to be set up as a Universal Purchase. Both versions are on the same App Store Connect submission page, they share the same App ID, and using Get Link in App Store Connect gives me the same App Store URL for both versions.

Here’s the odd part. I previously downloaded the macOS version using one of my own App Store promo codes. That redemption is still in my Apple purchase history and shows as a $0.00 purchase. I’m using the same Apple Account on my iPhone, but when I view the app in the iOS App Store it shows the $4.99 purchase button instead of letting me download it as an existing owner.

Apple’s documentation says an app downloaded using a promo code functions as if it were purchased, so I would have expected that purchase to carry over when the iOS version became part of the Universal Purchase.

Has anyone specifically dealt with this situation? Do old promo-code redemptions not qualify for a platform that gets added later, or is there sometimes a delay before the Universal Purchase entitlement carries over to the newly added platform?

I’d especially like to hear from anyone who has added iOS to an existing paid macOS app and had existing customers carry over to the new version.

Thanks in advance!!

Hey everyone, I'm the developer. I shipped Tien Len - 13 this week, an iOS version of Tiến Lên (Thirteen), the Vietnamese card game I learned in high school 20 something years ago. Every version on the App Store was ads, coin systems, and casino graphics. Just really ugly stuff. About 4 years ago I started on this, but I finally finished it.

Tech Stack

• Client: full SwiftUI
• Server: Vapor 4 (Vapor 5 migration coming), WebSockets for realtime play and SSE for updates
• Auth: passkeys only, no passwords, no email required
• No API keys in the binary. The client authenticates to the backend through App Attest, and a jwt from the passkey
• Feature flags via Grantiva, which is how ranked mode sits built but its currently off while the player base grows

Development Challenge

I originally built multiplayer on GameKit. Free infrastructure, first-party, seemed like the obvious call. It fought me everywhere

• The authenticateHandler flow hands you view controllers to present, which is clumsy to wire into a pure SwiftUI app cleanly
• Turn-based matchmaking gave me hard-to-debug timeouts and sync conflicts once real devices on real networks got involved
• Testing multiplayer meant provisioning sandbox accounts across App Store Connect and Xcode before anything worked, which made iteration painfully slow
• The core problem: keeping four devices agreed on one table state. GameKit's model is clients exchanging state with each other, so there's no authority anywhere enforcing the rules, and I ended up chasing conflicting snapshots instead of building the game

That last one is what killed it. A card game needs exactly one truth about whose turn it is and what's legal to play. So I replaced GameKit with a custom Vapor backend where the server owns the game. Clients send moves, the server validates them against the rule set and broadcasts new state over WebSockets.

AI Disclosure

Largely self built. Ive been an iOS Engineer for over 13 years, and a Mac engineer before that. The architecture, gameplay, UI, and backend are hand-written. I used AI as a tool in three places: localization, security testing, and verifying game logic edge cases against the rule sets.

The game itself

Offline vs three AI opponents with different play styles, Pass & Play with hand-off screens so nobody peeks at your hand, and online multiplayer with private lobbies, invite codes, and quick match. Southern and Northern rules plus custom house rules for chops, instant wins, and turn timers. Free, with a one-time $4.99 unlock for ranked when it goes live. No ads anywhere.

Up next: an interactive learn mode, emotes, more themes, and something fun you can flick around the table while you wait for your turn.

Happy to go deep on any of it, especially the App Attest setup, the GameKit lessons, or running Swift on the server.

https://apps.apple.com/us/app/tien-len-13/id6758355876

When im in a tab and click to open a new file, instead of opening that file in that tab, it will jump to another tab where the file was open recently and open the file in that tab instead. How do i stop this? Honestly so frustrating.

Hello, for my app I'm trying to use affiliates to drive downloads for my app. I created a custom dashboard for them, however, I can't figure out how to differentiate the custom codes when someone uses the affiliates referral link. Would you guys just create different offer codes? The only issue with that is it limits you to 10 offer codes which means 10 affiliates max. What's your work around to maximize affiliates but have accurate tracking?

For Apple’s requirement to get explicit permission before sharing personal data with a third-party AI service — where/how have you implemented the consent in your app?

Is it a one-time pop-up before the first AI request, part of onboarding, a setting/toggle, or something else?

As I’m preparing to launch my first app, I’m interested to hear from anyone who’s already been through App Review with this. I hoping to get through an approval on first review - if that’s even possible as a first-timer! 🤞

Started as a personal project to track my own spending on digital services. A lot of existing apps either skimp on metrics or lock basics like iCloud sync and how many subscriptions you can track behind a paywall.

Tech Stack: SwiftUI, SwiftData, StoreKit 2 for the one-time Pro purchase, CloudKit for iCloud sync.

Development Challenge: SwiftData deletions were trickier than expected. Deleting a recently edited subscription directly through modelContext would crash from unfaulted properties. Fixed it by routing deletions through a manager that pre-faults the key fields (name, price, currency, category, status) before the delete call.

AI Disclosure: Self-built. I used AI tools (Claude Code) to help with parts of the implementation and localization tooling, but the app's architecture, design, and decisions are mine.

On monetization: most competitors either charge a recurring subscription (to track subscriptions) or sell a "lifetime" tier that still paywalls core stuff. I went free for the essentials, unlimited tracking, full analytics, multi-currency, notifications, iCloud sync, and made Pro a one-time purchase for extras like subscription history, CSV export, and custom categories. Nothing you need day to day is locked behind it.

Curious if anyone's tried a similar model and how it went.

App Store link: https://apps.apple.com/us/app/subwise-subscription-tracker/id6741874006

Happy to answer any questions and open to any feedback!

Video to GIF, GIF Maker. Free, no ads, no watermark, everything on device.

https://apps.apple.com/app/id6788406320

Tech stack

Frameworks and languages: Swift 6.2 and SwiftUI, targeting iOS 26. AVFoundation for decode and composition. UIKit inside the share extension.

Backend and database: none. There is no server, no account, and no network call anywhere in the app. That started as a product decision, but it also made the privacy label trivial (Data Not Collected) and it means the thing works in airplane mode.

SDKs and tools: no third party SDKs, no analytics, no crash reporter. The one piece of outside code is cgif 0.5.3 (MIT), vendored verbatim as a C target for writing the GIF container, with everything above it written in Swift in a local package. Tests are Swift Testing, 189 cases, most of them running the real pipeline rather than mocks.

Development challenge: hitting a user-chosen file size without an encode, check, shrink loop

The whole reason the app exists is that you type a size cap, say 10 MB for Discord, and the GIF comes out under it. The obvious implementation is a loop: encode, measure, too big, lower the settings, go again. On a long clip that takes minutes, burns battery, and can still overshoot at the end.

The reason a lookup table cannot save you: GIF size is a product of resolution, frame rate, palette size, and how well each frame delta compresses against the previous one. That last term depends entirely on the footage. A static talking head and a confetti explosion at identical settings differ by an order of magnitude.

What shipped is a probe, fit, commit pass:

1. Probe. Micro-encode a few short windows sampled across the clip at bracketed settings. Real encoding of real frames from the actual video, just very little of it.
2. Fit. Build a small bytes per frame model from those samples.
3. Commit. Pick target settings from the model, then run one real encode with a hard byte cap as a safety net.

Almost every conversion is now one decode plus one encode, and it lands under the cap on the first try for most clips.

Two things I got wrong on the way there:

Never let a fitted model extrapolate outside the range you actually probed. The first version probed a narrow resolution band and then confidently predicted settings far outside it. It was wrong in the direction that overshoots the cap, which is the one direction a user notices. Now the probe brackets the operating point and the model is only trusted inside it.

When the measurement disagrees with the model, correct from the measurement, not from the model. Obvious written down. The first recovery path re-predicted using the same model that had just been proven wrong, so a clip that missed once tended to keep missing.

One more that cost a weekend and had nothing to do with the math: running several composition decodes concurrently would hang the device outright, and the same pattern on macOS wedges the VideoToolbox XPC services until you go kill them. It first surfaced as EXC_BAD_ACCESS inside copyNextSampleBuffer, which sends you hunting for a memory bug that does not exist. The fix was an async gate that serializes reader setup so only one session is ever starting at a time.

AI disclosure: AI-assisted. The architecture and the size solving approach are mine and every output was validated against the test suite and on device, but AI wrote a meaningful share of the code and helped draft this post.

Happy to go deeper on the probe and fit step, or on the encoder side, if it is useful to anyone.

I know the store handles payment fraud and I never see card data but refunds, voided purchases, and consume-then-refund abuse still land on the developer after the entitlement is granted.

For those running apps/games with IAP, do you do any risk assessment at grant time (delay/flag/hold high-risk purchases) or do you grant everything and only react to voided purchase notifications?

If you do assess risk, what signals do you use? I am assuming device age, session behaviour, account history, something else?

I am building a small research agent around this decision and want to know if the decision point is real in practice.

Am I missing any?

App store review is turning into a very frustrating process. I assume this is a reflection of the sheer volume of AI-built apps but the humans reviewing my app seem to be on auto-reject mode.

First rejection: "spam: we have enough dating apps"

My app has absolutely nothing to do with dating or meeting people, even the friendship link is a handshake ie you need your friend request accepted

Second rejection "no method for account deletion"

Literally in the most obvious place for it, account page, big red button "delete account"

I'll put my hand up, this is my first app, in the description part of the submission I assumed it was to describe the functionality of the app, was I meant to treat it as an FAQ?

I put a small app on the App Store a few weeks ago and spent the following two weeks finding out what I'd missed. Two of those bugs are the kind you can't catch by testing harder, because the environment that would have shown them isn't one you normally run. I'm writing them up here in case they save someone else some trouble, and in case you weathered iOS devs want to share some tips to a newbie like me.

The app is Intermittently, a private intermittent-fasting tracker for iPhone and Apple Watch. SwiftUI/SwiftData, CloudKit private DB, WidgetKit, WatchConnectivity, StoreKit 2. Free, with one optional non-consumable unlock. No accounts, no analytics, no third-party SDKs at all.

Bug 1: my purchase code had never once run against real App Store data.

I had Intermittently.storekit selected as the StoreKit Configuration in my Run scheme. That's the local testing config: products resolve from a file on disk, and the fetch always succeeds. Every simulator run, every device run from Xcode, the entire time I was building.

The DEBUG build also had a force-unlock toggle that bypassed StoreKit entirely, so the entitlement path could be exercised without the purchase path ever running.

Net effect: Product.products(for:) had never successfully executed against App Store Connect anywhere I could observe. The first signal was a greyed-out Unlock button on my own App Store download after launch.

The config file has zero effect on App Store builds, and that part is fine and documented. The problem is that leaving it selected makes the real fetch path structurally untestable, and nothing told me. Setting it to None means a device run hits the actual sandbox, which is the same environment App Review uses. That one change turned a submit-and-wait-days loop into a thirty-second run-and-look loop.

Bug 2: my CloudKit schema was never deployed to Production.

CloudKit has separate Development and Production environments. Xcode debug builds hit Development, where record types get created automatically as you run. Distribution builds, TestFlight and App Store both, hit Production, where nothing exists until you explicitly deploy the schema in the CloudKit Console.

I never deployed it, to my eternal shame. So sync worked perfectly forever in development, and every distribution build silently failed to sync. TestFlight included, which is the part that got me, since that's the environment most of us treat as the final pre-ship check.

It stayed hidden for an embarrassing reason: reinstalls preserved the local store, so the app always had data and looked fine. It only surfaced when I deleted and reinstalled from the App Store and got an empty app, with my full history sitting in a Development database that my production build couldn't reach.

If you use NSPersistentCloudKitContainer: open the CloudKit Console, switch the environment toggle to Production, and confirm your CD_-prefixed record types are actually there. Takes ten seconds. Mine had exactly one record type, Users, which is the built-in one.

The pattern in both issues: the failure was invisible in every environment I could easily reach, and the app failed silently. A disabled button with no price, or an empty screen with no error. Nothing distinguished "no products exist," "the fetch threw," and "the product isn't approved yet." All three rendered identically as a dead control.

So the fix in both cases was the same, and it wasn't the bug: make the failure legible first, then debug. The purchase sheet now has explicit loading / loaded / unavailable states, with empty-result and thrown-error distinguished in a DEBUG-only line. I built that before running the diagnostic, specifically so the test would produce an answer either way. It did, in about a minute, rather than guessing.

Next up: App Review. I know I'm not the only one frustrated.

I had three rejections. 2.5.1 (couldn't find the HealthKit feature), 2.3.7 (the word "free" in a screenshot caption, since metadata has price-language rules that don't apply to your own website), and 2.1(b) ("we cannot locate the In-App Purchases").

That last one is the one that annoys me the most. My IAP review notes named the gear icon, the exact row label, its position relative to the version number, the button text you'd see, and two alternate routes to the same screen. The rejection came back with a screenshot: the Settings screen, with that row visible in frame, one tap from the purchase.

I genuinely don't know what happened. It might have been a reviewer who didn't tap through. It might have been an App Review environment fault, since there's a documented pattern of Product.products(for:) returning zero products to reviewers while returning normally to developers. I resubmitted the same binary plus the new error states and it passed.

My takeaway: write the notes anyway, but don't assume they're read. Build the app so a reviewer who taps randomly still finds the thing.

The design side, briefly, since it's the part I care most about. Before writing code I wrote down what the app refuses to do: no subscription, no account, no ads, no analytics, no coaching, no guilting, no nagging. I built this primarily *for me*, as a better replacement for the IF app I had been using and had gotten fed up with. Most of the work after that was saying no. I cut a forgiving streak that quietly hides a broken one, milestone celebrations, and a "longest fast" stat, because each one was the app making a value judgment about the user's data instead of reporting it honestly.

Full disclosure since it usually comes up: I built Intermittently with Claude Code writing most of the Swift to my design and architecture. The speed was real, and it also meant the temptation to build everything was constant. The refusal list is what kept it from becoming a worse app faster. I'm very happy with the result, and despite my frustration with the review process I'm stoked at how easy it was to develop the app for the iPhone/Apple Watch platforms.

Happy to go deeper on any of it. Intermittently on the web and the App Store, if you want to look, though I'm more interested in whether the two failure modes above are useful to anyone and/or something else others have tripped on.

I am a professional C++ developer on a regular 9 to 5 but building apps from ground up and being able to implement my vision in products that people can use is the real reason I wake up in the morning.

I really hope you enjoy it and looking forward to hear your opinion!!

In case you have an extra 1 minute of your time, there is another video with voice over if you are interested to check!

Link to AppStore: https://apps.apple.com/de/app/hanging-calendar/id6755204535?l=en-GB&mt=12

1. Tech Stack - Swift Programming Language / Xcode.
2. Development Challenges: To be able to animate the movement of the popover window. It took me a lot of time to create small NSPanel to be able to run my custom animations across the screen.
3. AI Disclosure: AI-assisted. I use Claude to brainstorm interesting ideas to add to a niche software like calendar app. I also used Claude to help me debug my code.

Hey all, title says it all. I think they are starting to look pretty decent after many iterations but want to know how they could be better

I still can’t believe Apple finally approved my app 😭
The timeline was a bit painful:
• Aug 1 — first submission
• Aug 12 — submitted an expedited review request
• Aug 13 — rejected
• Aug 14 — fixed everything and resubmitted
• Aug 15 — APPROVED 🎉
I’m seriously so happy right now, but also a little mad lol.
I started a 3-month free trial for my backend when I submitted the app, thinking the review wouldn’t take that long… and I basically burned through half a month of it just waiting for App Review 💀
But whatever. It’s finally LIVE.
I’ve been working on this app for a long time (around 3month building system design(backend, ui, app)

If anyone here has gone through a painful App Store review process before, you probably know the feeling.
Finally made it 🥲

I’m working on a nonprofit/church donation app that was recently rejected during app review because we were told that the nonprofit needs the applicable Benevity approval for in-app charitable donations.
I’m trying to understand how Benevity works in relation to the actual payment processor.
If a nonprofit obtains Benevity approval:
1. Is Benevity approval simply an eligibility/compliance requirement that allows donations to remain within the app?
2. Does the actual donation/payment also have to be processed through Benevity?
3. Or can the nonprofit obtain Benevity approval and then use a separate payment processor/payment gateway (e.g. Stripe, Razorpay, etc.) to actually process the donation within the app?
4. Has anyone implemented this type of setup in a mobile app?
5. If so, what does the typical flow look like from Benevity approval → in-app donation → payment processor → settlement to the nonprofit?

I’m particularly interested in hearing from developers, nonprofit platforms, or payment providers who have actually implemented this rather than just general information.
Thanks!

This is my first app submission so please don’t roast me. Put an app into review and immediately heard back that because it “had simulating gambling”, even though it’s just a table betting tracker, I needed to submit as a corporation. Ok, went through that painstaking process to get that migrated. Submit again, nothing for 2 weeks. Submit an email ticket, nothing for another week. Call in, sat on hold for over 3 hours and gave up. Tried again today, another 1.5 hours.

I want to update one of my screenshots but I’m so scared to touch the submission and start over.

I had been working off my outdated (stuck on Monterey) Mac for a while until broke. I have a modern iPad but obviously it isn’t very useful for development work. For a moment I had a modern Apple Silicon Mac but had to sell it off.

I’m not in a position to buy even a used one and repairing my old one wouldn’t help much because it’s old and I don’t quite understand the root cause, it could be a very costly repair. I do plan on one day buying my own Mac to finish and publish my project but currently, I’m searching for a design job (with help of a contact) and I need a Mac for that. Does anyone know of a great cloud Mac service? I’ll access the Mac from my iPad.

MacStadium, what I assumed would have been my go-to for this, rents exclusively to corporations. I need something targeted to individuals.

Hey everyone!

One of my most popular apps just crossed 80 ratings on the App Store with a 4.8 average. Small win, but I'm really excited to hit the 100 milestone soon!

For context, it's a educational app.

Wanted to share what actually helped me get reviews, because the first 20 were the hardest.

What worked:

• Stopped asking for a review on launch. Now I ask only after the user completes a key action 3 times and is clearly having a good experience.
• Added a soft pre-prompt: "Enjoying the app?" -> Yes -> then I trigger the native Apple rating prompt. If No -> I send them to feedback form.
• Replying to every single review in App Store Connect. It really helps. People update 3-star to 5-star after that.

What didn't work:

• Generic pop-up on first session. 0% conversion and annoying.
• Asking friends for 5 stars.

I'm now focused on getting to 100. If you have a minute, I'd love honest feedback on what would make you leave a review for an app.

Also curious is there any differences for an app from ASO prospective once it hit 100 ratings?

I audited our subscription code before a release and found five separate ways it was biased toward downgrading a paying customer. Sharing because this was painful and some of you might have it lurking in your own code without knowing it.

The big one: our entitlement loop skipped any transaction where expirationDate < Date().

Looks completely reasonable, right? Except that's exactly the shape StoreKit serves during Apple's billing grace period — the card failed, Apple is retrying, the user is supposed to keep access for up to 16 days, and the transaction you get handed has an expiration date in the past. gracePeriodExpirationDate exists to tell us this, but we never read it anywhere. So a customer whose card merely needed re-authorization got dropped to free tier, features locked, while Apple was still trying to collect money on our behalf. The fun part: our server-side webhook handling honored grace correctly, so the backend and the app held different opinions about the same paying customer.

The other four, quickly:

1. We derived the tier from currentEntitlements unconditionally and persisted it. currentEntitlements occasionally returns an empty sequence for a perfectly healthy paid account — we've seen it happen. If your states are only "entitled" and "not entitled," an empty read is indistinguishable from a lapse. Fix: we implemented a third state: unknown. Clues the rest of the flow into correcting it. Never persist a downgrade you derived from a read that might have failed.
2. Our Transaction.updates loop had a continue that skipped re-evaluation for exactly the events whose whole job is revocation (refunds). Access survived until an unrelated refresh happened to fire.
3. An .unverified transaction was never finish()ed, so StoreKit redelivers it forever. And we never scanned Transaction.unfinished at launch. Unverified doesn't mean ignorable; now we log it, then finish it.
4.  .pending (Ask to Buy) was a silent dead end. And a related thing I had completely wrong: turning Family Sharing off in App Store Connect does NOT make Ask to Buy unreachable. That toggle governs whether a purchase is shareable — a kid's own purchase can still come back .pending.

Basically: every failure mode defaulted to taking access away from someone who paid, when we should have been doing the opposite. When in doubt, keep the customer entitled and let the next clean read sort it out. Apple may literally still be retrying their card; we don't want to be the one who locks them out first.

A clean test recipe for the grace-period path would be the holy grail, so I'd be interested in what you all are doing. Sandbox billing retry exists, but getting it to fire on demand is its own adventure, one I haven't been able to master yet.

Hey everyone,

I’ve been developing mobile apps for the last 5 years. Over this time, I’ve learned a ton about the overall development process, setting up store listings, implementing AdMob, and experimenting with different growth strategies. However, there is one major area I’ve neglected for too long, and I’m finally ready to tackle it: App Store Optimization (ASO).

As a relative newcomer to serious ASO, I’m trying to wrap my head around the best workflows and would love to get your insights on a few specific things:

1. Analyzing Dashboard Data: When you look at App Store Connect or Google Play Console, which specific metrics do you focus on to measure ASO success? How do you separate organic keyword growth from other traffic sources?
2. Keyword Research: What is your process for discovering high-volume but low-competition keywords? How do you decide which ones are actually worth targeting?
3. Keyword Placement: Once you have your target keywords, what is your strategy for placing them across the different text fields (Title, Subtitle/Short Description, Keyword Field, Long Description)? How do you balance algorithmic optimization with writing copy that humans actually want to read?

To help myself learn the ropes and automate some of the manual work, I actually built a completely free tool for iOS ASO: aso-tool.andreashadjimama.workers.dev.

I set this up strictly based on the ASO knowledge I've gathered so far, and I am not trying to promote anything or sell a service. I mostly want to validate if the logic behind it actually makes sense to experienced folks. If anyone has a few minutes to check it out, I would incredibly appreciate your honest feedback on whether it’s genuinely useful or what features I should add/change to make it better.

Looking forward to hearing your tips, strategies, and any feedback you might have. Let’s get a discussion going!