Apple Mobile Application Security interview questions

Both platforms sandbox apps and require signing; they differ in who decides what runs and how fast fixes arrive. Interviewers want the shared model first, then the differences that change a threat model.

A standard is a checklist only if you use it badly. The answer interviewers want maps the app's data and threats onto MASVS areas, then picks which MASTG tests are worth the time.

'Use the Keychain' is half an answer. Interviewers check whether you know the key never leaves the hardware, the data it protects still does, and which settings stop it riding along in a backup.

Any app can claim myapp://. That single fact breaks OAuth redirects, password-reset links and payment flows that trust a custom scheme. The fix is a link the operating system verifies against your domain.

A WebView puts a browser inside your app, without the browser's address bar, and often with a bridge to native code. XSS in that page is no longer 'just XSS'.

The token is safely in the Keychain, and also in the crash log, the analytics payload and the app-switcher screenshot. Interviewers want the list of side doors, not the front door again.

The device is in the attacker's hand in half the scenarios. A strong model sorts threats by where the attacker sits, then puts every decision that moves money behind a check the phone cannot fake.

Pinning narrows trust, and every outage story about it is a rotation story. The scored answer decides whether to pin at all, pins public keys with backups, and plans for the release that can never update.

Two different questions hide here: does the app validate TLS at all, and does it pin? Testers who merge them either miss the critical bug or report a non-issue as one.

Detection that runs on the attacker's device reports whatever the attacker allows it to. Interviewers want to hear what it is still good for, and what it must never decide alone.

Attestation gives your server a signed statement it did not have to trust the client for. The design question is what that statement covers, how you bind it to a request, and what you do when it is missing.

Anything in the app binary belongs to whoever downloads it. The strong answer stops trying to hide a client secret and builds on user tokens, PKCE, device-bound keys and server-side limits.

Unzip, decompile, read the manifest, then watch it run. The interview checks whether you know where the interesting parts of an app hide, and that obfuscation changes your effort, not your conclusions.

Moving a secret into C changes who can find it in an afternoon, not whether it can be found. The scored answer shows how an analyst would recover it, then replaces the design with one that does not need a shared secret.

No shield is unbreakable, so 'can it be bypassed' is the wrong test. Measure how much it raises an attacker's cost on the threats you actually face, and what it costs you in crashes, performance and false positives.

Everything shipped on the phone belongs to the person holding it: the weights, the system prompt and any key the assistant uses. And the assistant now reads notifications, messages and screens written by strangers.

Pinning protects the user from the network. It was never going to protect your API from the person holding the phone, and the good answer explains both halves.

Both platforms let an app declare its transport rules in a file the reviewer can read in seconds. Knowing which lines are dangerous makes you fast in a mobile review.

A key the app cannot export is only half the story. The other half is making the key usable only after the user is really present, which a hooked 'authentication succeeded' callback can fake.

On a phone, the signing key is the app's identity: it decides who can ship updates, which data the app can share, and what it is entitled to do. Lose it, or let someone else sign, and that identity changes hands.

Rooting is not one trick. It is a decision about the boot chain: either the owner unlocks it, or an exploit breaks it. Everything an app can detect follows from which.

Most mobile findings do not need root at all. The ones that do usually point to the same conclusion: the server must not trust the client.

Taking over a modern Android phone takes several bugs in a row. Each link targets a different layer, and Android's design adds a defence at every one.

iOS has fewer ways in than most platforms, so attackers aim at the few that remain: messages, the browser and the kernel. Apple's defences are built around those exact paths.

Most mobile malware never breaks the sandbox. It persuades the user to hand over the permissions that let it read the screen and act as them.

Your app can be fully patched on a phone whose kernel is two years old. The answer separates what you control, what the platform controls, and what you can only measure.

Exploit chains used by mercenary spyware depend on memory corruption. Tagging every allocation and checking the tag on every access attacks that dependency directly. The answer is how it works and where it stops.

Employees will read company email on their own phones either way. The scored answer protects the data without owning the device, and is honest about what IT can and cannot see.

Spyware chains usually arrive through features most people never use. The scored answer trades those features away for the people who need it, and plans for what happens when protection is not enough.

The sandbox is a Linux user ID, SELinux and a signature that decides who you are. Get those three right and most Android security questions become reasoning rather than recall.

Every exported component is an API that any app on the phone can call. The vulnerabilities are the same ones you know from web APIs: missing authorization, trusted input, and a confused deputy.