Microsoft engineers have published benchmark results showing that a Chromium-based browser using its own rendering engine scores 28.6% higher than Safari on Apple's own Speedometer 3.1 performance test on iOS.


Kyle Pflug, group product manager for the Microsoft Edge Web Platform, published results on Monday comparing a research prototype of Edge built with Apple's BrowserEngineKit framework against Safari running iOS 26.5.1. The Blink-based prototype scored 49.27 versus Safari's 38.3 on Speedometer 3.1, and also outperformed Safari on the JetStream 3 JavaScript benchmark by 13.1% (306.35 vs. 270.9) and on the MotionMark 1.3.1 graphics rendering benchmark by 2.1% (4,773.52 vs. 4,673.68). Pflug described the work as a research prototype rather than a finished product, and the numbers as preliminary results from his own device rather than lab conditions.

Apple requires all browsers on iOS to use WebKit, the engine that powers Safari, meaning browsers like Chrome and Firefox on iPhone are effectively reskinned Safari instances. The EU's Digital Markets Act theoretically changed that in March 2024, requiring Apple to allow alternative browser engines through BrowserEngineKit, yet more than two years later no browser maker has shipped an alternative engine on iOS. Companies cite technical barriers and the requirement to publish any such browser as an entirely separate app from their existing WebKit-based version.

Open Web Advocacy told The Register the results illustrate a 17-year cost to consumers. The group called on the European Commission to open a specification proceeding instructing Apple precisely how it must remove barriers to alternative engines, adding that restricting browser engines allows Apple to limit what the mobile web is capable of and keep businesses dependent on native apps and App Store rules.
This article, "Apple's WebKit Rules Reportedly Cost iOS Users Almost 30% Browser Performance" first appeared on MacRumors.com

Discuss this article in our forums

Apple's decision to move Hide My Email to a dedicated "private.icloud.com" domain appears to have the consequence of making it easier for platforms that want to block iCloud aliases to do so.


Apple is unifying the email domains used by Sign in with Apple and ‌iCloud‌+ Hide My Email under a single private.icloud.com domain later this summer. Sign in with Apple currently uses privaterelay.appleid.com, while Hide My Email uses icloud.com, the same domain as standard ‌iCloud‌ email addresses.

That shared domain has historically made it difficult for services to selectively block disposable ‌iCloud‌ addresses. Blocking icloud.com outright would also block legitimate users with standard Apple email accounts. With the new subdomain, that tradeoff disappears.

@vxdb on X was among the first to flag the implication: "platforms who want to ban ‌iCloud‌ aliases can now do so by banning this new subdomain without affecting all ‌iCloud‌ users." Others online noted that email services, signup flows, and anti-abuse systems will now have a clean, unambiguous target if they choose to restrict alias-generated addresses.

Apple has said that existing addresses on legacy domains will continue to work and that mail will be forwarded with no interruption, so current Hide My Email users won't lose access to their aliases. New addresses generated after the migration, however, will feature the private.icloud.com domain, and it is those addresses that become blockable in isolation for the first time.
This article, "Apple's New Hide My Email Domain Makes It Easier to Block iCloud Aliases" first appeared on MacRumors.com

Discuss this article in our forums

macOS 27 Golden Gate removes AFP support, ending Time Machine compatibility with Time Capsule after nearly two decades, but a community project from a Microsoft engineer offers a potential workaround for owners not yet ready to move on.


Apple's Time Capsule was introduced at Macworld Expo in January 2008, combining a Wi-Fi router with NAS-style network storage designed to work in tandem with the Time Machine backup software. Apple officially ended development on the entire AirPort line in April 2018, with the AirPort Express at $99, the AirPort Extreme at $199, and the AirPort Time Capsule at $299, available only while supplies lasted. The lineup sold out entirely by November 2018. Prior to that, Apple had not updated its AirPort products since 2013.

AFP dates back to 1988, when Apple designed a native file-sharing protocol for the Macintosh as part of the AppleTalk networking suite. SMB became the primary file-sharing protocol in OS X 10.9 Mavericks in 2013, and the ability to run an AFP server was removed in macOS 11 Big Sur in 2020.

Apple formally deprecated the AFP client in macOS Sequoia 15.5, and, when macOS 26 Tahoe launched, a warning in System Settings confirmed that AFP support and Time Capsule compatibility would end with macOS 27. As expected, the first developer beta of macOS 27 Golden Gate contains no AFP client at all, ending a protocol with more than 40 years of history in the Apple ecosystem.

All Time Capsule models rely on AFP and SMBv1, the original Server Message Block version from 1987. From macOS 27 onwards, Time Machine requires SMBv2 or SMBv3, which covers modern NAS hardware but rules out every Time Capsule model in its stock form. macOS 27 also enforces stricter network security requirements, including TLS 1.2 as a minimum, which is a bar that Time Capsule hardware cannot meet.

The community response is a GitHub project called TimeCapsuleSMB, created by James Chang, an engineer at Microsoft. Rather than replacing Apple's firmware, it installs a modern Samba build directly onto the Time Capsule. The device runs a Samba 4.24.3 server, advertises itself over Bonjour, and accepts authenticated SMB3 connections, so users can connect via a standard SMB URL in Finder rather than relying on Apple's legacy stack.

Only the fifth-generation Time Capsule tower model from 2013 auto-restarts the Samba server after a reboot. Earlier models require a manual activate command every time the device loses power, meaning backups may silently stop after an outage. It is also worth noting that switching to SMB via TimeCapsuleSMB begins a new Time Machine backup chain, with the new destination treated as a fresh start. There is no published long-term restore testing for the project, so a second backup destination is advisable.

macOS 27 Golden Gate is currently in developer beta, with a public beta due in July and a general release set for September. It is compatible only with Apple silicon Macs, meaning Intel Mac users who stay on macOS 26 can continue using Time Capsule for the foreseeable future. Apple silicon owners who want to upgrade will need a compliant backup target in place first, whether that is a modern NAS, an external drive, or a patched Time Capsule running TimeCapsuleSMB.
This article, "macOS 27 Golden Gate Kills Time Capsule Support" first appeared on MacRumors.com

Discuss this article in our forums