Post

Replies

Boosts

Views

Activity

Reply to App Store Rejection Under Guideline 4.2 (Minimum Functionality) – Hybrid Capacitor App With Native iOS Features and External Booking System
The 4.2 note is about what the reviewer experiences, not the plugin list. Right now the core flow (booking and paying) happens inside a RideBits web page, so to the reviewer the app is a browser around someone else’s site. Two changes to try: build the booking form in your own UI so pickup/dropoff, saved addresses, quotes and trip history live in the app, and hand off to RideBits only at the final payment step; then describe it in App Review Notes in plain words (“saves addresses, shows quotes, keeps past trips”) instead of CLGeocoder or CAPBridgeViewController. If you want, send me the project (GitHub link or zip, no keys) and Apple’s message and I’ll run it through a 12-point check, free. No promise of approval; I’m learning what Apple flags on web-wrapped apps.
2w
Reply to Repeated App Review Rejections: Custom-Built VPN App Flagged Under Guideline 4.3(a), Now Guideline 5.6
For 5.6 “features hidden during review”, the usual trigger is the app behaving differently for the reviewer than for real users: server-side feature flags, region or IP checks, account-state gating, or VPN config that only activates for paid accounts. Audit every remote flag and make the review build behave exactly like production, then list every feature with steps and a working test account in App Review notes. For the 4.3(a) part, reply with what is unique in the binary itself (your own Packet Tunnel code, no shared VPN SDK or template), not the UI. If you want, send me the project (GitHub link or zip, no keys) and Apple’s message and I’ll run it through a 12-point check, free. No promise of approval; I’m learning what Apple flags on AI-built apps.
2w
Reply to Four rejections under 4.3(b) — but our app was built to solve the exact problems 4.3(b) targets
Dating is the hardest 4.3(b) category, and the appeal needs to show the difference, not explain it. Your first screenshot and first screen should make “take a selfie today or you’re invisible” obvious within seconds, so the reviewer sees a different product rather than a dating template with a story attached. Keep the appeal to the structural points you listed, one line each, with a screenshot beside each. Don’t resubmit while the appeal is open; that restarts the queue. No guarantee it changes the outcome, but four identical rejections usually mean the reviewer never saw the difference.
2w
Reply to Repeated App Review Rejections Despite Fixes — How Do We Get Specific Feedback?
Which guideline do they keep citing? That decides the fix. Two things that break this loop: (1) reply in the Resolution Center with a numbered list, each line quoting the reviewer’s sentence, then exactly what changed and where to see it in the build, plus a screen recording. Reviewers rotate, and the next one needs the whole history in one place. (2) If it’s 4.2 or 4.3, the problem is usually what the app looks like in the first minute and in the screenshots, not the code; show the difference rather than claim it. Paste the exact rejection text and I’ll map it to concrete changes, free. No promise of approval.
2w
Reply to App Review Board appeal pending – Al-Bayati Academy (Apple ID 6812472129)
4.2.6 is the important one: it means the reviewer believes the app came from a template or app-generation service and wasn’t submitted by the owner of the content. Since the courses are yours, say that explicitly in the Resolution Center reply: name yourself as the provider of the content, say which tool built the app, and link to the academy so they can verify you operate it. For the 4.3 part, make it visibly different from generic course-player apps: your own branding, screenshots of your actual courses, and two sentences in Notes for Review on what is unique. If you paste Apple’s exact message, I’ll map it line by line, free. No promise of approval.
2w
Reply to App through lovable
Copying the URL into App Store Connect won’t work: Apple reviews a native app, not a link. The usual route for a Lovable app is to export the code to GitHub, wrap it with Capacitor (npx cap add ios), and build in the cloud if you don’t have a Mac (Codemagic has a free tier). Two things to get right before submitting, because they’re the most common rejections for wrapped web apps: bundle the site inside the app rather than pointing server.url at your live site (Apple’s 4.2 “minimum functionality”), and add at least one thing a browser can’t do, such as push notifications or camera. Happy to look over your project before you submit, free, no promise of approval. I’m learning what Apple flags on AI-built apps.
2w
Reply to App Store Rejection Under Guideline 4.2 (Minimum Functionality) – Hybrid Capacitor App With Native iOS Features and External Booking System
The 4.2 note is about what the reviewer experiences, not the plugin list. Right now the core flow (booking and paying) happens inside a RideBits web page, so to the reviewer the app is a browser around someone else’s site. Two changes to try: build the booking form in your own UI so pickup/dropoff, saved addresses, quotes and trip history live in the app, and hand off to RideBits only at the final payment step; then describe it in App Review Notes in plain words (“saves addresses, shows quotes, keeps past trips”) instead of CLGeocoder or CAPBridgeViewController. If you want, send me the project (GitHub link or zip, no keys) and Apple’s message and I’ll run it through a 12-point check, free. No promise of approval; I’m learning what Apple flags on web-wrapped apps.
Replies
Boosts
Views
Activity
2w
Reply to Repeated App Review Rejections: Custom-Built VPN App Flagged Under Guideline 4.3(a), Now Guideline 5.6
For 5.6 “features hidden during review”, the usual trigger is the app behaving differently for the reviewer than for real users: server-side feature flags, region or IP checks, account-state gating, or VPN config that only activates for paid accounts. Audit every remote flag and make the review build behave exactly like production, then list every feature with steps and a working test account in App Review notes. For the 4.3(a) part, reply with what is unique in the binary itself (your own Packet Tunnel code, no shared VPN SDK or template), not the UI. If you want, send me the project (GitHub link or zip, no keys) and Apple’s message and I’ll run it through a 12-point check, free. No promise of approval; I’m learning what Apple flags on AI-built apps.
Replies
Boosts
Views
Activity
2w
Reply to Four rejections under 4.3(b) — but our app was built to solve the exact problems 4.3(b) targets
Dating is the hardest 4.3(b) category, and the appeal needs to show the difference, not explain it. Your first screenshot and first screen should make “take a selfie today or you’re invisible” obvious within seconds, so the reviewer sees a different product rather than a dating template with a story attached. Keep the appeal to the structural points you listed, one line each, with a screenshot beside each. Don’t resubmit while the appeal is open; that restarts the queue. No guarantee it changes the outcome, but four identical rejections usually mean the reviewer never saw the difference.
Replies
Boosts
Views
Activity
2w
Reply to Repeated App Review Rejections Despite Fixes — How Do We Get Specific Feedback?
Which guideline do they keep citing? That decides the fix. Two things that break this loop: (1) reply in the Resolution Center with a numbered list, each line quoting the reviewer’s sentence, then exactly what changed and where to see it in the build, plus a screen recording. Reviewers rotate, and the next one needs the whole history in one place. (2) If it’s 4.2 or 4.3, the problem is usually what the app looks like in the first minute and in the screenshots, not the code; show the difference rather than claim it. Paste the exact rejection text and I’ll map it to concrete changes, free. No promise of approval.
Replies
Boosts
Views
Activity
2w
Reply to App Review Board appeal pending – Al-Bayati Academy (Apple ID 6812472129)
4.2.6 is the important one: it means the reviewer believes the app came from a template or app-generation service and wasn’t submitted by the owner of the content. Since the courses are yours, say that explicitly in the Resolution Center reply: name yourself as the provider of the content, say which tool built the app, and link to the academy so they can verify you operate it. For the 4.3 part, make it visibly different from generic course-player apps: your own branding, screenshots of your actual courses, and two sentences in Notes for Review on what is unique. If you paste Apple’s exact message, I’ll map it line by line, free. No promise of approval.
Replies
Boosts
Views
Activity
2w
Reply to App through lovable
Copying the URL into App Store Connect won’t work: Apple reviews a native app, not a link. The usual route for a Lovable app is to export the code to GitHub, wrap it with Capacitor (npx cap add ios), and build in the cloud if you don’t have a Mac (Codemagic has a free tier). Two things to get right before submitting, because they’re the most common rejections for wrapped web apps: bundle the site inside the app rather than pointing server.url at your live site (Apple’s 4.2 “minimum functionality”), and add at least one thing a browser can’t do, such as push notifications or camera. Happy to look over your project before you submit, free, no promise of approval. I’m learning what Apple flags on AI-built apps.
Replies
Boosts
Views
Activity
2w