Three of the five numbers people repeat about shipping on iOS are not in Apple's documentation.

Is there a 150 USD minimum before Apple pays you?

No. The page that would say so says something else entirely. Apple keeps one reference for this, in App Store Connect Help under Reference and then Reporting, titled Minimum payment threshold. It opens by saying that before payment can be sent to your bank, your account must meet the minimum payment threshold, and then prints a table of thresholds by bank country or region and bank account currency. Read on 17 October 2026, that table held 67 rows. Sixty of them were 0.02 USD.

Seven rows sat above two cents, and they are the only entries that amount to a real wait. Colombia at COP 100, Nicaragua at NIO 90, Hong Kong at HKD 27, Uganda at UGX 20, Thailand at THB 10, Sri Lanka at LKR 5 and the Republic of Korea at KRW 1. Apple then gives the fallback in one sentence: all other bank countries or regions and bank account currencies must exceed a minimum payment threshold of 40 USD. So if your banking country is in the table you are almost certainly clearing the threshold on your first sale, and if it is not, your number is 40 USD. The string 150 USD does not occur on the page. Neither does the number 150.

Two details on the neighbouring page matter more than the threshold does. Overview of receiving payments lists exceeding the minimum monthly payment threshold as one of four requirements, and it says for each country or region in which you sell content, which means the test is applied per market and per month rather than to one running total. The same page says that once you meet the requirements, payments are made within 45 days of the last day of the fiscal month in which the transaction was completed. That forty-five day lag is the thing that actually delays your first payment, and no threshold folklore will shorten it.

If you are choosing between store billing and a card processor on the strength of how fast money arrives, read both payout schedules before you decide which payment layer to use. The threshold is a rounding error next to the calendar.

Apple, App Store Connect Help, Minimum payment threshold, read 17 October 2026

Do distribution certificates last three years?

Apple does not publish a validity period for a distribution certificate at all. The Certificates section of Apple Developer Account Help has twelve pages, and I read all of them on 17 October 2026. Certificates overview is the canonical one, and the old developer.apple.com support path for certificates now redirects straight to it, so there is no second reference hiding behind an older URL. It explains the certificate types, says distribution certificates belong to the team rather than to a person, says only the Account Holder or an Admin can create them, and sets out what breaks when one expires or is revoked. It never says how long one lasts.

What Apple does publish is more useful than the figure people quote, because it is specific about which certificate. The page on replacing Developer ID certificates says certificates issued from the current authority are valid for one year and must be renewed annually. Not three years, one year, and only for Developer ID. The Cloud-managed certificates page describes a rotation schedule rather than a lifetime: a new cloud-managed certificate is automatically created 90 days before expiration when new signing requests are received, and manual rotation becomes available once the certificate has less than half of its validity duration left, which Apple puts in brackets as often 180 days. Do the arithmetic on that bracket and you get a validity of roughly a year, which is not three years either.

Two more dates are published, and both get mistaken for certificate lifetimes. Developer ID provisioning profiles generated after 22 February 2017 are valid for 18 years from the creation date, which is a profile and not a certificate. And Apple's own intermediate certificate, the Worldwide Developer Relations one that signs everything you sign, expires on 20 February 2030. That is the only hard expiry date in the whole section, and it belongs to Apple rather than to you.

The practical consequence is a renewal you should budget for rather than a number you should memorise. Signing credentials are a recurring item, like a developer programme membership, and they are exactly the sort of thing that gets forgotten until a release is blocked. Put them on the same list as everything else in what an app costs to maintain, and check the actual expiry date in your developer account rather than counting three years forward from something.

Apple, Developer Account Help, Certificates overview, read 17 October 2026

Does a TestFlight build really stop working after 90 days?

Yes, and this is the one in the set where the documentation agrees with the folklore. App Store Connect Help says it twice on a single page, TestFlight Overview, under Test a beta version. In step two it says you can test a build for up to 90 days. In step seven it says your build becomes unavailable for testers after 90 days. Two statements, same page, same number, so quote it without hedging.

The part worth reading twice is what the clock is attached to. The ninety days belong to the build, not to the tester and not to the group, so your testers, your invitations and your public link all survive an expiry and a new upload brings them back. The same page flags the case that runs the other way: if you do not expire your build and you submit it to the App Store, testers who received an invitation will still be able to test that build after it goes live. A stale beta can therefore sit beside your shipped version until you expire it on purpose.

The 30 device ceiling is real too, and the reason people argue about it is that it is published somewhere else. Apple's TestFlight page says testers can access all available beta builds you have shared with them, on up to 30 devices for comprehensive testing. It is a limit on one tester's devices, and it is separate from the two tester ceilings that App Store Connect Help publishes, which are 100 internal testers who hold a role in your account and up to 10,000 external testers.

I read six TestFlight pages in App Store Connect Help looking for that device figure: TestFlight Overview, Add internal testers, Invite external testers, View and manage tester information, Add testers to builds and the TestFlight tester information reference. It was not on any of them. That is a search that came up empty on six specific pages rather than proof that App Store Connect Help never mentions it, and the distinction is the whole point of this page.

What qualifies an app for an expedited review?

Nothing, in the sense people mean. There is no eligibility test to pass. Apple's Request an expedited review page, in App Review Help under After submitting for review, publishes four things and none of them is a criterion. A service target: App Review works around the clock with the goal of reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. Two examples of extenuating circumstances: fixing a critical bug, or timing your release to coincide with an event. One hard prerequisite, which is procedural rather than qualifying: only submissions that have already been sent to App Review can be expedited. And then a discretionary outcome, in Apple's own words, that App Review will evaluate your request and expedite the app's review as allowed by availability and demand.

No quota appears, and no annual allowance. What appears instead is a warning about behaviour. The help page says expedite requests should be reserved for matters of genuine urgency. The App Review Guidelines, in the After You Submit section, say to seek expedited review only when you truly need it, and that if Apple finds you are abusing the system it may reject your requests going forward. That is a judgement about a pattern, not a counter that resets in January, which is why nobody can tell you how many you get.

The actionable part is what you are told to write. For a critical bug fix, Apple asks you to include that information in the Notes field in App Store Connect when you submit. For an event, include the event, its date and how your app is associated with it. It also says to schedule the release in App Store Connect ahead of time if you can, which quietly removes most of the reasons people ask. If your only problem is that a date is coming, a scheduled release solves it without spending anything.

Worth knowing before you plan a launch around it: the target already assumes most reviews finish inside a day. An expedite is for the case where a day is too long, not for the case where you left the submission late. The ordinary path, including the demo account and the notes that stop a reviewer getting stuck, is set out in publishing to the App Store.

The five claims, and where each one actually lives

Every verdict below names the page it came from, because a verdict without a page is just another thing to repeat. Three of the five figures are not in the documentation. Two are, and one of those two is in a place that explains why the argument keeps happening. If you want to check the payout row yourself, the table is in the Minimum payment threshold reference and takes a minute to read.

How to tell an absence from a gap in your own searching

Saying a rule does not exist is a much bigger claim than saying one does, and the two need different evidence. A presence needs one page. An absence needs every page the thing could reasonably be on, named, so somebody else can check your work. That is why the certificate finding above lists twelve pages and the device finding lists six. If you cannot name the pages you read, you have not found an absence, you have found the limit of your search, and the honest sentence is the second one.

Four habits do most of the work. Start from the first party page and never from a forum answer, because forum answers are where the wrong numbers come from and they outrank the source. Check the URL you landed on, since Apple moves help pages often and the old path can return a page that looks real but is a not found notice; the certificates support path redirecting to Certificates overview is the benign version of that. Search for the exact string, not the idea, because a page that says 0.02 and 40 will never match a search for 150. And print the date you read it, since most of these pages carry no last updated stamp.

The last habit is the uncomfortable one. When the documentation turns out to agree with the thing everyone repeats, say so and move on. The 90 day expiry was going to be the fourth debunking on this page until I read the page, and it is now the strongest claim here precisely because it survived the check. A method that only ever produces surprises is not a method.