Let\u2019s make something ridiculous. Then make it work better.<\/p>\n\n\n
For this AI Playground, you\u2019ll use AI to help build a native iOS app for iPhone from a very questionable idea. You\u2019ll try an iPhone hardware capability you haven\u2019t 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.<\/p>\n\n\n
You may use AI directly in Xcode OR the Codex app<\/strong>. Choose whichever works best for you. If you want help getting started with Codex, check out the optional Codex lesson at nmi.cool\/ai<\/a>.<\/p>\n\n\n 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…<\/p>\n\n\n To determine our app direction, we will turn to the Mad Lib! Fill in the blanks to proceed.<\/p>\n\n\n Note:<\/strong> The examples are here to get your brain moving. Try to come up with your own answers instead of borrowing mine. And don\u2019t spend forever making the pieces fit\u2014the weird combinations are the point.<\/p>\n\n\n Now put them together. In each prompt below, replace the bold bracketed text<\/strong> with your own words and remove the brackets.<\/p>\n\n\n Build a native iOS app for iPhone called [app name]<\/strong> for [adjective]<\/strong> [type of people]<\/strong> who need to [everyday task]<\/strong> while [unusual situation]<\/strong>.<\/p>\n<\/div><\/div>\n\n\n Now add some personality.<\/strong> Read your completed premise. Now that you know what your app does, pick something the user might do in it\u2014finish a task, make a choice, save something, or reach a goal. How should the app dramatically respond?<\/p>\n\n\n 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:<\/p>\n\n\n When the user [does something in the app]<\/strong>, the app [responds in an unnecessarily dramatic way]<\/strong>.<\/p>\n<\/div><\/div>\n\n\n For example: \u201cWhen the user completes a task, the app awards them an absurd promotion.\u201d Hang on to your premise and personality sentence. We\u2019re about to add one more ingredient.<\/p>\n\n\n Choose at least one iPhone hardware capability you haven\u2019t used in an app before<\/strong>. Give it a meaningful job in your app. Some possibilities:<\/p>\n\n\n Pick something your available device supports. Try hardware behavior on a physical iPhone when possible; a simulator may not reproduce it. If you don\u2019t 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 \u201cno\u201d gracefully.<\/p>\n\n\n Now tack this sentence onto your Mad Lib:<\/strong><\/p>\n\n\n The app must use [unfamiliar iPhone hardware capability]<\/strong> to [describe what it will let the user do or experience]<\/strong>.<\/p>\n<\/div><\/div>\n\n\n Checkpoint:<\/strong> 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.<\/p>\n\n\n Here\u2019s what the completed Mad Lib could look like. Yours should head in its own wonderfully questionable direction.<\/p>\n\n\n Build a native iOS app for iPhone called The Department of Minor Accomplishments<\/strong> for overwhelmed college students<\/strong> who need to finish everyday tasks<\/strong> while serving as the sole employee of an imaginary government agency<\/strong>.<\/p>\n\n\n When the user completes a task<\/strong>, the app awards them an absurd promotion, such as \u201cDeputy Commissioner of Finally Replying to That Email.\u201d<\/strong><\/p>\n\n\n The app must use haptics<\/strong> to deliver a celebratory feedback pattern when users complete a task<\/strong>.<\/p>\n<\/div><\/div>\n\n\n 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\u20132 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\u2019t understand.<\/p>\n\n\n 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\u2019ll change, and any permissions or device limitations. Let me review the plan, then help me implement and test it in stages.<\/p>\n\n\n [Insert all three sentences: premise, dramatic response, and hardware]<\/strong><\/p>\n<\/div><\/div>\n\n\n When something breaks, give your assistant something specific to work with:<\/p>\n\n\n I expected [behavior]<\/strong>, but [actual result]<\/strong> happened. Here is the error and relevant code: [details]<\/strong>. Help me understand the cause, suggest a focused fix, and explain how to check it.<\/p>\n<\/div><\/div>\n\n\n Checkpoint:<\/strong> V1 runs, its main features work together, the dramatic response happens in the app, and the hardware capability does something meaningful.<\/p>\n\n\n Preserve your ridiculous V1 before making changes.<\/strong> Keep its working source in a clearly named project copy or a Git commit\/tag you can return to. Include V1\u2019s README.md before preserving that version. Then continue in your V2 copy or working version so V1 remains available.<\/p>\n\n\n Now choose one existing feature, interaction, or function<\/strong> and pivot it to solve a real problem for a specific audience. Continue developing the same app, reusing what you\u2019ve already built. One well-chosen change can give the app a compelling reason to exist. The silly name and personality can stay.<\/p>\n\n\n 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.<\/p>\n\n\n Here is what my app currently does: [features]<\/strong>. It uses [hardware capability and its role]<\/strong>. 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\u2019ll choose a direction before we make changes.<\/p>\n<\/div><\/div>\n\n\n 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\u2019t do that.<\/p>\n\n\n Checkpoint:<\/strong> \u201cI\u2019m adapting _____ so _____ can _____. I\u2019m keeping _____ and changing _____.\u201d Run the updated feature and see whether it delivers on that promise.<\/p>\n\n\n After your pivot is working, make 2\u20133 meaningful manual code edits in V2<\/strong> 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.<\/p>\n\n\n 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.<\/p>\n\n\n Explain how [this part of the code]<\/strong> works and point me to where I could improve [behavior or design]<\/strong>. Don\u2019t edit it for me. I want to make the change myself.<\/p>\n<\/div><\/div>\n\n\n 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\u20133 manual edits so you can explain them in V2\u2019s README.md.<\/p>\n\n\n Checkpoint:<\/strong> Your useful feature works, your 2\u20133 manual edits are in the final V2 build, and you can explain what each edit does.<\/p>\n\n\n Submit both app versions<\/strong>, clearly labeled V1 and V2, each with its own README.md<\/strong> file. A Markdown file is a plain-text document with simple headings, lists, and code snippets. Keep the writing brief and specific.<\/p>\n\n\n Include the V1 app source and a README.md containing:<\/p>\n\n\n Include the final V2 app source and a README.md containing:<\/p>\n\n\n Final checkpoint:<\/strong> Both versions are preserved, both README.md files are included, and V2 has a useful feature plus your own meaningful code changes.<\/p>\n\n\n Have fun with V1. Be thoughtful with V2. See how far one ridiculous idea can take you.<\/p>\n","protected":false},"excerpt":{"rendered":" Let\u2019s make something ridiculous. Then make it work better. For this AI Playground, you\u2019ll use AI to help build a native iOS app for iPhone from a very questionable idea. You\u2019ll try an iPhone hardware capability you haven\u2019t used before, turn one feature into something compelling, and get into the code yourself. Think of this … Continue reading From Ridiculous to Remarkable: An AI-Powered iOS Playground<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-4431","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/nmi.cool\/appdev\/wp-json\/wp\/v2\/pages\/4431","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nmi.cool\/appdev\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/nmi.cool\/appdev\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/nmi.cool\/appdev\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nmi.cool\/appdev\/wp-json\/wp\/v2\/comments?post=4431"}],"version-history":[{"count":11,"href":"https:\/\/nmi.cool\/appdev\/wp-json\/wp\/v2\/pages\/4431\/revisions"}],"predecessor-version":[{"id":4442,"href":"https:\/\/nmi.cool\/appdev\/wp-json\/wp\/v2\/pages\/4431\/revisions\/4442"}],"wp:attachment":[{"href":"https:\/\/nmi.cool\/appdev\/wp-json\/wp\/v2\/media?parent=4431"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Let the Mad Lib decide your fate<\/h2>\n\n\n
\n
3. Give your iPhone something new to do<\/h2>\n\n\n
\n
One ridiculous possibility<\/h2>\n\n\n
4. Build the ridiculous version<\/h2>\n\n\n
5. Save V1. Find the useful feature.<\/h2>\n\n\n
6. Make V2 your own<\/h2>\n\n\n
What to turn in<\/h2>\n\n\n
V1: The ridiculous original<\/h2>\n\n\n
\n
V2: The useful evolution<\/h2>\n\n\n
\n