Safari and Web Technologies Group Lab

Engineers and evangelists from the Safari and WebKit teams introduce themselves and set up a session covering the fundamentals of web development, upcoming web standards, WebKit's standards process, Safari extensions, spatial web features, and web performance.

The fundamentals still matter most: understand why the web has HTML, CSS, and JavaScript and what each is for. Invest in semantic HTML — which keeps expanding, so things that once required JavaScript can now be done declaratively — and learn CSS layout deeply. A strong grasp of the core three languages is the best preparation for whatever comes next.

A highlight is the newly founded Web Extensions Working Group. After five years in a community group meeting biweekly, the work is moving to a formal specification for the WebExtensions API, pushing toward real interoperability across browsers — a meaningful step for extension developers.

The web platform is genuinely capable — early iOS even considered shipping only web apps, and some first-party apps were originally built that way. Modern WebKit is highly optimized, so a well-built web app can feel excellent. The trade-off is that reaching that quality on the web is harder to sustain, which is why native remains valuable, but strong web performance is very achievable.

The team genuinely wants to hear from developers. File issues at bugs.webkit.org and engage with the evangelists on social media. What helps most is clear signal about which features matter and why — there are more good ideas than people to build them, so concrete, well-explained demand and real use cases help prioritize the work.

The recommended approach is to use HTTPCookieStore to observe and manipulate cookies for WKWebView, keeping them in sync between your app and the web view. The panel didn't have a cookies specialist present, so for deeper cases they suggested following up through the forums.

The team is enthusiastic about users generating extensions from a prompt to tailor their browsing. On closing the API gap, the direction is toward greater interoperability — the new WebExtensions Working Group is the vehicle for standardizing and expanding API coverage. Specific additions like Tab Group APIs are best raised and tracked through the developer forums and WebKit.

Spatial CSS is currently a proposal with no shipping news, though it's something the team feels positively about. What exists today is the inline HTML element for placing USD and other 3D formats into a page — you can drag models out and, with immersive environments, view them at full scale and create scenes procedurally.

There's still plenty of headroom — teams work on engine performance continuously. Developers often focus on their own JavaScript speed and image loading to get a usable page in front of users fast, while WebKit engineers keep improving how quickly a browsing experience becomes responsive. Performance work on both sides is ongoing, not finished.

Combine extension UI with your app. Use an extension popup for lightweight display, and the web navigation APIs to monitor page changes. To pass data between the extension and your native app for richer SwiftUI reporting, use native messaging. Those pieces let you surface page insights in your own UI across iOS, macOS, and visionOS.

Build the select the traditional way first — always include real text content for every option — then layer images, extra content, and CSS on top. Supporting browsers get all the styling; unsupporting ones fall back to the text list automatically, with no extra developer work. Text content is also essential for accessibility (screen readers announce it) and UX (icon- or color-only options are hard to recognize). This works because select was designed for progressive enhancement on purpose — the original selectmenu proposal was dropped in favor of reusing select so older browsers get a good fallback.

The model element exposes a ready promise signaling when the model has loaded, so you can show a spinner while loading and hide it when ready. As with images, there is a distinction between downloading an asset's bytes and having the resource actually loaded and usable — the same applies to models, including ones generated procedurally in JavaScript, and you can observe and present UI for each phase. There isn't a dedicated CSS pseudo-class for the loading state yet; the panel noted that as good feedback.

Keep models small and optimize them before publishing, just as with images — larger models mean longer download and processing time, and memory is finite. There are no hard guidelines, but a model that is content on a page generally shouldn't be larger than the page, so textures and geometry only need enough detail for how it is displayed. Maximum visual quality is often reachable around ten megabytes — larger than an equivalent image, but reasonable given the motion and interactivity. Full-screen immersive environments can legitimately be larger. Tooling is improving too: USDCrush now compresses textures to AVIF rather than JPEG, and mesh-compression formats are under discussion.

Safari's extension permission model is designed with user privacy first. Manifest-requested permissions aren't automatically granted — the user decides which sites an extension runs on, and Safari is clear about what a granted extension can do. Because developers often can't predict which sites a user will visit, they may over-request host permissions; the active-tab permission is a good workaround, granting access only to the current tab and dropping host permissions once the user navigates away.

In an immersive environment the web page is still present, so anything you need to do on that page remains available. It is a single-app experience: other apps alongside (like Messages) may dim, and a crown press restores the shared view. If you want the page to alter the immersive environment — moving your position, or playing or pausing an animation — you can put whatever UI you need onto the web page for the user to control it.

The model element is the first and easiest step for web developers to experience 3D and the spatial web — least friction, quick compelling results. You don't need an existing model: find one online, or use modern generation tools to create 3D models (creatively, or reconstructed from a set of images). From there it is a natural progression into learning more about 3D and tools like Blender. For everyday developers curious about spatial, starting with the model element is the recommendation.

With appearance-base select, the layout works correctly out of the box and the control inherits your page's styling — font, background color, font color — rather than a custom UA font, a big improvement over appearance:none. The standout is pseudo-element access: you can target and style individual parts (the picker icon, the drop-down menu, the checkmark) without affecting the rest. It is 100% interoperable across engines with a consistent underlying DOM — the foundation that makes reliable custom styling possible. Appearance-base for all form controls (not just select) is still in progress. The one open discussion is what the default should look like — the intent is for the UA stylesheet to carry as little opinion as possible and inherit as much as possible from the existing site.

How much work it takes depends on the extension — some convert and work out of the box; others rely on browser-specific APIs Safari may not support. To test, open the Develop menu and load a temporary extension using your existing Chrome or Firefox extension resources, then see what works. If an API behaves differently across browsers, raise it in the WebExtensions community and working group, or file a bug on bugs.webkit.org or via Feedback Assistant. There are no grave manifest differences across browsers, and Safari deliberately doesn't fail on unsupported manifest keys — a specific choice to ease migration.

Each panelist shared a closing thought: the Safari 27 beta release notes are exceptionally long this year — roughly twice normal — reflecting a major effort to fix long-standing paper cuts (including rewriting the JavaScript module loader to fix the top-level-await bug), and WebKit genuinely wants developers' bug reports. Extension support now lives in WebKit, so you can contribute code and file bugs directly. Recurring themes: play with the model element and enjoy 3D on the web, and lean on how much modern web standards do for you — you may be able to build with far fewer frameworks than expected. A closing wish: show off Safari-first standards like the random() and filter() functions and hanging punctuation.