Mobile Developer interview questions

iOS and Android provide similar app capabilities through different SDKs, tools, and platform conventions.

• iOS development normally uses Swift, Xcode, and Apple frameworks such as UIKit or SwiftUI.
• Android development normally uses Kotlin, Android Studio, and AndroidX libraries such as Jetpack Compose.
• Each platform has its own navigation, permission, background-work, and store-review rules, so a shared design still needs platform-specific decisions.

An application lifecycle describes platform-specific changes in whether an app or component is visible, interactive, backgrounded, or no longer running.

• An app should start user-visible work when its screen becomes active and pause work such as camera capture when it leaves the foreground.
• The operating system may terminate a background process to reclaim memory, so important state must not live only in RAM.
• iOS reports application and scene phases, while Android provides lifecycle callbacks for activities and other components, so they are not one shared state machine.
• Lifecycle callbacks are not a guarantee that every cleanup method will run before termination.

I would choose native development when platform integration or platform-specific behavior matters more than sharing UI code.

• Swift and Kotlin give direct access to new iOS and Android APIs without waiting for a cross-platform wrapper.
• React Native or Flutter can share much of the product logic and UI across platforms, which helps a small team ship both apps.
• Cross-platform code still needs native work for unsupported SDKs, widgets, background modes, or unusual hardware features.
• The choice should reflect team skills, required device APIs, and how closely each app must follow its platform conventions.

A junior iOS developer should be comfortable with Swift constants, optionals, functions, collections, structs, and classes.

• Use let for an immutable binding and var only when the value must change.
• Handle an optional with if let, guard let, optional chaining, or a default instead of force-unwrapping it.
• Prefer a struct for simple value data such as a Profile and a class when shared identity or inheritance is required.
• Use protocols to describe behavior that different types can implement without sharing a superclass.

Kotlin makes Android code safer and more concise through null safety, data classes, extension functions, and coroutines.

• A nullable type is written with ?, and safe calls plus the Elvis operator handle absent values explicitly.
• A data class generates value-oriented helpers such as equals, hashCode, copy, and a readable toString.
• Extension functions add convenient operations to an existing type without modifying or inheriting from it.
• Coroutines express asynchronous work sequentially while structured scopes control its lifetime.

Dart uses sound null safety and supports both mutable variables and immutable bindings.

• final assigns a value once at runtime, while const creates a compile-time constant.
• A type ending in ? may hold null; a non-nullable String cannot.
• Named parameters make widget constructors readable, and required marks a named argument that callers must provide.
• An async function returns a Future, and await reads its eventual result without blocking the UI thread.

TypeScript catches many shape and nullability mistakes before the React Native app runs.

• Interfaces or type aliases can describe API responses, component props, and navigation parameters.
• Union types model a small set of states, such as loading, success, or error, more safely than unrelated booleans.
• Type narrowing checks a value before code uses properties available only on one union member.
• TypeScript types disappear at runtime, so external JSON still needs validation when its contents are untrusted.

Nullable values must be explicit and checked before ordinary use; the exact syntax depends on the chosen stack.

• Swift uses optionals such as String? and requires unwrapping before ordinary use.
• Kotlin and Dart also mark nullable types with ?, while safe calls and explicit checks narrow them to non-null values.
• TypeScript checks null only when strictNullChecks is enabled, and those checks do not validate runtime JSON.
• Force operators such as Swift !, Kotlin !!, or Dart ! bypass safety and should be reserved for proven invariants.

A value is copied as independent data, while a reference lets multiple variables point to the same object.

• Swift structs have value semantics, so changing a copied settings struct does not change the original.
• Swift classes, Kotlin class instances, and Dart objects use reference identity, so mutations can be visible through every reference.
• Kotlin data classes provide copy helpers but their instances are still references, and nested mutable objects can still be shared.
• Immutable value-style models make UI state changes easier to reason about because updates replace data instead of mutating it secretly.

Asynchronous work keeps network and disk operations from freezing the main UI thread.

• Swift async and await, Kotlin coroutines, and Dart Futures suspend a task while it waits instead of blocking the interface.
• React Native commonly represents async results with Promises and consumes them with async and await.
• UI updates belong on the platform's main thread or main actor even when the data was loaded elsewhere.
• Errors and cancellation must be handled explicitly because a screen may disappear before the operation completes.

UIKit commonly builds a screen from a UIViewController and a hierarchy of UIView objects.

• Controls such as UILabel, UIButton, and UITableView are created in code or connected from a storyboard.
• Auto Layout constraints describe positions and sizes relative to guides, siblings, or the parent view.
• The controller responds to lifecycle callbacks and user actions, then updates views imperatively.
• Keeping data and business rules outside the view controller prevents it from becoming an oversized catch-all class.

SwiftUI declares a view as a function of current state and recomputes its body when observed state changes.

• VStack, HStack, and ZStack compose child views vertically, horizontally, or in layers.
• A view-owned simple value can use @State, while shared model data should come from an observable source.
• Modifiers return new view descriptions, so their order can change layout and appearance.
• The body may be evaluated many times, so it should describe UI rather than start uncontrolled side effects.

Compose recomposes composable functions that read state whose value has changed.

• remember retains a value across recompositions, while rememberSaveable can also restore supported values after activity recreation.
• Mutable state should be changed through its state holder so Compose can observe the update.
• Compose can skip unaffected composables when their inputs remain stable.
• Expensive calculations should be moved out of frequently recomposed code or memoized for the inputs they use.

React Native renders platform views from React components rather than displaying ordinary HTML in a browser.

• View, Text, and Pressable map to native-backed interface primitives instead of div, span, and button elements.
• Layout uses Yoga's Flexbox model, with defaults that differ from browser CSS, such as a column main axis.
• TypeScript or JavaScript handles React logic, while native modules expose device APIs that the framework does not provide directly.
• A WebView is a separate component for web content and is not how a normal React Native screen is rendered.

A Flutter widget is an immutable description of part of the user interface.

• StatelessWidget has no mutable State object of its own, but it can still depend on inherited context such as Theme or MediaQuery.
• Widgets form a configuration tree that Flutter turns into element and render-object structures for updates and layout.
• Common composition widgets include Row, Column, Stack, Padding, and ListView.
• Building small widgets with explicit constructor inputs keeps rebuilds and reuse understandable.

Declarative UI means describing what the interface should look like for the current state rather than issuing a sequence of view mutations.

• A loading state returns a spinner, while loaded state returns content, so the state model drives the visible branch.
• The framework compares or reevaluates descriptions and applies the necessary updates to the rendered interface.
• State should have a clear owner; duplicating the same value in several components creates conflicting sources of truth.
• Rendering code should remain free of uncontrolled side effects because it may run repeatedly.

Mobile layouts express relationships and flexible space instead of relying on fixed pixel coordinates.

• UIKit uses Auto Layout constraints, while SwiftUI and Compose compose stacks, frames, and flexible modifiers.
• React Native uses Flexbox, and Flutter uses constraints flowing down with sizes flowing up through its layout tree.
• Fixed sizes are appropriate for controls such as icons, but content areas should expand, wrap, or scroll.
• Test narrow phones, large phones, landscape, and enlarged text because screen width alone does not cover every layout constraint.

Logical units keep controls at a similar perceived size across screens with different pixel densities.

• iOS lays out in points, Android uses dp for geometry and sp for text, and Flutter uses logical pixels.
• The operating system maps those units to a device-specific number of physical pixels.
• An image asset may need multiple density variants so it stays sharp without changing its layout size.
• Text should respect the user's font scaling rather than being forced into a fixed physical height.

Safe areas and insets describe screen regions obstructed by system UI or device hardware.

• Status bars, camera cutouts, navigation bars, and the home indicator can overlap content drawn edge to edge.
• iOS exposes safe-area guides, while Android exposes window insets for system bars and display cutouts.
• Flutter SafeArea and framework-specific inset APIs can add the required padding around important content.
• Backgrounds may extend behind system UI, but tappable controls and essential text should remain reachable and visible.

State should live at the lowest shared owner that needs to coordinate all readers and writers.

• Keep temporary control state, such as whether a menu is open, inside the component that owns the menu.
• Lift shared form or selection state to a parent or screen model and pass values plus events downward.
• Derive values such as a filtered count from source state instead of storing a second copy that can become stale.
• Recomposition or rebuild is expected after state changes, so expensive I/O must not be started directly by ordinary rendering.