# Guideline 4.2 - Design: Minimal Content or Features

**Guideline:** 4.2 · **Store:** Apple App Store · **Risk:** high · **Difficulty:** hard · **Typical turnaround:** 1-4 weeks

Canonical URL: https://appstorereject.com/rejections/apple/4/guideline-42-design-minimal-content-or-features

## Description

Apple rejected your app under Guideline 4.2 because it does not include enough content or features to qualify as a standalone App Store experience. Your app may function correctly, but Apple considers it too thin — it might be a single-purpose utility that could be a website, a feature within another app, or an app with placeholder content. This rejection signals that Apple does not believe your app provides sufficient value to justify a dedicated App Store listing.

## Common variations

- App has only one or two screens with limited interactivity
- App is essentially a calculator, timer, or single-function tool with no additional value
- App launched with placeholder content or “coming soon” sections
- App’s primary content is static text that doesn’t change
- App provides functionality that is already covered by built-in iOS apps
- App is an MVP with too few features for Apple’s bar

## Example rejection email

```
Guideline 4.2 - Minimum Functionality

We found that the usefulness of your app is limited by the minimal amount of content or features it includes.

We encourage you to review your app concept and incorporate different content and features that are in compliance with the App Store Review Guidelines. We understand that there are no hard thresholds for what content is considered sufficient, but the App Store is intended for apps that provide a rich, engaging user experience.

Next Steps: Consider how you can add additional features, content, and functionality to create a more robust app experience. Apps that are simple web clippings, content aggregators, or a collection of links may not be appropriate for the App Store.
```

## Resolution steps

## How to Fix Minimal Content or Features

1. **Audit your app through Apple’s lens** — Ask honestly: does this app provide more value than a website bookmark or a Shortcut? If not, you need to add features that justify a native app.

2. **Add depth to your core feature** — If your app does one thing, make it do that one thing exceptionally well with multiple layers:
   - History/favorites/bookmarks for past interactions
   - Customization and settings (themes, units, preferences)
   - Data visualization or statistics about usage
   - Share/export functionality

3. **Implement native iOS capabilities** — Features that prove your app needs to be native:
   - Push notifications for timely updates
   - Widgets (WidgetKit) for at-a-glance information
   - Shortcuts/Siri integration for voice control
   - Offline mode with local data persistence
   - Live Activities for real-time status

4. **Add content depth** — If your app is content-based:
   - Ensure there is substantial initial content (not placeholder or “coming soon”)
   - Add search, filtering, and categorization
   - Include user-generated content features (favorites, notes, ratings)

5. **Build complementary features** — Think about what naturally extends your core concept:
   - A tip calculator app → add receipt splitting, payment tracking, restaurant history
   - A countdown timer → add multiple timers, categories, widgets, reminders
   - A unit converter → add favorites, history, currency rates, AR measurement

6. **Remove placeholder content** — Every section must be fully functional at review time. Remove any “coming soon” labels, greyed-out tabs, or empty states that suggest the app isn’t finished.

7. **Write a clear review note** — In your resubmission, explain the full feature set and use cases. Sometimes apps are richer than they appear at first glance, and a clear review note helps the reviewer understand the depth.

## Appeal guidance

Appeals rarely succeed for this rejection unless the reviewer genuinely missed features. If your app has hidden depth (e.g., features behind onboarding, or a demo account is needed), reply in Resolution Center with a detailed walkthrough video and explicit instructions for accessing all features. Otherwise, add more features and resubmit — arguing that your app is “sufficient” without changes almost never works.

## Before / after examples

**Before:** App structure that was rejected for minimal functionality:
- Screen 1: Text input field + "Convert" button
- Screen 2: Result display
- No settings, no history, no offline mode
- No widgets, no notifications, no Shortcuts
- Total screens: 2
- Total user interactions: type + tap button
**After:** Expanded app structure that passed review:
- Tab 1 — Convert: Full converter with 50+ unit categories, favorites, swap button
- Tab 2 — History: Searchable conversion history with date grouping
- Tab 3 — Favorites: Pinned conversions for quick access
- Settings: Theme selection, decimal precision, default units
- Widget: Quick-convert widget showing favorited conversions
- Shortcuts: "Convert X to Y" Siri Shortcut
- Offline: All conversions work without internet
- Share: Copy or share conversion results
- Total screens: 8+ | Total features: 12+
**Why it works:** The app went from a 2-screen utility to a full-featured conversion tool. Native iOS capabilities (widgets, Shortcuts, offline) prove it belongs as an app. History, favorites, and settings add depth that keeps users coming back.

**Before:** // Entire app: one view with minimal interaction
struct ContentView: View {
    @State private var input = ""
    @State private var result = ""

    var body: some View {
        VStack {
            TextField("Enter value", text: $input)
            Button("Calculate") { result = calculate(input) }
            Text(result)
        }
    }
}
**After:** // Rich app with tabs, history, widgets, and settings
@main
struct ConverterApp: App {
    var body: some Scene {
        WindowGroup {
            TabView {
                ConverterView()
                    .tabItem { Label("Convert", systemImage: "arrow.left.arrow.right") }
                HistoryView()
                    .tabItem { Label("History", systemImage: "clock") }
                FavoritesView()
                    .tabItem { Label("Favorites", systemImage: "star") }
                SettingsView()
                    .tabItem { Label("Settings", systemImage: "gear") }
            }
        }
    }
}

// Plus: WidgetBundle, AppIntents for Shortcuts, Core Data persistence
**Why it works:** The single-view app was expanded into a tabbed application with four main sections. Adding History, Favorites, and Settings gives the app depth, while WidgetKit and AppIntents integration demonstrates native platform value that justifies an App Store listing.

## Common questions

**Can you appeal a 4.2 rejection?**

Appeals rarely succeed for this rejection unless the reviewer genuinely missed features. If your app has hidden depth (e.g., features behind onboarding, or a demo account is needed), reply in Resolution Center with a detailed walkthrough video and explicit instructions for accessing all features. Otherwise, add more features and resubmit — arguing that your app is “sufficient” without changes almost never works.

**How long does this typically take to fix?**

Typical turnaround is 1-4 weeks (difficulty: hard). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-42-design-minimal-content-or-features*