Which guideline covers a shopping cart?

None of them cover the cart itself. The word cart appears exactly once in the whole document, inside the phrase a la carte in the subscriptions section, and the words shopping, checkout and basket appear zero times. Counted on 23 October 2026. What the guidelines govern is the sale: 3.1.3(e) for physical goods and for services consumed outside the app, and 3.1.1 for anything that unlocks features or content inside the app. The screen where someone changes a quantity is yours to design.

What does Apple document about storing a cart between sessions?

Nothing, in the document that can get you rejected. There is no clause in the App Store Review Guidelines about carts, saved baskets or abandoned checkouts, and no requirement either way about whether a cart survives the app closing. So the decision is an engineering one. In an Expo project the local stores Expo documents on its Store data page are expo-secure-store, expo-file-system, expo-sqlite and Async Storage. That page carries its own last updated date of 3 June 2026 and was read on 23 October 2026.

Should the cart live on the device or on the server?

Keep a copy on the device so the app opens with the basket still in it, and let the server own price, stock and tax. Expo describes Async Storage as unencrypted, persistent key-value storage that suits app state, and expo-sqlite as a database that is persisted across restarts of your app. Neither description promises anything about a reinstall, and the Store data page does not use the word reinstall at all, so do not treat the phone as the record of a sale. Re-price the basket when the checkout screen opens.

What if the same cart has a physical item and a digital one?

Then it has two payment paths, and Apple's gift card paragraph is the clearest illustration. Guideline 3.1.1 says digital gift cards, certificates, vouchers and coupons redeemable for digital goods or services can only be sold in your app using in-app purchase, while physical gift cards sold within an app and then mailed to customers may use payment methods other than in-app purchase. One product, two rules, decided by whether it goes in an envelope. Most shops handle this by keeping the digital items in a separate flow instead of one combined total.

I sell classes, not objects. Which rule applies?

It depends on how many people are in the room. Guideline 3.1.3(d) lets a real-time person-to-person service between two individuals use a purchase method other than in-app purchase, and gives tutoring, medical consultations, real estate tours and fitness training as examples. The next sentence says one-to-few and one-to-many real-time services must use in-app purchase. A one to one session and a group class are the same product to you and different products to App Review, so price and plumb them separately.

Can a builder submit the finished shop to the App Store for me?

No, and you should be wary of one that offers. Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, and that these services should not submit apps on behalf of their clients. A builder can write the project, sign it and upload the build. Pressing submit is yours, because the shop and its content are yours.

Articles · How-To GuidesUpdated October 2026

If you sell physical goods, Apple forbids in-app purchase for them.

Q: Does Apple allow a third-party payment processor for a shop?

Yes. For physical goods and for services consumed outside the app, Apple requires a purchase method other than in-app purchase, and the two examples it gives in 3.1.3(e) are Apple Pay and traditional credit card entry. Card entry means a processor, so a card processor is the normal answer. Apple does not name individual companies in that clause. If you offer Apple Pay as well, guideline 4.9 requires you to provide all material purchase information to the user before the sale and to use Apple Pay branding and interface elements correctly.

That is the sentence most people have backwards, and it is the one that decides how you build a cart. Guideline 3.1.3(e) of the App Store Review Guidelines is headed Goods and Services Outside of the App, and it says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. No commission on the order, and no StoreKit in the checkout. Read on 23 October 2026, from guidelines that carry their own last updated date of 16 October 2026.

The second thing worth knowing is what Apple does not say. There is no rule about carts at all. The word cart appears once in the entire document, in the phrase a la carte, and shopping, checkout and basket appear nowhere. So the basket, the quantity stepper and whether the cart is still there tomorrow morning are all yours. If you have not built anything yet, start at make an app and come back to the cart once a screen exists.

Start here

The short version

A cart is three lists and one argument about payment.

The three lists are easy. What is in the basket, what each line costs, and what the whole thing costs with shipping and tax. A shop assistant could describe them. Any app builder can put them on a screen in an afternoon, and the quantity stepper is the least interesting code in the project.

The argument is the payment, and what you sell settles it. Your own preference does not come into it. Sell a jumper and Apple requires you to take the money outside in-app purchase. Sell a downloadable pattern for that jumper and Apple requires in-app purchase, with the commission that comes with it. Same cart, same customer, two different clauses. Sort that out before anybody draws a screen, because it changes the checkout, the refund flow and the receipt.

Which guideline covers selling physical goods?

Guideline 3.1.3(e). It sits inside section 3.1.3, Other Purchase Methods, which lists the kinds of app that may use something other than in-app purchase. Clause (e) is headed Goods and Services Outside of the App and it is one sentence long: if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.

Read the verb. It says must use purchase methods other than in-app purchase. Plenty of people arrive expecting to be told they owe Apple a cut of every order and then build a StoreKit flow to pay it. That build gets rejected. There is no in-app purchase product type for a jumper, a pizza or a plumber, and trying to make one is a guideline breach rather than a generous gesture.

The opposite clause is 3.1.1. If you want to unlock features or functionality within your app, by way of Apple's own examples subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version, you must use in-app purchase, and apps may not use their own mechanisms to do it. The dividing line between the two clauses is where the thing is consumed, not how much it costs or whether it is physical. A printed book shipped to a house is 3.1.3(e). The same book as a file the app opens is 3.1.1.

One more sentence in that section catches people out. The preamble to 3.1.3 says apps in the section cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except for apps on the United States storefront and as set forth in 3.1.1(a) and 3.1.3(a), and that developers can send communications outside of the app about other purchasing methods. That restriction is about steering customers away from in-app purchase for things that should have used it. It does not undo clause (e), which is explicit that for physical goods the other method is the required one. If your shop sells both kinds of item, read both sentences slowly.

Apple, App Store Review Guidelines, guidelines 3.1.1 and 3.1.3, last updated 16 October 2026, read 23 October 2026

Check your lines

Which rule each thing in the cart falls under

Tick everything you sell. Every rule and every example below is quoted from Apple's App Store Review Guidelines, last updated 16 October 2026 and read on 23 October 2026. If you tick items from both halves, one cart has to carry two payment paths.

Nothing ticked yet. Start with the one line you expect the most revenue from, because that is the line that decides how the checkout screen is built.

Does Apple allow a third-party payment processor?

For physical goods, Apple requires one. The two examples named in 3.1.3(e) are Apple Pay and traditional credit card entry. Card entry means somebody has to process the card, and that somebody is a payment company you choose. Apple does not name any processor in that clause, does not approve a list, and does not take a share of an order placed through one.

If you offer Apple Pay in the checkout, section 4.9 adds two obligations. Apps using Apple Pay must provide all material purchase information to the user prior to sale of any good or service, and must use Apple Pay branding and user interface elements correctly, as described in Apple's Apple Pay Marketing Guidelines and Human Interface Guidelines. In practice that means the total, the shipping cost and anything recurring are on screen before the sheet appears, not after it. For a shop, that is also just good manners.

Two practical notes that are not in any guideline. First, never let the device decide the price. The app should send a basket of product identifiers and quantities, and your server should answer with the total it is willing to charge, because anything the phone calculates can be edited by someone who wants the jumper for a pound. Second, check stock at the moment of payment rather than at the moment the item went into the basket. A cart that sat on a phone for three days is a list of wishes, not a reservation.

The payment token is the one piece of this that belongs in encrypted storage. Expo's guidance for expo-secure-store is that it encrypts and securely stores key-value pairs locally on the device and is intended for small values such as tokens, keys and other secrets. A basket is not a secret. A customer session token is.

Apple, App Store Review Guidelines, guidelines 3.1.3(e) and 4.9, read 23 October 2026

Where does the cart live between sessions?

Wherever you decide, because Apple has written nothing about it. We searched the full review guidelines on 23 October 2026 for cart, shopping, checkout and basket. Cart returns one hit, and it is the phrase a la carte in the subscriptions clause. The other three return none. There is no requirement to keep a basket, no limit on how long you may keep one, and no rule about reminding somebody they left something in it.

So the question becomes which local store to use, and Expo answers that one in a single page. Its Store data guide, which carries a last updated date of 3 June 2026 and was read on 23 October 2026, lists four options with a line each about what they are for. The table below is those four descriptions. The last column is our read, and Expo does not say anything about baskets either way.

Option	What Expo's page says it is for	Right place for a basket?
expo-secure-store	Encrypts and securely stores key-value pairs locally on the device. Intended for small values such as tokens, keys and other secrets.	No
expo-file-system	Access to a file system stored locally on the device, and it can upload and download files from network URLs.	No
expo-sqlite	A database queried through a WebSQL-like API. Expo's page says the database is persisted across restarts of your app.	Yes
Async Storage	Asynchronous, unencrypted, persistent key-value storage. Expo calls it a good choice for small amounts of data, such as user preferences or app state.	Yes

For most shops, a few lines in Async Storage is the right amount of engineering. Expo describes it as asynchronous, unencrypted, persistent key-value storage and a good choice for small amounts of data such as user preferences or app state, which is a precise description of a basket. Move to expo-sqlite when you want to query the thing, for instance a saved-for-later list that runs to hundreds of rows, since Expo says that database is persisted across restarts of your app.

Note what Expo does not promise. The Store data page says nothing about what survives a reinstall, and the word reinstall does not appear on it at all. Treat the device copy as a convenience and write the real basket to your own account record once somebody is signed in. That also gets you the thing people actually want, which is a basket started on a phone and finished on a laptop.

Expo, Store data, last updated 3 June 2026, read 23 October 2026

What do you actually have to build?

Six screens, and only one of them is hard. A product list, a product page with an add button, the basket itself with quantity and remove, an address and delivery step, the payment step, and a confirmation that tells somebody what happens next. The hard one is the payment step, for the reasons above.

Then there are the five states nobody remembers until a customer finds them. An empty basket, which needs a sentence and a way back to the products. An item that went out of stock while it sat in the basket. A card that was declined, where the basket must still be there afterwards. A price that changed since the item was added. And a successful order placed on a connection that dropped before the app heard back, which is the one that produces two charges if you send the order without an idempotency key.

A basket is shared state that has to agree with a server, so the same discipline applies to it as to any other number two devices can both change. If the phone is the source of truth, two phones will disagree, which is exactly the trap described in add leaderboards. Once the order exists, the customer immediately wants to know where it is, and that is a different feature with its own notification plumbing, covered in add order tracking.

Newly is an AI app builder for this kind of job. You describe the shop in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync, so the checkout code is somewhere you can read and change. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and builds a standalone Android APK. It is $25 a month and there is no free tier. What it will not do is press submit on the App Store for you: guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, and the content of your shop is yours. The steps for doing that yourself are in publish to app store.

One last piece of advice from the shop floor. Do not build the basket first. Build one product page and one checkout that can take a single item, and sell something with it. A basket is a convenience for people who have already decided to buy twice, and you will learn more from the first real order than from a quantity stepper.

Expo, Store data, on the four local storage options, read 23 October 2026

Questions people ask about carts and app store rules

Not only can you, you have to. Guideline 3.1.3(e), headed Goods and Services Outside of the App, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. That is a requirement, not a permission. Read from the App Store Review Guidelines on 23 October 2026, which carry their own last updated date of 16 October 2026.

Write down what you sell. The rest follows from it.

List your products and mark each one as consumed inside the app or outside it. That single column decides your checkout, your commission and half your screens. Then describe the shop and let the builder write it.

Start building