Mobile App Developer Interview Questions & Answers

Preparing for a mobile app developer interview means gearing up for questions that span technical depth, real-world problem-solving, and soft skills. Interviewers want to understand not just what you know, but how you think, communicate, and collaborate. This guide walks you through the most common mobile app developer interview questions, provides realistic sample answers you can adapt, and equips you with strategies to showcase your unique strengths.

Common Mobile App Developer Interview Questions

Tell me about a mobile app you’ve built from start to finish. What was your role?

Why interviewers ask this: This open-ended question helps interviewers understand your full scope of experience, from ideation through launch. They’re assessing whether you can handle the entire development lifecycle, communicate your contributions clearly, and reflect on what you learned.

Sample answer: “I led the development of a fitness tracking app called FitFlow for iOS and Android. I was responsible for the app architecture, core feature development, and coordinating with our design and backend teams. The app tracked workouts, displayed progress analytics, and synced with wearable devices.

I built the architecture using MVVM to keep the code maintainable as we scaled. One challenge was handling real-time data sync with wearables without draining battery, so I implemented efficient background task scheduling and data batching. We went from initial concept to App Store launch in about four months, and within the first month, we hit 10,000 downloads. Looking back, I’d have invested more in automated testing early on—we caught bugs in QA that could’ve been caught earlier with unit tests.”

Personalization tip: Replace the app name and specific features with your own project. Focus on a challenge you solved and what you’d do differently. This shows self-awareness and growth mindset, which interviewers value.

What’s your experience with cross-platform development? Would you recommend it?

Why interviewers ask this: Many companies need to support both iOS and Android with limited resources. This question reveals whether you understand the trade-offs between cross-platform frameworks (React Native, Flutter) and native development, and whether you can make a reasoned argument for your choice.

Sample answer: “I’ve built three apps using React Native and one native iOS app. React Native is fantastic when you need to ship to both platforms quickly and share code—we reduced development time by about 30% compared to what native would’ve taken. The learning curve is gentler for web developers, and the hot reload feature speeds up iteration.

That said, I wouldn’t blanket-recommend it. For apps requiring heavy native features—like advanced AR or complex animations—React Native adds friction. I once spent two weeks working around performance issues on Android that would’ve been simpler in native Kotlin. For the fitness app I mentioned, we actually started with React Native but found that real-time sensor data handling was clunky, so we switched to native after the prototype phase.

My advice: use React Native for content-heavy or business apps, but if you need tight hardware integration or pixel-perfect animations, native is usually worth the extra development cost.”

Personalization tip: Share your honest take based on projects you’ve actually worked on. If you haven’t used cross-platform tools, discuss what attracts or concerns you about them based on your research. Nuance impresses more than blanket recommendations.

How do you approach optimizing app performance?

Why interviewers ask this: App performance directly affects user retention and app store ratings. This question tests whether you’re methodical about optimization, know the right tools, and understand common performance pitfalls.

Sample answer: “I treat performance optimization as ongoing, not a final step. Here’s my approach: First, I profile early and often. On iOS, I use Xcode Instruments to check for memory leaks, excessive CPU usage, and rendering frames. I look at the Memory and Core Animation tools specifically. On Android, I use Android Studio’s Profiler and Firebase Performance Monitoring.

For a recent app, I noticed the home screen was taking 3 seconds to load. I profiled it, found that we were doing a massive database query synchronously on the main thread, and blocking UI rendering. I moved that to a background thread and implemented lazy loading for list items. Load time dropped to 800ms.

Beyond that, I focus on: efficient data structures (avoiding N+1 queries), lazy loading images, and using appropriate caching strategies. I also monitor battery drain—I once realized we were polling an API every 30 seconds unnecessarily, which crushed battery life. Switching to a push notification model solved it.

I keep a performance budget in mind: target 60 FPS for animations, sub-1-second initial load, and minimal battery impact. When I review code, I ask: ‘Is this running on the main thread? Could this be batched? Am I fetching data unnecessarily?’”

Personalization tip: Use tools and metrics you’ve actually used. If you haven’t used Instruments yet, mention that you’re familiar with the concept and eager to dive deeper. Be specific about actual performance improvements you’ve made—concrete numbers (80% faster, 15% less battery) are more credible than vague claims.

How do you handle debugging in production?

Why interviewers ask this: Production bugs are inevitable. This question reveals whether you’re reactive (just fixing the bug) or strategic (understanding impact, learning from patterns, preventing recurrence).

Sample answer: “My first step is always to assess impact and severity. Is this blocking users from core features? How many users are affected? That determines urgency.

I use Firebase Crashlytics for crash reporting and Sentry for broader error monitoring. When a crash report comes in, I look at the stack trace, user session info, and reproducibility. I also check our analytics to see if there’s a spike in crashes at a specific time or for specific user segments.

We had a critical bug where users in specific regions couldn’t complete purchases. Crashlytics showed a network timeout error. After digging into logs, I found that our API timeout was too aggressive for slower networks. I increased the timeout, added exponential backoff retry logic, and deployed a patch within a few hours.

After fixing, I always ask: How did this slip through QA? Should we add automated tests? Can we add monitoring to catch similar issues earlier? We actually added a synthetic test that mimics slow network conditions, which caught three similar issues before they reached production.”

Personalization tip: Share a specific production issue you’ve handled. If you’re early in your career, talk about a bug you found in a side project or during internship. The key is showing that you investigate root cause, not just apply band-aids.

Explain the lifecycle of a mobile app from development to App Store release.

Why interviewers ask this: This tests whether you understand the entire process, not just coding. App Store policies, build processes, versioning, and beta testing are all part of shipping quality apps.

Sample answer: “The lifecycle starts with planning and design—figuring out features, user flows, and technical requirements. Then development in sprints, usually two-week cycles.

Throughout development, I’m running unit tests locally and pushing to a staging environment for integration testing. Once a feature is stable, it goes through QA.

When we’re ready to release, I create a release branch, bump the version number (following semantic versioning), and prepare release notes. For iOS, I build using Xcode, create an archive, and upload to App Store Connect. I fill out the metadata—description, screenshots, keywords for ASO. Apple reviews the build, which usually takes 24 hours.

Before that official submission, we often do a TestFlight beta release to test with real users on real devices. This catches issues that don’t show up in testing environments.

Once approved, the app goes live. But I don’t disappear—I monitor crash logs, user reviews, and analytics for the first few days. If there’s a critical issue, I prepare a hotfix.

On Android, the process is similar but faster—Google Play reviews are usually quicker than Apple. I use the same general flow: build, stage, beta test, submit, monitor.”

Personalization tip: Tailor this to the companies you’ve worked with. If you’ve used specific tools (TestFlight, Firebase, Google Play Console), mention them. If you’ve hit any App Store rejections, briefly mention how you handled the feedback.

What’s your approach to testing, and what types of tests do you prioritize?

Why interviewers ask this: Testing culture varies widely across companies. This question reveals whether you value quality, understand different testing levels, and can balance shipping speed with reliability.

Sample answer: “I prioritize tests based on impact and cost. For every feature, I ask: What’s the risk if this breaks? How hard is it to test manually?

I always write unit tests for business logic. These are fast, cheap to write, and catch issues early. For iOS, I use XCTest; for Android, JUnit. I aim for 80%+ coverage on core logic.

Integration tests are next—these test how components interact. If I’m building a payment feature, I test the whole flow: form validation, API calls, error handling. I use a test environment API so I’m not hitting production.

UI tests come last. They’re slow and fragile, so I focus on critical user journeys. For iOS, I use XCUITest; for Android, Espresso. I test the happy path and a few key error scenarios—not every possible tap.

In my last project, we built a CI/CD pipeline that ran unit tests on every commit, integration tests on pull requests, and UI tests nightly. This structure meant we caught bugs fast without slowing down development. We saw a 40% reduction in production bugs.

I also believe in manual testing for edge cases and user experience—automated tests can’t catch every weird interaction or performance hiccup.”

Personalization tip: Reference specific test frameworks and tools you’ve actually used. If you haven’t set up CI/CD, mention that you understand the concept and would like to implement it. Avoid saying “I write tests for everything”—that’s unrealistic and shows you don’t think about trade-offs.

How do you stay updated with new mobile technologies and trends?

Why interviewers ask this: Mobile development moves fast. This question gauges your commitment to continuous learning and whether you’ll stay sharp without constant handholding.

Sample answer: “I have a few habits. I follow key voices on Twitter—folks like @SwiftOnSecurity and various official platform accounts. I subscribe to newsletters like Hacker News and iOS Dev Weekly. They surface important updates and discussions without overwhelming my inbox.

I also participate in communities. I hang out on r/iOSProgramming and Stack Overflow, answering questions when I can. Teaching others reinforces my own understanding, and I learn a lot from other people’s problems.

For deeper dives, I take courses when I see a gap. I just finished a course on SwiftUI because I realized I was still thinking in UIKit patterns, and it was limiting my designs. That course immediately changed how I structured a view controller in my current project.

I attend one or two mobile developer conferences a year if possible, like WWDC. Not always in person—I watch recorded sessions and read recaps from other attendees.

Honestly, the key is intention. I set aside maybe five hours a week for learning, whether that’s reading, tinkering with a new tool, or working on a side project. That’s how I stay relevant without burning out.”

Personalization tip: Be honest about your learning style and frequency. If you’re not naturally inclined to follow industry news, emphasize how you learn through building (side projects are totally valid). The key is showing you have a system, not that you’re perfect.

Describe your experience with state management. Which approach do you prefer?

Why interviewers ask this: State management is a common pain point in app development. This reveals how you think about architecture, scalability, and whether you’ve dealt with complex data flows.

Sample answer: “State management was one of my biggest learning curves. Early on, I’d pass data through deeply nested view controllers and lose track of where changes came from.

With React Native, I experimented with Redux and MobX. Redux felt overly verbose at first—so much boilerplate—but I grew to appreciate how predictable it made debugging. When something was wrong, I could replay actions and understand exactly what happened. I used Redux Thunk for async actions, which felt natural.

For native iOS development, I’ve used SwiftUI’s @State and @EnvironmentObject for simpler apps, and I’ve built custom managers for more complex flows. For a music streaming app, I built a singleton player manager that coordinated playback state, queue management, and sync with backend. It worked, but in retrospect, I should’ve used a more structured pattern like MVVM with a view model that owned state.

These days, my preference depends on the app. For simple apps, local state is fine. For complex apps, I lean toward a unidirectional data flow pattern—kind of Redux-inspired but tailored to the platform. The key is: state flows down, events flow up. That simplicity prevents a lot of bugs.”

Personalization tip: If you haven’t used multiple state management approaches, that’s okay—talk about what you have used and why. If you’re just learning, discuss what you’re drawn to and why. Avoid claiming you’re an expert in everything; nuance is more believable.

Tell me about a time you had to refactor code. What made you decide it was necessary?

Why interviewers ask this: This tests whether you care about code quality over just shipping features, and whether you can balance technical debt against product velocity.

Sample answer: “In my second year on an iOS team, we had a huge view controller that handled user authentication, data fetching, and UI updates. It was maybe 800 lines, and adding any feature meant wading through tangled logic. New developers were terrified to touch it.

I made the case to my team that we needed to refactor. We weren’t adding new features that sprint anyway, so I spent time breaking it into smaller, single-responsibility view controllers using a coordinator pattern. I extracted networking logic into a dedicated service. I added unit tests as I went, which made me more confident refactoring wouldn’t break things.

The refactor took about a week, maybe 15% of a sprint. After that, adding new authentication flows took days instead of weeks. Team morale improved too—people weren’t dreading that code anymore.

The lesson: I learned to spot the smell early. If I’m struggling to name a class or a function has more than one reason to change, that’s a signal. I also learned that it’s easier to refactor incrementally than to let debt pile up. If I notice in code review that something could be cleaner, I’ll do a small refactor then instead of thinking ‘I’ll fix it later.’”

Personalization tip: Share a real example from your experience, not a hypothetical. If you haven’t done major refactoring, talk about a time you improved a small piece of code or how you’d approach a messy module. Show that you think about maintainability, not just shipping.

How do you handle security and data privacy in your apps?

Why interviewers ask this: Security and privacy matter to users and regulators. This reveals whether you think about security by default, not as an afterthought, and whether you understand compliance requirements.

Sample answer: “Security is top-of-mind early in the development process, not bolted on at the end. Here’s how I approach it:

For networking, I always use HTTPS and validate certificates. I never hardcode API keys—they go in secure storage. On iOS, I use Keychain; on Android, the Keystore. For sensitive user data like passwords or tokens, I encrypt at rest.

I’m also careful with user data. I only request permissions I need, and I explain why. For a fitness app, I need location for mapping workouts, but I don’t need access to the user’s photos. I also think about data retention—do I really need to store that data forever, or should I delete it after 30 days?

For compliance, if the app handles personal data, I follow GDPR and CCPA guidelines. That means being transparent about data collection and giving users the ability to export and delete their data.

One project that made this real was a fintech app handling credit card payments. We implemented certificate pinning to prevent man-in-the-middle attacks. We encrypted stored payment tokens. We audited third-party libraries to ensure they weren’t exfiltrating data. That extra diligence took time upfront but prevented a lot of potential problems.

I also stay updated on security vulnerabilities. I check security advisories for dependencies, and I use tools like OWASP Mobile Security to stress-test my apps.”

Personalization tip: Share a specific security decision you’ve made, even if it’s a small one (e.g., “I learned that storing passwords even hashed is risky, so I only store tokens”). Avoid generic statements like “I always follow best practices.” Show that you’ve thought through actual threats.

Walk me through how you’d build a feature from requirements to production.

Why interviewers ask this: This is a catchall question that reveals your process, communication, problem-solving, and how you navigate ambiguity.

Sample answer: “I start with clarity on requirements. I’ll meet with product and design to understand: What problem are we solving? Who’s the user? What’s success? I ask questions like: ‘What if the user has no internet?’ or ‘How often will this data refresh?’ I take notes and write down any assumptions.

Next, I work with design to understand the UX. I’ll review mockups, ask about edge cases, and propose technical constraints if needed. Then I do a technical spike—maybe a few hours exploring how I’d build it. I’ll check: Do I need new dependencies? Are there performance concerns? Is this compatible with our architecture?

I’ll then outline the architecture. For a new feature that displays user data with filters, I’d sketch out: Where does data come from (API, local cache)? How do I handle offline? What’s the error handling? I document this for code review.

Then I build it in small, reviewable chunks. Rather than submitting one massive pull request, I submit feature branches progressively: first, the data layer, then the UI, then integration. This makes code review easier and catches problems early.

Throughout, I’m writing tests—unit tests as I build, integration tests once pieces fit together. I also manual-test on real devices, not just simulators.

Once it’s solid, I tag it for release, add it to release notes, and coordinate with QA. After launch, I monitor crash logs and user feedback for the first few days. If there’s an issue, I’m ready to turn around a hotfix.”

Personalization tip: Use a real feature you’ve built as the example. If you’re new, use a project or feature you’d like to build, walking through how you’d approach it. The key is showing a systematic, collaborative process, not a lone-wolf coding sprint.

Why do you want to work in mobile development?

Why interviewers ask this: This reveals your motivation and whether you’ll stick around. It also helps them understand if you’re genuinely passionate or just looking for any tech job.

Sample answer: “I love the immediacy of mobile apps. You ship an update and within hours, millions of users are using your new code. You see direct impact. I also love the constraints—mobile forces you to think about performance, battery, and data usage in a way web development didn’t make obvious to me.

What really hooked me was building my first app for a cause I cared about. It was a tool to help small nonprofits manage donations. Watching people actually use something I built to do meaningful work was different from anything I’d experienced.

I also appreciate the community. Mobile developers are generous with knowledge—lots of open source, great conferences, active forums. Every project teaches me something new about iOS, Android, architecture, or just how to communicate better with teammates.

Right now, I’m drawn to [Company Name] because I love your app’s focus on accessibility and your recent open-source contributions. I want to work somewhere that cares about quality and users, not just shipping fast.”

Personalization tip: Make this personal. Talk about a specific moment when you fell in love with mobile development or what aspects of the work energize you. Reference the company specifically—what have they shipped that you admire? This is where genuine interest makes you stand out.

Behavioral Interview Questions for Mobile App Developers

Behavioral questions reveal how you think, communicate, and work with others. Use the STAR method: Situation, Task, Action, Result. Set the scene briefly, explain what you needed to accomplish, walk through what you actually did, and finish with the outcome and what you learned.

Tell me about a time you disagreed with a designer or product manager. How did you handle it?

Why interviewers ask this: They want to see if you can collaborate with non-engineers, advocate for technical perspective, and resolve conflict professionally.

STAR framework:

• Situation: Our design team proposed a beautiful animation for the app’s onboarding flow. It was pixel-perfect and impressive in mockups.
• Task: As the developer, I was concerned about performance on older devices (iPhone 6 and earlier were still 20% of our user base). I needed to communicate that concern without killing the design.
• Action: I didn’t immediately say “no.” Instead, I prototyped the animation, profiled it on an iPhone 6, and showed the team it was dropping to 30 FPS on older devices. I proposed alternatives: we could use the animation for iOS 13+ and a simpler transition for older devices, or we could optimize the animation to be GPU-friendly. I came prepared with solutions, not just problems. We discussed and landed on a hybrid approach.
• Result: The final onboarding looked great and performed well across all devices. The team respected that I wasn’t just saying “no”—I was finding ways to make their vision work. That changed how I approach design-dev collaboration.

Tip for personalizing: Use a real example. Focus on showing that you listened, understood their perspective, and found a win-win. Avoid painting yourself as the only logical voice in the room—that reads as arrogant.

Describe a time you failed on a project. What did you learn?

Why interviewers ask this: Failure stories reveal resilience, humility, and whether you extract learning from mistakes.

STAR framework:

• Situation: I was leading development on a feature that had a hard deadline. We were shipping a new notification system in two weeks.
• Task: I needed to build the feature, get it tested, and deployed to the App Store—all on a tight timeline.
• Action: I cut corners. I skipped some unit tests thinking I’d “add them later.” I didn’t do thorough cross-device testing, assuming the simulator was enough. I wanted to look good by hitting the deadline. We shipped on time.
• Result: Two days after release, we got reports of crashes on iOS 12 devices. The app was crashing for about 5% of users. I had to turn around a hotfix in a few hours, which was stressful. We lost time we didn’t have. If I’d done proper testing upfront, we would’ve caught it.
• Learning: I realized that cutting corners on quality always costs more time in the end. Now, I build time for testing into my estimates, even under pressure. I also learned to push back on unrealistic deadlines instead of silently accepting them.

Tip for personalizing: Pick a real failure, not a “failure” that was actually a success. Be honest about what you’d do differently. Show that you’ve changed your approach based on the lesson.

Tell me about a time you had to learn something new quickly for a project.

Why interviewers ask this: Mobile development evolves constantly. This reveals your learning agility and whether you can step outside your comfort zone.

STAR framework:

• Situation: My team decided to build a feature using SwiftUI, which I’d never used before. The feature was a complex filtering interface with custom interactions. Shipping was in four weeks.
• Task: I needed to ship a production-quality feature in a framework I’d never shipped in before.
• Action: I spent a week doing a deep dive. I watched WWDC sessions on SwiftUI, worked through tutorials, and built a small prototype. I also paired with a teammate who had more SwiftUI experience. We worked through the tricky parts together—state management, custom view modifiers, animating complex layouts. I spent evenings reading Apple’s documentation and playing with small experiments.
• Result: We shipped on time. The feature worked well and felt native. More importantly, I now feel comfortable with SwiftUI for complex UIs, whereas before I would’ve avoided it.
• Learning: I learned that I can pick up new technologies faster than I think if I’m intentional about it. I also learned to ask for help from teammates, not just bang my head against docs.

Tip for personalizing: Use a technology or framework you actually learned recently. Be specific about your process. Avoid claiming you’re a fast learner without backing it up with a real example.

Describe a time you had to communicate a technical concept to a non-technical person.

Why interviewers ask this: Mobile developers work with product managers, designers, and stakeholders who aren’t engineers. This reveals whether you can translate jargon into plain language.

STAR framework:

• Situation: Our CEO was asking why the app was “slow” and wanted to know if we could just “optimize it faster.” The team looked at me to explain the technical reality.
• Task: I needed to explain why app performance is complex and why we can’t just flip a switch, without condescending or overcomplicating it.
• Action: I used an analogy. I said: “App performance is like a restaurant. You can make it faster by hiring more cooks (multithreading), serving smaller portions (optimizing data), or streamlining the menu (removing features). But if you have a bad kitchen layout, none of that helps. We’ve profiled our app and found three main bottlenecks. Here’s what we’ll fix first, and here’s the realistic timeline.” I showed data—before-and-after metrics. I gave her a concrete plan.
• Result: She understood. We got buy-in to allocate engineering time for the optimizations. The conversation shifted from “just make it faster” to “let’s focus on these three areas.”

Tip for personalizing: Pick a situation where you successfully explained something complex. Show that you adapted your communication to your audience. Avoid making yourself the hero who had to educate everyone else—frame it as collaboration.

Tell me about a time you had to deal with ambiguous requirements.

Why interviewers ask this: Product requirements are often fuzzy. This reveals whether you ask questions, make assumptions, or get stuck.

STAR framework:

• Situation: Product came to us with a request: “Build an offline mode for the app.” That was the entire brief—no details on what data should sync, how to handle conflicts, or which features should work offline.
• Task: I needed to clarify requirements without blocking progress and build a feature that actually solved the user problem.
• Action: I didn’t start coding. Instead, I asked product: “Which user actions do we want to support offline? Chat? Viewing content? Purchases?” We discovered that users primarily wanted to browse and save content for later. I drafted a spec: users can browse cached content, save items to read offline, but can’t perform actions that need real-time data. I shared this with product and design for feedback. Once aligned, I built a system where data syncs bidirectionally when online, conflicts are resolved by keeping the most recent version, and UI indicates what’s available offline.
• Result: The feature shipped and users loved it. We reduced customer complaints about using the app on airplanes.
• Learning: I learned that ambiguous requirements are common, and the best move is to ask clarifying questions upfront rather than build the wrong thing.

Tip for personalizing: Show that you’re proactive about reducing ambiguity. Pick an example where you clarified before diving into code. This is a huge asset on product-driven teams.

Technical Interview Questions for Mobile App Developers

These questions dig into specific technical decisions, frameworks, and problem-solving approaches. Rather than memorizing answers, think through the framework the interviewer is looking for.

Explain the difference between UIViewController lifecycle methods in iOS. When would you use each?

Why interviewers ask this: Understanding lifecycle is fundamental to iOS development. This reveals whether you truly understand how iOS manages views or are just going through motions.

Answer framework:

Structure your answer around the key lifecycle methods in order:

1. init/initWithCoder – Initializer; never override for IBOutlets
2. loadView – Creates the view hierarchy; rarely override unless doing it programmatically
3. viewDidLoad – Best place to set up initial UI state, configure data, set up observers
4. viewWillAppear – Called before the view appears; use for things that change based on app state (refresh data, update UI colors)
5. viewDidAppear – View is fully visible; good for starting animations or analytics tracking
6. viewWillDisappear – Cleanup before view goes away
7. viewDidDisappear – View is gone; final cleanup
8. deinit – Deallocate; remove observers and timers

Sample thought process: “In viewDidLoad, I set up the UI and fetch initial data. In viewWillAppear, I refresh data that might have changed since the last time the user was on this screen—like if they edited something on a different screen. I use viewDidAppear for tracking analytics because I want to count it as a genuine view, not just a controller being allocated. For cleanup, I remove observers and cancel network requests in viewWillDisappear to prevent memory leaks and unnecessary work.”

Personalization tip: If asked follow-up questions about specific situations (e.g., “How would you refresh data when the user returns to this screen?”), walk through your decision-making. Avoid saying “I just use viewDidLoad for everything”—that signals incomplete understanding.

How would you implement a feature that caches data locally and syncs with a server?

Why interviewers ask this: This is a real problem every app faces. It tests your understanding of data persistence, network management, and offline-first thinking.

Answer framework:

Walk through the architecture:

1. Local storage layer – Where does data live? (Core Data, SQLite, Realm, UserDefaults)
2. Sync logic – When and how do you sync? (on app launch, periodically, on network availability)
3. Conflict resolution – What if the user changes data offline, and the server also changed? (last-write-wins, user chooses, merge logic)
4. Network detection – How do you know when network is available? (Reachability library)
5. UI updates – How do you keep the UI in sync as data changes? (Observers, combine, reactive patterns)

Sample answer: “I’d use Core Data for local storage because it’s performant and works well with Codable. I’d have a sync manager that watches for network availability using Network framework. When offline, writes go to Core Data immediately. When online, the sync manager checks if there are pending changes and batches them to the server.

For conflict resolution, the server is the source of truth—if there’s a conflict, the server version wins, and I’d notify the user if necessary. I’d use a ‘syncState’ field on each entity (synced, pending, failed) to track what needs attention.

For the UI, I’d use a Combine publisher that fires whenever Core Data changes, either from local writes or from sync completing. That way, the UI always reflects the current state without me having to manually call reloadData.

Edge case I’d handle: what if the sync fails halfway through? I’d implement retry logic with exponential backoff and log failures so the sync manager can pick up where it left off.”

Personalization tip: Reference frameworks and tools you’ve used. If you haven’t built this exact system, talk through how you’d approach it. Show that you’ve thought about edge cases, not just the happy path.

How do you handle memory management in Swift? When would you use weak or unowned references?

Why interviewers ask this: Memory leaks are a common source of crashes and performance degradation. This reveals whether you understand reference counting and retain cycles.

Answer framework:

Explain the mental model:

1. Strong references – Default; keep objects alive; use most of the time
2. Weak references – Don’t keep objects alive; used to break retain cycles; always optional
3. Unowned references – Don’t keep objects alive; must always have a value; risky but slightly more efficient
4. Retain cycles – When two objects strongly reference each other, neither can be deallocated

Sample answer: “Swift uses automatic reference counting. When you create a strong reference to an object, you’re saying ‘I need this to stay alive.’ When all strong references are released, the object is deallocated.

The problem: if object A strongly references object B, and object B strongly references object A, neither can be deallocated even if you’re done using them. That’s a retain cycle.

In closures, I often see this. If a closure captures self strongly, and the view controller holds the closure, you get a cycle. The fix: in the closure capture list, capture self as weak: { [weak self] in guard let self = self else { return } ... }. If self has been deallocated, the closure just exits gracefully.

I use unowned when I’m certain the referenced object will outlive the closure—like if a child view controller captures its parent. But weak is safer because it handles nil gracefully.

I’m careful with delegates too. If a UITableViewDelegate holds a strong reference to the view controller, and the view controller holds a strong reference to the delegate, that’s a cycle. That’s why delegate properties are usually weak in framework code.”

Personalization tip: Discuss real scenarios you’ve encountered or been aware of. If you haven’t debugged a memory leak yet, say so, but show that you understand the concepts. Avoid saying you never have retain cycles—it’s unrealistic.

Walk me through how you’d debug a crash in production.

Why interviewers ask this: Debugging under pressure is part of the job. This reveals your methodology and tools.

Answer framework:

Outline a systematic approach:

1. Gather information – Crash log, stack trace, affected versions/devices, frequency
2. Reproduce – Can you reproduce it locally? (often the hardest step)
3. Isolate – Use crash tools to narrow down: is it your code, a third-party library, or the OS?
4. Fix and test – Write a fix, verify it in a test environment, add tests to prevent regression
5. Deploy – Ship a hotfix or include in next release
6. Monitor – Watch for recurrence

Sample answer: “First, I’d look at the crash report in Firebase Crashlytics or Xcode Organizer. I’d check: what’s the stack trace? Which line? Which iOS versions? Is it affecting 0.1% of users or 5%?

Let’s say it’s a crash on iOS 14.2 specifically, in a payment flow, affecting 1% of users—so not super common. I’d try to reproduce it locally. I’d test on iOS 14.2, walk through the payment flow, and see if I can trigger it. If I