The resulting API analysis is too large when upload app to mac store

Asked 21/1, 2014 at 12:2 Answered 5/3, 2016 at 23:36

107

I am going to upload my first mac app to Apple Store

And fixed all validation bugs of icon,category...

But after then I passed validation with warning :

The resulting API analysis file is too large. We were unable to validate your API usage prior to delivery. This is just an informational message.

And my upload be rejected with the reason : "Invalid binary"
Is there anyone has experience of this case ?

UPDATE : this warning is not the reason of rejecting, it maybe the app archiving problem. I successfully released my app to store.

So, we can safely ignore that.

Convalesce answered 21/1, 2014 at 12:2 Comment(11)

Could you solve this problem? I have the same problem and I don't know what to do! – Noticeable 26/6, 2014 at 15:25

Received this too. I can't find a source anywhere to accurately explain what it means? – Refraction 5/8, 2014 at 9:22

This older answer might help. I believe the initial warning mesage is unrelated to the error: #3433860 – Trave 9/8, 2014 at 0:45

any luck solving this? – Sparkie 22/9, 2014 at 7:58

I just upgraded my very small shipping app from Swift 1.2 to Swift 2 and get this error. No additional functionality. This has pretty much got to actually be a shortcoming in their analysis tool. (This is for an iOS app, in Xcode 7, not Mac store.) – Painful 20/9, 2015 at 1:31

Same as Ray Fix, not using any private API, just upgrading code from Objective-C to swift – Thyratron 20/9, 2015 at 18:58

Same as above, no private APIs, just used Xcode 7 and i got. – Cowslip 25/9, 2015 at 16:26

The answers provided are outdated. Now this issue is mostly related to Xcode and Swift update. – Idaline 10/10, 2015 at 0:13

Got the same issue in Xcode 7 after adding a Swift 2 extension to an existing Objective-C class. Did somebody open a radar report for this assuming that we all agree that it is a bug in the Xcode analysis tool? – Bevus 14/10, 2015 at 7:42

I have this issue, after updating to Xcode 7 too. Did any of you who have the same problem as me, find a solution to it? So here's my problem, I have an iOS app which I built using Xcode 6 and I have released to the App Store, I updated it 3 times and it was all fine. Now just last week, I updated my app to be Xcode 7 compatible and to use Swift 2, and now when I try to upload it to the App Store fore review, I get this problem. – Pricking 17/10, 2015 at 1:45

Check this answer, too – Bauble 4/3, 2017 at 18:19

Apple forbids using private or undocumented APIs in iOS apps. Any calls you make to methods that have the same name as private or undocumented API methods will be flagged as a private API use, even if the method being called is something you have defined yourself.

App Loader does an initial scan, checking for method names, instance variable access, and even @selector usage with private method names. App Loader doesn't always do a great job, and the more source files you have the more likely it is to give you the warning that the API analysis file it has generated is "too large".

Fortunately, you can still submit your application, despite of the warning. Apple will check it internally, and if something gets kicked back because of overlapping names, you'll have to wade through the review process again.

Erika Sadun tried to make an app called API Kit that would do the scanning for you, but she appears to have abandoned her work and removed any trace of the application from her website.

Chimp Studios created App Scanner to do the same thing, but it hasn't been updated since 2011. Unfortunately, for large projects -- and this includes projects with a lot of extra pods from CocoaPods -- there is no current (2014) good way of solving this problem other than proactively naming things such that they won't conflict with private API method and instance names.

You can proactively learn about Apple's Cocoa Naming Conventions and try to anticipate. That will reduce future headaches. Until Apple introduces something like namespaces, however, we may continue to run into this problem from time to time.

The "invalid binary" error can come from a number of causes, but it is entirely unrelated to the API analysis document created by App Loader.

You should know that even with the scanning, there are still ways to get around the prohibition on using private/undocumented APIs. :)

Polyphagia answered 14/12, 2014 at 9:6 Comment(5)

Are you saying that this "too large" error is a purely mislabeled error? That it always indicates some kind of invalid API usage? How have you made this connection? – Macready 17/9, 2015 at 15:30

I realize the question was about the Mac App store but for the iOS app store, this answer is not fully correct. I just had this warning when I tried to validate my app with Xcode 7 GM, but when I actually uploaded it to ITC with Xcode 7 GM, there were no problems. – Macready 17/9, 2015 at 18:16

What's the hint... that you're implying on your last sentence? – Divine 7/10, 2015 at 2:43

Thank you for a very helpful answer. Do you know where the API Analysis file is to be found. I'd like to root out every warning from my app – Endophyte 29/11, 2015 at 12:54

So if iTunes Connects show that the build is uploaded, that means despite this error message, it did go through? And all I do now is wait for their approval? – Hyonhyoscine 2/1, 2017 at 15:22

After hitting this issue for the first time on my first Swift project, it looks like the most common answer to this question is now:

If you use Swift 2.x and XCode 7, you'll get this error. Just ignore it.

[UPDATE: XCode 7.3 & iOS 9.3 rollout seems to have fixed this issue!]

Burmeister answered 5/3, 2016 at 23:36 Comment(2)

I'm using Swift 2.1 in Xcode 7.3 and this seems to be the case. Hopefully they'll fix it soon. – Hyohyoid 7/3, 2016 at 6:28

jap, i m also using Swift 2.1.1 and xCode 7.2.1 get this info... i will let u know if it pass. – Reluct 16/3, 2016 at 17:59

Here is an easy way to get around them... store the selector name in reverse, like "dlroWolleH", then reverse the string before you call the method.

If Apple gets wise to that then you can encrypt them.

Adherent answered 14/12, 2014 at 13:29 Comment(3)

Or you can follow the review guidelines and not use private API. – Vehemence 29/5, 2015 at 8:45

This isn't going to stop anything. They will be able to detect if the method is called from the method itself. Not from the selector name you use. – Chirurgeon 24/9, 2015 at 11:33

@Chirurgeon it's possible to not call the private methods until a point in the future, such as after your app is approved – Waaf 15/10, 2015 at 3:36

Recommended topics

Hot tags