WakeWin is finally on the App Store. Here's what App Review made me cut.
Disclosure up front: WakeWin is mine. I'm building it alongside LeadGrid and Nalurio (some of you tried to talk me out of that back in July).
It went live yesterday. It's a free iOS alarm you can't turn off from bed. When it rings, the app names an everyday object, like the sink or the kettle. You walk over and photograph it, an AI check confirms it, then you do a short set of puzzles. Getting up earns tickets, and on Premium they go into a monthly draw.
Getting here took a lot of rejections. Three of them changed the product:
Internet radio, Guideline 5.2.3. You could wake up to a live station. Apple wanted third-party streaming rights I didn't have. I appealed and the App Review Board upheld it. Radio is now switched off on iOS in code, not with a remote flag, because a feature you can turn back on remotely counts as a hidden feature under 2.3.1.
What replaced it is better. There are 11 licensed instrumental tracks bundled in the app, each with its own licence proof pack, all at the same loudness, plus a "random song" mode that never plays the same track two mornings in a row. It's free, it works offline, and nobody can pull the rights out from under me.
Crash on launch on iOS 27, 2.1(a), last week. Xcode Cloud had quietly moved to the iOS 27 SDK, and iOS 27 won't launch an app built with that SDK unless it uses the UIScene life cycle. iOS 26 only logs a warning, so it ran fine on our phones. The fix was bumping Capacitor to 8.5.2 and adding a SceneDelegate. If your CI builds with "latest Xcode", check this before your next submission.
I also made the photo check free for everyone. It's the core of the app.
If you're on iOS 26, I'd love blunt feedback on the first run: https://apps.apple.com/app/wakewin/id6762138045
What's the worst rejection you've had, and did it make your product better or just smaller?
congrats
Congrats on getting through review. The bundled offline tracks are a smart replacement for the radio.
One thing I'd want to know as a user: what happens at 6am when the photo check can't give an answer? Say it rejects a correct photo, or there's no signal, or the service is down. An alarm you can't turn off is great until it won't stop for a reason that isn't your fault.
Is there an escape hatch after a few failed tries, and does the check work offline?
Fair worry. It was the first thing I had to get right. There are three exits:
The check needs a connection because it's a server-side AI call, so offline you land in the second case. The alarm itself doesn't need the network. iOS fires it through AlarmKit.
Congrats!
The iOS 27 SDK crash is the one I'd frame as the real lesson: building CI with "latest Xcode" means your toolchain silently upgrades between submissions, so pin the version and let the bump be a deliberate commit you test.
Agreed, that's the one I'd pass on. What stung is that none of my changes caused it. The toolchain moved underneath me, and iOS 26 only logged a warning, so every phone I tested on was fine. From now on an Xcode bump is its own change, and it goes through TestFlight on the newest iOS before anything else rides on it.
Congrats on getting through review! The photograph-an-object mechanic is clever. Curious whether the cuts ended up making the first-run experience simpler; review rejections often do that as a side effect.
A bit, yes, mostly by accident. Losing radio removed the one sound option that could fail at 6am because a stream didn't load. Now it's just the bundled tracks or random. And with the photo check free and on by default, a new user hits the real mechanic on their very first alarm instead of behind a paywall.
Congrats on getting it through. The CI/SDK mismatch is exactly the kind of failure a release matrix catches late; I’d pin the Xcode image and run a smoke test on the oldest supported OS plus the latest beta on every build instead of relying on “latest Xcode.” For the product change, comparing first-week activation (alarm completed, photo verified, second-morning return) before and after making the photo check free should help separate review-driven removal from a genuinely stronger core loop.
Oldest supported OS plus the latest beta is going on the checklist. That would have caught the iOS 27 crash a week earlier. Your three steps are close to what I plan to watch. The second morning is the one I actually trust, because anyone will try a weird alarm once.
Now that the app is live, what user behavior will tell you the App Review changes improved the product rather than simply making it easier to ship?
Second mornings. If people use it once and never set it again, the cuts only made it easier to ship. If they come back and leave the photo step on (it's on by default now, and you can turn it off), the core got stronger. It's been live two days, so it's too early to say.
That second-morning behavior should give you a much cleaner signal. If you’re open to it, what’s the best email to reach you on?
Honestly, the interesting part is that the rejections forced you to make some parts of the product stronger rather than just removing features. Making the photo check free especially makes sense since it’s the core interaction. I’d be curious to see what users actually do during their first few mornings, because that could reveal more than the initial feedback.
I can relate to this. I worked on a client project that got rejected around 10 times before we finally got it through App Review.
Some of the feedback actually made the app better, but there were also a few changes that felt like we were just trying to satisfy the review process.
Anyway Congrats on getting WakeWin through!
This is great work — reminds me of some of the calls I've had to make building Xstream4K. What would you do differently if you started over?