La build coche un spectre inhabituellement large: accessibilité, animations, CSS, édition, formulaires, HTML, JavaScript, médias, rendu, Spatial Web, Web API, Web Audio, Web Inspector, WebAssembly, WebDriver et WebRTC. Pour un dev PHP qui livre du front, c'est exactement le genre de révision à installer en parallèle de Safari stable, sans compte développeur, sur Tahoe ou Golden Gate, avant qu'elle ne se retrouve figée dans une prochaine release utilisateur.
Ce qui touche concrètement le code PHP en prod
Quand Safari bouge son moteur, le serveur PHP n'est pas concerné directement — mais tout ce qui est rendu, hydraté ou streamé côté client, oui. Les zones chaudes sur cette build:
- CSS et rendu: vérifier les grids, les
backdrop-filter, lescontainer queries. Une régression d'alignement ou de cascade côté Safari casse immédiatement les dashboards admin et les tunnels de paiement générés par Symfony ou Laravel. - Web API:
fetch,AbortController,IntersectionObserver,ResizeObserver. Toute API non testée sur la dernière builds remonte des bugs en production dès qu'Apple la pousse aux utilisateurs finaux. - WebRTC: ciblage direct si tu serves de la visio (Webex-like, support client, téléconsultation). Teste le handshake ICE, le codec H.264 et la reprise de stream depuis la dernière build.
- WebAssembly: si ton back-office embarque des libs WASM (PDF, tableurs, crypto côté client, traitement d'image), c'est le moment de rejouer la suite de tests dessus.
Tests à dérouler avant la release stable
Le canal Technology Preview coexiste avec Safari principal — activation via Réglages Système après téléchargement depuis le site Apple. Trois checks prioritaires sur un projet PHP:
1. Smoke test des routes critiques: login, formulaire de paiement, upload, génération PDF. Vérifier que les enchaînements JS côté client ne déclenchent pas d'erreur console inhabituelle.
2. Audit Web Inspector: la build corrige aussi Web Inspector. Profiter de la version pour profiler un cold start de page lourde (SSR + hydratation). Regarder les timings réseau, pas le mur JS.
3. Matrice de compatibilité: si tu cibles un parc mixte (Safari stable + Safari TP), note ce qui diffère. Ça nourrit la décision de push final.
Verdict
Build de maintenance transversale, aucune feature grand public à attendre. Pour un dev PHP qui livre du web: install, smoke tests, profilage, puis on attend la stabilisation. Rien à merger en urgence, mais à surveiller de près dans les deux semaines qui viennent — c'est typiquement ce type de révision qui révèle les régressions silencieuses avant qu'elles n'atteignent les utilisateurs.