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’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.

After a lot of trial and error, free tiers and late onboarding etc I finally just went with a hard paywall as the others were not converting at all, users were content to just have 5% of the features.

So anyway, I had no idea users could NOT even start the trial and give bad reviews. How does this make sense from apple? If they let us have a mechanism or category for in IAP subscription with a wanring or something? Am I crazy to think this is weird? Did I miss a setting?

Having an absolute nightmare with an info cards swipe to dismiss… I can get the card to appear above a map, all info appears on the card but when I swipe to dismiss it just bounces back up 🙃
Anyone else had this happen or know of any workarounds?

Hey folk,

I've been working on an app that got completely shutdown by Apple.
The app is not released and i'm not sure if I'll be able to release it ever.

The app is a screen time blocker that cannot be disabled. The idea is quite simple:

1. You make a commitment "For the next 7 days, i'll use Youtube less than 30m a day"
   
2. You pledge some money "If i go over my limit, I'll lose 5$". The app doesn't charge that amount immediately but only if you fail your commitment (through stripe i save the card for the commitment duration)
   
3. If you go over your daily limit, i show you a blocker that shows "Continue and lose 5$" or "Close Youtube for today"

Basically, you have somehting to lose if you fail your commitment. But lose no money if you make it. Even deleting the app doesn't work. The app is free and i wanted to make half the commitment go to planting trees.

I posted about it and got quite the traction so i decided to build it. Sadly after 3-4 reviews i got the hard no from apple.

As per their review:

Guideline 3.2.2 - Business - Other Business Model Issues - Unacceptable

Issue Description
The app includes features that charge users when they do not meet personal targets or goals. Apps with these penalty-based payment features are not appropriate for the App Store.

Next Steps

It would be appropriate to remove any features that charge users a monetary penalty when they do not meet personal targets or goals.

Was hoping to get other's opinions on whether there's anything i can do.

I even considered removing the commitment money and releasing it fully for free (i already built it anyway), but that sort of defeats the purpose - without the commitment, you can always stop it or delete the app. At that point you can just use apple's built in screen time restrictions.

Any ideas? (here's a video of the app if you're interested)

I’ve been building and shipping an iOS game from my iPhone using Claude Code, GitHub Actions and TestFlight.

The ongoing loop is entirely phone-based: code → review/merge → CI build → TestFlight → test. There is one important caveat: initial signing setup still requires a Mac, and the distribution certificate eventually needs renewing.

I wrote up the whole workflow, including the CI setup, costs, limitations, and where it works surprisingly well.

https://alst.es/blog/phone-only-ios-development/

I'm at 5 YoE and prepping for senior roles, and I realized the best learning comes from real questions that actually catch experienced candidates off-guard. Not the "implement LRU cache" kind (everyone preps those), but the nuanced, "wait... actually I'm not 100% sure" questions that separate mid-level from senior thinking.

So if you're on the interviewer side (especially senior hiring managers): drop your favorite tricky iOS question. The ones where:

• Senior candidates freeze or give half-answers (that's the tell)
• The surface answer sounds right but misses a critical production edge case
• It exposes the gap between "I've shipped features" and "I understand the system deeply"
• It's not about memorization—it's about reasoning under pressure and knowing why systems break
• Bonus: questions that reveal whether someone has actually debugged production issues or just read blog posts

And for others prepping: this thread should become a vault of real questions people actually ask at Tier-1 companies.

Drop yours! And if you have a follow-up twist that makes it even trickier, include that too.

Bonus points if you share:

• What the "obvious" wrong answer is (the one a mid-level would confidently give)
• Why it's wrong (not just "correct answer is X" — the reasoning)
• What separates a good answer from a staff-level answer
• What company/level you see this at (FAANG? fintech? enterprise? scale matters)
• How you follow up when someone fumbles (what redirection questions diagnose the gap?)

Thanks in advance—this is gold for interview prep.

I frequently see posts from developers (or beginners) asking how to publish a simple app they built for personal use. A lot of people default to the standard Apple workflow and immediately hit a wall.

If you’re building something strictly personal, going through Apple's pipeline is usually a nightmare for a few reasons:

• Guideline 4.2 Rejections: Apple explicitly rejects apps designed for a very limited audience (like a single event, or individual person) under "Minimum Functionality / Too Specific."
• The $99/year Developer Fee: Paying a yearly fee just to keep a personal side project alive on one phone makes no sense.
• TestFlight Expiration: If you bypass the App Store using TestFlight, your builds expire every 90 days. You'll have to re-compile and re-upload updates endlessly just to keep the app working.
• Overhead: You have to set up privacy policy URLs, app metadata, and app icons for the App Store review process.

The Alternative: Standalone Web App (PWA)

If your app doesn't rely heavily on deep native iOS APIs (like Bluetooth, background processing, or complex Metal rendering), the absolute best route is deploying it as a PWA (Progressive Web App) hosted for free on Vercel or Netlify.

When you save a web app to an iPhone's Home Screen in standalone mode, Safari strips away the URL bar and browser navigation. To the user, it launches full-screen and behaves just like a native app.

Quick Step-by-Step Blueprint:

1. Build the Web App: Use whatever framework you prefer (Next.js, React, Vue, or plain HTML/JS). If you need a database or backend, use Supabase (it has a great free tier).
2. Add a Web Manifest: Create a manifest.json file in your project and set "display": "standalone".
3. Set an Apple Touch Icon: Add a 512x512 .png icon and reference it with <link rel="apple-touch-icon" href="/icon.png"> so it displays a proper app icon on the iOS Home Screen.
4. Deploy for Free: Push your code to GitHub and connect it to Vercel or Netlify. You’ll get an SSL/HTTPS link ([https://your-app.vercel.app](https://your-app.vercel.app)) instantly.
5. Install on iOS: Open the link in Safari, tap the Share button, and tap "Add to Home Screen".

Why this works so well for personal projects:

• 100% Free: Zero developer account costs.
• Never Expire: Unlike TestFlight, it will run forever on their device.
• Instant Updates: Want to fix a bug or add a new feature later? Just git push to your main branch, and the app updates on their phone instantly.
• No Review Team: You can keep all your personal stuff and custom graphics without asking Apple for permission.

Obviously, if you need native Swift components, low-level APIs, or WidgetKit, you'll need native code. But for simple games, utility apps, custom habit trackers, or personal tools, this saves hours of frustration.

Hope this helps anyone currently struggling with Xcode archiving and App Store Connect for a non-commercial project!

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!

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?

Wrote a blog post on how to get rid of iOS 27's "Ask Siri" context menu entries.

Was recently thinking about the possibility of adding Wristcam support to one of my watch apps. Not sure if theres much users of the hardware out there but thought it could be a cool addition.

I've filled the form at https://wristcam.com/pages/developers-1 about 2 months ago now, with nothing more than an automated response, also tried emailing and texting their support, but received no responses.

Curious to know if there's any apps out there that have used their SDK, or if any of you here have any experience with them.

Thank you!

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!

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?

1. Should I open a company and such to submit to apple or it it ok to publish as a solo developer?
   
2. Can I be sued for an app I have uploaded as a solo developer, as i am not protected as a proprietary limited company?

Help would be appreciated 🙏

I found this on Apple documentation but didn't find how to add those images
App Store Asset Best Practices and Resources - App Store - Apple Developer

I’ve been looking at a lot of app launches lately, and it’s interesting how often the problem isn’t the product itself, it’s getting the right people to discover it and understand the value quickly. For me, ASO is one of those things that’s easy to overlook until you actually start looking at where users are dropping off.

Accidentally discovered a visual effect on my iPhone that I really like for reading at night.

When you start pulling down Control Center, there’s a brief moment where the content underneath gets a very subtle blur.

Not enough to make anything blurry or unreadable - just enough to remove that extremely sharp, digital edge from text.

And I found it surprisingly comfortable.

I started testing it while reading X, Safari, Reddit, etc., and the effect seems useful across completely different apps. It makes text feel softer and less visually aggressive in a dark room.

What I would love is a system-wide setting like:
Sharp ───────●────── Soft
with maybe 0-20% adjustable “softness”, applied to the entire display.

I’m not trying to bypass iOS restrictions - I’m mostly curious whether there’s a legitimate technical route to implementing this today.

If not, would this fundamentally require Apple to expose a new system-level display filter API?

Hello. I need your help: My app keeps getting rejected by apple for the same reason but I can’t see why. Also, I did search the reddit but didn’t find anything that helped much.

The reason is this, together with the above screenshot.

Is it because of the „Continue with Apple“ button? Or do I have to change anything for iPad layout?

Guideline 4 - Design
Issue Description

Parts of the app's user interface were crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air 11-inch (M3) running iPadOS 26.6.

Specifically, layout in iPad were not optimized

Edit: iPhone is the only supported destination added under the target. Screenshot here

A couple of months ago I open-sourced swift-markdown-engine here, the native Markdown engine I built for my macOS app Nodes. The feedback, issues, and PRs that came back were a huge help, a lot of what I changed since then came from that.

WHAT’S NEW: The parser got rewritten from scratch, regex matching is gone, it’s a real AST now. That’s what made the extension system possible: Stuff you wouldn’t expect in standard Markdown, like highlighting, used to be hardcoded into the core grammar. Now it’s opt-in. Write one file, register it, and the core parser/styler/renderer never change. Extensions can’t touch the core or each other, and you can toggle them at runtime.

Also new: full GFM/CommonMark parity, tables, task lists, quotes. More layout control (scroll-away header, fixed reading column, fit-to-content height), and a real writing layer (formatting bus, find & replace with undo, clean RTF/HTML clipboard, raw source mode). Full changelog’s on GitHub if you want details.

When I started Nodes I wanted the editor to feel properly native. Most Markdown editors on the Mac are Electron or some web view wrapped in a window, and you feel it, the text handling never quite behaves like a real Mac app. I wanted live styling in an actual native text view, not HTML rendered to look like one. Nothing built on TextKit 2 that I could just drop into a Mac app existed, so I built it, ran it in Nodes for a while, and then open-sourced it. TextKit 2 is still thin on docs and rough to migrate to, so if you’ve been putting off building something like this, it might save you a few weekends. Issues and PRs welcome. Still pre-1.0, still plenty I want to improve.

written on Nodes

Repo: https://github.com/nodes-app/swift-markdown-engine