Safari on Mac · Research guidance. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
Read both parts of the behaviour
Apple’s current Safari guide says an existing website sign-in is carried into a new Dock web app in most cases. Its web-app overview also describes the resulting app as independent of Safari with its own browsing data and settings. These statements address different stages rather than requiring every later session change to stay identical.
Consider a later cleanup
Imagine creating a web app from a signed-in page and later clearing website data in one context. A different subsequent sign-in state is a reason to inspect which context was changed. It is not enough evidence to conclude that the provider created a second paid account or that the original password spontaneously changed.
Record the window and action
Keep a note of whether the action occurred in Safari or in the web app, the site address and the exact cleanup or sign-out control used. Avoid sharing the password or session token. This lets support distinguish a context-specific session change from a provider-side account change without guessing from the window’s icon.
Use a narrow next check
Return through the legitimate site and inspect the account state in the context you actually intend to use. If the provider reports a separate account problem, retain that message as its own evidence. Repeated global browser resets or new purchases are poor substitutes for identifying which window holds which session.
Questions, answered
Does starting signed in mean every later state must stay shared?
No. Apple also documents the web app’s independent ongoing context.
Should the same account be purchased again because one context signed out?
First identify the context and actual account message; a sign-out is not proof another purchase is needed.