I published my first fully vibe coded application: Toddler Photo Lock. It’s extremely simple: Select a photo, start Guided Access, and hand your phone to your toddler. Your kid can then view the photo without you having to worry about them doing something else on your phone.
Why I wanted this app
My wife and I try to minimize our use of screens around our daughter so as to not get her overly interested in them. The American Academy of Pediatrics recommends zero screen time for children under 18 months, except for FaceTime with family. But when our daughter was 10 months old, she started reaching for our phones and getting very frustrated when we didn’t let her have them.
Even if children only see phones used for photos and FaceTime, they are naturally still going to be very curious about them (this is true for all objects they see their parents using). We felt that fighting a battle and saying “NO!” every time she saw a phone would just draw more attention to it and make it more enticing. We were looking for a solution that would allow her to hold the phone for short periods of time without getting sucked into all the swiping and interactivity that exists even on the default lock screen. With nothing else to do, we thought she would eventually get bored.
Apple’s built-in Guided Access feature along with the default Photos app got us almost all the way there. But when using Guided Access in Photos, she can still swipe between media and cause havoc with buttons. We tried but failed to find any app in the app store for this use case, so I decided to vibe code it.
A perfect match for vibe coding
A few things make this app a great candidate for full vibe coding:
- It’s fully local-only by design. This means no server, no real security, and no worry about load. In other words, I don’t need to make important architectural decisions that have long term impacts.
- Its scope is extremely limited. Grant access to some photos, pick one, and have the screen lock. That covers the main features! With an app this simple you don’t have to worry about code reuse, following consistent patterns across the application, or any of the concerns you have with large codebases.
- (personal reason) It’s an iOS-native application. I’m a web developer and know close to nothing about native mobile application development. I could have made a web app and added it to my home screen via “Add to Home Screen” but then 1. there’s a lot of overhead with a web browser and 2. if you’re going to vibe code something why not vibe code the more correct thing?
Fully vibed still requires effort
My daughter was 14 months old when I finally got the app published in the App Store. Building the initial app that worked on my phone only took a day. Getting the app published (with my limited time to work on the app) took 3 months.
I worked with Gemini to estimate the feasibilty of the app and create a big picture plan. I then worked with Augment Code with GPT 5.4 to flesh out the plan and made some manual edits.
Then I had Augment go at it. It got the job done! Naturally, there were ambiguous or missing things in the spec and I had to iterate a bit. This is where the majority of the actual development time was spent, adding little features that I didn’t think of or didn’t know were required to publish to the app store (like having an in-app privacy page).
I then spent time setting up the project on GitHub with an MIT license (because I think anything modest and fully vibe coded should be open source). I created a FAQ and GitHub issue templates, because I’ve found both of them to be incredibly useful with Just Read. As a web developer, I also felt the need to create a tiny, bare-boned marketing site.
App Store review is the worst
To get the app in the App Store I had to do a ton of small tasks like adding a description, adding preview photos, creating an icon, and sizing everything in the way that they want.
In order to post to the App Store, you have to join the Apple Developer Program. And it costs nearly $110 annually!?! On the web all you need is a ~$10 domain (if that!) and a static file host. Thanks vendor lock in and monopolization…
The App Store has many checklists of requirements / tasks, one after another. No checklist is comprehensive. Some todo items in App Store Connect didn’t show the first time around. Documentation for uploading a build was hard to find and what I found had broken links and no clear steps. I resorted to using Google Search’s AI answer which was more useful.
My first submission was rejected because I needed to have a parental lock on any outbound links (like the FAQ) and I needed to use Apple’s payment system in-app instead of a link to Buy Me A Coffee.
When I tried to set up in-app purchasing I got a “Missing metadata” warning with no indication of what’s missing. I also was told images I tried to upload were of the wrong dimension but it didn’t specify what the dimension they should be. It turns out my iPhone 11 is too old so the size of the screenshot I took is smaller than the current gen iPhone and that prevented me from using being able to use the screenshot directly.
Additionally, for setting up in-app purchases, having a .storekit file is apparently not sufficient. I had to select the .storekit file I made, select it in XCode, then add all of the values a second time through the XCode app.
When I tried to resubmit to the app store I got a “You do not have required contracts to perform an operation” error but it didn’t say what was missing. It turns out I had to go to https://developer.apple.com/account and accept an updated agreement.
I failed the next submission because I didn’t sign the paid app agreement but it didn’t tell me I needed to sign that until they rejected my submission.
The next submission was rejected for 3 reasons, none of which were made clear. I asked for clarification and they said 2 were not issues and gave me additional info about the third was, which I then fixed.
This confusing back and worth happened several more times. If Steve Jobs were watching I think he would have fired people who were responsible for such a terrible experience.
Time taken
All in all, the app itself took me around 3 hours of planning and “development” time— mostly multi tasking, checking in, and giving new prompts. I spent another 6+ hours setting up the GitHub project, creating a website, and getting the app in the App store (not counting the 3 months in App Store back-and-forth purgatory…).
Without LLMs, developing this app would have taken a lot longer (realistically I just wouldn’t have ever made the app).
In general I don’t recommend using AI in this way
Though I did look at a small portion of the code to update strings and such (e.g. prompting an LLM to change “Choose More” to “Choose more” still feels wrong to me), I don’t know the technical details of how this app works. That’s interesting to me.
This app was a great fit for coding in this way. Most apps are not.
In my day job, I use agents to speed up the planning and coding processes with a LOT more technical-level implementation guiding. In large, complicated, convoluted codebases there’s also more areas where this generation of agents gets stuck / gets it wrong. So I don’t expect to be fully vibe coding in my day job, at least in the near term.
So did the app help?
If you read to the end, you might be wondering if the app has been successful for our family. We think so!
Our daughter still gets excited when she sees a phone, and often wants to hold it. When she does, she looks at the locked picture and talks to it as if she’s on FaceTime. She also puts the phone up to her ear and says “Hello?!” and babbles a fake conversation. It has been one of her first instances of “pretend play” and the type of phone usage we want her to be excited about when she is older. She does eventually get bored of it on her own within 5 minutes, which has not happened when she holds a phone on the lock screen (usually she ends up taking an infinite vlog of herself).
Toddler Photo Lock gives us the option to treat the phone as neutral instead of forbidden. If she reaches for one of our phones, we can choose whether it is a good time to let her hold it or not, just like we would anything else. We know that phone usage will continue to be a challenge as she grows older but we are happy to have a solution that is working for us right now!