Safari on iPhones and iPads refuses cookies from a site framed inside another, unless the visitor has used it directly, so an embedded calendar forgets each choice. Test on a fresh device and link to the full page.

Back at the start

A hair salon adds an online booking calendar to its contact page. Clients choose a stylist, a service and a time, then press continue to enter their details.

On the salon's computer it works. On iPhones and iPads, pressing continue brings back the calendar's opening screen, with the stylist and the time forgotten. Clients try twice, then phone or give up.

The salon owner tries it on her own iPhone, and it works perfectly. The booking service says nothing is wrong at its end. Both are telling the truth.

Why the calendar forgets

An embedded calendar is not part of the salon's page. It is a page from the booking service, shown inside a frame, and the browser treats it as a separate site.

To remember a choice from one step to the next, the calendar stores a small cookie. When the visitor presses continue, the booking service reads the cookie back and carries on from the chosen time.

Safari, the browser on iPhones and iPads, by default refuses cookies from a site inside a frame unless the visitor has already been to that site directly. With no cookie to read, the service starts again.

Signs that cookies are the cause

The pattern is distinctive once you know it:

Several of these together point at the cookie setting rather than at a fault in either the booking service or the site.

Why the owner never sees it

The salon owner manages bookings on the service's own website, from the same phone. Safari therefore already holds cookies from the booking service, and lets the frame use them.

A new client has never been to the booking service directly. Her Safari treats the calendar as a stranger in a frame and turns its cookie away.

So the people who test the site are exactly the people for whom it works. That is how a problem like this can last for months.

Testing on a real device

Test on an iPhone or iPad that has never used the booking service, or clear Safari's cookies and data in the device's settings first. Then book from your own site, step by step.

Resizing a desktop browser to phone width will not show the problem. Cookie rules belong to the browser, not the screen size, and Chrome on a computer accepts the cookie.

Clearing that data signs the device out of other sites, so a spare phone or a borrowed tablet is the easiest choice.

A worked example

A bouncy castle rental business run by a couple in the Tri-Cities delivers inflatable castles, slides and obstacle courses to birthday parties and school fairs. Parents book a unit, a date and a delivery window online.

The booking calendar, from an online booking service, sat inside the company's own Book page. Through the spring, parents kept phoning to say the website went back to the beginning.

The owner's phone booked without trouble, because she managed the calendar from it every day. A borrowed iPad, cleared first, failed at the second step every time.

The frame was replaced with a large button reading "Check dates and book", which opens the booking service's full page, with the company's logo and colours set in the service's options.

The company's own page keeps the units, prices, delivery area and phone number. Opened directly, the booking page is the site the visitor is on, so Safari accepts its cookie.

Why the full booking page usually works

Opened as a page of its own, the booking service is no longer a third party. Safari treats it like any site the visitor chose to visit, and its cookies work normally.

The full page is often better on a phone in other ways too. It was designed for the whole screen rather than squeezed into a box, and the address bar shows a secure connection before payment details go in.

Booking services usually offer both a code to embed and a plain link. Ask for the link, and for any settings that show your name and colours on their page.

What to ask the booking service

Ask whether its embedded calendar is meant to work in Safari on iPhones, and how it keeps a visitor's choices between steps. A service that has met this before will know at once.

Ask too whether the confirmation email can link back to your site, so clients who booked on the service's page return to you afterwards.

Keeping your own page useful

Whatever sits inside a frame belongs to the booking service, so search engines credit it to the service's address, not yours. The page around it is what your site actually says.

Put the useful facts there in plain text: what can be booked, prices, hours or delivery area, cancellation terms and a phone number for anyone who prefers to call.

Label the button with the action, such as "Check dates and book", so visitors know what will happen when they tap it.

The counter-case

Not every embedded calendar fails. Some keep the visitor's choices within the page rather than in a cookie, and work in Safari just as they do anywhere else.

Some businesses also prefer the frame because visitors never leave the site, and that is a fair preference when the calendar passes the test.

The argument here is for testing, not against embedding. If yours books cleanly on a fresh iPhone, keep it; if it does not, a plain link is a small change that works.

A booking test on a fresh iPhone

  1. Borrow an iPhone or iPad that has never used your booking service.
  2. Open your booking page in Safari.
  3. Pick a time and press continue.
  4. Note where it fails, if it does.
  5. Ask the booking service for its full-page link.
  6. Replace the frame with a clear button to that page.
  7. Repeat the test on the same device.

Step one is the whole test. A device that has used the booking service before will pass every time, and only a fresh one shows what a new client sees.

Embedded video players carry a hidden cost of their own, which six embedded videos on one testimonials page tallies player by player.


Frequently asked questions

Why does the booking calendar start over on iPhones?

Safari refuses cookies from a site shown inside another site's frame unless the visitor has used it directly. The calendar cannot store the chosen time, so it starts again.

Why does it work on our own phones?

Staff who manage bookings on the service's own website already have its cookies, and Safari lets the frame use them. New clients have never visited it directly.

How should we test the booking page?

Use an iPhone or iPad that has never used the booking service, or clear Safari's cookies and data first, then book from your own site step by step.

Will resizing a desktop browser show the problem?

No. The cookie rule belongs to Safari, not to the screen size, and Chrome on a computer accepts the cookie that Safari turns away.

What usually fixes it?

Replace the embedded calendar with a clear button linking to the booking service's full page. Opened directly, it is no longer a third party, and its cookies work.

Should every embedded calendar be removed?

No. Some keep choices without cookies and work in Safari as anywhere else. If yours books cleanly on a fresh iPhone, there is no reason to change it.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Booking calendar starting over on iPhones?

Tell us where your booking page lives, and we will try it on a cleared iPhone and suggest the fix.

Start a Conversation