Most mobile teams discover compliance issues the same way: a rejection email from Apple or Google right before a release deadline.
I’m trying to understand where the real pain actually sits in the pre submission process. I’ve been building something that scans the compiled app binary before submission, but I’m not convinced yet which problems matter most in practice.
The starting point was simple. Your source code and your compiled binary aren’t the same thing. Transitive dependencies pull in SDKs, bundle fonts, embed API endpoints, and add entitlements. None of that shows up in your project files, but it does show up in the .ipa, .apk, or .aab that a reviewer looks at.
So I started unpacking the binary and parsing what’s actually in there: binary plists, Android binary AXML, entitlement files, framework lists, and string extraction across compiled content.
What surprised me is how much of this has nothing to do with store rejection. Font licensing turned into a rabbit hole. A plugin can bundle something like Helvetica Neue into your binary without you touching a font file. Without the right license, that is IP risk. The same goes for GPL or LGPL in transitive dependencies if you are statically linking.
On the other hand, some issues are clearly tied to rejection, like privacy declarations not matching what’s actually in the binary, or SDKs doing things you did not expect.
I’m curious how this looks in real workflows.
What does your pre submission process look like today?
What actually costs you the most time after a rejection?
What kinds of issues tend to slip through before submission?
Is this mostly store guideline issues, unexpected SDK behavior, licensing, or something else?
And honestly, is this painful enough that you would pay to prevent it, or is it just part of the process?
Eryq•1h ago
I’m trying to understand where the real pain actually sits in the pre submission process. I’ve been building something that scans the compiled app binary before submission, but I’m not convinced yet which problems matter most in practice.
The starting point was simple. Your source code and your compiled binary aren’t the same thing. Transitive dependencies pull in SDKs, bundle fonts, embed API endpoints, and add entitlements. None of that shows up in your project files, but it does show up in the .ipa, .apk, or .aab that a reviewer looks at.
So I started unpacking the binary and parsing what’s actually in there: binary plists, Android binary AXML, entitlement files, framework lists, and string extraction across compiled content.
What surprised me is how much of this has nothing to do with store rejection. Font licensing turned into a rabbit hole. A plugin can bundle something like Helvetica Neue into your binary without you touching a font file. Without the right license, that is IP risk. The same goes for GPL or LGPL in transitive dependencies if you are statically linking.
On the other hand, some issues are clearly tied to rejection, like privacy declarations not matching what’s actually in the binary, or SDKs doing things you did not expect.
I’m curious how this looks in real workflows.
What does your pre submission process look like today? What actually costs you the most time after a rejection? What kinds of issues tend to slip through before submission? Is this mostly store guideline issues, unexpected SDK behavior, licensing, or something else?
And honestly, is this painful enough that you would pay to prevent it, or is it just part of the process?