Session 1: App Concepts & Scoping

You already build for the web, so the first useful question is not how do I build an app but does this need to be one. An app differs from a website in four specific ways: it is installed, so it opens instantly and sits on a home screen; it can work offline, holding its own data; it has direct access to the device — camera, location, notifications, contacts; and it can run in the background, doing things while the user is elsewhere.

If your idea needs none of those, a website is the better answer. It is cheaper to build, needs no app store approval, updates instantly for everyone, and works on any device with a browser. A great many app ideas are website ideas wearing a costume, and recognising that early saves months.

Where an app genuinely wins is frequency and presence. Something used several times a day — an expense tracker, a habit log, a delivery app — benefits from being installed, opening fast and working on a bad connection. That is the category our course project sits in, and it is the category worth learning to build for.

The commonest reason a first app is never finished is that it was the wrong project. Three tests decide it. Would you use it yourself? A project you would actually open is a project you will keep fixing, and you become your own tester with real opinions. Is the data real? An app with invented sample data teaches you nothing about edge cases; an app tracking your own spending immediately shows you what happens with a zero, a huge number, a missing category.

The third test is the important one: can it be finished in four weeks by one person? Almost every first idea fails this, and the fix is not more time but a smaller app. Our course project is deliberately modest — record an expense, list the expenses, show a monthly total by category. Four screens. It is small enough to complete and complete properly, and it still touches every concept in the course.

The trap to avoid is the idea that impresses. A marketplace, a ride app, a social network — these are enormous systems with two-sided problems, payments, moderation and trust, and they are the wrong first project however exciting. Build something small, finish it, ship it, and you will have learned more than a year of planning something large.

Scoping means deciding what version one is, and the discipline is that version one is the smallest thing that still works as a product. Not the smallest thing you can build — the smallest thing a user could open and get value from. For the expense tracker that means adding and listing expenses; it does not mean charts, budgets, receipts or multiple currencies, however obvious those feel.

The method is to write every feature you can think of, then split each into must-have — without it the app does not work — and nice-to-have — with it the app is better. Version one is the must-haves only. The nice-to-haves go in a list for later, which matters psychologically: you are not abandoning them, you are ordering them.

Then the test that catches most over-scoping: can you describe version one in one sentence? Record expenses and see a monthly total by category. If your version one needs three sentences, it is three versions. And the corollary worth internalising — a finished small app is worth more than an unfinished ambitious one, in your portfolio, in your learning, and in your confidence.

An app that works but feels wrong is usually ignoring platform conventions — the expectations users have absorbed from every other app on their phone. The largest differences sit between iOS and Android. Android has a system back button (hardware or gesture) that must behave sensibly; iOS does not, so back is always an on-screen control. Navigation placement differs: Android apps often put navigation in a drawer or at the top, iOS apps in a bottom tab bar.

Smaller conventions add up: swipe to go back is standard on iOS, long-press menus behave differently, date and number formats vary by region, and status bar colour and content are handled differently. None of these break an app, and all of them make one feel slightly foreign.

The practical approach for a first app is to follow the framework's defaults, which are already platform-aware, rather than inventing your own navigation. A standard tab bar with three or four items feels correct on both platforms; a custom gesture-based navigation you designed feels like yours, and not in a good way. Custom interaction is earned after the basics work.

This is worth being precise about, because vague promises here waste people's money. You do not need a Mac to learn mobile development or to build a working app. The toolchain we use runs on Windows and Linux, you can develop and test on an Android device or in a browser-based simulator, and you can even distribute an Android app without ever touching macOS.

Apple's App Store is the exception, and it is a hard one: final iOS builds require macOS. There is no legitimate way around it, and any course or tool claiming otherwise is describing a workaround that will fail at the point you need it. So if your goal is publishing to the App Store, you will eventually need a Mac — or a client who has one, or a cloud build service, which is a real option but not a free one.

The honest framing is that the skills are the same and the last mile differs. Everything in this course — screens, navigation, state, data, testing — applies to both platforms, and an app built here can be shipped to iOS later by someone with the right machine. We say this plainly rather than letting you discover it in week six.