I don't know this mirroring feature too well, but what's missing that a third party couldn't implement the same thing for android? Like scrcpy works. Its not as polished, but thats a ui/presentation issue. Are there features in macos that enable iOS mirroring that only Apple can use?

▲ supermatt 19 hours ago | parent [-]

I haven’t used it much (I am in the EU) so I can’t give an extensive list. But a few I noticed when I was in UK:

  - You can initiate from the MacBook.
  - you don’t need to wake and unlock the phone manually 
  - the phone itself stays physically locked
  - drag/drop

Basically you can keep it in your pocket/bag instead of physically holding and unlocking it.

Mirroring aside there’s things like remote copy/paste, continuity with desktop apps, etc.

Edit: Wow, downvotes for what exactly? Because I own an iPhone and MacBook or because I dislike Apples shitty business practices?

▲

tonyedgecombe 18 hours ago | parent [-]

I can see why Apple might be reluctant to open this technology up to third parties, it would be a nightmare to keep it secure.

▲

supermatt 18 hours ago | parent [-]

Why should that be apples decision to make? There are many software vendors with much better security track records than apple.

▲

tpmoney 18 hours ago | parent [-]

Because Apple’s reputation (and customer trust in the ecosystem) depends on their security posture, and the less headlines that involve 3rd party applications on your computer being able to read the iPhone clipboard while the phone remains locked the better?

Also because people should have the choice to buy a device from a vendor that is locked down if that is what they want.

▲

supermatt 17 hours ago | parent | next [-]

Then they should enable interoperability. Either provide a secure platform that others can access, or let third parties offer their own. The whole point of passkeys is to handle remote authentication and authorisation securely - and is effectively what Apple are already doing under the hood.

This whole "we can only trust Apple" argument is outdated given modern security standards like FIDO2/WebAuthn and passkeys

▲

_aavaa_ 18 hours ago | parent | prev [-]

Nothing about providing the API for this requires that your phone automatically accept such requests.

They can change it so that all first requests require confirmation with password.

	▲	tpmoney 17 hours ago \| parent [-]
		And you can secure your HTTP server and SSH server with credentials too, but if your wanting a secure internal service it’s also probably a good idea to put a firewall in place and only allow access from authorized endpoints. Security isn’t a binary thing. It comes in layers and “no publicly accessible API” is (or at least can be) more secure than “public API”.