Guideline 4.2 Rejection: How to Fix "Minimum Functionality" Issues
If you're reading this, you probably just got the most frustrating rejection in the App Store playbook. Guideline 4.2 is Apple's way of saying "your app isn't app-y enough." It's subjective. It's vague. And it's rejected more apps than any guideline except 2.1.
I've been on both sides of this—rejected three times for 4.2 on my first serious app, then later shipping apps that were objectively simpler but somehow passed. The difference? Understanding what Apple's really looking for.
Apple's Actual Words
"Your app must include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store."
Translation: "We don't want your mobile website in an app shell. Convince us you needed to be an app."
Real Story: ProtonMail's 4.2 Rejection
In 2019, the encrypted email provider ProtonMail was rejected under 4.2 because reviewers thought the free tier didn't offer enough functionality. A major security-focused email service, rejected for being "too basic." After public backlash and some back-and-forth with Apple, it was approved. The lesson? 4.2 is subjective, and sometimes you need to push back.
What Gets You Rejected
Apple reviewers have a mental checklist. They're asking: "Why does this need to be an app instead of a bookmark?" If you can't answer that, you're getting 4.2'd.
The WKWebView Special
Your app is basically Safari with your logo. The reviewer opens it, sees a WebView loading your website, and hits reject before their coffee gets cold. Doesn't matter how good your website is.
The "One Button" App
You built a flashlight app. Or a tip calculator. Or an app that does exactly one thing that iOS already does. Unless it does that one thing exceptionally well with unique features, 4.2.
The Digital Brochure
Your client's restaurant wants an app. It shows the menu, hours, and a map. That's it. No ordering. No reservations. No loyalty program. Apple says: "just make a website."
The Template Farm
You used Appy Pie or a similar service to generate 50 apps for 50 local businesses. Apple's automated systems detect duplicate code structures. Mass rejection incoming.
The frustrating truth: 4.2 is wildly inconsistent. I've seen fart apps get approved while genuinely useful utilities get rejected. Different reviewers, different interpretations, different luck. Your job is to make rejection as hard as possible to justify.
Guideline 4.2 Sub-Categories
Apple's rejection emails often cite specific 4.2 sub-guidelines. Here's what each means:
4.2.1 - Apps Using Non-Public APIs
Your app uses private frameworks or APIs not documented in Apple's public SDK.
Fix: Remove any private API calls. Use nm or otool to scan your binary for private symbols.
4.2.2 - Apps That Are Not Useful
The app doesn't provide lasting value or meaningful functionality. This is the most common 4.2 rejection.
Fix: Add native features like offline support, push notifications, widgets, Siri shortcuts, or device integration that websites can't replicate.
4.2.3 - Apps That Are Simply Websites
Your app is primarily a web view with no native iOS features or offline capabilities.
Fix: Implement at least 3-4 native features. Consider: native navigation, local data caching, biometric authentication, camera integration, or Apple Pay.
4.2.5 - Apps Primarily Marketing Materials
The app functions more as an advertisement than a useful tool.
Fix: Add genuine utility. For a restaurant: add ordering, reservations, loyalty program. For a business: add appointment booking, customer service chat, or account management.
4.2.6 - Apps from Templates or App Generation Services
The app was created using a drag-and-drop builder without significant customization.
Fix: Extensively customize the template. Add unique features, custom UI elements, and functionality that differentiates it from other template-built apps.
How to Fix a 4.2 Rejection
Getting past Guideline 4.2 requires demonstrating that your app provides value beyond a website. Here's a systematic approach:
Add Native iOS Features
Implement features that require native access and can't be replicated by a website:
- • Push Notifications: Keep users engaged with timely updates
- • Widgets: Show app content on the home screen
- • Siri Shortcuts: Voice-activated app actions
- • Apple Watch: Companion app or complications
- • Offline Mode: Cache data for use without internet
- • Camera/Photos: Scan documents, take photos, access library
- • Face ID/Touch ID: Biometric authentication
- • HealthKit/CoreMotion: Access fitness and health data
Enhance the User Experience
Make your app feel native and polished:
- • Use native navigation (UINavigationController, TabBar)
- • Implement swipe gestures and haptic feedback
- • Add smooth animations and transitions
- • Follow Human Interface Guidelines strictly
- • Support Dynamic Type and accessibility features
- • Add pull-to-refresh and native loading states
Write a Compelling Appeal
If you believe your app provides value, explain it clearly in the Resolution Center:
Dear App Review Team,
We respectfully request reconsideration of our app [Name].
Native features we've implemented:
1. Push notifications for [specific use case]
2. Offline data caching using CoreData
3. Face ID authentication for secure access
4. Home screen widget showing [specific data]
Value beyond a website:
[Explain specific user benefits that require native access]
Thank you for your consideration.
Real-World Examples
✗ Rejected: Restaurant Menu App
A WebView showing the restaurant's menu PDF with contact information and hours.
Why: No functionality beyond what the website offers.
✓ Approved: Restaurant App
Native menu with ordering, Apple Pay, push notifications for order status, loyalty rewards, and table reservations.
Why: Genuine utility that requires native capabilities.
✗ Rejected: Company Info App
Static pages showing company information, team bios, and a contact form.
Why: Marketing material with no app-specific value.
✓ Approved: Client Portal App
Secure login with Face ID, document upload via camera, push notifications for updates, offline document access, and in-app messaging.
Why: Provides secure, convenient access that improves on web experience.
Questions I Always Get
"Should I appeal or just add features?"
Usually, add features. Appeals for 4.2 rarely work unless you've genuinely been misunderstood OR you have a strong case that the reviewer missed something. Writing a compelling appeal that says "my app IS useful because..." is harder than just adding push notifications and offline mode. Do both if you can—add features AND explain them clearly in your resubmission notes.
"How many native features is enough?"
There's no magic number, but I aim for 3-4 that I can list clearly. Quality beats quantity. A well-implemented offline mode with local sync is worth more than push notifications + widgets + Siri shortcuts that feel bolted on. The reviewer should see your native features within 30 seconds of opening the app.
"My app was approved before! Why is it getting rejected NOW?"
This happens all the time and it's maddening. A few possibilities: (1) Different reviewer with different interpretation, (2) Apple raised the bar—what passed in 2021 might not pass in 2025, (3) Your update changed something that triggered a fresh review of the whole app. Unfortunately, "but you approved it before" is not a valid appeal argument.
"Will using React Native or Flutter get me rejected?"
No. I've shipped dozens of React Native apps. Apple doesn't care about your framework—they care about the user experience. The Expo community ships thousands of apps successfully. The real question is: does your app feel native and provide value? If yes, your tech stack is irrelevant.
"Can I resubmit immediately?"
Yes, as soon as you've made meaningful changes. In fact, quick turnaround looks good—it shows you're responsive and taking the feedback seriously. Just make sure you actually fixed/added something. Resubmitting the same binary hoping for a different reviewer is a waste of everyone's time and Apple notices.
"What if my app is genuinely simple by design?"
Then you need to explain WHY in Review Notes. Some apps are intentionally minimal—meditation timers, focused tools, accessibility aids. If simplicity IS the feature, make that case clearly. "This app is designed to do one thing without distraction" is a valid argument. Back it up with great execution and maybe some accessibility features.
Pre-Submission Checklist for 4.2
Related Guides
Avoid 4.2 Rejections Before They Happen
Our AI Review Toolkit scans your app for common 4.2 triggers and suggests native features to implement before you submit.
Get the AI Toolkit — $29.99