01From nothing to everything
Before you build an app, it is worth knowing what you are joining. The app economy did not creep into existence — it appeared almost overnight, and it was not even meant to happen.
This section is set as reading, not lesson time. Come to the first lesson having read it and having thought about the discussion questions at the bottom of the page — we will spend fifteen minutes comparing answers and then go straight to building. With only six lessons there is no spare one to read in.
The iPhone launched without apps
When the first iPhone went on sale on 29 June 2007, it shipped with about fifteen built-in apps and no way to add more. Steve Jobs did not want outside developers on the device at all. His public advice to programmers was to build websites instead — "web apps" that ran in Safari.
Developers hated the idea. Within weeks people had broken into the phone's software to install their own programs anyway. Apple gave in: a software development kit arrived in early 2008, and on 10 July 2008 the App Store opened with roughly 500 apps. Around a quarter of them were free. Ten million downloads happened in the first weekend.
Android's marketplace opened three months later. Between them, those two stores changed how software reaches people: no boxes, no discs, no shops, and a fourteen-year-old with an idea suddenly had the same distribution channel as Microsoft.
How fast did it grow?
Why a log scale? On a normal scale the 2008 bar would be about a quarter of a pixel tall — invisible next to two million. A logarithmic axis lets you see the shape of explosive growth: notice the jump from 2008 to 2009 is steeper than everything that followed. The gold rush was over quickly.
Where things stand now
Look closely at those numbers. Business of Apps says 142 billion downloads in 2025. Sensor Tower says 149 billion. Another firm says 137.8 billion. They are all "correct." They count different things: some count re-installs and updates, some count only one download per account, some include third-party Android stores and some do not.
When you write your own evaluation later in this unit, you will need to quote numbers about your users. Say where they came from and how they were counted — a statistic without a method behind it is just a rumour with a decimal point.
A short timeline
iPhone launches — closed
Fifteen built-in apps. No store, no third-party software. Jobs tells developers to write websites.
The App Store opens
10 July: about 500 apps. Developers keep 70% of the sale price and pay a US$99 yearly fee. Android Market opens in October.
In-app purchases arrive
Suddenly an app can be free and still make money. This one change eventually reshapes the entire industry — and gives us "freemium" games.
"There's an app for that"
Instagram (2010), Uber, Snapchat. The App Store passes one million apps in October 2013. Phone cameras, GPS and accelerometers become the raw material for whole businesses.
Apps become infrastructure
Banking, transport tickets, school timetables, medical appointments. Using some services without an app becomes genuinely difficult.
AI eats the charts
Downloads flatten at roughly 140–150 billion a year — almost everyone who can have a phone already has one. Growth now comes from spending, not installs. ChatGPT becomes the most downloaded app on Earth in 2025.
What this means for you
The barrier is gone
The hard part of software used to be distribution — getting a disc into a shop. Now anyone can publish. The hard part is being worth opening twice.
Most apps fail quietly
Over a quarter of apps on Google Play get fewer than 100 downloads, ever. Building an app is easy now. Building one somebody needs is not.
The sensors are the point
A phone knows where it is, which way it is facing, how fast it is moving and what it can hear. Apps that use that are the ones that could not exist on a desktop.
Discussion — pick one app on your phone
- What did people do instead of using this app in 2006?
- Which phone sensor or hardware feature does it rely on? What would it lose without it?
- How does it make money? Purchase, subscription, in-app purchases, advertising, or data?
- If it disappeared tomorrow, what would break in your day — and is that a good or bad thing?
02Getting set up
App Inventor runs entirely in a web browser. There is nothing to install on your laptop. Everything you build is saved on MIT's servers under your Google account, so you can pick it up on any machine.
Create your account
5 minutes — do this once
- Go to
appinventor.mit.eduand click Create Apps! (top right). - Sign in with your school Google account. Do not use a personal account — you will not be able to hand work in from it.
- Accept the terms of service. Skip the welcome survey if you like.
- You will land on the project list. It is empty. That is correct.
App Inventor autosaves constantly — there is no Save button and you do not need one. But before you attempt anything risky, use Projects → Save project as… to make a copy you can fall back to. This is the single most useful habit in this unit.
Choose how you will test
Pick one now — you can change later
You need a way to actually see your app running while you build it. There are three routes, and which one you use depends on the phone in your pocket.
Android phone
Install MIT AI2 Companion from Google Play. In App Inventor choose Connect → AI Companion and scan the QR code. Your app appears live and updates as you change blocks.
You can also export a real installable app later via Build → Android App (.apk).
iPhone
Install MIT App Inventor from the App Store. Connect the same way. Live testing works well.
Limitation: you cannot export an installable file for iPhone — Apple does not allow it. Your app runs inside the Companion. A handful of components are Android-only; the palette warns you.
No phone in class
Use the emulator: install aiStarter on the laptop, then Connect → Emulator. A simulated Android phone opens on screen.
It is slower and it cannot shake, tilt, or know where it is — so sensor projects need a real device at some point.
App Inventor is a website and your project lives on MIT's servers, so you can open it on any computer with your school Google account and carry on. Testing at home is the part that differs: Android students should build an .apk (step 5 of the guided build) and install it, after which no computer is needed at all. iPhone students need a computer and their phone on the same home Wi-Fi to use the Companion.
Nine times out of ten the phone is on mobile data and the laptop is on the school Wi-Fi. They must be on the same network. If the school network blocks device-to-device traffic, use the six-character code option instead of the QR code, or fall back to the emulator.
The two rooms: Designer and Blocks
App Inventor has exactly two screens, and you switch between them with the buttons in the top right. Everything you will ever do happens in one or the other.
Designer — what the app looks like
- Palette (left) — the parts bin. Drawers for User Interface, Layout, Media, Drawing and Animation, Maps, Sensors, Social, Storage, Connectivity.
- Viewer (middle) — a fake phone. Drag components onto it.
- Components (right) — the list of everything you have added. Rename things here.
- Properties (far right) — colour, size, text, font of whichever component is selected.
- Media — images and sounds you have uploaded.
Blocks — what the app does
- Built-in drawers — Control, Logic, Math, Text, Lists, Dictionaries, Colours, Variables, Procedures.
- Component drawers — click any component's name to get the blocks that belong to it.
- Canvas — drag blocks here and snap them together. Blocks only fit where they make sense, so shape is a hint.
- Warnings counter (bottom left) — yellow triangles are blocks not attached to anything; red crosses are real errors. Get both to zero.
App Inventor is event-driven. Your code does not run top to bottom like a story. It sits waiting, and when something happens — a tap, a shake, a timer tick, a text message arriving — the matching event block wakes up and runs what is inside it. Every program you write in this unit is a set of answers to "when X happens, do Y".
Visible and non-visible components
Some components you can see: buttons, labels, images, sliders. Others do a job without appearing on screen at all — a text-to-speech engine, an accelerometer, a database, a web connection. When you drag those onto the Viewer they drop underneath the phone, in a strip labelled "Non-visible components". They are not broken. They are meant to be there.
App Inventor names things Button1, Label1, Label2. By block 30 you will have no idea which is which. Rename every component the moment you add it, using a name that says what it is for: AskButton, AnswerLabel, CountLabel. This is worth real marks in the rubric, and it is the difference between a two-minute fix and a twenty-minute one.
03Guided build: Pocket Oracle
We are going to build a fortune-telling app. You ask it a question out loud, shake the phone, and it answers — in a voice, on screen, and it keeps count of how many times you have bothered it. Along the way you will meet every idea you need for your own project: components, events, variables, lists, randomness, decisions, procedures and sensors.
What you will learn to use
- Components and properties — the Designer
- Event handlers —
when … do - Lists and
pick a random item - Global variables and a counter
if / elsedecisions- A procedure, to stop repeating yourself
- A real sensor — the accelerometer
- Building an installable file
Working preview — tap it. This is what you are building.
Lesson 1: steps 1–5, finishing with a working app installed on your own phone. Lesson 2: steps 6–12 and the checkpoint quiz.
A hundred minutes is a long stretch. Stop at step 5, install it, and spend ten minutes showing it to the people around you before starting the second half — you will spot things in someone else's app that you cannot see in your own.
If you fall behind, steps 1–7 still give you a finished, demonstrable app, and they cover every technique the assessment requires except the sensor. Finish the rest at home. Do not skip step 10: the procedure is the reason step 11 takes two minutes.
Start the project and set up the screen
Designer · ~8 minutes
- From the project list choose Start a new project. Name it
PocketOracle— no spaces allowed in project names. - Click Screen1 in the Components panel so its properties appear on the right.
- Set these properties:
| Property | Set it to | Why |
|---|---|---|
| AppName | Pocket Oracle | This is the name under the icon on the phone. It can have spaces. |
| Title | Pocket Oracle | The bar across the top of the app. |
| AlignHorizontal | Center: 3 | Everything you add now stacks down the middle instead of hugging the left edge. |
| BackgroundColor | Dark blue (Custom…) | An oracle in default white looks like a tax form. |
| Theme | Device Default | Leave it. Changing themes mid-project causes odd colour bugs. |
The fake phone in the Viewer should now be dark with your title across the top. Nothing else has changed. That is the whole step.
Lay out the interface
Designer · ~12 minutes
Drag these from the User Interface drawer onto the phone, in this order. Rename each one straight away using the Rename button under the Components panel.
| Drag this | Rename it to | Key properties |
|---|---|---|
| Label | PromptLabel | Text: Ask your question, then shake. FontSize: 16 TextColor: White |
| Label | AnswerLabel | Text: … FontSize: 26 FontBold: ticked TextColor: Yellow Width: Fill parent TextAlignment: center |
| Button | AskButton | Text: Ask the Oracle FontSize: 18 Width: Fill parent Shape: rounded |
| Label | CountLabel | Text: Questions asked: 0 FontSize: 12 TextColor: Light Gray |
If you have an image you want as the oracle's "orb", drag an Image component above PromptLabel, click Picture → Upload File, and set Width and Height to about 150 pixels. Keep it under 200 KB — large images make the Companion crawl.
Stuck? Components landing in the wrong order
Order is set by where you drop, not by the order you created things. Drag a component up or down in the Viewer to move it, or drag it in the Components tree. If something refuses to move, it has probably landed inside an arrangement — drag it out to the phone body first.
Add the invisible machinery
Designer · ~4 minutes
- From the Media drawer, drag TextToSpeech onto the phone. Leave the name as
TextToSpeech1. - From the Sensors drawer, drag AccelerometerSensor onto the phone. Leave it as
AccelerometerSensor1.
Both drop into the grey strip below the phone labelled Non-visible components. Nothing appears on the screen itself, and nothing is wrong.
Click AccelerometerSensor1 and find Sensitivity. Default is moderate. If your shake never triggers later, come back and set it to weak — confusingly, "weak" means a weaker shake will set it off, which is what you usually want in a noisy classroom.
Your first block — and your first test
Blocks · ~10 minutes
Switch to the Blocks editor (button, top right). We are going to make the button do one hard-coded thing, then run it on a real phone before adding anything else. Test early. Always.
- Click
AskButtonin the left tree. Drag outwhen AskButton.Click do. - Click
AnswerLabel. Drag outset AnswerLabel.Text toand snap it inside the click block. - Click the Text drawer. Drag out the empty string block
" "and plug it into the socket. Click it and typeYes, definitely.
- Now connect: Connect → AI Companion, scan the QR code with the Companion app on your phone.
- Wait for the app to appear. Tap the button. The label should change.
Because when something breaks in twenty minutes' time, you will know it was not the connection, the phone or the layout. You have just eliminated three quarters of the things that could be wrong. Professional developers do exactly this.
Build your first .apk and take it home
~15 minutes · do this now, not at the end
Your app does one thing. That is enough to install it properly. Building an .apk now matters for a practical reason: the Companion only works when your phone and the laptop are on the same network. An installed app does not care. Once it is on your phone it stays there, and you can show it to anyone, anywhere.
- Choose Build → Android App (.apk). MIT's server compiles it — usually under a minute, longer if the whole class presses the button at once.
- You get a QR code, valid for about two hours. Scan it with your phone's camera and install.
- Android will warn you about installing from an unknown source. That warning is correct and you should normally heed it — here the unknown source is you.
- Open it from your home screen. No laptop, no cable, no Companion.
Once now, once at the end of the guided build, and at least once during your own project so a classmate can test it on their phone. Treat it as a routine, not a final ceremony — it is how you find out whether the thing actually works away from your desk.
You cannot build an installable file, and no workaround changes that. Use the Companion instead. It works perfectly well at home: open App Inventor in a browser on any computer, put that computer and your phone on the same home Wi-Fi, and connect as usual. For homework you need both devices; Android students only need the phone.
App Inventor is a website. Your project is on MIT's servers, tied to your school Google account. You can open it on any computer, anywhere, and pick up exactly where you stopped. There is nothing to install and nothing to carry.
A list of answers, picked at random
Blocks · ~15 minutes
One answer is not an oracle. We need a list — a single named box holding many values — and a way to pull one out at random.
- From Variables, drag
initialize global name toonto an empty part of the canvas. Clicknameand rename itanswers. - From Lists, drag
make a listinto its socket. It starts with two sockets. - Click the small blue mutator gear on
make a list. A mini-window opens. Drag extraitemblocks in to grow the list to eight sockets, then click the gear again to close it. - From Text, drag eight
" "blocks in and type your eight answers. Mix positive, negative and evasive ones — that is what makes it funny. - Back in the click block, delete your hard-coded text block. From Lists, drag
pick a random item listinto the empty socket. - From Variables, drag
getinto its socket and chooseglobal answersfrom the dropdown.
Test it. Tap the button ten times. You should see different answers — and occasionally the same one twice in a row, which is what random actually looks like.
Stuck? The get dropdown is empty
The initialize global block has to exist before the dropdown can offer it, and it must be sitting loose on the canvas — never inside an event block. Check the warnings counter at the bottom left. If you renamed the variable after plugging in the get, App Inventor usually updates it automatically, but check the dropdown says global answers and not global name.
Give it a voice
Blocks · ~5 minutes
- Click
TextToSpeech1in the tree. Dragcall TextToSpeech1.Speak messageand snap it underneath theset AnswerLabel.Textblock, still inside the click event. - Click
AnswerLabeland drag out the getter blockAnswerLabel.Textinto themessagesocket.
We set the label first, then read it back to speak it. If you swap the two blocks the app will speak the previous answer — a classic bug, and a good one to understand now rather than in your assessment.
Test with headphones or you will start a riot.
Count the questions — a variable that changes
Blocks · ~15 minutes
The list was a variable that stays the same. Now we need one that changes while the app runs: a counter.
- From Variables, add
initialize global askCount toand plug in a0from the Math drawer. - Inside the click event, add
set global askCount to. - From Math, drag the
+block into it. Putget global askCounton the left and a Math1on the right. - Add
set CountLabel.Text to, and from Text drag in ajoinblock. First socket: a text block readingQuestions asked:(keep the trailing space). Second socket:get global askCount.
"Set askCount to the current value of askCount, plus one." It looks circular but it is not: the right-hand side is worked out first, then stored back. Almost every counter in every program ever written works exactly like this.
Make a decision — if / else
Blocks · ~12 minutes
An oracle with a personality gets annoyed. After ten questions, it should say so instead of showing the counter.
- From Control, drag out an
if / thenblock. - Click its blue mutator gear and drag an
elseinto theifto add an else branch. Close the gear. - From Math, drag the
=comparison block into theifsocket, then use its dropdown to change=to≥. - Left side:
get global askCount. Right side: Math10. - Move your existing
set CountLabel.Textblock into the else branch, and build a new one in the then branch with a text block readingThe Oracle grows weary.
Extend it: three-way decision
Use the mutator gear again to add an else if. Make the oracle mildly impatient at 5 questions, weary at 10, and refuse to answer at all past 15 — that last one means putting the whole answer-picking code inside the else branch too. Try it before you look at anyone else's solution.
Stop repeating yourself — write a procedure
Blocks · ~12 minutes
We are about to add shake-to-ask. Shaking should do exactly what tapping does. Copying all those blocks would mean fixing every future bug twice. Instead, give the whole routine a name.
- From Procedures, drag out
to procedure do. Click the wordprocedureand rename itConsultOracle. - Drag everything that is currently inside
when AskButton.Clickout and into the procedure body. - From Procedures, drag
call ConsultOracleinto the now-empty click event.
A procedure is a named parcel of instructions. Write it once, call it from anywhere. In your assessment, markers look for this: if the same five blocks appear in three places, that is a procedure waiting to be written. Naming it well is half the value — ConsultOracle tells a reader what happens; Procedure1 tells them nothing.
Shake to ask — using a real sensor
Blocks · ~8 minutes
- Click
AccelerometerSensor1. Drag outwhen AccelerometerSensor1.Shaking do. - Put a single
call ConsultOracleinside it. That is the entire step — because you did step 10 properly.
Test on a real phone. The emulator cannot shake. Hold the phone firmly and give it a decisive flick — not a wave.
Stuck? It fires five times per shake
Real hardware is noisy: one human shake can trip the sensor repeatedly. Two fixes, and you should try the first before reading the second. (1) Set Sensitivity to weak in the Designer. (2) Add a Clock component and a boolean global canAsk: set it to false when the oracle speaks, start a one-second timer, set it back to true on the timer event, and wrap the shake handler in if get global canAsk. That second technique is called debouncing and it will be useful in your own project.
Ship it properly
~12 minutes · your second build
- Icon: back in the Designer, select Screen1 and upload a square image (about 512×512) as the
Iconproperty. - Rebuild: Build → Android App (.apk) again. The icon and the new features only appear in a fresh build — the copy already on your phone is frozen at step 5.
- iPhone: as before, no installable file. Record a screen capture of the finished app running in the Companion — that is your equivalent deliverable, and it is worth the same marks.
- Back it up: Projects → Export selected project (.aia) to my computer. This
.aiafile is your source code. Keep it — you will submit it.
.aia is your project — it can be re-opened and edited in App Inventor. .apk is the finished app — it installs on Android but cannot be edited back into blocks. Submitting only the .apk means nobody can mark your code.
Before you move on
You have now used every structural idea you need. Everything in the assessment task is a recombination of these:
Something happened — run this.
A named box that remembers a value.
One box holding many values in order.
A fork in the road, decided while running.
A named parcel of instructions, reusable.
The app finds out about the real world.
A setting you can read or change live.
Small, early, often, on a real device.
04Block reference
Everything below is something you will reach for during the assessment task. Colour tells you which drawer it lives in — that alone will save you a lot of hunting.
The blocks you will use constantly
| Block | Drawer | What it does / when to reach for it |
|---|---|---|
when <component>.Click | Component | Runs when the user taps. The backbone of nearly every app. |
when Screen1.Initialize | Screen | Runs once, the moment the app opens. Use it to load saved data and set up the starting state. |
if / then / else | Control | Decisions. Click the blue gear to add else if and else. |
for each number from…to | Control | Repeat a fixed number of times — building a grid, dealing cards. |
for each item in list | Control | Do something to every entry in a list. Far cleaner than a counter loop. |
and / or / not | Logic | Combine conditions: "if the score is high and time is left…" |
= ≠ < > ≤ ≥ | Math | One block — change the operator with the dropdown. |
random integer from…to | Math | Random numbers. Note it includes both end values. |
join | Text | Glue text and numbers together for display. Use the gear to add more sockets. |
is empty | Text | Check whether a textbox has been filled in before using what is in it. |
make a list / add items to list | Lists | Create a list, then grow it while the app runs. |
select list item list index | Lists | Get entry number n. Lists in App Inventor start at 1, not 0. |
length of list | Lists | How many entries. Essential for "have we reached the last question?" |
initialize global / get / set | Variables | Named storage that survives while the app runs. |
to <name> do | Procedures | A reusable named routine. Add parameters with the gear to make it flexible. |
to <name> result | Procedures | A routine that hands a value back — e.g. "work out the grade from this score". |
Components worth knowing about
Storage — making things stick
TinyDB saves data on the phone so it is still there tomorrow. Two blocks do everything: call TinyDB1.StoreValue tag… valueToStore… and call TinyDB1.GetValue tag… valueIfTagNotThere…. That last socket matters — put an empty list or a 0 in it so your app does not crash on first run.
Pair it with when Screen1.Initialize to load, and save every time the data changes.
Clock — time and repetition
when Clock1.Timer fires over and over at whatever interval you set (in milliseconds). It drives countdowns, animation, auto-refresh and debouncing. TimerEnabled switches it on and off — a stopwatch is just a clock you enable and disable.
Set TimerInterval to 1000 for one tick per second, 50 for smooth animation.
Canvas & ImageSprite — games
A Canvas is a drawing area with coordinates. ImageSprites move around on it with Speed and Heading, and fire Touched, CollidedWith and EdgeReached events. Almost any simple arcade game is three sprites and a Clock.
Sensors & the real world
LocationSensor (latitude, longitude, street address), Pedometer, ProximitySensor, OrientationSensor (tilt), BarcodeScanner, SpeechRecognizer. These are what make it a phone app rather than a webpage. Check the palette note for any that are Android-only.
Pattern: save a list and get it back next time
Call SaveEntries every single time you add, edit or delete something. Forgetting one place is the most common bug in tracker apps.
Pattern: check the input before you use it
Markers look for this. An app that misbehaves when the user does something unexpected is not finished, and "the user should not have done that" is not a defence.
05Assessment task: build your own app
Choose one project from the list below, or propose your own. You get three build lessons of 100 minutes, plus whatever you do between them. You are marked on the thinking and the process as much as the finished app — a small app that is well planned, well tested and honestly evaluated will out-score an ambitious one held together with tape.
What you hand in
| Deliverable | Detail |
|---|---|
| The project file | Your exported .aia. This is what gets opened and marked. |
| The running app | Android: the built .apk. iPhone: a screen recording of the app running in the Companion. |
| Design folio | One page. The problem and who has it · two interface sketches (on paper is fine, photograph them) · a component list · your algorithm as a flowchart or pseudocode. |
| Test log | A table of at least five tests: what you did, what you expected, what actually happened, what you changed. Include the tests that failed — those are the valuable ones. Fill it in as you go; two minutes at the end of each build lesson is enough. |
| User feedback | Two people who are not you use your app. Record what confused them. Then say what you changed as a result. |
| Evaluation | 200–300 words: does it solve the problem, what would you do with another week, what did you learn about your own process. |
| Demo | 60 seconds, live, in the final lesson. Show it working. Show one thing that was hard. |
Three lessons is not enough on its own, and it is not meant to be. Build an .apk at the end of every lesson and take it with you — then the work between lessons is real work on a real app, not a promise to yourself that you will look at it later. Anything you change at home is already saved when you walk in next time.
Whatever you choose, your app must contain: at least one global variable that changes while running, at least one list, at least one if decision, at least one procedure you wrote yourself, and sensible component names throughout.
Multiple screens are no longer required — in five lessons they cost more time than they teach. Build one screen and make it good. If you want a second one, it counts as an extension.
Project options
Safe: A, B, E, F. These can be finished and polished in three lessons plus homework.
Doable if you are quick and you cut hard: C, D. Both have a technical hurdle — sprite collision, or location permissions — that can eat half a lesson before you have built anything.
Only with an approved plan: G, H. Option H in particular needs an Android device and most of a lesson just to get two devices talking. Take it only if you already know what you are doing.
A — Quiz Master
Most scaffoldedA multiple-choice quiz on a topic you actually know something about — a subject you study, a sport, a game, local history. Questions come from a list, the app tracks the score, and it gives a result at the end with a message that depends on how well the user did.
The interesting problem: how do you store a question, its four options and which one is right, all together? (Answer: a list of lists, or parallel lists. Work out which you prefer and justify it in your folio.)
Likely components: ListView or Buttons · Label · Notifier · TinyDB for high score
B — Habit or Study Tracker
Data-focusedLog something once a day — homework done, water drunk, minutes practised, mood — and see it over time. The data has to survive the app being closed, which means TinyDB.
The interesting problem: deciding what counts as "a day", and what the app should show when there is no data yet. Empty states are a real design skill.
Likely components: TinyDB · ListView · Clock · TextBox · Slider · Chart (optional)
C — Arcade Game
Motion & timingSomething moves, the player has to catch it, dodge it or tap it before time runs out. Difficulty ramps up. Score is kept and the best one is remembered.
The interesting problem: difficulty curves. A game that gets faster by a fixed amount each point becomes impossible in twenty seconds. Work out a curve that stays playable and explain it.
Likely components: Canvas · ImageSprite · Ball · Clock · Sound · TinyDB · AccelerometerSensor for tilt control
D — Campus Guide or Field Guide
Uses locationA guide to somewhere real: the school grounds, a walking track, the birds in your backyard, the war memorials in your suburb. Pick an entry from a list to see detail, a photo, and where it is.
The interesting problem: what should it do with no signal, or when location permission is refused? Handle it gracefully rather than crashing.
Likely components: ListView · Image · LocationSensor · Map & Marker · one screen is plenty
E — Soundboard or Instrument
Quick to startA grid of pads that play sounds you record or make yourself. Then push it further: record a sequence and play it back, or add a metronome.
The interesting problem: playback of a recorded sequence needs a list of what was pressed and a Clock to space it out. Getting the timing right is genuinely tricky.
Likely components: Player · Sound · TableArrangement · Clock · Lists
F — Accessibility Tool
Real userBuild something for a person who finds a phone difficult: very large buttons that speak what they do, a communication board for someone who is non-verbal, a magnifier, a high-contrast timer, a medication reminder.
The interesting problem: you must design for someone who is not you. Interview a real person about what they need — that interview goes in your folio and it will change your design.
Likely components: TextToSpeech · SpeechRecognizer · large Buttons · Notifier · Clock
G — Open: solve a real problem for a real person
Open-endedFind someone at school, at home or in a club you belong to who does something tedious, and build them a tool. A tuck-shop order tally. A coach's substitution timer. A scorer for a game your family plays. A stocktake app for the drama department's props.
To take this option you must submit a one-page proposal naming the person, the problem, and how you will know if it worked. Get it approved before you write a single block.
Why it is worth it: you get a real user who will tell you the truth, which makes the evaluation section write itself.
Components: whatever the problem needs — that is the point
H — Open: connect to hardware
Open-ended · ambitiousUse BluetoothClient to talk to a micro:bit or an Arduino. Your phone becomes the screen and brain; the board becomes the sensors and lights. Read a temperature and graph it. Drive a robot with tilt control. Build a doorbell that texts you.
Also requires an approved proposal. Bluetooth pairing is fiddly and Android-only in App Inventor — you need an Android device and you need to plan for things not connecting.
Warning worth taking seriously: budget a full lesson just for getting the two devices talking to each other before you build anything on top.
Components: BluetoothClient · Clock · ListPicker for device selection · Chart
Extensions — how to reach Extending
Whichever option you choose, the top band asks for genuine independence. With six lessons, one of these done properly beats three done badly. Pick one, or invent your own of similar difficulty:
Technical
- Data survives closing the app (
TinyDB), including a sensible empty state - A procedure that takes parameters and returns a result
- Multiple screens that pass data between them (
open another screen with start value) - Pull live data off the internet with the
Webcomponent and read the JSON - Build a list display from data at runtime rather than hard-coding buttons
- Handle the failure cases: no input, no network, no permission, no data yet
Design and process
- User testing where the design visibly changed as a result — show the before and after
- An accessibility pass: contrast, touch-target size, and it still works with the phone's font size turned up
- A consistent visual identity — custom icon, one type scale, a deliberate palette
- A written comparison of two approaches you considered, and why you chose one
- Publish or distribute it: give the
.apkto a real user and report what happened
The most common mistake is picking the most ambitious project and finishing 40% of it. With six lessons that mistake is fatal, because there is no slack to recover in — and a lost lesson costs you a fortnight. Aim for something you can get working by the end of Lesson 4, so Lesson 5 is spent making it good rather than making it exist.
The whole unit, lesson by lesson
Six lessons of 100 minutes, three per fortnight. Because they are a fortnight apart in places, the "before next lesson" column is not optional — it is where a third of the work happens.
| Lesson | In the lesson | Ends with | Before next lesson |
|---|---|---|---|
| 1 | App era discussion (15 min) · accounts and Companion · guided build steps 1–5 · show your app to the people near you | A working app installed on your own phone | Show it to someone outside class. Note one thing you would change. |
| 2 | Guided build steps 6–12 · second .apk build with icon · checkpoint quiz | Oracle finished, exported, quiz submitted | Read the project options. Arrive at Lesson 3 with two ideas. |
| 3 | Pitch your two ideas to a partner (20 min) · choose one · two sketches · component list · algorithm · start building | Design folio handed up. G/H proposals approved | Build the core feature. Do not decorate anything yet. |
| 4 | Finish the core · mid-lesson: build an .apk, swap phones with a partner, 15 min of peer testing · act on what you learn | The main job of your app actually works | Your one extension. Test log to 3 entries. |
| 5 | User testing with two people · act on the feedback · polish · icon · final .apk · start the evaluation | Test log at 5 entries, everything working | Finish the evaluation. Export the .aia. Rehearse 60 seconds. |
| 6 | 60-second demos · submission | Submitted | — |
Stop adding features. Spend the lesson making what you already have work reliably, and do the extension only if there is time left. A finished small app with an honest evaluation sits comfortably in Consolidating. An unfinished ambitious one does not.
06Assessment rubric
Four criteria, three bands. Read this in Lesson 3, before you start building — the Extending column tells you exactly what to aim at, and with six lessons there is no time to discover it late.
1 — Investigating and designing
| Developing | Consolidating | Extending |
|---|---|---|
| Names an app idea. Sketches exist but are rough or incomplete. The intended user is vague or is "anyone". | States a clear problem and a specific user. Two usable sketches. Components listed and the algorithm described in pseudocode or a flowchart. | Problem is justified with evidence — an interview, observation or data. Design decisions are argued, alternatives are considered and rejected with reasons. Scope is deliberately limited and the trade-off is explained. |
2 — Programming and computational thinking
| Developing | Consolidating | Extending |
|---|---|---|
| App runs but is limited. Uses events and properties. Variables or lists may be missing or unused. Repeated blocks are copied rather than reused. Warnings remain in the workspace. | Meets all minimum requirements: variables, a list, a conditional and at least one working procedure. Logic is correct for expected input. Components are sensibly named and the workspace is clean. | Uses procedures with parameters and/or return values. Data structures chosen deliberately and justified. Handles unexpected input and failure states. Data persists where it should. Blocks are organised and commented so another person could take over the project. |
3 — Interface and user experience
| Developing | Consolidating | Extending |
|---|---|---|
| Default components, inconsistent spacing or colour. Some labels unclear. Works on the developer's device only. | Consistent layout, readable type, a deliberate colour choice. The user can tell what to do without being told. Custom icon and app name set. | A coherent visual identity carried across every screen. Accessible: strong contrast, generous touch targets, still usable with system font size increased. Empty states and errors are designed rather than left to chance. |
4 — Testing, evaluating and documenting
| Developing | Consolidating | Extending |
|---|---|---|
| A few tests recorded, mostly of things that worked. Evaluation is a description of the app rather than a judgement of it. | Five or more tests including failures, with the fix recorded. Two users tested and their feedback reported. Evaluation judges the app against the original problem. | Tests target edge cases deliberately, not just the happy path. User testing led to a visible design change, and the before and after are both shown. Evaluation is honest about what did not work, quantifies success where possible, and identifies specific next steps. |
Submitting only the .apk. You will have built several by now, and none of them can be opened as blocks. Export the .aia as well or criterion 2 cannot be marked.
A test log written the night before. It reads exactly like one, every time. Two minutes at the end of each lesson and it is done.
07Checkpoint
Eight questions to confirm the guided build stuck, then your project proposal. When you are finished, click Create my assessment at the bottom — it produces a document to submit.
Q1What does an event block such as when AskButton.Click do actually do?
Q2You drag a TextToSpeech component onto the Viewer and it does not appear on the phone. What has happened?
Q3Your list answers has eight items. Which index gets you the first one?
Q4Which file do you submit so a teacher can open and mark your blocks?
Q5Why did we move the oracle's instructions into a procedure before adding shake-to-ask?
Q6A student puts call TextToSpeech1.Speak message AnswerLabel.Text above set AnswerLabel.Text to…. What happens?
Q7Your project partner has an iPhone. What can they do?
Q8Three research firms report 2025 global app downloads as 137.8 billion, 142 billion and 149 billion. What is the sensible conclusion?
Your project proposal
This downloads a document containing your quiz results and your proposal. Upload it to the class page. Nothing is sent anywhere automatically — if you close this page without exporting, your answers are gone.
08Teacher notes
Staff access
Sequencing, known failure points, differentiation and moderation guidance.
Lesson sequence (6 × 100 min, three per fortnight)
- L1: App era discussion, 15 min — the section is set as prior reading. Accounts, Companion, guided steps 1–5, ending with every Android student holding an installed app. Last 10 minutes: they show each other.
- L2: Guided steps 6–12, rebuild with icon, checkpoint quiz. Steps 1–7 alone are a viable stopping point for anyone who has lost time.
- L3: Paired pitch of two ideas each, then choose. Two sketches, algorithm, folio handed up in the lesson. G/H proposals approved or refused on the spot. Building starts in the last half hour.
- L4–5: Build. Five-minute stand-up at the start of each. L4 has a compulsory mid-lesson build-and-swap; L5 is testing, polish and evaluation.
- L6: 60-second demos and submission.
Shaping 100 minutes
- Nobody sustains a hundred minutes of block-dragging. The unit is written in roughly 40-minute chunks with something physical between them — install, swap phones, show a partner, stand up and report.
- The
.apkbuild is a natural break: it takes a minute or two of server time, which is exactly long enough for a stretch and a conversation. Use it deliberately rather than letting them watch a progress bar. - The paired pitch in L3 is the highest-value twenty minutes in the unit. Students talk themselves out of unworkable ideas far more efficiently than you can talk them out of one.
Build-server logistics — now that everyone builds
- Thirty simultaneous builds will queue. Stagger by row, or make the build the thing they do on reaching a milestone rather than all at once at the bell.
- QR codes expire in about two hours. A code generated early in a 100-minute lesson may be dead by the end of it — rebuild rather than debugging a phantom install failure.
- Android's "unknown sources" warning trips students up once each. Walk the whole class through it in L1 and it never resurfaces.
- Managed or school-owned Android devices may block sideloading outright. Check one before L1 — if it is blocked, those students are on the Companion like the iPhone cohort and the homework model changes for them.
- Fortnightly gaps mean stale builds: the copy on a student's phone is frozen at whatever they last compiled. Make "rebuild before you test" an explicit habit or you will spend L5 diagnosing bugs that were fixed a fortnight ago.
What was cut from the seven-week version, and why
- The multiple-screen requirement. Passing data between screens costs a lesson and teaches little that one screen does not. It is now an extension.
- The second user-testing round. One round with a documented change is enough evidence for the Extending band.
- Design folio scope — three sketches to two, and the "what I chose not to build" section dropped. Folio is now one page and is done in class, not at home.
- Test log eight entries to five; extensions two to one; evaluation 500 words to 300; demo 90 seconds to 60.
- The App Era section moved to prior reading. This is the one that will slip — set it a fortnight ahead and check it, or you will lose time you cannot spare.
- Not cut: the guided build, which is the load-bearing part. Shortening it produces students who cannot start their own project, and you get the time back in support later. It gained a step rather than losing one.
What the fortnightly timetable changes
- Up to fourteen days between lessons means forgetting is the main enemy, not time. The first ten minutes of L4 and L5 should be re-orientation, not new content.
- Students building their own
.apks is what makes the gap productive: an app on the phone gets opened and fiddled with; a project on a server does not. - Set the between-lesson task explicitly and check it at the door. "Keep working on it" produces nothing across a fortnight.
- An absence now costs a fortnight of momentum. The guided build page is written to be followed unsupervised — point absentees at it rather than reteaching.
Where this version breaks
- A lost lesson — assembly, excursion, sickness — costs a fortnight and has nowhere to go. Decide in advance that the extension in L5 is what you sacrifice, and tell students that at the start.
- Option choice at L3 is the highest-risk moment. Have A, B, E and F pre-approved so students can start building the same lesson; only G and H need a conversation.
- Require the final
.apkto be built in L5, not L6. Demos should start on time, not wait on a compile queue.
Known failure points, in order of frequency
- Companion will not connect — phone on mobile data, laptop on school Wi-Fi. Have the emulator installed on a few machines as a fallback before the unit starts.
- Personal Google accounts — work becomes unretrievable when they forget the password. Enforce school accounts in lesson one.
- Accelerometer fires repeatedly — step 11's reveal covers debouncing; worth demonstrating to the whole class.
- Lists indexed from 0 — students with prior Python exposure trip on this constantly.
- Build server queue — see the logistics section above; this becomes a routine issue once every student is building rather than just you.
- iPhone students demoralised at not getting an installable file — and it stings more now that classmates walk out with apps on their phones. Frame it as a platform-politics lesson in L1, set screen recording as the equivalent deliverable from the start, and make sure they know the Companion works fine on home Wi-Fi so they are not locked out of homework.
Differentiation
- Needs more support: Options A or E, and provide a half-built .aia with the Designer complete so they only work in Blocks. Build their first
.apkalongside them in L1 — if they leave without one, they will do nothing before L2. - Ready for more: Options G or H, or require the Web component and live JSON. The parameters-and-return-value extension is the single best stretch for strong students.
- Absent or joining late: steps 1–7 give a working, demonstrable app on their own, and step 5 gets it onto their phone; the unit degrades gracefully.
Privacy and safety worth flagging to students
- Option D uses location. Nothing leaves the device with a plain LocationSensor, but say so explicitly — and if anyone adds a Web component, that changes.
- Option F requires interviewing a real person: consent, and no recording without it.
- Sound recordings and photographs of other students need permission. Distributing an .apk containing someone's face or voice is worth a conversation.
Moderation
- Mark criterion 2 from the .aia with the project open, not from screenshots — naming and structure are invisible otherwise.
- The fastest reliable discriminator between Consolidating and Extending is whether procedures take parameters, and whether failure states are handled.
- Watch for whole-class drift toward Option A. Cap it at about a third of the cohort if you want a spread of demos worth watching.
Curriculum mapping
- Maps to the Years 9–10 Digital Technologies processes and production skills: defining problems with user requirements, designing algorithms, implementing in a visual programming environment, iterative testing and evaluation against criteria.
- The App Era section covers the knowledge and understanding strand around the impact of digital systems on society, and doubles as data-interpretation practice.
- Check the exact content descriptor codes against the current scope and sequence before publishing to families — they change between curriculum versions.
This gate is a speed bump, not security — the notes are in the page source. Change the password in the source before distributing, and do not put anything genuinely confidential here.