Mobile App Development

What this covers

• Designing screens with layout containers (ConstraintLayout, Flexbox/Column-Row, or SwiftUI stacks) so the UI adapts to different screen sizes and orientations
• Wiring UI events — taps, text input, list selection — to handler code, and updating the interface from that code without freezing it
• The activity/view lifecycle: what happens on create, pause, resume and destroy, and where to put setup and cleanup code
• Holding and restoring state across rotation, backgrounding, and navigation between screens
• Displaying lists of data with an adapter or list builder, including handling empty and loading states
• Storing data on the device with SharedPreferences, UserDefaults, or a small SQLite/Room database, and reading it back on next launch
• Requesting runtime permissions (camera, location, storage) and handling the case where the user says no
• Testing on an emulator versus a physical device, reading logcat or console output, and tracing a crash back to a line of code

Where learners get stuck

Assuming a screen stays alive the whole time the app is open, so variables set in one place mysteriously reset

Students carry over desktop-program habits where main() runs start to finish. On mobile the system can destroy and rebuild a screen on rotation or when memory is low, so anything not saved to state or storage is lost.

Doing network calls or file reads on the main/UI thread and then not understanding why the app freezes or throws NetworkOnMainThreadException

In earlier coursework every line ran in order and waiting was invisible. Mobile frameworks reserve the main thread for drawing, so blocking work has to move to a coroutine, async task, or background queue.

Treating the emulator as identical to a real phone — hardcoding pixel sizes, assuming permissions are already granted, or ignoring slow networks

The default emulator has one screen size and pre-granted settings, so a layout that looks correct there breaks on a narrower device or when a real user declines a permission prompt.

What a session looks like

Sessions run as spoken conversation with Evelyn while you have your project open. A typical hour: you describe what your app should do and what it currently does, then you're asked to read out the relevant chunk of layout or handler code so the mismatch can be located. Evelyn talks through the fix rather than dictating a file — for example, walking you through where in the lifecycle to move an initialisation, or how to restructure a list adapter. Debugging sessions centre on reading the actual error text and stack trace aloud. Planning sessions cover breaking an app idea into screens, deciding what data has to persist, and sequencing the build so you have something runnable early.

Helpful to know first

• Comfortable writing loops, conditionals, functions and using arrays or lists in at least one language
• Familiar with classes, objects and methods — mobile frameworks are built around them
• Able to install and open an IDE (Android Studio, Xcode, or a Flutter setup) and run a sample project on an emulator
• Basic file and folder navigation on your computer, since project structure matters

Questions

Does my child need a Mac to learn mobile app development?

Only for iOS. Xcode and Swift require macOS. Android development with Android Studio works on Windows, Mac or Linux, and Flutter runs on all three though it can only build iOS apps on a Mac. Most high school courses use Android or a cross-platform tool for this reason.

Should I start with Android, iOS, or Flutter?

Start with whatever your class or teacher uses so your work matches assignments. If you're choosing freely, Android with Kotlin or Flutter with Dart avoid the Mac requirement. The lifecycle, state and layout concepts transfer between all of them.

Can Evelyn help debug an app that crashes on launch?

Yes. You read out the error message and stack trace, and the session works backwards from there to the line and cause — a null view reference, a missing manifest entry, a permission not declared. You make the edits yourself.

Is this the same as the programming my child already does in class?

There's overlap in language basics, but mobile adds a framework you don't control: the operating system decides when your screen is created, paused or destroyed. Much of the learning is about writing code that behaves correctly under those interruptions.