From Permissions to Subscriptions: A Transparent, Restrained, and Reversible Implementation Checklist for iOS Review
Centered on iOS App Store submission review, from permission requests, privacy policies, and subscription payments to troubleshooting rejections, this provides concrete practices and conditions under the principles of transparency, restraint, and reversibility, helping developers understand the review's value judgments and prepare a verifiable path.
1. This is not submitting an App; it is submitting a "trust contract"
When many people prepare an iOS App for submission for the first time, they instinctively think: "The code runs, the icons are set, the Bundle ID is created correctly, just click Submit and it's done." I have seen too many teams get stuck at the review stage—not because the features were not built, but because they simply did not understand what Apple's review team looks at every day. They are not looking for bugs; they are verifying whether you truly respect users, respect platform rules, and respect the privacy bottom line. This is essentially a
two-way trust contract
: you promise not to abuse permissions, not to induce clicks, not to hide logic, and not to bypass system mechanisms; Apple, in turn, promises you eligibility to enter the world's most stringent but also highest-quality distribution channel.
The text of this contract is the App Store Review Guidelines. But note that it is not an operation manual; it is a system of value judgments. For example, the guidelines say "Apps should not contain confusing UI elements." On the surface this is a design specification, but at a deeper level it is Apple's absolute defense of "user autonomy"—any behavior that makes users mistakenly think they tapped A but triggers B counts as a violation. Another example is "must not use non-public APIs." The logic behind this is not technical lockdown, but preventing developers from bypassing Apple's unified control over security, performance, and battery management. So a failed review is never "Apple changed the rules again"; it is a divergence between your value consensus and Apple's.
I have participated in the submission process for more than a dozen Apps across different categories, from utility apps to social apps to enterprise internal apps, and I have found an iron rule:
Review pass rates have almost nothing to do with code quality, but are strongly correlated with "the honesty of the user journey"
. So-called honesty means whether, at every step from the user first seeing the App Store page to installing, launching, authorizing, using, and exiting, all information is consistent, predictable, and free of hidden actions. For example, you write "supports offline notes" in the App Store description, but on first launch you force users to log in to iCloud before they can create a new page—this is a typical dishonesty. The user expects "available offline," but you deliver "available only after login." The gap in between is a breeding ground for review rejection.
Although the keywords do not include them, the core words that actually run through the entire process are only three:
transparent, restrained, reversible
. Transparent means all permission requests, data collection, and payment logic must be clearly disclosed before user action; restrained means not requesting unnecessary permissions (for example, a flashlight App requesting contacts), not piling on irrelevant features (for example, a calculator App forcing in an ad SDK), and not creating false urgency (for example, "only 3 spots left"); reversible means users can withdraw authorization, turn off tracking, and delete their accounts at any time, and the operation path must not be buried five levels deep in menus. These three points are not techniques; they are principles that should be engraved into your product DNA at the moment you submit.
Many developers treat review as a "technical hurdle" and spend a lot of time researching how to bypass screenshot detection, how to fake test accounts, and how to keep reviewers from seeing sensitive pages. This is a directional mistake. Apple's review team members each look at hundreds of Apps per day on average. They will not read your Swift code line by line, but they will quickly scan with a highly structured checklist: Are permission pop-ups abrupt? Is the subscription entry hidden deep in settings? Is the privacy policy link 404? Does payment jump to an external webpage? These are all concrete indicators of "honesty." The more you try to "slip through," the more likely you are to expose a flaw in some detail—for example, you disabled ad ID tracking in the test build but forgot to disable it in the production build, and the reviewer triggers a "tracking not declared" error as soon as they test it.
So stop asking "how can I get through review quickly"; ask "is there any step in my App that makes users feel deceived?" The answer to this question determines whether your first submission receives "2.1 App Completeness" or "5.1.1 Data Collection and Storage."
2. Permission Requests: Not "I Can Ask For It," but "I Must Use It"
The iOS permission system is the area where reviews most often hit pitfalls, but the vast majority of problems are not technical implementation errors; they are mismatches between product logic and permission demands. Apple does not oppose your requesting permissions such as photos, location, and notifications, but it requires you to prove:
this permission is an indispensable part of the current user task, and the user can immediately understand why it should be granted
. Let us look at several real cases.
A certain image editing App popped up a photo library permission request on the launch screen, with the reason "to make it convenient for you to quickly import photos." This directly triggered a review rejection. Why? Because the user has just opened the App, has not tapped any button, and does not even know whether this is an editor or a wallpaper generator, yet you are asking to access all photos—this violates the "minimum necessary" principle. The correct approach is: after the user taps the "Import from Photo Library" button, then pop up the permission request, and clearly state the purpose in the pop-up copy: "Access to the photo library is needed to import the photos you select for editing." The key difference here is:
permission requests must be tied to a specific user action, and the copy must point to an immediate, visible operation result
Here is another more hidden pitfall: a certain sports tracking App continuously obtains location in the background to calculate step count. The review was rejected on the grounds of "background location use not declared." The developer felt wronged: "Health Apps are allowed to use background location in the first place!" The problem was that the privacy policy document only said "used to record exercise routes" and did not mention "continuous background collection." Apple's logic is clear: foreground location is an explicit behavior when the user actively starts exercising, while background location is an implicit behavior that the system continuously runs when the user is unaware, and the two must be declared separately, with background use requiring separate user confirmation. We later added an independent pop-up on the App's first launch: "Allow continuous step counting in the background? This will help you accurately count all-day activity even when the screen is locked," and updated the privacy policy at the same time. Two weeks later, it passed in one go.
Notification permissions are likewise full of traps. Many Apps immediately pop up a notification authorization request after the user successfully registers, with the copy "Turn on notifications so you don't miss important messages." This is a typical vague statement. Apple requires notification purposes to be specific to scenarios, for example: "Turn on notifications, and when your order status updates, we will promptly remind you." More critically,
An equal-rights option of "do not enable" must be provided
. We once had an e-commerce app that popped up a notification request at the last step of the registration flow, with only two buttons below: "Allow" and "Remind Me Later." "Remind Me Later" was actually a skip, but users could not find a path to "Never Allow." The reviewer pointed out that this constituted inducement—users either had to accept or be repeatedly disturbed. The solution was to change it to three buttons: "Allow," "Skip for Now," and "Don't Ask Again," and after "Don't Ask Again," automatically jump to the system notification settings page to teach users how to turn it off manually.
Here is a hard-won lesson:
The copy of all permission pop-ups must pass the "three-second test"
—users glance at it and within three seconds can answer three questions: What permission am I giving? What will happen after I give it? What functionality will I lose if I don't give it? If the answer is vague (such as "enhance experience"), abstract (such as "optimize service"), or threatening (such as "this app cannot be used unless enabled"), it will basically be rejected. We have an internal checklist that we verify item by item before every submission:
Permission Type | Qualified Copy Example | Common Unqualified Wording | Risk Level |
Photos | "Access photos to import the pictures you select for editing" | "Access photos to enhance image processing capabilities" | ⚠️⚠️⚠️ |
Location | "Get current location to show nearby stores" | "Get location to provide personalized services" | ⚠️⚠️⚠️ |
Notifications | "Send a push reminder when the order ships" | "Enable notifications to enjoy better service" | ⚠️⚠️ |
Microphone | "Microphone access is needed to record voice notes" | "Voice features require microphone permission" | ⚠️ |
Tip: Starting from iOS 17, the system limits the frequency of permission requests. If a user rejects a certain permission twice in a row, the third request will be blocked by the system. This means you can no longer rely on "trying a few more times" to increase the pass rate; you must ensure that the first request is precise, necessary, and understandable.
There is another easily overlooked point:
The timing of permission requests must match the user's mental model
. For example, for a fitness app, it is reasonable to request motion sensor permission after the user clicks the "Start Training" button; but if it is requested on the "My Profile" page, it seems abrupt. We did an AB test: for the same app, Group A requested all permissions uniformly after the user completed onboarding, while Group B requested them step by step by functional module. As a result, Group B's first-submission pass rate was 37% higher, and users' subsequent permission grant rate increased by 22%. The reason is simple: step-by-step requests make users feel "I am controlling the pace," while batch requests create a feeling of "being forced."
Finally, let me emphasize a technical detail:
Permission status checks must be done upfront, rather than only catching exceptions when calling the API
. For example, for photo library permission, you cannot wait until
PHPhotoLibrary.shared().performChanges
to discover
PHAuthorizationStatus.denied
, but should first call
PHPhotoLibrary.authorizationStatus(for: .photo)
to check the status before the user clicks the "Import" button. If it has already been denied, you should directly guide the user to the settings page rather than popping up a dialog to try again—the latter will be regarded as harassment.
3. Privacy Policy: Not a Legal Document, but a User Manual
Many developers treat the privacy policy as a "fill-in-the-blank" exercise to satisfy review, copying and pasting templates and piling up vague statements such as "we may collect..." and "we may use it for..." This precisely hits the most sensitive nerve of Apple's review. Apple does not require you to write like a lawyer's letter, but it does require you to write like a
manual that users can understand, verify, and act on
. Reviewers will compare word by word your privacy policy, the actual behavior in the app, and the privacy information form (Privacy Manifest) filled out in App Store Connect; the three must match perfectly.
Let me start with a hard-learned lesson: an education app wrote in its privacy policy, "We collect device identifiers to prevent fraudulent orders," but in the App Store Connect privacy information table, it checked "Device Identifier" without filling in the specific purpose field. The review was rejected on the grounds that "the privacy information table does not fully declare the purpose of the data." This looks like a filling oversight, but it is actually a break in the product logic—if you cannot even clearly explain why you collect device IDs, why should users trust you?
The correct approach is:
The privacy policy must use a minimalist "verb + object + purpose" structure
. For example:
❌ "We may collect your location information"
✅ "We obtain your real-time location in order to display nearby learning centers on the map"
❌ "We use advertising identifiers for personalized advertising"
✅ "We use the advertising identifier (IDFA) solely to show you course recommendation ads related to your learning interests"
More critically,
every declared data collection behavior must be intuitively verifiable or switchable off by users within the app
. For example, if you write "collect clipboard content to provide quick translation," then users must be able to find a "clipboard access switch" in settings, and after turning it off, the translation feature should degrade to manual input mode rather than simply crash. We had a utility app that was rejected three times because of its "clipboard monitoring" feature. The first time, we only mentioned it in the privacy policy and provided no switch; the second time, we added a switch, but the feature was completely unusable after it was turned off; the third time, we refactored the logic: after the clipboard is turned off, long-pressing text still shows the "Translate" menu item, but tapping it prompts "Please enable clipboard permission to enable quick translation, or manually copy the text into the translation box," along with a one-tap button to jump to the settings page. That time it passed.
The App Store Connect privacy information table (Privacy Manifest) is a hard threshold added in recent years. It requires you to declare all data types, collection purposes, whether they are used for tracking, and whether they are shared with third parties in a structured way. There is a fatal misconception here: developers often interpret "whether used for tracking" as "whether advertising is done," but Apple's definition of "tracking" is much broader—
any data transmission that identifies users across apps or websites and associates their behavior counts as tracking
. For example, if your app integrates a certain data analytics SDK that sends user IDs and behavior events to a server, and that server also provides services for other apps, this constitutes tracking. Even if you do not do advertising, you must check "Yes" and declare the purpose.
We once had an enterprise internal app that was rejected because it integrated a general-purpose analytics SDK. That SDK uploads basic information such as device model, system version, and network type by default. We wrote "used to optimize app performance" in the privacy policy, but omitted the "device model" item in the privacy information table. The reviewer used a network packet capture tool to catch the SDK uploading
device_model=iPhone14,2
, and since the table did not declare it, it would be directly judged as "undisclosed data collection." The solution is not to delete the SDK, but to: 1) clearly list all fields and purposes in the privacy policy; 2) check each item in the privacy information table; 3) add a configuration switch for the SDK, allowing administrators to turn off device information upload in the backend.
Note: after iOS 14.5, the ATT (App Tracking Transparency) framework became mandatory. But many developers only show the popup on first launch and ignore it afterward. Apple requires that the ATT popup be triggered when the user has a clear intent, such as after tapping a "View Personalized Recommendations" button, rather than popping up immediately on launch. Our tests found that the ATT popup's user authorization rate is strongly correlated with trigger timing: popping it up after the user completes registration gave an authorization rate of 18%; popping it up after the user taps "Discover New Courses" gave an authorization rate of 41%; popping it up after the user actively turns on the "Personalized Recommendations" switch gave an authorization rate of 63%.
Finally, let me share a practical technique:
use the "reverse verification method" to self-check your privacy policy
. Print out the full text of your privacy policy, then compare it sentence by sentence against the app's actual behavior:
Does each sentence correspond to a real feature?
Is each feature really collecting the declared data?
Is each piece of data really being used for the declared purpose?
Can users turn off that data collection in settings?
After it is turned off, does the feature degrade as declared rather than become unusable?
As long as even one point is not satisfied, it is an audit risk point. Our team now enforces a mandatory requirement: before a PR is merged, a non-developer member (such as a product manager) must take the privacy policy and walk through all paths against the test build, taking screenshots for the record. This is more effective than any automated check.
4. Subscriptions and payments: Apple is not a tax collector but a gatekeeper of transactions
In-app purchase (IAP) review is another high-frequency minefield, but the root cause is often not the technical implementation but a misalignment between business logic and Apple's rules. Apple does not object to you making money, but it firmly opposes "blurring the boundaries of transactions"—that is, making users unable to tell whether they are buying a digital service or being redirected to an external website to buy physical goods. This directly leads to rejection on the grounds of "directing users to bypass App Store payment."
The key word here is "directing." The following behaviors will all be judged as disguised directing:
There is also a big pitfall in subscription design:
The "cancellation mechanism" for the free trial period must have zero obstacles
. Apple requires that users be able to cancel at any time during the trial period, and that after cancellation the service continues until the end of the trial period without incurring any charge. But many apps hide the cancellation entry in a five-level path like "Settings → Account → Subscription Management → Find this App → Tap Cancel → Confirm." Reviewers will simulate user operations, and if the cancellation steps exceed three, it will most likely be rejected. Our solution is: add a "Manage Subscription" button in a fixed bar at the top of the subscription page; tapping it jumps directly to the system subscription management page (
) and pre-fills the App ID. This way the user only needs to tap "Cancel Subscription" once on the system page.
Another commonly overlooked point is
the reasonableness of price tiers
. Apple does not set specific prices, but it requires that the price gradient match user expectations. For example, a certain utility app offers three subscriptions: monthly ¥30, yearly ¥299, and lifetime ¥499. On the surface the yearly plan is cheaper than the monthly plan, but when converted, the yearly plan equals ¥24.9/month, and the lifetime plan equals ¥41.6/month—the lifetime plan is nearly 70% more expensive than the yearly plan, which violates the common sense that "long-term payment should be more favorable." Reviewers will ask: "Why would a user choose the lifetime plan?" In the end we adjusted it to: monthly ¥30, yearly ¥240 (¥20/month), lifetime ¥399 (equivalent to ¥33/month, but with all future features included). After the adjustment it passed on the first try.
The technical implementation of IAP also has hard requirements. The most common mistake is:
Failure to correctly handle renewal status changes
. For example, the user turns off auto-renewal in the App Store, but the app still shows "Membership valid until December 31, 2025." Apple requires the app to respond in real time to
SKPaymentTransactionObserver
the
updatedTransactions
callback and to update the UI on
SKPaymentTransactionState.restored
or
SKPaymentTransactionState.failed
. We once had an app that cached the local expiration time, so after the user canceled the renewal it still showed as valid, and it was rejected on the grounds of "failure to accurately reflect the user's subscription status."
Tip: when testing IAP in the sandbox environment, you must cover all exceptional scenarios. We established a standard test checklist: 1) kill the app immediately after a successful purchase, restart and verify the status; 2) interrupt the network during purchase, restart and verify whether it recovers; 3) the user turns off renewal in the App Store, wait 24 hours and verify whether the in-app status is synchronized; 4) purchase with a Family Sharing account and verify the permission inheritance between the primary account and the sub-account. Miss one test item, and problems may appear after launch.
Finally, let me emphasize a business ethics issue:
"Subscription traps" are the red line among red lines
. For example, a certain bookkeeping app has "Enable annual subscription" checked by default when the user registers, and after the user unchecks it the button text changes to "Remind me later," which actually skips rather than cancels. Or a certain news app shows a pop-up after the user reads the 5th article: "Become a member to unlock all content," while the small print at the bottom of the page says "Auto-renews after activation, ¥18 per month." These designs all exploit users' attention blind spots, and Apple's review team has zero tolerance for them. Our principle is: all paid entry points must have a clear price label, a clear statement of the billing cycle, and a clear cancellation method, and must not be checked by default when first presented.
5. The troubleshooting chain after a review rejection: from logs to scenario reproduction
When you receive a review rejection email, your first reaction should not be "Apple is messing around again," but rather to launch a standardized
four-layer troubleshooting chain
. The process our team has summarized is: log layer → behavior layer → documentation layer → scenario layer. Skipping any one of these layers can lead to repeated submission failures.
Layer One: Log Layer — Capture the real behavior the reviewer sees
Apple's rejection emails usually say "Tested on iOS 16.4 on iPhone 13," but they won't tell you the specific operation path. At this point, you must use the same device, the same system version, and the same test account to fully reproduce the reviewer's operations. We use Xcode's Devices and Simulators window to connect to a real device, enable Console logs, and filter for
appstore
and
skpayment
keywords. Focus on three types of logs: 1) when a permission request is triggered, the
PHAuthorizationStatus
changes; 2) during the IAP payment process, the
SKPaymentTransactionState
flow; 3) in network requests, the
NSAllowsArbitraryLoads
warnings. Once, the rejection reason was "undeclared network requests." We checked the logs and found that a certain third-party SDK was secretly sending HTTP requests (non-HTTPS) during initialization, while we thought it only used HTTPS. The logs clearly showed
[SDK] Network request to failed due to NSAppTransportSecurity
Layer Two: Behavior Layer — Verify the completeness of all interaction paths
Many rejections stem from "edge paths not covered." For example, the reviewer tested "placing an order in guest mode," while your IAP logic only triggers in the logged-in state; or they tested "opening the app directly from the App Store page," while your launch logic assumes the user must go through the welcome page. Our current approach is: create a "review path matrix table," with user identity on the horizontal axis (new user/returning user/guest/family sharing) and entry scenario on the vertical axis (opened by tapping in App Store/opened by tapping a notification/opened via Spotlight search/opened by tapping a Widget), and annotate at each intersection all permission requests, IAP triggers, and network request behaviors under that path. Before submission, the testers must verify each item one by one according to the matrix.
Layer Three: Documentation Layer — Three-table unified verification
Pull out the three documents in App Store Connect and place them side by side: 1) the App Store page copy; 2) the Privacy Manifest; 3) the in-app privacy policy PDF. Use Excel VLOOKUP to compare: does the "cloud sync" mentioned in the App Store copy declare the "iCloud container" in the privacy manifest? Does the "analyzing user behavior" written in the privacy policy have "diagnostic data" checked in the privacy manifest? We once found a rookie mistake: the App Store copy said "supports iCloud sync," but the privacy manifest missed checking iCloud, while the privacy policy PDF said "we use iCloud to store your notes." The three were inconsistent, and it was rejected outright.
Layer Four: Scenario Layer — Walk through the user journey again from the reviewer's perspective
This is the most critical step. Put on headphones, start screen recording, and pretend you are the reviewer:
Don't look at any development documentation; start only from the App Store page;
Open the app, don't tap any onboarding prompts, and directly try the core features;
When each permission popup appears, tap "Don't Allow" and see whether the app crashes or loses functionality;
On the IAP page, after tapping "Purchase," immediately switch to the background and then switch back, and see whether the state is correct;
Turn off all permissions in Settings, then open the app again, and see whether there are any unhandled exceptions.
We had a social app that was rejected for "unable to complete the registration process." It passed under conventional testing, but when we walked through it again from the reviewer's perspective, we found that: when the user taps "Skip avatar setup" on the registration page, the app silently calls
PHPhotoLibrary.shared().performChanges
to try to read the photo album — this is to generate a default avatar, but at this point the user has not granted photo album permission at all. The logs reported an error
PHAuthorizationStatus.notDetermined
, and the app had no try-catch, causing the registration process to freeze. The fix was simple: when skipping the avatar, directly use the system default avatar and don't touch the photo album API.
Note: The Apple review team sometimes uses special test accounts, and services such as iCloud, Apple Pay, and Family Sharing on that account may be in an abnormal state. If you suspect it is an environment issue, you can create a "review-only build" in TestFlight in App Store Connect and note in the Notes: "All third-party SDKs are disabled in this build, and only core features are retained, for verifying the basic flow." We have used this trick to resolve three "irreproducible rejections."
The entire troubleshooting process takes an average of 4-8 hours, but it is far more efficient than blindly making changes and resubmitting (which usually means waiting another 2-3 days for review). Our team has now solidified this chain into a Checklist, executed by a dedicated person before each submission, and the pass rate has increased from 62% to 91%.
6. Those details that reviewers will not say explicitly but that determine success or failure
In addition to matters explicitly prohibited by the rules, there are also some "unwritten rule"-level details. They are not written in the guidelines, yet they genuinely affect review results. These details often determine whether you "pass on the first try" or "get rejected repeatedly." I have compiled the six most commonly overlooked points, all extracted from real cases.
First, screenshot quality is the first impression
Screenshots on the App Store page are not decoration; they are the primary basis for reviewers to assess the authenticity of the App. We once had an App rejected because the screenshots showed a "WeChat Login" button, and the reason was "WeChat SDK not integrated." In fact, the button was only a UI placeholder, but the reviewer saw the screenshot and concluded that you provided that feature. Solution: all screenshots must 100% reflect the real interface of the currently submitted version. If a feature is still under development, do not show it in the screenshots; if a button is displayed only under specific conditions (such as the user having already linked WeChat), do not capture that state in the screenshots. A stricter approach is: use Xcode's View Hierarchy debugger to confirm that every pixel in the screenshots comes from the current build version, not from a design PSD.
Second, the test account must be "clean" and "usable."
Review emails often say "please provide a test account," but many people provide an account with either the wrong password, insufficient permissions, or a linked payment method that prevents the reviewer from testing IAP. The correct approach is: create a dedicated test account, set the password to
Test123456
(simple and easy to remember), preload a test credit card in the account (a virtual card number can be generated in the Apple Developer backend), and ensure that the account has never logged in to iCloud or Game Center. We also found a detail: the Apple ID email suffix of the test account must be
@icloud.com
. Using Gmail or QQ Mail sometimes triggers additional verification and delays the review.
Third, the "small print" in metadata is a minefield.
Reviewers scan places such as the App name, subtitle, and keywords word by word. For example, an App's subtitle said "free download, no in-app purchases," but it actually had IAP, so it was directly rejected. Another example is keyword stuffing with "WeChat, Alipay, Douyin"; even if the App does not integrate them, it will be questioned as misleading. Our current approach is: all metadata copy is reviewed by legal colleagues using the "understandable by an elementary school student" standard—remove all modifiers and keep only the subject, predicate, and object. For example, change "ultra-fast, HD, intelligent video editing tool" to "video editing App."
Fourth, zero tolerance for crash logs.
In the Crash Reports tab in Xcode Organizer, any report with a crash rate exceeding 0.1% may become a reason for review rejection. Apple does not require you to be 100% crash-free, but it requires you to prove that you have located and fixed high-frequency crashes. We had a utility App that was rejected because
EXC_BAD_ACCESS (SIGSEGV)
the crash rate was 0.3%. Investigation found that a third-party library released an object that was not retained on iOS 17.2. The solution is not to wait for the library to update, but to use
@try/@catch
to wrap the call, report custom logs on crash, and fall back to backup logic at the same time. When submitting, state in Review Notes: "Fixed the crash caused by the XX library under iOS 17.2; see Crash Report ID XXX for details."
Fifth, the "About Us" page must be real and verifiable
The email, website, and phone number in the App's "Settings → About → Contact Us" must be real and valid. We once had an App rejected because the contact email reply timed out (>48 hours). Apple will send a test email to that email address. If there is no reply, or the reply content is unrelated to the App, it will be judged as "unable to contact the developer." Now we use Zapier to automatically forward all emails sent to that email address to the team Slack channel, and set up a bot to automatically reply: "Your message has been received, and a human will reply within 24 hours."
Sixth, Review Notes are a bonus
Many people treat Review Notes as an optional field, but it is actually your only communication window with the reviewer. Good Notes can greatly reduce review costs. The format is: 1) separate sections with emoji (⚠️ indicates risk points, ✅ indicates verified); 2) order by the reviewer's concerns (permissions → IAP → privacy → crashes); 3) for each item, state "what was done + why it was done + how it was verified." For example:
✅ 相册权限：仅在用户点击“导入照片”按钮后请求，文案为“访问相册以导入您选择的照片进行编辑”。已在iOS 16.4/17.2真机验证。
⚠️ ATT弹窗：仅在用户点击“个性化推荐”开关后触发，非启动时弹出。已用TestFlight邀请审核员验证。
We have calculated that submissions with detailed Notes have an average review time shortened by 38%, and the resubmission rate decreased by 52%.
These details may seem trivial, but they are exactly what constitutes the "last mile" to passing review. Rules are the skeleton, details are the flesh and blood, and the fullness of the flesh and blood determines whether the reviewer sees you as "a developer who does things seriously" or "an opportunist who goes through the motions."