WWDC Quick Look πŸ’“ By SwiftGGTeam
What's new in privacy

What's new in privacy

Watch original video

Highlight

Privacy updates in iOS 18 and macOS Sequoia center on one core design philosophy: breaking β€œfull authorization” into β€œprecise selection”, letting users share only necessary data fragments through system-level Pickers (26:31).


Core Content

For a long time, apps requesting sensitive data permissions had only two options: full authorization or denial. That put users in a dilemmaβ€”wanting one feature meant handing over far more data than needed. An expense app might only need work-related transactions but had to access full bank statements; a setup app might only need to connect a camera once but required full Bluetooth scanning capability.

iOS 18 and macOS Sequoia solve this with system-level Pickers. Pickers are rendered by the system; apps cannot read their contents (02:11). After users select specific data in a Picker, only the selected portion is shared with the app. This turns β€œauthorization” into β€œselection”, so users no longer need to over-share.

New Pickers this year cover three areas: FinanceKit’s transaction picker lets users share specific financial transactions instead of entire bank statements (03:09); the Image Playground API gives apps only the final selected generated image while generation stays fully system-hosted (04:57); AccessorySetupKit merges three permission dialogsβ€”Bluetooth pairing, Wi-Fi connection, and device confirmationβ€”into one picker (05:58).


Detailed Content

New Data Pickers

FinanceKit Transaction Picker

This is the new way to access financial data from Apple Card, Savings, Apple Cash, and more. When you request access to financial transaction data, the system shows two options (02:34):

Transaction Picker
β”œβ”€ Use case: Only need access to a batch of existing transactions
β”œβ”€ User behavior: Search and select specific transactions in a system-rendered list
└─ Data result: Only selected transactions are shared

Ongoing Access Control
β”œβ”€ Use case: Need continuous, full financial data access
β”œβ”€ User behavior: Select accounts to share and set earliest share date per account
└─ Data result: Full data stream matching the time range
Key points
β”œβ”€ Transaction picker does not require FinanceKit Entitlement
β”œβ”€ Ongoing access requires successfully applying for FinanceKit Entitlement
β”œβ”€ Users can set "earliest share date" per account individually
└─ This selection layer lets users control whether older, more sensitive data is shared

Image Playground API

System-provided on-device image generation integrated into your app as a Sheet (04:57). Flow:

1. App presents Image Playground Sheet
2. Optional: provide text prompts or reference images
3. User iterates on image generation in a system-hosted environment
4. Only the user's final selected image is shared with the app
Key points
β”œβ”€ No permission dialog required
β”œβ”€ Image generation and selection are system-hosted; apps cannot peek
β”œβ”€ Only the final selected image is shared
└─ Generation completes entirely on device

AccessorySetupKit

Unified solution for Bluetooth accessory pairing, consolidating three previously separate permission flows (05:58):

Old flow (3 separate dialogs)
β”œβ”€ Bluetooth pairing prompt
β”œβ”€ Wi-Fi network join prompt
└─ Bluetooth accessory pairing confirmation

New flow (AccessorySetupKit, one step)
β”œβ”€ Complete Bluetooth pairing and Wi-Fi connection in one tap
β”œβ”€ App can access paired devices
β”œβ”€ App cannot discover devices never paired before
└─ Rename accessories and manage permissions in Settings
Key points
β”œβ”€ Does not require full Bluetooth scanning permission
β”œβ”€ After pairing, app can only access devices paired with that app
β”œβ”€ Can unbind devices in the new accessories menu
β”œβ”€ Can share accessory permissions with other apps
└─ Preferred pairing approach in iOS 18

Platform Protection Upgrades

Private Wi-Fi Address

iOS MAC address randomization now includes rotation; macOS gets MAC address protection for the first time (08:11):

Before iOS 18
└─ Each Wi-Fi network uses one random MAC address

After iOS 18
β”œβ”€ With "Rotate Wi-Fi Address" on: MAC address rotates roughly every two weeks
β”œβ”€ With "Rotate Wi-Fi Address" off: random address for that network stays fixed
β”œβ”€ Forgotten networks: rotate within 24 hours at most
β”œβ”€ Public networks: rotation enabled by default
└─ Other networks: random address by default
Key points
β”œβ”€ MAC address is not protected by Wi-Fi security modes
β”œβ”€ Visible and trackable by all devices on the same network
β”œβ”€ iOS 18 setting renamed from "Private Wi-Fi Address" to "Rotate Wi-Fi Address"
└─ macOS now has the same rotation policy as iOS

macOS Extension Transparency

macOS now shows system notifications when extensions are installed and provides unified management in Login Items & Extensions settings (10:17):

Changes
β”œβ”€ System notification when extensions are installed
β”œβ”€ More extension types support notifications and settings control
β”œβ”€ Cron disabled by default; can be re-enabled in the same settings window
β”œβ”€ Login items and extensions now unified in System Settings
└─ Deprecated: Directory Services plug-in, legacy QuickLook plug-ins, com.apple.loginitems.plist

App Group Container Protection

macOS now provides sandbox protection for App Group containers (12:23):

Single app container (existing mechanism)
β”œβ”€ App Sandbox restricts access to protected resources
β”œβ”€ Prompt shown when one app tries to access another app's container
└─ User can allow or deny

App Group container (new protection)
β”œβ”€ Multiple apps can share data
β”œβ”€ Prompt shown when another developer's app tries to access
β”œβ”€ Can use protected group containers only for sensitive data (such as browsing history)
└─ Avoid prompts by: correctly declaring Entitlement, using correct Group ID, using Foundation APIs only

Permission Flow Improvements

Contacts Permission

iOS 18 introduces a two-stage dialog for contacts permission (15:30):

Two-stage flow (for apps requesting access to multiple contacts)
β”œβ”€ Stage 1: Ask whether to share contacts
└─ Stage 2: Choose "Limited Access" or "Full Access"

Contact Access Button (for contact search scenarios)
β”œβ”€ No full-screen Picker required
β”œβ”€ Can embed in your own UI
β”œβ”€ Share contacts with a light tap
└─ Does not require full, continuous contacts access
Key points
β”œβ”€ Two-stage flow enabled automatically; no new API adoption required
β”œβ”€ Contact Access Button suits scenarios like searching email recipients
└─ Few apps truly need full, continuous contacts access

Bluetooth Permission

iOS 18 Bluetooth authorization dialogs now clearly show data types exposed by Bluetooth access and potential risks (17:21):

New dialog content
β”œβ”€ Map showing device's current location
β”œβ”€ Examples of associated devices
β”œβ”€ Information Bluetooth access may leak
β”‚   β”œβ”€ Device location
β”‚   └─ Unique device identifiers used for tracking
└─ Combined with your usage description string to help informed decisions
Key points
β”œβ”€ Granting continuous Bluetooth access is a significant choice
β”œβ”€ New dialog enabled automatically; no new API adoption required
β”œβ”€ AccessorySetupKit is a better choice when full Bluetooth access isn't needed
└─ Clear usage description strings are key to building trust

Local Network Permission

macOS Sequoia introduces permission control for local network access (18:14):

Applicable scenarios
β”œβ”€ Using Bonjour browse or broadcast
β”œβ”€ Using custom multicast, broadcast, or unicast connections
└─ Any connection relying on the local network

Requirements
β”œβ”€ Must include local network usage description in Info.plist
β”œβ”€ If Bonjour Services key exists, must include NSLocalNetworkUsageDescription
β”œβ”€ If Networking Multicast entitlement exists, must include description
└─ Access blocked when requirements aren't met

New Platform Capabilities

App Lock and Hide

iOS 18 lets users lock and hide any app (20:06):

Effects
β”œβ”€ Face ID, Touch ID, or passcode required before accessing app
β”œβ”€ All entry points (such as Share Sheet actions) require authentication
β”œβ”€ Content won't appear in search or notifications
└─ Others can't accidentally see sensitive information

Automatic Passkey Upgrade

iOS 18 and macOS Sequoia support automatically upgrading existing accounts to passkeys at sign-in (21:48):

Benefits
β”œβ”€ Passkeys are standards-based password replacements
β”œβ”€ Easier to use, more secure, phishing-resistant
β”œβ”€ Can automatically upgrade existing accounts during sign-in
β”œβ”€ Coexist with passwords; no login flow changes required
└─ Reduces password management burden on users

Live Caller ID and Private Information Retrieval

New caller ID tools use private relay and homomorphic encryption for private information retrieval (21:49):

Workflow
β”œβ”€ Device sends encrypted phone number to server
β”œβ”€ Server computes on ciphertext (without decrypting)
β”œβ”€ Server evaluates matches
└─ Returns transformed ciphertext to device

Key points
β”œβ”€ Server never sees plaintext phone numbers
β”œβ”€ Uses homomorphic encryption to compute on ciphertext
β”œβ”€ Open-source server configuration resources coming late 2024
└─ See documentation: Getting up-to-date calling and blocking information for your app

Core Takeaways

1. Use Pickers instead of full permissions

For sensitive data like accessory pairing, contacts, and transaction records, prefer system Pickers over requesting full permission access. Pickers let users share only necessary data fragments, protecting privacy and reducing data your app must manage.

Why it’s worth doing: Users are more willing to use features when they clearly control data sharing scope, improving feature adoption.

How to start: Review all sensitive data scenarios in your app and check whether a corresponding Picker (AccessorySetupKit, Contact Access Button, FinanceKit Transaction Picker) can replace full access.

2. Prepare clear usage descriptions for local network and Bluetooth access

Local network and Bluetooth permission dialogs in iOS 18 and macOS Sequoia now clearly show data types exposed by access. Clear usage description strings are key to building user trust.

Why it’s worth doing: Users seeing permission dialogs without context are more likely to deny access. Good descriptions improve authorization rates.

How to start: Review all local network and Bluetooth usage description strings in Info.plist; ensure they clearly describe how your app uses the data.

3. Use AccessorySetupKit to simplify accessory pairing

If your app pairs Bluetooth accessories, AccessorySetupKit merges three separate permission flows into oneβ€”smoother UX and more precise privacy protection.

Why it’s worth doing: Reduces permission dialog confusion, improves pairing success rate, and app can only access paired devicesβ€”aligning with least privilege.

How to start: See the β€œMeet AccessorySetupKit” session to learn how to migrate existing pairing flows to the new API.

4. Consider enabling passkeys for sensitive features

If your app uses passwords for account protection, consider supporting passkeys and automatic upgrade. This provides a more secure, easier sign-in experience.

Why it’s worth doing: Passkeys are more secure and phishing-resistant than passwords, reducing password management burden.

How to start: See β€œStreamline sign-in with passkey upgrades and credential managers” to learn how to implement automatic passkey upgrade in your app.


Comments

GitHub Issues Β· utterances