AppReviewFix
Guideline library
Apple App Store — Design

4.2.3 — App independence

Official source: App Store Review GuidelinesTopic overview: The review process, app quality and enforcement
What this guideline means

An app submitted for review has to function fully on its own — it can't depend on other unreleased apps, an external device that isn't yet available, or a companion product that doesn't exist yet to actually work.

Why apps actually get flagged

Common with hardware-companion apps submitted before the physical product has actually shipped, leaving reviewers unable to test any real functionality.

A real example

"Your app requires companion hardware or software that is not currently available, so its core functionality could not be verified, per guideline 4.2.3."

The short version, in more detail

Guideline 4.2.3 requires that an app can be reviewed and used on its own. It cannot depend on another unreleased app, on a device that does not yet exist or on a companion product the reviewer cannot get. If the core functionality only works with something unavailable, the reviewer cannot judge the app, which is why hardware companion apps submitted before launch often run into this rule.

Why this rule exists

App Review can approve only what it can test. If an app does nothing without a specific accessory or service that is not available, there is no way to confirm that it works, that it is safe or that it matches its description. The rule also protects users who would download an app that appears to be live but cannot do anything until a product ships later.

What this guideline covers

  • Apps that rely on a companion app or service.
  • Hardware-dependent apps submitted before the hardware ships.
  • Features that cannot be tested without outside resources.
  • The availability of what the app depends on at review time.

What usually triggers this rejection

  • A companion app for a device that is not on sale yet.
  • An app that needs another unreleased app to work.
  • A service that is not live at the time of review.
  • A demo that does not show real functionality.
  • An app that gives the reviewer no way to access its main features.

How reviewers evaluate it

  • Reviewers try to use the app as a customer would.
  • They ask whether the main features can be exercised.
  • They consider whether demonstration modes or sample devices are provided.
  • They refuse approval when the app cannot be tested.

Common misunderstandings

  • An app is not reviewed on the promise of a future product.
  • A limited demo does not always satisfy the need to see real functionality.
  • The rule is not about quality. It is about being able to evaluate the app.

Common questions

Can I submit before my hardware launches?

The app needs to be usable and testable at the time of review.

Does the reviewer need the device?

They need some way to see the core functionality, which can include demo access or a provided unit.

Does this affect enterprise apps?

The same principle applies: the reviewer must be able to reach the main features.

Platform rules change often. This page is a plain-language explanation written by AppReviewFix, not official guidance. Check the current App Store Review Guidelines for the exact wording.

Got this exact rejection?Paste it in and get a diagnosis specific to your app, free.
Decode my rejection
Related guidelines
Functionality — Functionality, content and user experienceTarget API Level — Target API level requirements2.1 — App Completeness2.2 — Beta testing2.3.1 — Hidden or undocumented features
AppReviewFix
ProductDecoderPricingGuideline library
CompanyAboutFAQContact
ResourcesGuidesTopic overviewsCommon rejection reasons
LegalTermsPrivacy
© 2026 AppReviewFixBuilt by a developer, not a committee.