I'm implementing ShareKit in my App. Everything is working fine, I also got rid of most of the warnings (all the warnings that are caused because ShareKit suports OS 2.x - my app suports 3.2 and above, so I didn't need these code lines anyhow...)
There is only one file I'm not able to solve - the FBRequest.m. I cannot simply remove the lines that get warnings because if I do so my app doesn't connect to Facebook.
In a previous post I published about this issue someone referenced me to a ShareKit fork that supposes to fix this - but (!) it requires that I switch the files that I already modified for my app (and also, I ran the fork "Example App" and found the same warnings...).
If I drill down to the specific Warnings, they sum up to 2 types (I have 9 warnings, but most of them are from the same type)
FBLOG and FBLOG2 - whenever one of them appear in the code, I get the following Warning: Unused Entity Issue: Expression result unused
FBXMLHandler vs. NSXMLParser - There are 2 warnings relating to this issue, in the parseXMLResponse method:
- Class 'FBXMLHandler' does not implement the 'NSXMLParserDelegate' protocol
- Semantic Issue: Assigning to 'id<NSXMLParserDelegate>' from incompatible type 'FBXMLHandler *'
Had anyone happened to solve these issues in their app and can guide me how to deal with them?
OR...
Had anyone encountered these issues, ignored them, uploaded their app to app store and was not rejected by Apple App Review (and therefore can say "hi, you can just ignore these warnings. Apple don't care...")?
I found one post that solves the FBXMLHandler vs. NSXMLParser issues
here is the link:
https://github.com/ideashower/ShareKit/issues/215
Regarding the FBLOG issue - I just did "//" for all the lines that produce this warning and it seems to be working fine.
If anyone knows that what I had done here is wrong and may cause other problems, do tell...
I encountered the same problem and I ended up doing just what you did :))
The warning appears because of the parentheses. It interprets the function as an expression and considers that you didn't use it's result.
Regarding what it does, I'm not 100% sure but looking at it I'm quite convinced it's just a log function useful for debug without any actual role.
Related
I noticed strange behaviour during working with Swift projects. I can't explain it other than Swift sometimes calls wrong method. It is very rare and even adding blank lines to the code could lead that this error is gone.
Let me explain in screenshots what I mean, next I use CoreData example of SwiftDDP project that can be found on Github, but such issues I was able to see in my own projects.
Here we at Todos.swift:74 where you can see breakpoint, I expect that next call should be getId() method of MeteorClient class because it was already instantiated:
After Step Into as you can see the ping() of the same instance is called:
The next two steps into lead to EXC_BAD_ACCESS exception:
In my project I saw this issue fairly often before I stopped using singletons, so it could be related to Swift static memory usage or I don't understand something that is not surprising as I have little experience with multithreading and memory management.
My environment is:
AppCode OC-145.184.11
Xcode Version 7.2.1 (7C1002)
iOS 9.2 SDK
Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81)
NOTE: Here I use AppCode but the same behavior I was able see in Xcode, and even more if the same issue that reproduces in Xcode could not reproduce in AppCode and vice versa.
Would be thankful if someone can explain this strange behaviour to me.
Thanks!
This just happened on my team, using Swift 2.2. It's really incredibly strange. It's not a threading issue or an async problem, it was a very cut & dry use case. We called one instance method and another one above it got called. I deleted the method that was getting called, and then the one above THAT got called instead. Then I moved the method I was actually calling to a different location in the file, and it looked like multiple properties were getting called.
This is disturbing and worrisome, as now you feel you can't trust your code to run properly.
But we did "solve" it. We moved the method up to the code that was actually getting triggered, and after a little trial & error the right method got called. Not yet sure if this will manifest itself for other methods.
It'd be nice to be able to provide a simple project where this is happening, but it seems highly unlikely that it's possible, and I can't share a snap shot of my code base with Apple. It must be a perfect storm of something to cause a bug with Swift's run time.
I had a similar issue, I think. Couldn't see that the wrong function was being called, but breakpoints on the function that was being called were never hit, and I couldn't step into the function from where it was being called. I added a new function (I called it wtf) with the same parameter list and implementation, and that one worked as expected, so it must have been a weird linking issue in the Swift compiler.
Update: super-cleaning appeared to work (see below), but it doesn't. Looks like I'm leaving my wtf function in.
After super-cleaning the project, it looks like everything's working as expected again:
clean (cmd + shift + k)
clean build dir (cmd + opt + shift + k)
quit XCode
delete derived data (rm -rf ~/Library/Developer/Xcode/DerivedData/*)
FYI, in my case, the function I call is in a generic base class, called from a generic subclass, triggered by a specialized sub-sub-class. As we all know, the generics are still very buggy in the Swift compiler, so that's probably why I encountered this.
Do you have multiple threads running? Maybe a network thread?
I thought I had this issue too but then it turned out my one thread was doing something and because the other thread crashed it stopped the other thread at a random point. I only noticed this thread so it seemed like it crashed at a random #IBAction function.
When I switched to iPhone 6 simulator instead of iPhone 7, it seems to be working correctly now!
Our app was rejected from review because of a mysterious crash. After debugging I found that it was having this same issue - but only for the Release scheme!
So I went through every setting in Build Settings one by one to see if switching it to that of another scheme would fix the issue: changing ENABLE_TESTABILITY to true fixed it......
I receive this error when appending an already-successful build in XCode. What I don't understand is I'm not changing anything when appending, and this error shows up.
I've never used an 'old version of Xcode' as the error implicitly states.
Does anyone know how to get append working on a consistent basis?
This is a very simple project, and I'm using Playhaven and TapForTap SDK's, if that offers any insight.
Turns out, XCode upgraded itself without telling me. :(
I rolled back to the version I was using and all is well.
With no code snippets or error logs, it's very hard to determine what the source of your problem is. There's no way to know if your error is describing the cause of your problem or a symptom of the problem without more information.
I can only offer some suggestions:
My first thought is that you're using a deprecated method in your code somewhere, possibly "Append", which if that is the case, more than likely has an updated counterpart, but you'll have to check documentation regarding that.
If you've used "Append" previously with no errors, then you should look into what exactly you've changed in your new build, and verify that the methods you're using are supported.
If your errors are vague or unhelpful, you can begin the process of elimination and start commenting out blocks of code until it builds successfully, and narrow down the source of the problem significantly.
However, it would be to your benefit to expand your question with more information.
I'm new to the update/versioning process of an app and Xcode, so here are a few questions:
I create the app and was approved by apple running in the old xcode and simulator 5.1. I DIDN'T have any warning messages. Now when running in new xcode and simulator 6.0, I get 20+ new warning messages.
Does Apple expect NO warnings in any build in any version?
Do I need to fix all of the warnings or only certain ones?
(i.e. my app files VS external 3rd party frameworks/libraries that I included/imported into the app)
Fixing them for this version 6.0 may break for older version, correct?
The app was create with a target of 5.1, but wanted to move that back to 4.3 (more user coverage), I can only test that on the simulator is that okay?
Here are some example warnings:
- JSONKit.m - Semantic Issue - Direct Access to objective-c's isa is deprecated in favor of object_setClass() and object_getClass()
- Many types ones like - Format specifices type 'unsigned long' but the argument has type 'NSUInteger' (aka 'unsigned int')
- Cocoa API Issue - Using 'stringWithString:' with a literal is redundant
Thanks for the help.
Apple has no idea what warnings you got compiling your code. All they see is a signed binary, one that either works (approve) or doesn't (reject).
Why are you getting them now? Because the new version of Xcode has better heuristics for checking suspicious code. Deprecation warnings are because you're now using a newer version of iOS as a target.
Should you fix them? Probably. I do release code with compile warnings but you need to consider the risks of not fixing the warning on a case-by-case basis. Some are more important or dangerous than others.
The convention is that compilers generate errors and warnings.
Errors are fatal problems that prevent the compiler being able to parse the source and generate code.
Compiler warnings are about potential issues which do not prevent the compilation succeeding but may cause issues at run-time, or flag issues you should be aware of.
You should understand the issue that each of the warnings is describing, and decide whether to take action.
Specifically, deprecation warnings are a 'heads-up' that future versions of iOS (or a library, or whatever) may no longer support the API you're using, and it's time to think about moving to the new API, or remove the code that relies on that API.
Often, warnings can be safely ignored, but it's best practice to keep your code clean of warnings so any new warnings are apparent, and grab your attention.
Apple will not reject an app based on compilation warnings. Apple only see the submitted binary, and don't have access to the source code and any associated warnings.
In the case of using JSONKit I would recommend wrapping your code around an adapater class so you can use NSJSONSerialization for versions above or equal to 5.0.
How large is the user base with iOS version lower than 5.0? I read that its less than 1 percent?
I'm building a app with Bump API and Facebook SDK.
And at some point suddenly an error appeared which hasn't been there before.
The strange thing is, that it first was in an Facebook SDK header file and now it's in Bumper.h.
I'm pretty sure that the error is not where XCode says it is. But i can't find anything. This is pretty frustrating and it once again confirms that XCode can be a REAL pain.
Somebody of you have any ideas what could be wrong? I'm developing with iOS 5. Thx
Travel up the include chain. The actual error will be in something that includes Bumper.h or an include in the file that includes Bumper.h (and so on till you get to the missing #end , } or ; )
When a compile is done all the includes are glued together into one file which is why you are seeing the consequences of the syntax error in the wrong place.
I'm implementing ShareKit in my app. Everything is working fine, but there are many warnings caused by the ShareKit files.
When I look into them it seems that they all relate to just a few issues:
ShareKit is using some deprecated items (mostly "font" related).
FBLOG2 - many times ShareKit calling this feature, but don't use it; so the warning is always: Expresion result unused
In FBRequest.m file there is a method called "(id)parseXMLResponse:(NSData*)data error:(NSError**)error". the warning I get is "Semantic Issue: Assigning to 'id' from incompatible type 'FBXMLHandler *'"
Can anyone direct me to how to solve these warnings?
OR... Does anyone know if Apple App Review rejects applications that carry these warnings (as I said, besides the fact that the warnings are being called, my app is working fine and all the ShareKit features I had implemented are functioning fine as well)?
Sharekit hasn't been updated by the authors in over a year. That being said, some things have changed since then (APIs updated, method deprecated, etc.) However, Sharekit should still work. If the warnings bother you (as they should), they shouldn't be very difficult to fix. If you need help, google the specific warnings.
For example, the font issue is just setFont has been deprecated in favor of cell.textLabel.font = ...