System Design for Apple Platforms Questions

Architectural patterns and system design considerations for building software on Apple platforms (iOS, macOS, watchOS, tvOS). Includes architecture styles (MVC, MVVM, VIPER, Clean Architecture), data flow and separation of concerns, offline caching and synchronization, caching strategies, performance optimization, platform constraints, and patterns for scalable, maintainable Apple ecosystem applications.

EasyTechnical

91 practiced

What is App Transport Security (ATS) on Apple platforms, and why is it important for client-server communications? Describe the typical ATS constraints and how to safely handle exceptions when integrating legacy backends.

MediumTechnical

91 practiced

Compare REST and GraphQL for mobile Apple clients where many small screens request different subsets of data and offline behavior is required. Discuss caching, batching, schema evolution, overfetching/underfetching, and implications for synchronization and background updates.

Sample Answer

High-level summary: For iOS clients with many small screens and offline requirements, GraphQL often fits better for avoiding overfetching and tailoring payloads, while REST can be simpler for strong HTTP caching and background sync patterns. Key trade-offs follow.

Caching- REST: benefits from HTTP caching (ETag, Cache-Control) and intermediate caches (CDN). Easy to cache whole resource responses using NSURLSession/NSURLCache. - GraphQL: single POST endpoint complicates standard HTTP caching; requires client-side normalized cache (Apollo, Relay) stored in Core Data/SQLite/Realm for offline. Normalization enables fine-grained cache updates and reads per-screen.

Batching- REST: natural to combine multiple endpoints via a gateway or batch endpoints; but many round-trips risk latency. - GraphQL: supports query batching and fetching multiple shapes in one request, reducing RTTs — helpful on mobile networks.

Schema evolution- REST: versioning (URI, header) or additive fields; breaking changes are explicit. - GraphQL: encourages additive, non-breaking changes and deprecations; clients request fields they need so schema can evolve without new versions, which is useful across many small screens.

Overfetching/Underfetching- REST: often overfetches (server returns full resource) or requires many endpoints to avoid underfetching. - GraphQL: precisely selects fields, minimizing payloads — saves battery and bandwidth on mobile.

Synchronization & background updates- REST: easier to leverage HTTP semantics for delta sync (If-Modified-Since, ETag) and background NSURLSession/Background Fetch. - GraphQL: requires explicit delta queries or server subscriptions; for background refresh use persisted queries and lightweight delta fields. For offline-first, store normalized cache + change queue for mutations; sync via background tasks (BGAppRefresh/BGProcessing) and silent push to trigger sync.

Conflict resolution & offline writes- REST: often full-resource PATCH/PUT with ETag-based optimistic concurrency. - GraphQL: supports fine-grained optimistic updates on fields; need client-side conflict resolution (timestamps, last-write-wins, CRDTs) and server-side merge strategies.

Practical recommendation- Use GraphQL with a normalized persistent cache (Apollo + SQLite/Core Data) if many small screens and variable field needs dominate. Implement persisted queries, server-side query cost limits, and background delta endpoints for efficient sync. - Use REST if you rely heavily on CDN caching, simple background HTTP semantics, or want straightforward tooling for ETag-based sync. Hybrid approach (GraphQL for UI, REST for large file/static assets/deltas) often yields best results.

EasyTechnical

91 practiced

Describe common communication patterns between an iPhone app and its watchOS companion using WatchConnectivity: transferUserInfo, updateApplicationContext, transferFile, and interactive messaging. Include size limits, delivery guarantees, and recommendation for syncing large datasets to Apple Watch with minimal battery impact.

MediumTechnical

81 practiced

How would you design client-side rate-limiting and exponential backoff for API requests from an iOS app interacting with a global microservices backend? Include algorithms for per-user, per-device, and global limits, and describe how the client should react to 429/503 responses.

Sample Answer

Requirements & goals:- Prevent client-side overload of backend and noisy retries.- Respect server limits (per-user, per-device, global).- Improve UX: fast retries when safe, decay retries on repeated errors.- Survive app restarts and intermittent connectivity.

Client-side design (algorithms):1. Local token-bucket per-scope- Per-device bucket: capacity C_device, refill r_device/sec.- Per-user bucket: capacity C_user, refill r_user/sec (shared across devices for same account; best-effort locally).- Global bucket (client-side soft guard): small capacity to avoid bursty fan-out across app features.Implementation: before each API call, attempt to consume 1 token from all applicable buckets; if any bucket empty, enqueue or delay request.

2. Sync with server limits- Read Retry-After, X-RateLimit-Limit/Remaining/Reset headers and adjust local buckets (set tokens = Remaining; schedule refill according to Reset).- When server provides per-user counters, prefer server truth and reduce local rate.

Exponential backoff + jitter (on 429/503)- Use formula: delay = base * 2^attempt + jitter, where jitter is uniform random in [0, min(delay, jitter_max)].- Cap at max_backoff (e.g., 60s). Use full jitter to avoid synchronized retries.- For 429 with Retry-After: respect server-specified delay, then apply backoff for subsequent failures.- For 503 (transient server down): treat similar to 429 but consider increasing penalty (e.g., exponential multiplier >1).

Client reaction flow- On 429: - Read Retry-After (if present) -> pause requests for that scope (user/device/global) until time. - Increment attempt counter for endpoint/user -> apply exponential backoff for retries. - Update local per-user token bucket to 0 and schedule refill at Reset.- On 503: - Backoff with exponential jitter, escalate to global backoff if many endpoints return 503. - Optionally downgrade polling frequency, disable non-critical background syncs.- On success after backoff: reset attempt counter for that endpoint/scope.

Persistence & heuristics- Persist token bucket state and attempt counters to disk (UserDefaults/Keychain) to survive restarts.- Use conservative defaults; adapt via server hints and telemetry.- Fail-fast for non-idempotent requests: avoid automatic retries; surface error to user or queue for manual retry.- For idempotent GET/PUT: safe to retry with backoff.

Observability & safety- Log 429/503 counts and Retry-After values; surface metrics to backend teams.- Expose opt-out toggles (e.g., "Low Data Mode") to reduce client limits.- Test with chaos scenarios and scale tests.

Trade-offs & rationale- Client-side limits are best-effort; server is authoritative. Local token buckets reduce noisy retries and improve UX.- Persisting state avoids thundering herd on restarts.- Using jitter prevents synchronized retry storms.- Respecting Retry-After makes client polite and aligns with server-side policy.

MediumSystem Design

88 practiced

Design a feature-flag system for an iOS app integrated with a distributed backend that supports targeting by user segments, low-latency evaluation for startup paths, and safe defaults when the flag service is unreachable. Include the SDK surface and server-side considerations.

Sample Answer

Requirements / constraints:- Targeting by user segments (attributes + cohorts), gradual rollouts (percentage), rule hierarchy- Low-latency evaluation on app startup and hot paths (<1ms ideally)- Safe defaults when service unreachable- Telemetry and exposure events; secure config delivery; scalable server-side management

High-level design:- Server: Admin UI → Flag service + Segment service + Audit/metrics + Push/Delta API- Client: iOS SDK with local evaluation engine, persistent cache, background updater, and fallback config Server ↔ (HTTPS REST for full sync, gRPC or SSE/Push for deltas) → iOS SDK

Server-side components:1. Flag store: canonical JSON definitions (rules, percentage rollouts, targeting expressions), versioned and signed.2. Segment/trait service: maintains dynamic cohorts (computed periodically or via streaming events).3. Delta API & push: publish flag deltas (signed) via SSE/gRPC or APNs+fetch for mobile; also provide full snapshot endpoint.4. Metrics & analytics: collect exposures, evaluations, failures; support ROLLBACK and audit logs.5. Security: sign flag snapshots; TLS; auth tokens with scopes; rate limiting.

Client-side (iOS SDK) responsibilities:- API surface (example): - FeatureFlagClient.initialize(apiKey: String, user: User, options: Options, completion: (Result)->Void) - isEnabled(_ key: String) -> Bool - getVariant(_ key: String) -> String? - evaluate(_ key: String, with user: User) -> EvaluationResult - onUpdate(callback) - forceRefresh(completion) - registerExposure(_ key, result)- Behavior: - On initialize: load local cache (disk); if empty use baked-in defaults (safe default specified per-flag); evaluate synchronously using local evaluator - Background: fetch full snapshot asynchronously; apply deltas signed by server; merge with local cache atomically - Low-latency: evaluator is pure local logic (no network). Use precompiled rules (compiled into bytecode/AST) and fast bucketing (stable hashing, e.g., Murmur3 on userID + flagID → normalized [0,1) for percentage rollouts) - Persistent store: encrypted file or Core Data; store last-good snapshot + metadata (version, signature) - Fallbacks: per-flag default value; global safe mode flag to force safe defaults; SDK exposes health state (online, degraded, offline) - Consistency: each snapshot includes version + signature; SDK verifies signature before applying; if verification fails retain previous snapshot and report error - Targeting: evaluate attribute-based predicates locally; support segment membership by caching segment IDs returned from server; if segment data missing, treat as not matched unless flag default indicates otherwise - Telemetry: queue exposure and evaluation events locally and flush in background; include sampling to reduce bandwidth

Evaluation flow (startup hot path):1. App calls isEnabled("new-ui") → SDK loads in-memory compiled rules from last snapshot (loaded synchronously at init)2. Evaluator checks flag existence → if not present, returns safe default3. Evaluate predicates (attributes from current user); if rollout rule present compute hash bucket → decide variation4. Return result immediately

Rollout & bucketing:- Use deterministic hashing of stable identifier (user id, fallback to device id) + flag id + salt- Support percentage rollouts and hierarchical rules (target -> rules -> default)

Edge cases & safety:- Unreachable server: use cached snapshot; if none, return safe default; SDK optionally emits diagnostic event- Stale segments: include TTL; on segment TTL expiry treat as unknown and use conservative default or administrative rule- Partial updates: apply delta patches atomically- A/B consistency: sticky assignment persisted per user for consistency across sessions

Observability & Ops:- Server-side: monitor delta publish latency, error rates, flag change frequency, audit trails- Client-side: metrics for fetch success, apply failures, eval errors, last sync timestamp; include Sentry/Crash integration to capture evaluator exceptions

Trade-offs:- Full local evaluation improves latency & offline behavior but increases client complexity and snapshot size. Mitigate by trimming flags and compressing snapshots.- Using APNs to notify clients of updates reduces polling but adds platform complexity.

Testing & rollout:- Unit tests for evaluator and bucketing; integration tests against server snapshots; staged rollout via percentage rules with kill-switch and quick rollback ability.

This design ensures sub-ms startup evaluations, safe deterministic fallbacks when offline, precise targeting via cached segments, secure signed snapshots and operational visibility for safe rollouts.

Unlock Full Question Bank

Get access to hundreds of System Design for Apple Platforms interview questions and detailed answers.

Join thousands of developers preparing for their dream job.