Sample questions
Ios Lifecycle Background ExecutionDifficulty 1
What is the primary purpose of application(_:didFinishLaunchingWithOptions:) in an iOS app delegate?
- aIt renders the first screen's layout constraints
- bIt compiles the app's storyboard at runtime.
- cIt runs once per screen every time a view appears.
- dIt performs one-time app-wide setup right after launch✓
Explanation:This app delegate method is called once after the process launches, and is the standard place for app-wide setup (e.g. configuring services, third-party SDKs) before any UI is shown.
Ios Lifecycle Background ExecutionDifficulty 1
In a scene-based (UIKit multi-window) app, what is scene(_:willConnectTo:options:) responsible for?
- aHandling low-memory warnings for the whole process.
- bRegistering push notification categories globally
- cSetting up the UI/window for one specific scene as it connects✓
- dTerminating other scenes when one connects.
Explanation:Each UIScene gets its own connection callback; this is where a scene sets up its own window and root view controller, since a single process can host multiple independent scenes.
Ios Lifecycle Background ExecutionDifficulty 2
What is the practical difference between applicationWillResignActive(_:) and applicationDidEnterBackground(_:)?
- aThey fire in the reverse order on every device
- bresignActive only exists for scene-based apps
- cresignActive fires first (still on screen, losing focus).✓
- denterBackground fires before the app has even finished launching.
Explanation:applicationWillResignActive fires when the app is about to lose focus but may still be partially visible (e.g. a system alert appearing); applicationDidEnterBackground fires once it is no longer visible at all — a later, stronger stage of the same transition.
Ios Lifecycle Background ExecutionDifficulty 2
What's the relationship between applicationWillEnterForeground(_:) and applicationDidBecomeActive(_:)?
- aThey are two names for the exact same callback
- bwillEnterForeground fires first (about to be visible).✓
- cdidBecomeActive always fires first, then willEnterForeground.
- dwillEnterForeground only fires on cold launch
Explanation:willEnterForeground signals the transition back to the foreground is starting (UI becoming visible again), while didBecomeActive fires slightly after, once the app is fully active and receiving events again.
Ios Lifecycle Background ExecutionDifficulty 2
Which best describes UIScene's .background activation state (as opposed to .foregroundActive/.foregroundInactive)?
- aThe scene has never been connected at all
- bThe scene is visible but partially obscured by a system dialog
- cThe scene is guaranteed to be destroyed within one second
- dThe scene is not visible on screen at all✓
Explanation:.background means the scene's content is not currently on screen; the process may still be running (subject to system limits), unlike .foregroundActive/.foregroundInactive which both mean the scene is at least partly visible.
Ios Lifecycle Background ExecutionDifficulty 1
What does calling UNUserNotificationCenter.current().requestAuthorization(options:) do?
- aPrompts the user for permission to display notifications✓
- bImmediately schedules a background task
- cRegisters the device token with the push service
- dDownloads pending remote notifications from the server.
Explanation:This call triggers the system permission prompt asking the user to allow (or deny) alerts, sounds, and/or badges for notifications — it is unrelated to device token registration or background tasks.