Apple and Intel reached a "preliminary agreement" for Intel to make chips for Apple hardware, The Wall Street Journal reported Friday. Apple had famously moved on from Intel-powered computers with its highly successful transition to Apple Silicon, but now it appears the two companies will be working closely together again.

Intel appointed Lip-Bu Tan as its new CEO in March 2025, and in August, the US government took a 10 percent stake in the company.

The WSJ says that it's "still unclear" what Apple products will get Intel chips. Apple and Intel didn't immediately reply to a request for comment from The Verge.

Bloomberg reported this we …

Read the full story at The Verge.

Policymakers around the world are advancing age assurance proposals to protect children and teens online. Some approaches restrict minors’ access to certain services or content, while others would require devices, operating systems, or app stores to collect age information and pass age signals to apps and websites. These proposals are driven by serious concerns, but without appropriate scoping, they risk imposing burdensome requirements on open source software and developer infrastructure services that do not present the same risks to minors as consumer-facing platforms. In this blog post, we’ll provide an overview of what developers should know and how to engage.

The harms these laws aim to address are serious and deserve attention. Grooming for sexual purposes, exposure to violent content, and online bullying are just some of the risks young people are facing online. At the same time, participation in online communities, including open source software development, can be an important part of a young person’s education and social life. When trying to strike a balance between freedom and protection, policymakers are not always aware of how their proposals could affect developers or how the open source ecosystem operates.

“Age assurance” refers to a range of approaches used to determine or estimate a user’s age. It is sometimes used interchangeably with “age verification,” which typically refers to higher-confidence methods like photo ID matching or checks against financial or identity systems. Age assurance also includes self-attestation (where users report their age) and age estimation (where age is inferred from signals, facial scanning, or behavior). These approaches span a wide spectrum, with ongoing debate about tradeoffs between accuracy, privacy, security, interoperability, and accessibility. Proposals also vary in what age thresholds trigger restrictions, the services or content covered, how parental consent should factor in, and how access is limited. While we do not discuss each approach in detail here, we encourage readers to engage with the legislation, consider different technical and policy perspectives, and think about how to protect young people online while preserving access to the knowledge, learning opportunities, and creative potential the internet enables—including opportunities to learn to code and participate in the global open source ecosystem.

A poorly designed age assurance law could have significant unintended impacts for open source projects. For example, requirements that operating systems centrally collect and manage user data, or that restrict users from installing software outside of centralized app stores, would conflict with the decentralized, user-controlled norms of the open source ecosystem.

Another potential pitfall is placing age assurance requirements on “publishers” of operating systems, regardless of whether they are individuals or companies. Open source operating systems are frequently iterated on, reused, and redistributed by individual contributors and small communities, many of which have limited resources and small user bases. Similarly, applying age assurance requirements on “publishers” of operating systems, regardless of whether they are individuals or companies. The diversity of the software ecosystem is worth preserving.

GitHub has engaged with governments on age‑related online safety proposals for several years. In some cases, including Australia’s Social Media Minimum Age legislation, we worked with policymakers to explain why open source code collaboration platforms should not be in scope. Similar exemptions appear elsewhere. France’s current Social Media Minimum Age proposal, for example, includes the same exclusions for open source code collaboration sites and online encyclopedias that appear in the EU Copyright Directive.

Many policymakers recognize that access to the open source software development ecosystem delivers significant public benefits, including education, innovation, and security, and that the risks young people face from participating in open source development communities are materially different by comparison. At the same time, a growing number of laws are seeking to advance child safety goals at varying levels of the tech stack, including through operating systems and application distribution layers. This has raised new questions for developers about how these requirements apply in practice, and whether open source operating systems and developer infrastructure like GitHub could be impacted.

Legislation to know 

• California AB 1043 Digital Age Assurance Act and 2026 amending bill AB 1856: Requires operating system providers (in coordination with covered app stores) to collect self‑declared age at account setup and transmit an age‑range signal to applications via a real‑time API.
• Colorado SB 26-051 Age Attestation on Computing Devices: Requires operating systems and covered app stores to generate and share an age‑bracket signal with applications via a real‑time interface, with evolving definitions of “covered application” and “covered application store” shaping scope.
• Illinois HB 4140 Digital Age Assurance Act: Applies to operating system providers and requires collection of age data and transmission of an age‑category signal to developers via a real‑time API, closely mirroring California’s model.
• New York S 8102/A 8893 Device‑Level Age Assurance: Applies broadly to device manufacturers, operating systems, and app stores, requiring “commercially reasonable” age assurance (not just self‑reporting) at device activation and transmission of a verified age signal to apps and websites.

This is just a selection of operating system and app store age assurance legislation in the United States. There have also been related but distinct laws focused on app stores passed in Texas (SB 2420), Louisiana (HB 570), and Utah (SB 142).

These proposals are actively evolving. In Colorado, SB 26‑051 recently had a committee hearing on April 23, 2026, as part of ongoing legislative consideration. The hearing reflected the complexity of balancing child safety, privacy, and feasibility, and included strong engagement from open source developers and organizations. Committee members also signaled that the intent is not to bring open source operating systems or developer infrastructure into scope, and the latest amended text clarified that software installed outside of app stores, including software downloaded from public repositories, is not in scope.

In Brazil, the Digital Statute for Children and Adolescents (Digital ECA), enforceable as of March 2026, applies broadly to digital services “likely to be accessed by children and adolescents” including operating systems, app stores, and platforms, and excludes essential internet functionalities such as open technical protocols and standards. Although the Brazilian National Data Protection Agency (ANPD) has not yet formally clarified whether or how the law applies to free and open source software, its regulatory agenda has initially prioritized “app stores and proprietary operating systems,” and recent draft guidance under public consultation indicates that systems based on collaborative models and free software should not be subject to the same obligations as proprietary services.

Despite this, legal uncertainty has already driven some open source projects to restrict access in Brazil, reflecting concerns about the feasibility of compliance for non-commercial, volunteer-driven ecosystems. While the law was primarily designed for commercial actors, key questions about scope remain unresolved, making it critical for open source developers to actively participate in the ongoing public consultation to ensure implementation reflects decentralized development models and avoids unintended restrictions on access and innovation.

What is an app store, really?

While much of the open source community’s concern has focused on the risk that these proposals could present to open source operating systems, an equally important open question is how “application store” and “application” are defined. As drafted, some definitions of “application store” are broad enough to capture developer infrastructure—such as code collaboration platforms, package managers, and open source indexing services—simply because they allow users to access or download software.

Making software available for download is not the same as operating the kind of centralized, consumer-facing marketplace that most people would understand to be an app store. It is also important to define “application” precisely. Downloading software components like source code, libraries, frameworks, models, and utilities is fundamentally different from offering a standalone executable application through a consumer app marketplace. These components are upstream building blocks, not end‑user products, and the services that host or index them do not control consumer distribution or presentation in the way traditional app stores do.

Recent amendments and discussions across jurisdictions suggest regulators intend to focus on consumer‑facing distribution and services that control end‑user access. Clear statutory distinctions are needed to ensure laws align with that intent. This reflects a familiar challenge in technology policymaking. Frameworks aimed at youth safety and age assurance are typically responding to risks associated with consumer-facing services that collect and monetize user data, distribute content at scale, and rely on engagement-driven systems to shape user behavior.

By contrast, platforms that support collaborative software development serve a fundamentally different function—they are built to help users create, share, and maintain code, not to attract mass audiences, amplify content, or drive passive or excessive consumption—resulting in a materially lower risk profile. Open source communities operating on services like GitHub are organized around shared technical goals and guided by norms of collaboration, reuse, and transparency, further underscoring why these developer-focused services should be distinguished from consumer-facing platforms in regulatory design.

Open source software is also a key driver of economic development and innovation and functions as critical digital infrastructure. Ensuring that policies accurately reflect how open source is built and maintained is essential to preserving these benefits. When policymakers engage directly with open source developers and civil society, they are often able to refine definitions, clarify scope, and better align laws with technical realities.

Uncertainty around compliance requirements can be challenging for open source developers, many of whom contribute on a voluntary basis. At the same time, there are positive examples of policymakers engaging with the open source community to strike a balanced approach. The EU Cyber Resilience Act, for example, was refined through an iterative process to get the balance right for open source. Across U.S. states, these bills continue to evolve and policymakers have shown a willingness to engage with the open source community and consider changes to align with regulatory intent and technical feasibility.

An opportunity for engagement 

The window for constructive engagement remains open—and developer voices can make a meaningful difference.

Whether through contacting elected representatives in states considering these proposals like California, Colorado, Illinois, and New York, contributing to Brazil’s Digital ECA public consultation, or engaging with organizations like the Open Source Initiative, or through foundations that steward projects that may be impacted like the FreeBSD Foundation and Debian, there are concrete ways for developers to share their perspectives—helping ensure these policies both support children’s digital safety and reflect technical realities, align with regulatory intent, and avoid unintended harm to the open source ecosystem.

GitHub will continue working with policymakers and the open source community to support balanced approaches that protect young people while preserving open development. We encourage developers to stay informed, connect with open source policy organizations, and reach out to us with questions or concerns. We’ll also continue this conversation with a Maintainer Month livestream on May 22 with panelists from the FreeBSD Foundation and the Open Source Initiative to discuss the broader issues raised by these proposals and how technology policy can be designed with open source in mind.

The post Why age assurance laws matter for developers appeared first on The GitHub Blog.

Comment

This is the seven hundred and fiftieth issue of this little newsletter, so I hope you’ll forgive a little introspection. 😱

When I first started tinkering with Objective-C in 2006, I had no idea it would set me on a whole new career trajectory. I’d recently left a job working with C# and ASP.NET to start a small business writing Ruby on Rails apps on the brand new Intel Mac I’d just bought.

It was Ruby on Rails (along with SubEthaEdit) that brought me to the Mac, but once I had arrived I wanted to learn more about how it worked. I put my free time into learning Objective-C, wrote some little Mac widgets and apps, and learned everything I could about Cocoa.

I really loved what I found, and not just in the language or frameworks, but in the community. I met wonderful people online, attended a few conferences in the UK, and made my way out to WWDC for the first time to meet even more while queuing in the cold around the back of Moscone West, waiting to see Steve Jobs take the stage.

When I started this newsletter in 2011 it was partly because I wanted to become even more involved in that community. I enjoyed other community-digest email newsletters, and with no one else covering Apple-platform development in that format, I figured it might be something I could do. I had no idea I’d still be writing it almost 15 years later in 2026.

But as much as I did become a bigger part of that community, what I built would not have been possible without you all. I did a very rough calculation and I’d say I’ve probably read around half a million blog posts/articles over the years and turned that into almost 20,000 links back to the community over 750 issues. It is a privilege to be so connected to the community through reading everything you all blog about each week, and I’ve only been able to keep writing for this long because you all continue to read. ❤️

The community is so much richer and more diverse than it was back in 2011 when iOS Dev Weekly started. So many more people are writing about Swift and Apple-platform development, and I’d like to think this newsletter played a small part in helping that to happen.

– Dave Verwer

News

Apple announced this year’s Swift Student Challenge winners this week. There are 350 winners in total, and this post highlights four outstanding entries covering everything from helping people with hand tremors to paint again, to helping people who get nervous when speaking in public gain confidence. Worthy winners, all of them!

Code

I can’t believe I’ve not yet linked to Cupertino, the MCP server that crawls, indexes, and serves Apple’s developer documentation to AI agents. Now seems like a great time to change that with the release of 1.0.0, which Mihaela Mihaljević Jakić describes as:

The first release I’d actually call stable.

Sounds like a perfect time to check it out if you’ve not already.

Josh Adams:

Hardening ios-build-verify was the part of the development arc I least anticipated and the part that most changed the artifact. The skill itself took about a week to write. The hardening cycle that followed took about three days, and the artifact at the end of those three days was meaningfully different from the artifact at the start.

Give your agent the ability to test its changes out in the simulator using the accessibility APIs and Josh’s ios-build-verify plugin for Claude Code. The article itself is a highly detailed look at why you need something like this, and some of the issues he faced when developing it.

I loved Paulo Andrade’s post where he dives into adding that last layer of macOS polish. Is it possible to get there with SwiftUI? It really should be, but unfortunately he concludes that we’re still not quite there yet. Depressingly, he concludes that it might not even be a priority:

Looking through past Apple Design Awards, Agenda in 2018 may well have been the last truly Mac-assed winner. That feels revealing.

I really hope we get there one day, with this level of polish becoming possible in SwiftUI. I love a good Mac-assed Mac app.

Business and Marketing

Mike Swanson:

One of the most dangerous things about analytics is that they feel objective. A chart is a chart. A number is a number. They have the aesthetic of truth.

I really enjoyed this look at how software has evolved over the years, and whether it’s any better as a result. My view is slightly less critical than Mike’s, but it made me think, and I’m sure it will make you do the same.

Videos

One of the things I love about try! Swift Tokyo is the completely (well, mostly) different lineup of speakers. If you didn’t manage to make it to Japan, give some of the videos a watch this weekend!

And finally...

Swift on a Game Boy Advance? Yep!

Job postings that came across my desk, slack, email, discord, etc this week.

The post Job listings for week ending 5/8 appeared first on Leon Adato.