Separate availability from search position.
First open the app’s direct store link in the intended storefront context. Record whether the listing opens and whether the product is available there. An unavailable app and a live app that is hard to find require different investigations.
Apple’s availability-status reference explains country and region status indicators. Use the recorded status rather than treating an approved submission as proof that every market is live.
Reproduce the observation precisely.
Save the query, storefront, date and device context. Search the current published name and record the results you actually see. Do not turn one missing observation into a claim that the app has disappeared everywhere.
Use consistent rank observations to compare like with like. Record the range inspected; “not observed” is more precise than an invented position.
Confirm the published version.
Check whether the name and metadata on the live page match the version you intended to release. A draft, submission and published listing are different states. Record recent releases or naming changes that could explain a mismatch.
Keep the facts in a change log. Do not promise a universal number of hours for search changes without a current official basis for the specific situation.
Investigate relevance after the availability checks.
If the page is live and the observation is reproducible, examine the query and the actual listing. Exact-name discovery and a competitive category query are different problems. A relevant term is not a guarantee of a particular position.
Use the brand-query guide or the target-keyword guide. Avoid changing several fields at once before identifying which question you are trying to answer.
Escalate a documented discrepancy.
If status and observed availability conflict, prepare a concise record for the appropriate platform support channel: app identifier, affected storefront, exact query, dates and screenshots. Keep credentials out of the report.
A reproducible support case is more useful than repeated speculative edits. When the issue is positioning rather than availability, use the evidence to define an iOS ASO review.
