Practice iOS interview answers on screen state, shared models, async results, persistence and testability with an original saved-draft workflow. These original practice questions connect a concept to a decision and a failure case. They are preparation exercises, not leaked employer questions. State your assumptions before proposing an implementation.
Who should own screen state?
Choose an owner whose lifetime matches the information. A temporary selection may belong to a screen; an authenticated session may belong to an application-level owner. Explain how state reaches the UI and how changes are made. Global mutable state can make sharing convenient while obscuring which screen changed it. Test whether two screen instances should observe the same value or independent drafts.
How do you distinguish model state from presentation state?
A stored order and whether its detail panel is expanded represent different responsibilities. Keep business rules in a suitable model or domain boundary and let presentation state describe the current interaction. Some values are derived from others and need not be separately mutable. Explain the source of truth and avoid synchronizing two copies of the same fact without a clear reason.
What happens when asynchronous results arrive late?
Associate the result with the request and current item. Navigation or a new selection can make an old result irrelevant. Use suitable isolation for UI work and a cancellation strategy where supported, but also reject stale responses. Explain success, failure and empty-state behavior. A completion callback running without a crash does not mean it updated the correct user context.
What should persist across app launches?
Persist the data the product actually needs, with a strategy appropriate to its sensitivity and durability. A draft may need restoration; a temporary animation state often does not. Explain migration and invalid data, not just which storage API you know. When local and server state differ, define which operation resolves the disagreement and what the user sees while that happens.
How do you make app logic testable?
Separate the rule under test from UI and transport details where that creates a useful boundary. Inject controllable dependencies such as a clock or data provider. Test state transitions and observable outcomes with deterministic input. Avoid a mock-heavy test that repeats implementation calls without establishing user behavior. Include a case where an older request completes after a newer one.
Worked interview scenario
Original workflow: a user edits a profile draft, leaves the screen and returns. Clarify whether leaving saves, discards or prompts about unsaved changes. Give the draft an owner matching that choice. If it must survive an app relaunch, define explicit persistence rather than relying on an object remaining in memory.
Now submit the draft and lose connectivity before receiving confirmation. Distinguish local draft data from confirmed server data and show an understandable pending state. When reconnecting, reconcile the operation's outcome. Test submitting twice, loading a newer server version and restoring a partially edited draft. These transitions reveal more architectural understanding than listing storage frameworks.
Practice exercise
Draw the source of truth for server profile, local draft and screen interaction. Explain what survives navigation and relaunch. Rehearse a cancellation case and an out-of-order result case, then propose one deterministic test proving that the wrong profile is never updated on screen.
Review your explanation
Use Cluegent during practice to challenge your own draft. Ask for a follow-up about the scenario's weakest assumption, answer it without suggestions, then check your reasoning against the official reference. Review current plans before subscribing. Follow the employer's tool policy in the actual interview.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Should all screen state be shared globally?
Choose ownership by lifetime and sharing requirements. Independent drafts should not accidentally mutate each other through shared state.
Does keeping an object in memory provide persistence?
No. App relaunch and process termination require explicit restoration or durable storage where the product needs it.