Seasonal pricing is a rule your code reads at booking time, not a price you edit by hand.

What actually changes when you price by season?

Three things, and only one of them is the number. The first is where the number comes from. A price stops being an attribute of the service and becomes the output of a small function: the base price, then every rule whose window contains the slot, applied in a defined order. The second is that a price now needs a date in order to exist at all. Any screen showing a price without a date is showing a guess, which is why a bare from price is the most dangerous string in a booking app. The third is that you need a record of what you quoted, because the rule that produced it will not be there in six months.

Overlap is where the bugs live. Christmas week sits inside the winter season, which sits on top of the base price. A Saturday in August is caught by both the weekend rule and the summer rule. If your code loops through every matching rule and multiplies, you will one day charge 1.5 times 1.4 and read about it in a review. Give every rule a precedence number, take the highest one that matches, and keep a short deliberate list of the rules you do want to combine, such as a per person group rate on top of a seasonal night rate. Then apply discount codes last, after everything else, with a cap on the total, so an off peak rate plus a code cannot take a booking below what it costs you to turn up.

Dates are harder than they look. A season boundary is a date in the timezone where the work happens, not on the customer's phone. Someone booking from another continent can choose 1 July, have it resolved as 30 June, and pay the off peak rate for a peak day. Store the business timezone on the business, resolve the slot there, and compare dates rather than timestamps. A booking that spans a boundary needs splitting: price each night at its own rate instead of the whole stay at the arrival rate, and show the breakdown, because a single total that does not match the nightly rates reads as an error. If you also push confirmed bookings out to the customer's own calendar with calendar sync, put the agreed price in the event description so the number travels with the appointment.

One more habit that saves money later: compute in minor units, so cents or pence as integers, and round once at the end. Percentages applied to floating point prices drift, and a penny of drift on a deposit means the balance never quite clears. Keep the rule that produced the number on the line item too. You will want it the first time a customer asks why a Tuesday in February cost more than they expected.

Do the store rules let you change a service price by season?

Yes, and for a real world service the store rules push the thing that would stop you out of the way. App Store Review Guideline 3.1.3(e), 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. Read that carefully, because it is commonly repeated backwards. It is a prohibition, not a permission. In-app purchase is forbidden for a haircut, not merely optional for it. Build it the other way round and the app gets rejected. The consequence is the one you want: the price lives in your own database, behind your own payment processor, and nobody reviews a change to it.

The rule next door catches people, and it turns on how many customers are in the room. Guideline 3.1.3(d), Person-to-Person Services, allows purchase methods other than in-app purchase for real-time person-to-person services between two individuals, and Apple names tutoring students, medical consultations, real estate tours and fitness training as its examples. The same paragraph then says that one-to-few and one-to-many real-time services must use in-app purchase. So a one to one coaching call in January is yours to price however you like. A live group class with eight people in it is not: that payment has to run through in-app purchase, and your seasonal price becomes an App Store price with a scheduled start date. If your app sells both, they are two payment paths, not one with a flag on it. Decide which one each product is before you build the pricing screen.

The third case is anything consumed inside the app. Guideline 3.1.1 requires in-app purchase to unlock features or functionality within your app, and it names subscriptions, in-game currencies, game levels, access to premium content and unlocking a full version. A seasonal discount on a premium tier is therefore an in-app purchase price change, not a database edit. One correction worth carrying with you, because the wrong number gets quoted at this constantly: guideline 3.1.5 is Cryptocurrencies. It covers wallets, mining, exchanges and coin offerings, and has nothing to say about real world services. If a checklist sends you there for a booking, the checklist is wrong. Google Play has its own version of the same carve-out and its own subscription price change flow, so check that separately rather than assuming the two stores agree.

Apple, App Store Review Guidelines, 3.1.1, 3.1.3(d) and 3.1.3(e), read 14 October 2026

What will Apple let you do to a subscription price?

Less than you would like, and the limits are worth reading before you plan anything seasonal. The flow lives in App Store Connect. Open Apps, select your app, click Subscriptions in the sidebar, open the auto-renewable subscription, go to the Subscription Prices section and click the add button, then Plan Subscription Price Change. You choose the countries or regions, a start date and the new price, and App Store Connect offers comparable prices for the other storefronts with taxes and exchange rates already applied. The step that matters is the next one, where you decide what happens to the people already paying.

Option one keeps the current price for existing subscribers, so anyone who subscribed before the start date is not affected, and if their subscription expires they can resubscribe at the preserved price within 60 days of expiration. Option two applies the change to existing subscribers, and App Store Connect indicates per country or region whether consent is required or whether subscribers will simply be notified. Consent is required if any one of three conditions applies. The subscriber is located in a region that requires consent for any price change. Or the increase is more than 50% of the current price and the difference in price exceeds approximately US$5 per period for non-annual subscriptions, or US$50 per year for annual ones, with the exact thresholds varying by storefront. Or, and this is the one that decides your plan, the subscriber experienced a price increase for that subscription within the past 12 months.

That last condition is what makes a seasonal subscription price impractical. Raise it for summer and lower it again in September, and next summer's increase lands inside twelve months of the last one, so every affected subscriber has to actively agree or lose the subscription. Apple is blunt about the consequence: if a subscriber does not consent before the first renewal at the higher price, their subscription expires at the end of the last renewal cycle at the former price. Until then Apple requests consent roughly weekly through email, push notifications and in-app messaging. Two more limits stack on top. You can schedule only one future price change at a time, per country or region, per billing plan type, and scheduling a second one overwrites the first. And a price decrease applies to every existing subscription with no option to preserve the higher price, and cannot be reversed once it is in effect, though you can schedule an increase afterwards.

So price the booking, not the subscription. Keep the recurring price flat all year and put the seasonal money where you control it, in the service charge your own payment processor collects. If you really want to sell a summer pass, sell it as a non-renewing product with an end date rather than moving the price of an auto-renewable one. The notice periods are useful either way. When consent is needed, the first email goes out 60 days before the renewal date for two month, three month, six month and annual subscriptions, 27 days before for monthly, and 7 days before for weekly. When consent is not needed, the first email is 27 days before renewal, in-app messaging appears on the first app launch after the notice period begins, and a push notification follows 7 days before renewal if the in-app message was not viewed. All of that was read on 14 October 2026, and the thresholds are explicitly subject to change with tax and exchange rates, so check them again before you schedule anything.

Apple, App Store Connect Help, manage pricing for auto-renewable subscriptions, read 14 October 2026

How do you show a seasonal price without starting an argument?

Put the number next to the date, before anyone commits. A calendar that shows a price on each day settles the question silently, and it is the single change that removes most pricing complaints. The opposite is a from price on the listing that turns into something else at the checkout. That reads as a bait and switch whether or not you meant it, and people say so in reviews. If you have to show one number before a date is chosen, show a range and label the ends of it.

Say why. August rate or Saturday rate next to the line item costs you nothing and answers the question before it is asked. Then honour what you showed. Give every quote an expiry of a few minutes, store it, and charge the stored number even if a lead time rule has moved on while the customer was finding their card. When you change a rule, bookings already in the book keep their frozen price, which is the entire reason you wrote the number onto the booking in the first place. If you take a deposit now and the balance on the day, both halves come off the same frozen quote, or the arithmetic will not add up when they arrive.

Keep your own receipt. You took the payment, so you issue the record, and it should name the rule that produced the price. That one line prevents most disputes and nearly all of the arguments with your own staff. Be honest about the direction of travel too: off peak pricing is not a loss. An empty Tuesday earns nothing at all, so a discount that fills it is upside as long as it clears the costs that do not move with the season. Work out what those fixed costs actually are before you set the floor, including what it costs to publish an app, and then keep every discounted rate above them.