Let’s make something ridiculous. Then make it work better.
For this AI Playground, you’ll use AI to help build a native iOS app for iPhone from a very questionable idea. You’ll try an iPhone hardware capability you haven’t used before, turn one feature into something compelling, and get into the code yourself. Think of this as one app with two versions: the ridiculous original and its surprisingly useful evolution.
1. Choose your AI sidekick
You may use AI directly in Xcode OR the Codex app. Choose whichever works best for you. If you want help getting started with Codex, check out the optional Codex lesson at nmi.cool/ai.
Create a new iOS project in Xcode and get the starter app running. Aim for a cohesive, working app with a thoughtful interface and features that make the idea fun to use. Give yourself room to experiment while keeping the scope manageable for this playground. “Cool, but what are we building?!” I’m glad you asked…
2. Let the Mad Lib decide your fate
To determine our app direction, we will turn to the Mad Lib! Fill in the blanks to proceed.
Note: The examples are here to get your brain moving. Try to come up with your own answers instead of borrowing mine. And don’t spend forever making the pieces fit—the weird combinations are the point.
- An adjective: __________ (overcaffeinated, suspiciously cheerful, wildly competitive)
- A type of person, profession, or hobby group: __________ (substitute teachers, amateur birdwatchers, weekend bakers)
- An everyday task: __________ (choose lunch, organize a to-do list, remember what to pack)
- An unusual situation: __________ (waiting for a delayed flight, hosting a family reunion, hiding from a surprise party)
- An over-the-top app name: __________ (Lunchpocalypse, Captain Checklist, Operation Sockstorm)
Now put them together. In each prompt below, replace the bold bracketed text with your own words and remove the brackets.
Build a native iOS app for iPhone called [app name] for [adjective] [type of people] who need to [everyday task] while [unusual situation].
Now add some personality. Read your completed premise. Now that you know what your app does, pick something the user might do in it—finish a task, make a choice, save something, or reach a goal. How should the app dramatically respond?
Maybe it displays an official proclamation, awards a ridiculous title, or presents a theatrical objection. Choose a response that actually happens in the app, then add this sentence to your premise:
When the user [does something in the app], the app [responds in an unnecessarily dramatic way].
For example: “When the user completes a task, the app awards them an absurd promotion.” Hang on to your premise and personality sentence. We’re about to add one more ingredient.
3. Give your iPhone something new to do
Choose at least one iPhone hardware capability you haven’t used in an app before. Give it a meaningful job in your app. Some possibilities:
- Motion: use tilt, movement, or orientation to control something.
- Camera: capture a photo that becomes part of the app’s workflow.
- Microphone: respond to sound or record a short audio input.
- Location: make an interaction depend on where the user is.
- Haptics: use tactile feedback to communicate an action, state, or result.
Pick something your available device supports. Try hardware behavior on a physical iPhone when possible; a simulator may not reproduce it. If you don’t have access to a device, check in before committing to your idea. For features that request permission, explain why the app needs access and handle a “no” gracefully.
Now tack this sentence onto your Mad Lib:
The app must use [unfamiliar iPhone hardware capability] to [describe what it will let the user do or experience].
Checkpoint: You have a complete three-sentence app directive: the premise, the dramatic response, and the hardware sentence. You can explain how the unfamiliar hardware capability fits your idea.
One ridiculous possibility
Here’s what the completed Mad Lib could look like. Yours should head in its own wonderfully questionable direction.
Build a native iOS app for iPhone called The Department of Minor Accomplishments for overwhelmed college students who need to finish everyday tasks while serving as the sole employee of an imaginary government agency.
When the user completes a task, the app awards them an absurd promotion, such as “Deputy Commissioner of Finally Replying to That Email.”
The app must use haptics to deliver a celebratory feedback pattern when users complete a task.
4. Build the ridiculous version
Give your AI assistant the complete three-sentence directive. Ask for a plan, choose the features worth building, and work through them in stages. Save 1–2 useful prompts or short exchanges from each version for its README.md. Aim for an app that feels intentional: a clear flow, useful feedback, and enough functionality to explore the premise. Run it as you go and ask about code you don’t understand.
Help me build this native iOS app for iPhone in SwiftUI with the prompt below. Propose a cohesive experience with thoughtful design and a manageable set of features that bring the idea to life. Explain the plan, files we’ll change, and any permissions or device limitations. Let me review the plan, then help me implement and test it in stages.
[Insert all three sentences: premise, dramatic response, and hardware]
When something breaks, give your assistant something specific to work with:
I expected [behavior], but [actual result] happened. Here is the error and relevant code: [details]. Help me understand the cause, suggest a focused fix, and explain how to check it.
Checkpoint: V1 runs, its main features work together, the dramatic response happens in the app, and the hardware capability does something meaningful.
5. Save V1. Find the useful feature.
Preserve your ridiculous V1 before making changes. Keep its working source in a clearly named project copy or a Git commit/tag you can return to. Include V1’s README.md before preserving that version. Then continue in your V2 copy or working version so V1 remains available.
Now choose one existing feature, interaction, or function and pivot it to solve a real problem for a specific audience. Continue developing the same app, reusing what you’ve already built. One well-chosen change can give the app a compelling reason to exist. The silly name and personality can stay.
For example, The Department of Minor Accomplishments already celebrates completed tasks. Adapt its task feature so students can break an overwhelming assignment into manageable steps, with a promotion and celebratory haptics for each step completed. The same app now helps students make progress on work they might otherwise put off. The imaginary government agency can stay.
Here is what my app currently does: [features]. It uses [hardware capability and its role]. Help me identify three options for adapting one existing feature to meet a real need while keeping the hardware meaningfully involved. For each, explain who benefits, what changes, and what code or interface we can reuse. Keep this within the current project. I’ll choose a direction before we make changes.
Choose a direction and implement it in V2. Keep the hardware capability meaningfully involved. Your change should improve what someone can accomplish; a new name or color scheme alone won’t do that.
Checkpoint: “I’m adapting _____ so _____ can _____. I’m keeping _____ and changing _____.” Run the updated feature and see whether it delivers on that promise.
6. Make V2 your own
After your pivot is working, make 2–3 meaningful manual code edits in V2 to improve its design or functionality. Personally type and adjust these changes in the source code. AI can explain the code or help you find the right place, but accepting its edits or pasting an entire generated replacement does not count.
You have plenty of flexibility. Improve the layout or readability, adjust interaction logic, tune a motion threshold, add a useful validation rule, or make feedback clearer. Choose changes you can explain and that make a noticeable difference to the experience.
Explain how [this part of the code] works and point me to where I could improve [behavior or design]. Don’t edit it for me. I want to make the change myself.
Run the app after each change. Check the updated feature from start to finish, including an awkward case such as missing input or denied permission. Keep before-and-after code snippets and the file names for your 2–3 manual edits so you can explain them in V2’s README.md.
Checkpoint: Your useful feature works, your 2–3 manual edits are in the final V2 build, and you can explain what each edit does.
What to turn in
Submit both app versions, clearly labeled V1 and V2, each with its own README.md file. A Markdown file is a plain-text document with simple headings, lists, and code snippets. Keep the writing brief and specific.
V1: The ridiculous original
Include the V1 app source and a README.md containing:
- The idea: your complete three-sentence directive (premise, dramatic response, and hardware) and a brief description of what V1 does.
- The hardware: what capability you chose, why it was new to you, and how the app uses it.
- Your AI collaboration: which tool(s) you used and 1–2 prompts or short exchanges that helped shape V1.
- How to run it: any setup steps or device requirements someone needs to use this version.
V2: The useful evolution
Include the final V2 app source and a README.md containing:
- The pivot: the one feature you adapted, who it helps, the problem it solves, and what you reused from V1. Explain why someone would want to use it and how the hardware remains involved.
- Your 2–3 manual edits: for each, identify the file, include a before-and-after code snippet, and explain what you changed and how it improves the app.
- Your AI collaboration and reflection: name the tool(s) you used for V2 and include 1–2 prompts or short exchanges from V2. Briefly explain what AI helped with, something you corrected or rethought, and something you now understand better.
- How to run it: any setup steps or device requirements for the final version.
Final checkpoint: Both versions are preserved, both README.md files are included, and V2 has a useful feature plus your own meaningful code changes.
Have fun with V1. Be thoughtful with V2. See how far one ridiculous idea can take you.