SMART LOTTO Dev Log #3 — A QR Code Feature That Blocked App Store Approval

The App Was Ready. Review Kept Failing.

Everything was built. I submitted to App Store review. It came back rejected.

The reason was baffling. The reviewer had decided my app was involved in actual gambling or lottery ticket transactions. It isn't. It's a statistics and number generator tool. No money changes hands. You can't buy a ticket through it.

The QR Scan Feature

At the time, the app included a feature where you could scan the QR code printed on a physical lottery ticket. This would open the official Donghaeng Lottery results page — showing whether the ticket had won.

A convenience feature. Much faster than navigating to the website manually.

But to the reviewer, it apparently read as: "this app scans lottery tickets and shows results" — which sounds more like a lottery service than a number generator.

The rejection was roughly:

This app appears to support actual lottery transactions. Apps facilitating lottery sales or gambling must meet additional requirements.

The Appeal Failed

I wrote a detailed appeal: no money changes hands, no purchases are facilitated, the QR scan simply opens a URL in an external browser. Clear, factual, documented.

Same rejection.

A couple more rounds produced the same result.

The Fix: Hide the Feature

The solution I landed on wasn't removing the feature — it was hiding it.

The QR scan code stayed in the codebase. I simply removed the button that navigated to that screen. The feature existed but was inaccessible.

The next submission passed review.

This is logically strange: if the feature's existence was the problem, leaving it in the code should still fail. But App Store review works by running the app and navigating through it. A feature with no accessible entry point is invisible to reviewers.

What This Taught Me About App Store Review

Review is a combination of automated checks and human judgment. Human judgment introduces inconsistency — the same app described differently can get different outcomes, and the same feature assessed by different reviewers can go either way.

After this experience, I started reading App Store guidelines before building any new feature — especially anything involving external links, payments, or content that could be misread as facilitating transactions.

The time spent on those rejection cycles was frustrating. But learning how the review process actually operates early in my development career turned out to be worthwhile.

Next: performance problems with statistics — and how Dictionary fixed them.