How do you approach an unfamiliar Apple framework: what do you check before you write code, and how do you answer “have you used X?” well?

17.7.1 · L5 · Interview

Predict first

You are asked about a framework you have never used. Which answer is strongest?

// A: guess the API names confidently
// B: describe purpose, lifecycle, entitlement, privacy and pitfalls, then say how you would verify the details
// C: say you do not know and stop

Mental model. Before hiring a contractor you ask the same questions every time: what exactly do they do, when are they on site, what licences do they need, what do they touch in the house, and what usually goes wrong. The answers matter more than their brochure.

Interviewers pick a framework and probe. A reliable way to be useful on any of them is the same five-part checklist, which is also how to learn one quickly. 1) Purpose and boundaries: what problem does it solve, what does it not do, and what is the modern API versus the legacy one (StoreKit 2 over receipts, CKSyncEngine over raw operations, PHPicker over a photo-library grant, async sequences over delegates)? Read the overview page and the WWDC session for the current recommendation, and note the minimum OS version. 2) Lifecycle and process constraints: where does it run and for how long (foreground, background mode, extension, or the system on your behalf), what wakes the app (push, significant change, a delegate callback after relaunch), what happens when the app is suspended or force-quit, and what budgets apply (notification limits, 20 geofences, background execution time, Live Activity duration, request rate limits). 3) Entitlements, capabilities and review: which capability to add, which Info.plist keys are mandatory (a missing usage string crashes at the request), which entitlements need Apple’s approval (CarPlay, critical alerts, some Wallet and health uses), what App Review checks, and which sandbox or test environments exist. 4) Privacy and permissions: what data it touches, what the authorization levels are (when in use versus always, limited, write-only), whether a system UI avoids the permission entirely (pickers), how denial is surfaced, what you must declare in the privacy manifest and App Store labels, and how to ask in context. 5) Pitfalls and testing: what fails silently, what differs on the simulator (no Secure Enclave, no motion sensors, no App Attest), what needs a real device or account, the common errors, thread and actor requirements, and how to test it (local configuration files, mocks around a protocol, the CarPlay simulator).

Then practise the answer. “I have used X” (L2) is purpose plus one real example; “entitlements and privacy” (L3) adds the capability, usage strings and the permission model; and “how it actually works” (L5) explains one mechanism in depth: for push, the provider-APNs-device path with priorities and collapse; for CloudKit, change tokens and subscriptions; for StoreKit 2, signed transactions, entitlements and server notifications; for location, the difference between continuous updates and region monitoring. Wrap the framework behind your own protocol so the rest of the app does not depend on it, and so tests do not need the real service. Keep a short personal reference table per framework and revisit it each WWDC, since APIs, limits and review rules change every year. Finally, be honest about the edges: say what you have shipped, what you have only read about, and how you would find out, since a confident “I would check the entitlement and the documented limits first” beats a guess.

A structured approach and an honest plan to verify show real engineering judgement, which is what the question is testing.

	Typical constraint	Typical privacy surface
UserNotifications / APNs	user permission, 64 pending locals, throttled silent push	permission prompt, content passes through Apple
Core Location	20 regions, battery cost, background rules	precise vs approximate, always vs when in use
Contacts, EventKit, Photos	authorization levels, pickers avoid permission	personal data, limited and write-only modes
HealthKit	locked when device is locked, per-type authorization	read denial is hidden by design
CloudKit	schema deployment, quotas, no server logic	private database uses the user’s iCloud
StoreKit 2	verify, finish, listen for updates, server notifications	purchase history and account tokens
Live Activities / CarPlay / App Clips	4 KB and 8 hours; approved categories; 15 MB	visible on the lock screen or in the car

Common traps

Learning the API without the constraints. The lifecycle, entitlement and privacy rules decide whether it works in production.
Using the legacy API because tutorials do. Check which API Apple currently recommends and its minimum OS.

They might follow up with

What do you say when asked about a framework you have not used? Explain how you would approach it with the five questions, and what you would verify first.
How do you keep an app independent of a framework? Wrap it behind your own protocol and inject it.

How do you approach an unfamiliar Apple framework: what do you check before you write code, and how do you answer “have you used X?” well?

Predict first

Common traps

They might follow up with

Related questions