Juli Clover (Hacker News, Reddit):
The Digital Markets Act requires Apple to provide third-party accessories with the same capabilities and access to device features that Apple’s own products get. In iOS 26.3, EU wearable device makers can now test proximity pairing and improved notifications.
Here are the new capabilities that Apple is adding:
- Proximity pairing - Devices like earbuds will be able to pair with an iOS device in an AirPods-like way by bringing the accessory close to an iPhone or iPad to initiate a simple, one-tap pairing process. Pairing third-party devices will no longer require multiple steps.
- Notifications - Third-party accessories like smart watches will be able to receive notifications from the iPhone. Users will be able to view and react to incoming notifications, which is functionality normally limited to the Apple Watch.
I’m looking forward to Apple’s blog post about how easier Bluetooth pairing will put users at risk. The notification forwarding was previously announced, but I didn’t realize it also included support for reactions.
Steve Dent:
However, there’s no indication that it will allow seamless switching between devices as you can do with Apple’s [AirPods], for instance.
Previously:
Update (2025-12-26): Steven Aquino:
I could be wrong, but it sounds like Apple’s using its AccessorySetupKit API for this.
[…]
In the end, this week’s news should make disabled people living in the European Union really happy because product pairing is about to become a way more accessible experience.
These benefits aren’t exclusive to Apple. Google’s “Fast Pair” does it on Android too.
AirPods Antitrust Bluetooth Digital Markets Act (DMA) European Union iOS iOS 26
Joe Rossignol (Slashdot):
Due to regulatory action, Apple has agreed to allow alternative app stores, third-party payment systems for in-app purchases, and in-app links to external offers on iOS in Brazil, according to legal news website MLex and Brazilian blog Tecnoblog.
Previously:
Update (2025-12-26): Hartley Charlton (Slashdot):
CADE specified that Apple may still display warnings or informational messages to users, but those messages must be neutral, objective, and limited in scope, and must not introduce extra steps or barriers that make alternative options harder to use.
According to Brazilian technology site Tecnoblog, which said it obtained the details directly from CADE, purchases made through the App Store will remain subject to a 10% or 25% commission under standard terms. Developers who use Apple's payment system would also pay a 5% transaction fee.
If an app directs users to pay outside the app using only static text, with no clickable link or button, Apple will not charge a fee. If the app includes a clickable button or link that sends users to an external website for payment, Apple will charge a 15% fee. Third-party app stores will be subject to a 5% Core Technology Commission.
Marcus Mendes:
In 2022, Latin American e-commerce giant MercadoLibre filed a complaint with Brazil’s competition watchdog, the Conselho Administrativo de Defesa Econômica (CADE), challenging Apple’s iOS App Store rules, including restrictions on app distribution and the mandatory use of Apple’s in-app payment system.
Since then, the legal back-and-forth closely followed the script seen in other countries where Apple has faced similar antitrust scrutiny. Both Apple and MercadoLibre scored legal wins, which were immediately challenged by the opposing side.
[…]
In a statement provided to 9to5Mac, Apple said:
In order to comply with regulatory demands from CADE, Apple is making changes that will impact iOS apps in Brazil. While these changes will open new privacy and security risks to users, we have worked to maintain protections against some threats, including keeping in place important safeguards for younger users. These safeguards will not eliminate every risk, but they will help ensure that iOS remains the best, most secure mobile platform available in Brazil and we will continue to advocate on behalf of users and developers.
Antitrust App Marketplaces Brazil Business External iOS Payments iOS iOS 26 Legal
Juli Clover:
Apple and Google are teaming up to make it easier for users to switch between iPhone and Android smartphones, according to 9to5Google. There is a new Android Canary build available today that simplifies data transfer between two smartphones, and Apple is going to implement the functionality in an upcoming iOS 26 beta.
[…]
The collaboration will apparently add “more functionality” and support for transferring data types that are not available to transfer with the current tools.
This is good, but I don’t love that it seems to be a private arrangement between Apple and Google. We should all be able to get a dump of our own data.
Juli Clover:
The simplified smartphone switching Apple and Google are adopting is an example of how the Digital Markets Act (DMA) benefits users and developers, the European Commission said today. Apple and Google are making it easier for users to switch between iPhone and Android smartphones, adding an option to transfer data from another smartphone during the device setup process.
Apple and Google are implementing this functionality because the DMA requires services to offer effective data portability to avoid data lock-in to an operating system.
[…]
The DMA is also the reason why Apple and Google designed a simplified eSIM transfer solution earlier this year.
Previously:
Update (2026-01-22): Tim Hardwick:
Chrome for iOS will soon feature an option for iPhone users to import their Safari data into Google’s mobile browser, avoiding the need to perform the transfer on desktop.
Android Antitrust Digital Markets Act (DMA) European Union Google Chrome iOS iOS 26 iOS App MobileSafari
Thijs Xhaflaire:
Jamf Threat Labs observed a signed and notarized stealer that did not follow the typical execution chains we have seen in the past. The sample in question looked highly similar to past variants of the increasingly active MacSync Stealer malware but was revamped in its design.
Unlike earlier MacSync Stealer variants that primarily rely on drag-to-terminal or ClickFix-style techniques, this sample adopts a more deceptive, hands-off approach. Delivered as a code-signed and notarized Swift application within a disk image named zk-call-messenger-installer-3.9.2-lts.dmg , distributed via https://zkcall.net/download, it removes the need for any direct terminal interaction. Instead, the dropper retrieves an encoded script from a remote server and executes it via a Swift-built helper executable.
Bill Toulas (Reddit):
The stealer emerged in April 2025 as Mac.C by a threat actor named ‘Mentalpositive’. It gained traction by July, joining the less crowded but still profitable space of macOS stealers alongside AMOS and Odyssey.
A previous analysis of Mac.C by MacPaw Moonlock indicates that it can steal iCloud keychain credentials, passwords stored on web browsers, system metadata, cryptocurrency wallet data, and files from the filesystem.
Jeff Johnson (Mastodon):
I hate to say I told you so but…who am I kidding, I love to say I told you so. In 2019 I wrote a prescient blog post, The true and false security benefits of Mac app notarization, in which I foretold such an attack, suggesting that notarization is security theater.
[…]
Many of the Mac malware “protections” that Apple has added over the years are merely punishments for Mac users and honest Mac developers, making their computing life more miserable while leaving gaping holes for malware to sneak through. (See my own Apple Security Credits, as a Mac developer, not a professional security researcher, and those are just issues that Apple fixed, not all of the issues I discovered.) Earlier this month 9to5Mac also reported, Apple security bounties slashed as Mac malware grows, a tacit admission by Apple of this hopeless situation.
Céline Didone:
it was always about creating fear around the well established practice of installing apps from outside the App Store.
Previously:
Update (2025-12-30): Jeff Johnson (Mastodon, Rosyna Keller):
My assumption all along was that notarization is intended to stop malware authors from distributing their own maliciously crafted apps, and in this respect I still think notarization is security theater. However, perhaps my assumption was wrong. What if the purpose of notarization is more narrowly focused, to prevent supply chain attacks like XcodeGhost? The requirement of uploading the built app to Apple for a malware scan is not very good at stopping a determined attacker with full control over app creation, submission, and distribution who is intentionally trying to sneak malware past Apple. On the other hand, the notarization requirement can stop an unwitting developer who is unintentionally distributing known malware in their app only as a carrier, a dupe, already a victim themselves.
The timeline of notarization seems a bit off, three years between 2015 and 2018 for Apple to engineer a mitigation for the massive, damaging XcodeGhost supply chain attack. I don’t see a sense of urgency there; it would be practically lackadaisical. Nonetheless, the motivation and implementation would make sense in light of XcodeGhost.
Is this blog post a mea culpa by me? Maybe! I now acknowledge there may be some security benefit to notarization. Whether the benefit outweighs the many downsides is another question, though. In any case, it would have been nice if Apple had made some kind of public, official statement like, “Hey, we’re introducing notarization because of XcodeGhost,” and then the whole thing would have made sense to everyone from the beginning. Instead, Apple chose its habitual path of greatest resistance, security by obscurity.
Previously:
Mac macOS Tahoe 26 Malware Notarization
