App Store Submission for Korean SMBs: Apple Developer, DUNS, and the Guideline 4.3 Trap

Most "Korean restaurant gets an app" stories die at the App Store submission step. Not because the app is bad — because nobody told the owner about DUNS numbers, App Privacy labels, or the famous Guideline 4.3 that auto-rejects template apps. Here is the actual sequence for a Korean SMB owner shipping their first app to iOS and Android in 2026.

Step 1: Apple Developer enrollment ($99/year)

You enroll either as an Individual (in your name) or as an Organization (in your LLC or Corp name). Individual is faster — usually 24-48 hours — but the app shows your personal name as the publisher. Organization shows your business name and is what most Korean restaurants want, but requires a DUNS number, which adds 1-3 weeks of processing time.

A DUNS number is a free identifier from Dun & Bradstreet. You apply at developer.apple.com/enroll, and Apple verifies your business via D&B. The catch: if your LLC was formed in the last 6 months, D&B may not have it on file, and you have to manually request DUNS at dnb.com first. Plan for 3 weeks total if you go the Organization route. If you need to ship faster, start as Individual and migrate to Organization later.

Step 2: Google Play Console ($25 one-time)

Google Play is much simpler than Apple. $25 one-time fee, identity verification, and you are in within 1-2 days. The catch on Google: as of 2024, new developer accounts must complete a "closed testing" phase with at least 12 testers for 14 days before publishing publicly. Plan for that two-week buffer.

Step 3: App Privacy nutrition labels (this trips up everyone)

Apple requires you to declare what data your app collects, how it is used, and who it is shared with. The form has 14 categories ranging from "Contact Info" to "Sensitive Info" to "Diagnostics." Get this wrong and your app gets rejected. The honest answer for most Korean restaurant apps: you collect Email Address (for the order), Phone Number (for delivery), Coarse Location (for delivery zones), Purchase History (for reordering), and Device ID (for push notifications). Declare each one truthfully.

Step 4: Avoiding Guideline 4.3 — the template trap

Apple Guideline 4.3 says: "Apps that are simply a website packaged as an app, or are essentially the same as other apps in the App Store, will be rejected." This kills almost every cheap app-builder service ($500-2000 promises) because they generate hundreds of near-identical restaurant apps from the same template. The reviewer sees the pattern and rejects.

How to pass: your app must have at least one feature that exists nowhere else. For a Korean restaurant, that usually means bilingual (Korean + English) menu with Korean cultural context (banchan explanations, allergen notes, dish photos taken in your kitchen, not stock images). Custom graphics. A native iOS or Android UI shell, not a webview. We have shipped over a dozen restaurant apps and have not had a Guideline 4.3 rejection — because none of them are templates.

Step 5: Screenshots, app preview videos, and the iPad trap

You need 6.7-inch and 6.5-inch iPhone screenshots (3-10 each), and as of iOS 17, iPad screenshots are required if your app supports iPad. The trap: many restaurant apps technically launch on iPad even when not designed for it, and Apple rejects them for "poor iPad layout." Either explicitly disable iPad support in the build settings, or design for both. Pick one before submission.

Step 6: App Review notes — the bilingual trick

In the App Review notes field, write a 3-4 sentence explanation of what your app does, in plain English. For Korean restaurants, mention: "This is a Korean-American restaurant ordering app. The Korean-language UI may appear during review — please use the language toggle in the top-right corner to switch to English." This single sentence prevents about 30% of "we cannot review your app" rejections.

Step 7: After approval — the launch checklist