Thuta Learning
Search
ExercisesMobile Developmentintermediate

Practice Set 2

Relax. We'll talk through this in plain words — no textbook voice.

What you'll walk away with

  • Understand Practice Set 2 with zero fear
  • Run the Xcode/SwiftUI code yourself
  • Apply this concept in a real project right away

Let's think about it this way for a second

This round steps up from round 1 — instead of practicing each skill in isolation, you'll combine them all at once. That includes deciding how to split MVVM layers for an app, choosing between View-local `@State` and app-wide `ObservableObject` depending on the scenario, and writing an App Store submission plan as a production document. Budget about 10 minutes per task.

Let's connect this to a real-world scenario

Task 1: Design the MVVM layers (Data/ViewModel/View) for a note-taking app (offline-first, with optional iCloud sync), and write out what each layer's responsibilities should be. Task 2: For the two scenarios 'the text in a search box (View-local)' vs 'the user's login status (app-wide)', decide whether to use `@State` or `ObservableObject` and explain why. Task 3: If an app's crash rate suddenly spikes after launching on the App Store (as seen in Xcode Organizer/Firebase Crashlytics), write out what steps you'd follow to investigate and respond. Task 4: Design the permission declaration/request flow for the requirement 'I want the app's camera permission for just one feature (a receipt scanner), and I don't want photo library access'.

Let's walk through it together

text
# Task 2 - @State vs ObservableObject
Search box text (used by one screen only) -> @State
  (View-local, private, doesn't need to be shared)

User login status (needed across many screens) -> ObservableObject
  (app-wide, injected via .environmentObject at the root)

# Task 3 - crash-rate incident response
1. Check Xcode Organizer / Crashlytics — which screen/exception spiked?
2. Check recent release notes — did a new version just roll out?
3. Reproduce locally on the affected iOS version/device if possible
4. If severe, consider phased release pause in App Store Connect
5. Document root cause once fixed, add a regression test
You should see
You'll come away with an MVVM layer design, a @State-vs-ObservableObject decision, a crash-rate incident response plan, and a scoped permission flow.

5-minute try-it

Write the permission flow for Task 4 yourself for camera permission (`NSCameraUsageDescription`), following the same pattern as `LocationManager` from the Intermediate chapter.

A quick word of caution

App Store review checks strictly for permission scope creep — if your declared usage description doesn't match the app's actual behavior (for example, saying 'receipt scan' while also accessing the photo library), you can get rejected.

Easy traps

  • Putting View-local state (search text, form input) into an `ObservableObject` — that's overkill and can trigger app-wide re-renders
  • Requesting photo library access ('NSPhotoLibraryUsageDescription') that a core feature doesn't actually need (when all you want is camera capture) — not realizing this can get you rejected by App Store review

Now try it yourself

Write the permission flow for Task 4 yourself for camera permission (`NSCameraUsageDescription`), following the same pattern as `LocationManager` from the Intermediate chapter.

You'll know it worked when: You'll come away with an MVVM layer design, a @State-vs-ObservableObject decision, a crash-rate incident response plan, and a scoped permission flow.

Practice Set 2 | Thuta Learning