# What to check before submitting a native app to App Review

> Prepare an Apple app for review, choose useful native interactions, adopt Liquid Glass, and understand how direct Mac distribution differs.

Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-10-23 | Topics: [Mac](https://flaviocopes.com/tags/mac/) | Canonical: https://flaviocopes.com/app-store-review-native-apps/

A native interface can make your app easier to use. Familiar navigation, readable controls, and the right keyboard behavior save people from learning your interface before they can do their work.

App Store submission adds another job. You have to demonstrate that the app works, explain its purpose, and meet the review guidelines that apply to it.

If you're turning a web product into an Apple app, work through those decisions before rebuilding the entire interface. A change in framework should solve a problem you can describe.

## Start with the task people came to do

Suppose you're building a reading app. Its main job is to let someone save an article and read it later.

Write down that journey before choosing controls. How does an article get into the app? Where does it appear? What happens if the connection disappears while someone is reading?

For this hypothetical app, useful platform integration could include a share extension for saving a page, a reading layout that respects text-size preferences, and downloaded articles for a train journey. Each choice helps the reader finish the task.

Adding a native button that opens your website leaves the reader doing most of the work in the website. Apple's [guideline 4.2](https://developer.apple.com/app-store/review/guidelines/#minimum-functionality) expects lasting utility and an experience beyond a repackaged website. It doesn't promise approval because you picked SwiftUI, nor does it make a framework name a substitute for useful functionality.

## Check behavior on the device

Native UI includes how an interface responds, as well as how it looks.

Walk through your app with the keyboard visible. Open a sheet, dismiss it, return to the previous screen, and resume an unfinished action. Try the largest text size your layout supports. Read the controls with VoiceOver.

For the reading example, check what happens when a saved article has no title. Open an article that failed to download. Try saving the same URL twice. These cases reveal whether someone can recover without guessing what happened.

A screenshot won't show most of this. An interface can look finished while its Back button discards work or its error message leaves you trapped.

If you're new to Apple's declarative UI framework, the [SwiftUI introduction](https://flaviocopes.com/swiftui-introduction/) explains views and state. Use a small working screen to learn the framework before replacing an entire app.

## Adopt Liquid Glass through standard components

Liquid Glass changes the appearance of controls and navigation surfaces. Apple explains that standard components in SwiftUI, UIKit, and AppKit adopt the system appearance when built with the appropriate current SDKs and run on supported platform releases.

The [Liquid Glass adoption guide](https://developer.apple.com/documentation/technologyoverviews/adopting-liquid-glass) recommends starting with a rebuild and inspecting the result. Custom backgrounds can interfere with the system effects. You don't automatically need a rewrite to adopt the material.

For our reading app, start with its navigation bar and toolbar. Keep the article itself readable. Apple advises using custom glass effects sparingly and testing accessibility settings that reduce transparency or motion.

Treat this as interface work with its own acceptance checks. Text should stay legible over different article images. Controls should remain understandable when transparency changes. A visual refresh doesn't answer questions about missing functionality, privacy, or a broken purchase flow.

## Prepare a submission someone can test

Apple's [App Review preparation guide](https://developer.apple.com/app-store/review/) identifies incomplete apps, broken links, and placeholder content among common problems. Give the reviewer a working path through the product.

For the reading app, I'd prepare an account with a few saved articles. I'd also explain how to save a new one. If the app requires a backend, that backend needs to be accessible during review.

Use the review notes to explain features that require setup. For example:

```text
Sign in with the demo account in App Review Information.
The Library contains three saved articles.
To test saving, open a webpage in Safari, choose Share,
and select the app's Save Article extension.
Return to Library to read the saved article.
```

This is an example of useful review notes, not a claim about a real submission. Keep credentials in the appropriate submission fields and ensure the account remains usable.

Check the support and privacy-policy links, screenshots, and description against the submitted build. If the app sells something, make sure the reviewer can reach and exercise that flow. Apple's [submission checklist](https://developer.apple.com/app-store/review/guidelines/#before-you-submit) explains what information and access to provide.

## Respond to the specific rejection

If a submission is rejected, read the cited guideline and the reviewer's explanation before deciding to rebuild.

Fix a missing demo login by supplying a working account. If the screen breaks, repair it. For a concern about minimum functionality, explain the actual utility or change the product to address the concern.

You can [reply in App Store Connect](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/) and attach supporting material. Explain the steps to reach the feature under discussion. Apple also provides an [appeal process](https://developer.apple.com/app-store/review/#contacting-us) when you believe the decision misinterprets the app or guidelines.

Another developer's eventual approval doesn't tell you which change resolved their rejection. Use your own review message and the published requirements to decide what to do next.

## Make the Mac distribution choice separately

For a Mac app, you can also distribute directly from your website. Apple's [Developer ID program](https://developer.apple.com/developer-id/) supports signing software distributed outside the Mac App Store.

For that route, build a proper release process with Developer ID signing and notarization. Apple describes [macOS notarization](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution) as an automated check for malicious content and signing issues. It is a different process from App Review.

Direct distribution also means arranging delivery and updates. My post on [Mac app updates](https://flaviocopes.com/mac-app-updates/) shows how that can work with GitHub Releases.

This Mac option doesn't turn an iPhone app into a directly downloadable Mac app. Keep the target platform, interface implementation, and distribution route explicit in your plan. Then test the complete journey on that platform, from installation to the first useful result.