Is DPLA 3.2(f) the same as App Review Guideline 3.2?

No. Guideline 3.2 covers business models. Section 3.2(f) of the Developer Program License Agreement covers dishonest or fraudulent conduct and is applied to the whole account.

Can ads alone trigger a 3.2(f) termination?

They can be the evidence. If an ad promises content or features the reviewed build does not show, Apple can read that as the app changing after review.

Should I open a new account and start over?

No. Apple says new accounts created after this notice may also be terminated. Use the appeal.

DPLA3.2(f)

Developer Program License Agreement 3.2(f) — Dishonest or Fraudulent Activity

3.2(f) is not an App Review guideline. It is the Developer Program License Agreement clause Apple uses to remove an account for dishonest or fraudulent activity — most often because what users see is different from what review saw.

§ 01What this rejection usually means

This is an account-level decision. All apps on the account are removed, earnings are paused, and app transfers are disabled.
There is no resubmission path while the account is flagged. The only channel is the appeal described in the notice.
“Concept or feature switch” is what Chinese developer communities call an “A/B package”: review sees app A, users get app B.
Apple does not need to find the switch in your code. A public ad that promises content the reviewer never saw can be enough.

§ 02Common causes

Ad creatives (run through Adjust, AppsFlyer, or ad networks directly) showing content or features that the reviewed build does not offer.
Content or UI gated by attribution data — network, campaign, ad group, or creative — so paid users see a different app than review.
Remote config, region, language, or install-date flags that turn on features after approval.
Hidden entrances, gestures, or web views that load a different product.
Content you are not licensed to provide, or metadata that misrepresents the app.

§ 03How to diagnose your case

List every active and recent campaign, then place each creative next to the build Apple reviewed. Mark anything the reviewer could not have seen.
Search the code for attribution callbacks (for example Adjust attribution or deferred deep links) and check whether any branch changes content.
List every remote-config key that can show, hide, or swap a feature, and what the reviewed build received.
Check related apps on the account: the notice applies to the account, not only the newest submission.

§ 05What to inspect in your project

Checklist

Adjust dashboard: campaigns, networks, creatives, and tracker links for the last 90 days
Creative library on Meta, TikTok, Google, and other networks
Code paths that read attribution, campaign, or deep-link parameters
Remote config and feature-flag history around each review date
App Store screenshots, preview, and description vs. what ads promise
Review Notes: whether any server-driven feature was disclosed

§ 06What not to do

Do not

Do not create a new developer account. The notice warns this can terminate the new or associated accounts.
Do not move the apps to another team or a friend’s account.
Do not delete campaigns or config history before you document it. Pause, then record.
Do not claim in the appeal that there is no mismatch unless every ad matches the reviewed build.

§ 07Questions people ask next

Is DPLA 3.2(f) the same as App Review Guideline 3.2?: No. Guideline 3.2 covers business models. Section 3.2(f) of the Developer Program License Agreement covers dishonest or fraudulent conduct and is applied to the whole account.
Can ads alone trigger a 3.2(f) termination?: They can be the evidence. If an ad promises content or features the reviewed build does not show, Apple can read that as the app changing after review.
Should I open a new account and start over?: No. Apple says new accounts created after this notice may also be terminated. Use the appeal.