1

I am developing one application in which I use YouTube GData API. This throws nearly 32 warnings in my project.

My questions are, Will Apple reject the app with multiple warnings?

Are they seeing this warnings seriously?

enter image description here

Cœur
  • 37,241
  • 25
  • 195
  • 267
Easwaramoorthy Kanagaraj
  • 3,925
  • 8
  • 36
  • 62
  • 3
    Why not simply fix the warnings? – John Parker Aug 07 '13 at 12:31
  • 6
    Hum? Apple doesn't see your source code... They have no idea how many warnings you get... –  Aug 07 '13 at 12:32
  • @H2CO3 If you declare a variable named `id` like `NSString *id;` So apple check's it rite ? Application loader will give you a warning to fix it anyways.... – IronManGill Aug 07 '13 at 12:34
  • @IronManGill And how does Apple check it? One does not submit the source code of the app, only the binary... –  Aug 07 '13 at 12:35
  • @H2CO3 Pls explain then "Apple doesn't see your source code... They have no idea how many warnings you get".... How would it be possible for Apple then to know what kind of variables you are using in your App if they aren't checking the code ? – IronManGill Aug 07 '13 at 12:38
  • They have tool something like this http://stackoverflow.com/questions/3593420/android-getting-source-code-from-an-apk-file.... – IronManGill Aug 07 '13 at 12:38
  • @IronManGill the variable names are written into the binary, so it's not hard for Apple to scan for that stuff. But they don't see the original code, so they don't know whether it was generating warnings. – Rik Smith-Unna Aug 07 '13 at 12:41
  • @IronManGill "How would it be possible for Apple then to know what kind of variables you are using" - it's not possible for them. They don't care what variables you are using, and variable names are gone during compilation anyway. –  Aug 07 '13 at 12:41
  • @H2CO3 Well they do care please check Richard's comment above... maybe like he said they only scan the libraries.... I haven't gone through that .... Here pls go through this http://stackoverflow.com/questions/14448056/the-app-references-non-public-selector-in-id-facebook-sdk-ios and https://developers.facebook.com/bugs/143882255765923/ – IronManGill Aug 07 '13 at 12:44
  • @RichardSmith No, the variable names are **not** written into the binary (unless one's dumb enough to sumbit a debug build). –  Aug 07 '13 at 12:46
  • @IronManGill Richard's wrong, the variable names are not written into the binary, and Apple doesn't care either. What they do care about is the names of the **functions** and **classes** used, and 1. that's something completely different, 2. it still isn't the source code itself, and I repeat, there's **no way for Apple to find out what kind of warnings the original source code threw.** –  Aug 07 '13 at 12:47
  • @H2CO3, sorry, that's true for the release and distribution builds. I was thinking of method names (which are left in the binary). – Rik Smith-Unna Aug 07 '13 at 12:50
  • @H2CO3 hmm thanks for the info .... but if his warnings are coming due to the names of the functions and classes used ... then his App would be rejected rite ? – IronManGill Aug 07 '13 at 12:56
  • @IronManGill How many times should I repeat that ***APPLE HAS NO WAY TO FIND OUT IF THERE WERE ANY WARNINGS!!!???*** –  Aug 07 '13 at 12:57
  • @H2CO3 I think you're misinterpreting that last question. IronManGill is saying that since Apple can check class/function names, that you shouldn't ignore warnings that are about class/functions names since Apple can detect those problems independently of the Xcode warning system. – Rik Smith-Unna Aug 07 '13 at 13:04
  • 1
    @RichardSmith Mere function names aren't enough for fully-featured syntactic checking. If it was, then all of our codes would look like `NSLog objectAtIndex strlen` - just a list of function names would be good and the compiler would do what we wanted, right? Too bad it doesn't work like this. Apple is primarily interested in the usage of private functions and classes and other private APIs - and those have nothing to do with warnings. (One exception may be deprecated functions, but that's again something completely different - the main concept is what I just explained.) –  Aug 07 '13 at 13:07

4 Answers4

14

Warnings are for a developer to fix, if he/she chooses to fix. It is a good code review practice to have your code generate minimal possible warnings. Developer should try to resolve as many warnings as possible. However, at times, it is possible that Xcode generates some stray warnings.

As far as Apple policy is considered, you should go through the Apple Appstore Review Guidelines document which has a comprehensive list of reasons that can lead to your app's rejection in the review process.

Warning related information is specific to the IDE that is Xcode. This information is not bundled with the .app/.ipa file. So no way to find out unless someone gets the source code.

Amar
  • 13,202
  • 7
  • 53
  • 71
9

Apple has no way of knowing what warnings are generated by your code, since they only see the compiled product. So no, your app won't be rejected on that basis.

It's good practise to make sure you tidy up all warnings, as they are usually meaningful.

Of course, if the warnings are in a third-party module, that's not your fault, and you can turn off the warnings for the imported files using clang pragmas. See this answer for how to disable warnings for specific code or files.

Community
  • 1
  • 1
Rik Smith-Unna
  • 3,465
  • 2
  • 21
  • 21
1

It's a good habit to enable the flag "treat warnings as errors" when you start a project, but sometimes I see that 3rd party projects will throw a lot of them. So yes, you can submit your app and no, they won't look at the warnings :)

Vik
  • 1,897
  • 12
  • 18
1

My applicatiom with warning was aprove without problems, so you can deploy your application with warnings :)

Roman Barzyczak
  • 3,785
  • 1
  • 30
  • 44