Later this summer, Apple will unify the email domains used by Sign in with Apple and iCloud+ Hide My Email under a single, shared domain: private.icloud.com.

New addresses generated for both features will be issued on the new domain. For example:

• Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com.

• iCloud+ Hide My Email addresses, previously issued on icloud.com, will be issued on private.icloud.com.

Existing addresses on the legacy domains will continue to work and forward mail to users without interruption.

What you need to do

• Developers with apps or websites that use Sign in with Apple should ensure that their account systems, email validation logic, and allowlists accept addresses on the new private.icloud.com domain in addition to existing domains: privaterelay.appleid.com and icloud.com.

• Email service providers should update any domain-based filtering, suppression lists, or routing rules that explicitly enumerate relay domains so that the new private.icloud.com domain is included.

Learn more about Sign in with Apple

Communicating using the Private Email Relay Service

Just a reminder! Please take the Flutter Q2 survey! The survey closes at the end of day on Friday, June 19th.

It won’t take long and your feedback helps drive our roadmap!

Thank you!

---

Flutter Q2 survey was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

More and more, I'm finding that I'm getting asked a series of similar questions when a customer decides to pick up a Cloud Solution Provider or switches between a Cloud Solution Provider for Microsoft. It starts with a: "What happens to our tenant? Do we lose our identities? Does someone have to rebuild Entra ID?" The short answer is no. The longer answer is the rest of this post, because while nothing dramatic happens to your tenant, plenty of small things change at the billing, permissions,...

Customizable select is coming to Safari 27. With this technology, developers can fully control the appearance of <select> elements — custom arrows, option layouts, color swatches, icons, full visual styling — without the need for JavaScript libraries or an endless parade of <div> elements. And because it’s a built-in control, you don’t have to compromise on keyboard navigation or accessibility semantics.

But, to ensure this built-in control works well for everyone, it’s important to follow this single but essential rule: always provide text content or accessible text attributes for your option elements.

Every time that rule is broken, every time an option is styled to show a visual without any text and without any accessible fallbacks, three different problems get introduced all at once. The menu is harder to use for everyone, impossible to use with accessibility tools, and it becomes a completely broken experience in browsers that don’t support it yet.

When you remember to follow the rule, you’ll improve the user experience, support accessibility, and provide progressive enhancement so it works for people regardless of what browser they choose.

We’ll show you why following this mission critical rule gets you:

Better UX

Take this category filter from a photographer’s gallery site. The version below uses icons alone — a building, a flower, a hummingbird — to represent each category:

It looks clean. But a user who doesn’t immediately recognize what the hummingbird icon represents has no fallback. The closed select shows only an icon in the button, with no other hint of what’s currently selected. Add a text label to each option and the experience becomes immediately scannable. The selected state is readable at a glance, and every option is unambiguous:

The icons are still there. The labels make it readily decipherable for everyone.

Better accessibility

When a screen reader encounters an option with no text, the user may not hear a descriptive label for each option. Braille rendering and other assistive technology output may also be confusing. Text, even when hidden visually with a .visually-hidden class, stays in the accessibility tree and gives screen readers, braille displays, and speech recognition software something real to work with. If you use an icon as an <img>, add an alt or aria-label — or mark it decorative using alt="" and let the visible or visually-hidden label carry the meaning.

<option>
   <img src="bird.svg" alt="">
   <span>Wildlife</span>
</option>

The problem you solve isn’t just a compliance checkbox: it’s the difference between a visitor completing your form and someone abandoning it.

Better progressive enhancement

Customizable select is a new feature. Browsers that don’t yet support it fall back to the platform-native <select> — which is exactly the right behavior, as long as your options still make sense in that fallback state.

If you’ve removed text in favor of icons or swatches, a user on an older browser sees a dropdown full of empty options. The same is true when CSS fails to load at all: a slow connection, a corporate proxy stripping stylesheets, a user with custom styles enabled. Wrap your enhancements in @supports (appearance: base-select) and keep plain text as your baseline. Adding a swatch is an enhancement. Removing the color name to make room for it is a regression.

The rule for maximizing the power and utility of customizable select is simple: keep the text. You can hide it visually. You can make it tiny. You can position it off-screen. But it needs to be there. Icons, swatches, and illustrations are additions to an option — never substitutes for it. Follow that rule and the rest of customizable select is yours to play with.

Feedback

We love hearing from you. To share your thoughts, find our web evangelists online: Saron Yitbarek on BlueSky, Jen Simmons on Bluesky / Mastodon, and Jon Davis on Bluesky / Mastodon. You can follow WebKit on LinkedIn. If you run into any issues, we welcome your feedback on Safari UI (learn more about filing Feedback), or your WebKit bug report about web technologies or Web Inspector. If you run into a website that isn’t working as expected, please file a report at webcompat.com. Filing issues really does make a difference.

In part 4 of this series we created our final two agents. In this final part of the series we’ll review the workflow that we create with the StateGraph class of LangGraph.

In the following code we pass the ResearchState object to StateGraph and create a node for each agent and edges that represent transitions between the nodes. There is one conditional edge: if the reviewer rejects the draft, it goes back to the author

workflow.add_node("blogger", blogger_node)
workflow.add_node("researcher", research_node)
workflow.add_node("author", author_node)
workflow.add_node("reviewer", reviewer_node)

workflow.set_entry_point("blogger")

workflow.add_edge("researcher", "author")
workflow.add_edge("author", "reviewer")

# Add conditional edges from blogger
workflow.add_conditional_edges(
    "reviewer",
    lambda state: "author" if state.get("review_result") == rejected else "blogger"
    {
        "author": "author",
        "END": END
    }
app = workflow.compile()

That’s it. All that’s left is to take it out for a spin.