iOS Interview Series #9: Questions Every Senior iOS Developer Should Know

Question 1. The “Golden Triangle” of Code Signing

Interviewer: “Can you explain the relationship between a Certificate, an App ID, and a Provisioning Profile?”

Answer:

Think of it as a Passport System:

• The Certificate (.p12): This is your Identity. It proves you are a verified Apple Developer. (The “Passport”).
• The App ID: This is the Identifier. It uniquely identifies your app (e.g., com.company.appname) and defines which "powers" it has (Push Notifications, iCloud, etc.). (The "Destination").
• The Provisioning Profile: This is the Link. It ties the Certificate and the App ID together, along with a list of allowed Devices (UDIDs). (The “Visa”).

Senior Insight: “The Provisioning Profile is actually just a cryptographically signed plist that the iOS kernel checks before launching the app. If the bits don’t match, the app is killed instantly.”

Question 2. Development vs. Distribution Profiles

Interviewer: “Why can’t I just use a Development Profile to put an app on the App Store?”

Answer:

• Development Profile: Used for debugging. It includes get-task-allow = true, which allows Xcode to attach a debugger to the process. It is limited to the UDIDs registered in your account.
• Distribution Profile: Used for TestFlight/App Store. It has get-task-allow = false (you cannot debug a production app). It does not contain UDIDs because Apple handles the distribution to any device via the store.

Question 3. Provisioning “Hell” and Automation (Fastlane)

Interviewer: “On a large team, ‘Automatic Provisioning’ in Xcode often fails or creates a mess of redundant profiles. How do you manage this at scale?”

Answer:

I implement the ‘Match’ pattern. Instead of every developer creating their own certificates, we use a private, encrypted Git repository as a Single Source of Truth for our team’s certificates and profiles.

• The Benefit: A new developer joins the team, runs one command (fastlane match development), and their machine is instantly set up with the correct, shared credentials. This prevents the 'Revoke Certificate' wars that happen in many companies."

Question 4. TestFlight: Internal vs. External Groups

Interviewer: “What is the difference between an Internal and External TestFlight group, and why does it matter for our release cycle?”

Answer:

• Internal Groups: Up to 100 users (usually your employees). Builds are available instantly as soon as they process. No Beta Review required.
• External Groups: Up to 10,000 users. The first build of a new version requires a “Beta App Review” from Apple.
• Senior Strategy: I set up CI (Continuous Integration) to automatically push ‘Nightly’ builds to the Internal group. We only move to the External group once the build has passed QA in the internal environment.

Question 5. The “Privacy Manifest” and “Export Compliance”

Interviewer: Recently, apps are being held up because of missing Export Compliance. How do you handle the ‘ITSAppUsesNonExemptEncryption’ key?”

Answer:

In the Info.plist, we should set ITSAppUsesNonExemptEncryption to NO if we only use standard HTTPS. If we don't do this, every time we upload a build, someone has to manually click a button in App Store Connect to 'confirm' the encryption. By adding it to the plist, we automate the bypass and keep the CI/CD pipeline moving.

Question 6. App Thinning: Slicing, Bitcode, and On-Demand Resources

Interviewer: Our app is too large (over 200MB). How do you use ‘App Thinning’ to help users on 16GB devices?

Answer:

1. Slicing: The App Store creates variants of your app. An iPhone 15 Pro only downloads the @3x assets, while an iPhone SE only gets the @2x assets.
2. Bitcode (Deprecated/Legacy Knowledge): Apple used to re-compile your app for the specific architecture, but this is now largely handled by Xcode 14+ defaults.
3. On-Demand Resources (ODR): For a game or heavy app, you can host assets (like Level 5) on Apple’s servers. The app only downloads them when the user reaches that part of the app.

Question 7. The “Distribution” Cross-Question

Interviewer: Imagine this scenario: “A critical bug was found in Production. We fixed it in 5 minutes. Now we need to get it to users ASAP. Walk me through the ‘Expedited Review’ process and the ‘Phased Release’ strategy. If 50% of users have already downloaded the buggy version, how do we stop the bleeding?”

Answer:

1. The “Emergency” Strategy: Stop the Bleeding

If a buggy version is live and 50% of users have it, you have two immediate levers:

• Pause Phased Release: If you used a Phased Release (7-day rollout), you can click “Pause” in App Store Connect. This immediately stops the update from being sent to the remaining 50% of users.

Note: You can keep it paused for up to 30 days while you prepare a fix.

• Remove from Sale (The “Nuclear” Option): If the bug is catastrophic (e.g., data loss), you can change the app’s status to “Removed from Sale.” This takes the app off the store entirely for new downloads, though it doesn’t delete it from existing phones.

2. The Fix: Expedited Review

Once the code is fixed, you don’t wait in the standard 24–48 hour queue.

• The Request: You submit a new build and then fill out the Expedited Review Request form.
• The Justification: You must select “Critical Bug Fix” and clearly explain how it affects users (e.g., “The app crashes on launch for 50% of our user base”).
• The Result: Apple usually approves these within a few hours.

Pro Tip: Don’t cry wolf. If you request expedited reviews for minor UI tweaks, Apple will eventually start ignoring your requests.