0Pricing
React Native Academy · บทเรียน

การส่งตรวจสอบและการตอบสนองต่อการปฏิเสธ

อัปโหลดบิลด์ด้วย EAS Submit หรือ Transporter เลือกบิลด์เพื่อตรวจสอบใน App Store Connect และทำความเข้าใจสาเหตุการปฏิเสธที่พบบ่อยรวมถึงวิธีแก้ไข

การส่งตรวจสอบและการตอบสนองต่อการปฏิเสธ เป็นบทเรียน React Native Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน React Native Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส React Native Academy มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

The App Review Process

After you submit your app for review, Apple's App Review team manually and automatically tests it against the App Store Review Guidelines. Review times average 1–3 business days for a first submission and often less for updates. You can check the status in App Store Connect: Waiting for Review, In Review, Ready for Sale, or Rejected. Apple may ask clarifying questions via the Resolution Center before completing the review.

Submitting the Build for Review

With all metadata complete and a build selected, click Add for Review in App Store Connect, then Submit to App Review. Apple checks you answered all legal questions (export compliance, content rights, content rating). Once submitted you receive an email confirmation. The app moves to Waiting for Review — you cannot edit metadata while it is under review, but you can remove the submission and resubmit if you catch a critical issue.

# Alternatively, use EAS Submit to upload AND trigger review:
eas submit --platform ios --latest

# EAS submit options:
# --latest           Use the most recent build
# --id <build-id>    Submit a specific build
# --non-interactive  For CI pipelines

# Check submission status:
eas submission:list --platform ios

Common Rejection Reasons

Understanding common rejection reasons helps you avoid them proactively. The most frequent causes are: crashes during review (test thoroughly before submitting), broken links in the support/privacy URL, misleading screenshots that don't match actual app behavior, missing functionality (the reviewer cannot log in without test credentials), and privacy guideline violations (collecting data without disclosure or user consent).

// Top rejection categories (from Apple data):

// Guideline 2.1 - App Completeness:
//   Crashes, broken links, test content visible in production

// Guideline 4.0 - Design:
//   UI that doesn't match screenshots, placeholder text left in

// Guideline 5.1 - Privacy:
//   Collecting user data without disclosure or tracking without ATT

// Guideline 3.1 - Payments:
//   Selling digital goods outside of Apple's IAP system

// Guideline 1.0 - Objectionable Content:
//   Offensive content, hate speech, graphic violence

The Resolution Center

When your app is rejected, Apple posts the reason in the Resolution Center in App Store Connect. You can reply directly to the reviewer, ask clarifying questions, and provide additional context. If you believe the rejection is incorrect, you can appeal or request a phone call with the App Review team. Resolution Center messages are timestamped — Apple typically responds within 1–2 business days.

// Resolution Center communication tips:

// 1. Read the full rejection message carefully
//    Apple often quotes the specific guideline violated

// 2. Ask clarifying questions if the rejection is vague
//    'Could you clarify which specific screen had the crash?'

// 3. Explain your fix clearly
//    'We have fixed the crash by adding a null check in line 45.
//     The updated build (version 1.0.1) addresses this.'

// 4. Provide a video if the feature is hard to find
//    Attach a screen recording to your reply

Guideline 2.1: App Completeness

Guideline 2.1 rejections mean the reviewer found the app incomplete or non-functional. Common causes include: broken flows the reviewer could not complete, missing test credentials, a feature that works only on specific device models, or a login that fails (perhaps your staging backend is down). Always test the app on a clean device with a fresh account using the exact credentials you provided in the review notes.

// Pre-submission checklist to avoid 2.1:

// 1. Test on a REAL device (not just simulator)
// 2. Create a dedicated review account and TEST IT
//    - Log in fresh (don't use a pre-seeded account)
//    - Complete the sign-up flow from scratch
// 3. Test every tab / navigation path
// 4. Test with a fresh install (no leftover cached state)
// 5. Check that all images, API calls, and links load
// 6. Verify screenshot accuracy matches current app UI

Guideline 5.1: Privacy Violations

Apple enforces privacy guidelines strictly. Guideline 5.1 covers: collecting device data without user consent, using IDFA/device fingerprinting without the ATT (App Tracking Transparency) prompt, missing usage description strings in Info.plist, and not disclosing collected data in the Data Safety section. The ATT framework must be implemented if you track users across apps or websites — calling requestTrackingAuthorization() before any tracking activity.

// App Tracking Transparency (ATT) - required for tracking
import { requestTrackingPermissionsAsync } from 'expo-tracking-transparency';

async function requestTracking() {
  const { status } = await requestTrackingPermissionsAsync();
  if (status === 'granted') {
    // User opted in — enable analytics/ads
    initializeAnalytics();
  } else {
    // User declined — use anonymous/aggregated data only
    initializeAnonymousAnalytics();
  }
}

// Info.plist required:
// NSUserTrackingUsageDescription: 'We use tracking to personalize ads.'

Guideline 3.1: Payment Guidelines

If your app sells digital goods or subscriptions, Apple mandates they go through its In-App Purchase (IAP) system. You cannot link to a web payment flow for digital content that can be used in the app — doing so triggers a Guideline 3.1 rejection. Physical goods (e.g., ordering a pizza), services rendered in-person (e.g., a taxi ride), and business-to-business sales have explicit exemptions. When in doubt, use IAP.

// What requires Apple IAP:
// - Premium features / unlocks
// - Subscriptions to content or services
// - Virtual currency / gems
// - Consumable boosts inside the app

// What does NOT require IAP:
// - Selling physical goods (ecommerce)
// - Services delivered in-person (food delivery, rideshare)
// - B2B enterprise sales
// - Reader apps reading content purchased elsewhere (Reader Rule)
//   e.g., Kindle, Spotify (no in-app upgrade allowed though)

Expedited Review Requests

Apple offers an expedited review process for time-sensitive situations: critical bug fixes, security vulnerabilities discovered in production, or a release tied to a major media event. Submit an expedited review request through the Resolution Center after submitting the build. Provide a business justification — Apple evaluates requests individually and approves a subset. This does not guarantee same-day approval but typically cuts wait time significantly.

// When to request expedited review:
// - Production crash affecting >X% of users
// - Security vulnerability that needs immediate patch
// - Legal deadline (court order, regulation change)
// - Major event launch (Conference release, holiday launch)

// Process:
// App Store Connect > Resolution Center
// > Request Expedited Review
// > Choose: App Update
// > Explain the urgency (2-3 sentences)
// > Submit request

Responding to a Metadata Rejection

Metadata rejections (name, screenshots, description) do not always require a new binary. You can update the metadata and resubmit the same build for review. Fix the specific item called out (e.g., a screenshot showing a feature you removed), update it in App Store Connect, and reply in the Resolution Center explaining what you changed. This can be resolved much faster than issues requiring code changes.

// Metadata rejection workflow:
// 1. Read the specific guideline cited
// 2. Update the metadata in App Store Connect
//    (Screenshots, Description, Keywords, etc.)
// 3. Go to Resolution Center
// 4. Reply with:
//    'We have updated the screenshot for the Home tab to accurately
//     reflect the current app UI. The feature shown (X) is available
//     after sign-in. Please see the updated screenshot attached.'
// 5. Click 'Resubmit for Review' (not a new version submission)

Appealing a Rejection

If you disagree with a rejection, you can formally appeal to the App Review Board. This is appropriate when you believe your app complies with the guidelines and the reviewer made an error. File the appeal through the Resolution Center, citing the specific guideline you believe you comply with and providing evidence. Appeals take longer than just fixing and resubmitting. For borderline cases, consider calling the App Review team — it is a real phone conversation with a reviewer.

// When to appeal vs. fix-and-resubmit:

// Fix and resubmit (faster):
// - Clear violation you can fix in < 1 day
// - Crash reproducible and fixable
// - Missing info you can add easily

// Appeal:
// - You genuinely comply but reviewer misread the app
// - You need a policy exception for your use case
// - Your app is being held to a different standard
//   than similar apps already on the store

// Resolution Center > Reply to Review > Request Appeal

Post-Approval: Phased Release

After approval, instead of releasing to all users immediately, use Phased Release. Apple rolls out the update to a percentage of users over 7 days (1%, 2%, 5%, 10%, 20%, 50%, 100%). You can pause the rollout at any point if crash rates spike. This limits the blast radius of a bug that slipped through testing. Phased release is available for app updates, not first submissions.

// Enable Phased Release in App Store Connect:
// My Apps > Version > Phased Release for Automatic Updates
// Select: Release over 7-day period

// Day 1: 1% of users
// Day 2: 2% of users
// Day 3: 5% of users
// Day 4: 10% of users
// Day 5: 20% of users
// Day 6: 50% of users
// Day 7: 100% of users

// You can manually pause if crash rates rise:
// Version > Phased Release > Pause

Quick Check

Test your understanding of React Native Mobile Development concepts from this lesson.

Lesson Recap

In this lesson you learned: how the App Store review process works and typical timelines, how to use the Resolution Center to respond to and appeal rejections, and how to avoid the most common rejection reasons (2.1 completeness, 5.1 privacy, 3.1 payments). You also saw how to request expedited review and use Phased Release to limit rollout risk. Next up we cover creating a keystore and signing the Android AAB.

คำถามที่พบบ่อย

บทเรียน “การส่งตรวจสอบและการตอบสนองต่อการปฏิเสธ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การส่งตรวจสอบและการตอบสนองต่อการปฏิเสธ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส React Native Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส React Native Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การส่งตรวจสอบและการตอบสนองต่อการปฏิเสธ”

อัปโหลดบิลด์ด้วย EAS Submit หรือ Transporter เลือกบิลด์เพื่อตรวจสอบใน App Store Connect และทำความเข้าใจสาเหตุการปฏิเสธที่พบบ่อยรวมถึงวิธีแก้ไข คุณปฏิบัติ React Native Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน React Native Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน React Native Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การส่งตรวจสอบและการตอบสนองต่อการปฏิเสธ” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน React Native Academy นี้ได้ไหม

ได้ บทเรียน React Native Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การตั้งค่าบัญชี Apple Developer และใบรับรอง
  2. การกำหนดค่าการลงนามด้วย EAS Build
  3. การเตรียมข้อมูลเมตา App Store ใน App Store Connect
  4. การส่งตรวจสอบและการตอบสนองต่อการปฏิเสธ
← กลับไปที่ React Native Academy