Introduction
The old iTunes Connect warning about "unexpected machine code" was confusing because it sounded like a malware finding or an automatic rejection. In practice, it was often a warning triggered by how Apple analyzed uploaded binaries, and many developers saw it even on apps built with normal Xcode toolchains. The right response is to distinguish between a harmless warning, a truly unusual embedded binary, and a packaging mistake such as unsupported architectures or third-party precompiled code.
What the Warning Was Really Pointing At
Historically, the warning appeared when Apple's ingestion pipeline noticed binary content that did not match its expectations for a straightforward App Store build. That did not automatically mean the app was invalid. It could reflect:
third-party static libraries or frameworks compiled differently
embedded binaries with unexpected sections or architectures
tooling bugs on Apple's side
unusual code generation or obfuscation
Because the message came from iTunes Connect rather than the local Xcode build, developers often had very little context. That is why the first engineering step is to inspect what is actually inside the app bundle rather than assuming the warning is meaningful by itself.
Audit the App Binary and Embedded Frameworks
Use local command-line tools to inspect the binary composition of the archive before uploading.
Check architectures:
find MyApp.app -type f \( -perm -111 -o -name '*.dylib' -o -name '*.framework' \) -print0 \
| xargs -0 file ``` Inspect a specific binary more closely: ```bash otool -hv MyApp.app/MyApp lipo -info MyApp.app/MyApp ``` These checks help answer practical questions: - is there any simulator architecture left in the archive - did a vendor ship a library built in a nonstandard way - is there an unexpected executable embedded in resources Even if the warning turns out harmless, this audit is still worth doing because it catches packaging issues that really can cause rejection. ## Pay Special Attention to Third-Party Libraries Third-party SDKs are one of the most common places where unexpected binary content enters the app. If the app is built from clean source but links precompiled frameworks, those frameworks deserve inspection. A simple triage process is: 1. list all embedded frameworks and static libraries 2. inspect architectures with `lipo -info` 3. remove obsolete or duplicate binaries 4. rebuild from source when possible 5. update vendor SDKs if they are old If the warning appeared after adding a particular dependency, isolate that dependency first instead of treating the whole app as suspect. ## Understand Why the Warning Was Often Non-Blocking Developers historically reported that apps with this warning were often still accepted. That matters because it suggests the signal was sometimes advisory rather than enforcement. So the correct posture is: - do not ignore the warning completely - do not assume rejection is inevitable - verify the binary contents methodically - if everything looks normal, submit and monitor the result This is a better response than making random build-setting changes without evidence. ## A Safe Build Discipline The best way to reduce this class of warning is to keep the release pipeline boring. Practical habits include: - archive with a current Xcode release - use release builds from source when possible - avoid hand-editing app bundles - strip unused architectures during packaging - remove dead frameworks and helper binaries - keep vendor SDKs current If you do need embedded native code, make sure it is expected, signed correctly, and present for a legitimate runtime reason. ## When to Escalate If the warning appears on a minimal app with no unusual libraries, or if it begins appearing across multiple clean projects, treat the possibility of an Apple-side issue seriously. In that situation, local binary inspection may show nothing abnormal. A reasonable escalation path is: 1. confirm the archive is built with standard tools 2. inspect embedded binaries locally 3. test with the latest Xcode and dependency versions 4. compare against a reduced reproduction if possible 5. contact Apple Developer support if the warning is paired with an actual submission failure Warnings without rejection usually do not justify a full release stop unless you also find something suspicious locally. ## Common Pitfalls A common mistake is treating the warning as proof that the app contains malicious or forbidden code. The message is not that precise. Another mistake is ignoring third-party frameworks during inspection. The main app binary may be fine while a bundled library is the unusual part. People also often respond by toggling random build settings without understanding the archive contents. That wastes time and can introduce new issues. Finally, do not assume every old iTunes Connect warning maps neatly to today's App Store Connect tooling. The underlying platform and diagnostics have changed over time. ## Summary - The old iTunes Connect "unexpected machine code" warning was often advisory rather than an automatic rejection - Start by auditing the app binary and embedded frameworks with tools such as `file`, `otool`, and `lipo` - Third-party precompiled libraries are common sources of unexpected binary content - If local inspection looks normal, the warning may be harmless, especially when the app still validates and uploads cleanly - Keep the release build pipeline simple and source-based where possible - Escalate to Apple only when the warning is paired with a real submission failure or you find suspicious binaries locally
