Privacy and security are not one feature you add at the end. They shape authentication, cloud processing, AI agents, telemetry, App Store privacy labels, app architecture, platform APIs, and how clearly you explain your app’s behavior to users.
As usual, the goal is simple: make the questions easier to scan, easier to revisit, and easier to connect with real app development problems.
I tried to preserve the original wording and combine related answers where appropriate. However, some inaccuracies or mismatches are still possible.
Enjoy! And subscribe so you don’t miss the next Lab.
Prompt injection becomes especially important with agentic systems because a model may have access to private data, the ability to perform actions, and untrusted context.
The panel called out indirect prompt injection as a specific risk. In that attack, a malicious document, message, or other piece of content enters the model’s context and tries to make the model do something the user did not intend.
Apple treats this as a new class of security and privacy risk. For features such as Siri AI and other agentic experiences, the teams design mitigations before the feature ships.
Those mitigations include deterministic approaches, such as confirmation prompts where the user explicitly approves an action, and probabilistic approaches, such as spotlighting parts of a prompt so the model can distinguish trusted instructions from untrusted content.
The practical developer lesson is to think carefully about the “lethal trifecta”: private data, actions, and untrusted context. If your agentic feature combines all three, you need a strong security design.
Private Cloud Compute and third-party AI APIs are different cases.
When you use Apple’s Private Cloud Compute through Apple APIs, Apple’s PCC guarantees apply. The panel highlighted stateless computation, non-targetability, enforceable guarantees, cryptographic proof, and public documentation and tooling that developers or security researchers can use to verify Apple’s claims.
Data sent to PCC is used only to fulfill the request. It is not available for Apple or anyone else to inspect, and the node removes the data after the request. If the node reboots, the persistent volume that could hold data is wiped clean.
For third-party APIs, Apple’s PCC guarantees do not apply. If you send user data to Anthropic, Google, or another provider, you need to read that provider’s terms and documentation, understand what they do with the data, and explain that clearly to users.
The practical rule is simple: if data leaves your app through a third-party service, you are responsible for understanding and communicating that service’s data handling.
For App Store privacy labels, you are responsible for declaring data collected from your app, whether it goes to your own servers or to another company’s service.
That means a third-party processor does not automatically remove your responsibility. You still need to understand what data leaves the app, whether it is linked to the user, what purpose it is used for, and what the third party does with it.
The point of the privacy label is to give users the full picture of your app’s privacy practices. If the user’s voice or photo data is sent to an outside service, even only for processing, that relationship needs to be understood and represented accurately.
The same broad agentic-security concerns apply: untrusted context, private data, and actions. Xcode adds another dimension because agents may interact with tools, source code, project files, build systems, and the developer’s local environment.
Apple designs these features with a secure-by-design approach. The panel mentioned additional mitigations around Xcode, including allow-listing common tools when Xcode is used as an MCP server.
The best practice is to treat agentic coding tools as powerful assistants, not fully trusted actors. Be deliberate about which tools the agent can call, which files it can access, and which actions require human approval.
Review code changes and understand generated behavior before committing or shipping. Agentic coding can accelerate development, but it does not remove the need for code review and security thinking.
The panel pointed developers to Apple’s in-depth Private Cloud Compute security guide for the full technical explanation.
At a high level, PCC is built around stateless compute, verifiable privacy, transparency, and enforceable guarantees. Apple publishes documentation and tooling so researchers can independently verify that deployed PCC software matches the public guarantees.
PCC also uses attestation. The discussion called out additional security layers in the Google Cloud PCC deployment, including requiring two verifiable attestations for hardware from two separate vendors.
Apple also isolates complex parsing work, such as image parsing, into separately sandboxed nodes where needed. This may add latency, but it reduces risk when processing complex data formats.
The larger point is that Apple is not asking developers or users to simply trust the cloud. PCC is designed so claims about software, node identity, and data handling can be checked continuously. If rogue software were deployed to a node, attestation would change and devices would reject it.
The panel framed this as a mix of tooling, architecture, and developer responsibility.
Generative AI and coding agents can help you review your app’s privacy and security assumptions. You can describe what your app promises, what data it handles, and where that data flows, then use the model as one tool to look for gaps.
Apple also provides platform APIs that are secure and private by default where possible. CloudKit is a good example: it lets you sync user data across a user’s devices without running your own server, which can reduce the amount of infrastructure risk you take on.
But you still need to reason about your app. For security, start by asking what inputs enter the app and how much you trust them. For privacy, ask what user data you collect, where it goes, and who you vend it to.
The panel’s reminder was direct: developers are partly responsible for the privacy and security of the people who use their apps. Use platform-native tools, but do not stop thinking critically about data flows.
Start with the platform frameworks that reduce how much sensitive work you need to build yourself.
For account security, adopt passkeys instead of passwords when you can. Passkeys reduce phishing risk, simplify sign-in, and remove a lot of password-reset friction.
For secrets and credentials, use Keychain and choose the right data protection class. For cryptographic work, use CryptoKit instead of inventing your own crypto. For cloud sync, use CloudKit where it fits, because Apple handles much of the secure synchronization work for you.
For privacy, practice data minimization. Ask whether you need the data at all. If you only need a photo, contact, file, or location once, consider an out-of-process picker or a more limited permission rather than asking for broad access.
For telemetry, start with the question you actually need answered. If a metric will not lead to a product or code decision, do not collect it. Use the least identifying identifier that works: a session identifier may be better than a device identifier, and many cases should not need a real user identity at all.
Use the strongest protection that still allows the app experience to work.
For local data, use data protection classes. For very sensitive data, the panel suggested protection that is only available when the device is unlocked, and for keys in Keychain you can require biometric unlock where appropriate.
For CloudKit, use encrypted values so sensitive data remains protected when synchronized across a user’s devices. For users with Advanced Data Protection enabled, CloudKit encrypted values can be end-to-end encrypted.
Search and indexing require a careful tradeoff. If content needs to be indexed after the device locks, use the right data protection class for that requirement. The panel mentioned classes that keep data available for a limited time after locking, allowing background indexing to complete before the key becomes unavailable.
The practical model is to separate what must be highly protected from what must remain searchable, and to choose data protection classes and CloudKit encryption deliberately instead of storing everything at the same level.
It depends on which feature you are using.
Existing code-completion features can run entirely on device and work offline.
Other features that integrate with cloud-based coding systems, such as Claude Code or OpenAI Codex-style integrations, require internet access. Those cannot work in a fully air-gapped environment because the request needs to leave the device.
The short version: local completion can work offline; cloud-backed agentic coding features need the network.
Siri AI uses several layers of protection.
Some work happens on device. When larger models are needed, Siri can use Private Cloud Compute, which brings the PCC guarantees discussed earlier: stateless computation, attestation, enforceable guarantees, and data used only to fulfill the request.
On device, Apple uses platform technologies such as sandboxing, entitlements, and controlled system daemons to gather and process the context needed for Siri. Not every process can access that user data.
When third-party apps are involved, data is minimized. Siri does not simply hand over extra private context to an app. It shares what is needed for the user-directed action.
User consent systems still matter. If Siri needs access to protected categories such as location, the same kinds of privacy controls and prompts apply.
The panel also emphasized Apple silicon as a privacy technology: more local compute means more work can stay on device, inside the platform’s security boundaries.
TCC stands for transparency, consent, and control.
It refers to the protections that let apps request access to protected user data such as photos, microphone, camera, contacts, location, and similar categories.
The point is that users can see what an app is asking for, decide whether to grant access, and retain control. If an app has not asked for microphone access and the user has not granted it, the app should not be able to access microphone data.
TCC is one of the core privacy systems developers interact with when building apps for Apple platforms.
Yes.
The panel said existing MDM controls for Siri should still apply. Enterprises should think carefully about which parts of Siri AI they want to allow or restrict in their environments.
If an enterprise has specific policy needs, the recommendation was to file feedback. Apple wants to understand how organizations want to configure these tools, especially when some features may be useful while others need stricter control.
The panel did not announce a specific new ITP feature in this lab.
They emphasized that Intelligent Tracking Prevention continues to be an area Apple invests in over time. It has evolved for years and remains an important privacy technology.
For technical details and updates, the panel pointed developers to WebKit resources such as webkit.org.
Make trust observable.
App Store privacy labels are one place to start because they create a standardized way for users to compare privacy practices before downloading an app.
Inside the app, be transparent about what data you have and why. If you collect or process user data, do not hide that fact. Give users a way to understand and control it.
The panel also discussed the idea of privacy assurances: simple, understandable promises about what the app does and does not do with user data. Those assurances can become a guiding light for architecture and implementation. If the architecture cannot satisfy the assurance, the design needs to change.
Avoid vague statements such as “we care about privacy.” Explain the actual behavior: what data is used, what stays on device, what is encrypted, what is shared, and what controls the user has.
Start with the fundamentals that sit underneath every secure app: memory safety, system isolation, authentication, cryptography, and permission boundaries.
On Apple platforms, that means learning how sandboxing, entitlements, code signing, Keychain, CryptoKit, Network framework security, data protection classes, and TCC fit together. These are not isolated features; they form the security model your app runs inside.
For app security, learn how to handle untrusted inputs, how to store secrets, how to design least-privilege data access, and how to use platform APIs instead of inventing your own security mechanisms.
For privacy, learn the data-flow questions: what data enters the app, where it is stored, whether it leaves the device, who receives it, and whether the user understands and controls that use.
The panel also encouraged students interested in cybersecurity and privacy to keep an eye on Apple roles, because these teams hire for exactly this kind of work.
Start with the platform security fundamentals before trying to memorize every API.
For Apple platforms, that means understanding sandboxing, entitlements, code signing, Keychain, CryptoKit, Network framework security, data protection classes, passkeys, and TCC. These concepts explain how apps are isolated, how secrets are stored, how permissions are granted, how data is protected at rest, and how the system keeps untrusted code away from sensitive user data.
For app security, focus on untrusted input, least privilege, credential handling, safe networking, and using platform APIs instead of inventing custom security mechanisms.
For privacy, learn to map the data flow: what data enters the app, where it is stored, whether it leaves the device, who receives it, and whether the user understands and controls that use.
The panel also noted that Apple hires for cybersecurity and privacy roles, so students interested in this area should keep an eye on those opportunities.
Passkeys are part of a broad standard, and Apple participates in the standards work around them.
The panel noted that passkeys only work well if they can sync and interoperate across the ecosystem, so this is not something one company can solve alone. Apple is working with other companies through the standards process to make passkey lifecycle behavior more reliable.
The practical issue is that servers and clients need a way to understand when a passkey is still valid, has been removed, or should no longer be offered. That kind of lifecycle signaling matters for keeping account state and credential state aligned.
The panel did not present this as an Apple-only mechanism. It framed the answer as an ecosystem and standards effort, where Apple is involved because passkeys need broad cross-company compatibility.
Start with Hardened Runtime.
On macOS, Hardened Runtime helps protect your process memory. It prevents common attack paths such as another process injecting unsigned or unverified code into your process, spinning up malicious threads, attaching a debugger, or reading memory in ways that would expose sensitive data.
If you are asking how to protect in-process memory, the panel’s first recommendation was to enable Hardened Runtime.
For secrets that only need to live briefly in memory, the panel suggested thinking about destruction rather than encryption. If a password, token, or key is needed only for a short operation, clear it as soon as you no longer need it. Encrypting data in memory may not be the right answer if the real goal is to minimize how long the secret exists there at all.
For cryptographic keys, the panel also called out Secure Enclave-backed keys. You can generate a key that is bound to the Secure Enclave on that device, which means that even if an attacker compromises the app, the process, or the device, the key cannot simply be exported and used somewhere else. It depends on the Secure Enclave hardware of that particular device.
You can also use attestation APIs to prove that a key is held by the device’s Secure Enclave. That gives the server or relying party more confidence about where the key lives and how it is protected.
Use Keychain and platform protections for long-lived secrets, avoid keeping sensitive values resident in RAM longer than necessary, and prefer Secure Enclave-backed non-exportable keys when the key should never leave the device.
A huge thank-you to everyone who joined and shared practical privacy and security questions throughout the session. Your questions made the discussion useful for developers working with prompt injection risks, Private Cloud Compute, third-party model providers, App Store privacy labels, Xcode agents, CloudKit, SwiftData, passkeys, TCC, Siri AI, telemetry, MDM, trust communication, sensitive permissions, platform security fundamentals, passkey lifecycle, and secrets in memory.
Question acknowledgments: Tanya/Taya, Claire Casey, Scott G., Ying Shu, Michael row01, Patatita, Evolving This Design, CMD Dev, Brandon 7269, Conil, M3 Elixir, Thumb Drive, D. Vervkin, and the online WWDC audience who submitted and upvoted the remaining Privacy and Security questions.
Finally, a heartfelt thank-you to David, Yosh, Katie, Dan, Rohit, Emily, and the teams behind the scenes for leading the session and explaining how privacy and security fit into modern app development.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.