Apps can now have up to 8 public and 15 private pricing plans. Billing flows can be tested during review and on development stores without real charges, and the App Events API now accepts usage "corrections (negative values)" and "decimal values (such as 1.5)".
Each app can now have up to 8 public plans (previously 4) and 15 private plans (previously 10).
Billing flows can be tried during review, on development stores, and on other partners' development stores without incurring real charges.
The API now accepts negative values (adjustments or credits for previously reported usage) and decimal values (such as 1.5). Previously, only integers greater than 0 were allowed.
There are now three ways to test the billing flow without incurring real charges, one for each role.
Reviewers can select an existing plan as-is to test it.No more need to create a dedicated test plan for review.
Install your app on your own development store andsubscribe to any plan for freeto verify the billing flow.
When you mark a plan as "free",other partners and developers can install it on their own development stores and test that plan.
The article explicitly calls out adjusting or crediting event usage you've already reported. Mischarges and refunds can be expressed by sending negative events.
No more rounding up or down to integers — you can design billing units that match actual usage. The article's example is "1.5".
| Item | Before | Now |
|---|---|---|
| Public plan limit | 4 per app | 8 per app |
| Private plan limit | 10 per app | 15 per app |
| Billing tests during app review | Create a separate test-only plan | Not needed Reviewers select an existing plan |
| Your own app on development stores | — (previous behavior not described in the article) | Free Can subscribe on any plan |
| Testing by other partners | — (previous behavior not described in the article) | Available Plans marked free, on each partner's own development store |
| App Events values | Positive integers only | Negative and fractional values allowed(adjustments/credits, e.g. 1.5) |
Plan design flexibility nearly doubles. But a flood of plans becomes noise for merchants choosing one, so decide on your pricing-tier strategy before adding more.
Reviewers can now select an existing plan directly, so the practice of preparing a dedicated plan before submitting for review is no longer necessary. Existing test-only plans are candidates for cleanup.
Publishing a plan as free lets other partners and developers try it on their own development stores. Useful as a channel for beta distribution or agency-facing demos.
The article positions them as adjust / credit against reported usage. Refund and miscount-correction workflows can be expressed in App Events itself, rather than compensating in your own DB.
The changelog post doesn't specify the allowed range for negative and decimal values, rounding behavior, or how offsets against existing events are calculated. Verify these in the App pricing documentation and App Events API referencethe article points to before implementing. Existing submission code that rounds values to integers is a candidate for review.