Common App Store 2.3.1 triggers
Guideline 2.3.1 is about accurate metadata. Apple rejects apps that hide features, show screenshots that do not match the binary, or keep leftover names, icons, and strings from another product. 2.3.1 often appears next to 4.3 when a team reuses an old project as a new listing.
Typical triggers
Store screenshots that advertise a feature the build does not contain. In-app copy or resource filenames that still mention a previous brand. A binary that embeds URLs, scheme names, or analytics keys from another app. Preview video that shows a different navigation structure than the archived IPA.
Self-check before resubmission
Search the project and the IPA for the old display name, old bundle seeds, and leftover Info.plist URL schemes. Confirm every screenshot is captured from the build you will upload. If you changed only the store listing, reviewers can still see the old product inside resources. The longer list is in Common 2.3.1 triggers.
How resource and SDK isolation help
Crab can rename, break signatures on, and encrypt resource files without asking you to keep a parallel source tree. The runtime support SDK uses independent characteristics per build, so two packages from the same toolchain are less likely to share the same supporting bits. Combine that with honest metadata. Obfuscation does not hide a feature from review and must not be used that way.
If you cannot submit the listing yourself
If you cannot handle App Store Connect, certificates, or review replies, use the App Submission Service: a specialist team submits the obfuscated app, with no fee if the review fails. Pricing is quoted via the homepage chat.
Related reading
If the rejection is mainly about being a duplicate, start at 4.3. For crash logs after a rebuild, see dSYM restore. Operator steps are in the docs.
Request a trial, then archive and submit
Download App Center, choose the General or Uni-app edition, then apply for a license on the registration-code page. The docs cover the operator steps.