NSDeprecated which tunnels through CF_Deprecated into the clang attribute availability only handles deprecation for MACOSX and IOS.
Are there any calls or series of macros that replicate this tool for third parties.
I am working on V2 of an SDK and there are certain calls we want to deprecate as well as EOL.
(Please note, this SDK is still in Objective-C; so Swift only solutions don't solve my issue)
The deprecation warnings and errors would be fantastic at compilation and code generation time; however, I fear this is something I'd need to spin on my own.
Any pointers or reference on this before I have to decide if I need to kill the time on this side project?
You can #define a macro in your SDK project to make a shorthand for the deprecation message. We did something similar in the Core Plot project.
There is a function attribute deprecated provided by GNU compiler.
The syntax to mark deprecated functions is:
void Foo() __attribute__( (deprecated("message", "replacement")) );
The first one is the message to display when emitting the warning; the second one enables the compiler to provide a Fix-It to replace the deprecated name with a new name.
More information on using function attributes can be found in GCC Attribute Syntax documentation or Attributes in Clang documentation
some handy macros are in the NSObjCRuntime.h from Apple.
NS_DEPRECATED_IOS(6.0,10.0)
works like a charm.
Related
I have an app with Firebase integration to connect analytics using cocoapods. It was working well without any yellow warnings for iOS 13, but when I installed the new cocoa pods for target iOS 14 and build the app I get 6 yellow warning messages
"XXXPods/GoogleUtilities/GoogleUtilities/Logger/GULLogger.m:130:20: This old-style function definition is not preceded by a prototype"
When I was looking for answers online, there are only few and pointing to Flutter. I don't have Flutter for this app and I don't think I will be needing one. Does anyone else have the same issue? How can this be silenced for iOS 14 please?
I can downgrade the pods to iOS 13 but the whole point was to update the version.
Thank you for any help/direction
So this is a new warning in Xcode 12.5 (I believe) for old C style functions declared in those SDKs or any old style code using that syntax.
What does it mean?
do-not-leave-the-parameter-list-of-a-function-blank---use-void
if a function declaration does not include arguments, as in
double atof();, that too is taken to mean that nothing is to be assumed about the arguments of atof; all parameter checking is turned off. This special meaning of the empty argument list is intended to permit older C programs to compile with new compilers. But it's a bad idea to use it with new programs. If the function takes arguments, declare them; if it takes no arguments, use void.
So this is how your function prototype should look:
int foo(void);
And this is how the function definition should be:
int foo(void)
{
...
<statements>
...
return 1;
}
One advantage of using the above, over int foo() type of declaration (ie. without using the keyword void), is that the compiler can detect the error if you call your function using an erroneous statement like foo(42). This kind of a function call statement would not cause any errors if you leave the parameter list blank. The error would pass silently, undetected and the code would still execute.
What can we do?
May be raise a ticket for Firebase SDK to address (if there is not one already).
How big of a problem is this?
Depends on the implementation details. Could be as simple as replacing () with (void) for all of these functions. Could be a little more involved as explained above otherwise.
Firebase team maintains the SDKs regularly and we should see a fix for this in an upcoming release soon.
Run pod update
Firebase fixed this issue in February after Xcode 12.5 was introduced github.com/google/GoogleUtilities/pull/8/files.
I have a private cocoapod that I've built. It's written in Obj-C. I had some old APIs in my library, that I wanted to mark as deprecated, mainly as a reminder to my team that they should start using some newer APIs.
So I have a routine, in my ObjC library, that looks like this:
-(void) myOldRoutine DEPRECATED_MSG_ATTRIBUTE("Use myNewRoutine instead");
In my client app, I have both ObjC and Swift files. If I call "myOldRoutine" in my ".m" file, I just get a compiler warning.
But if I make the exact same call, in Swift, I get an error. The error message is identical to the warning message, except it's an error, and halts compilation.
Thanks in advance for any help.
Swift has an own setting that controls if warnings are errors. It's named SWIFT_TREAT_WARNINGS_AS_ERRORS. Whereas the setting which controls this for C/Obj-C/C++ is named GCC_TREAT_WARNINGS_AS_ERRORS. If the first one is set, deprecations result in warnings everywhere but Swift where they are errors.
Just replace your deprecated routine:
-(void) myOldRoutine DEPRECATED_MSG_ATTRIBUTE("Use myNewRoutine instead");
with the "#warning - your comment".
I have just finished porting a decent amount of c-sources to the iOS platform and packaged them as a universal static framework. I, then, added the framework (not the project) to a sample iOS app in order to test linkage and proper function. That's when I ran into a humbling problem.
In my attempt to solve the problem described here, I also came across some symbols that are composed through the heavy use of macros (i HATE those). Some of those macros use function attributes that are really extensions of gcc rather than of standard C.
Of course I can always add -std=gnu89, but even then, I am not sure it will resolve the original problem of undefined symbols in the static library.
Not only that, I am now worried that my port to iOS of those sources may not be an accurate port and may result in the type of bugs/issues that maybe related to compiler's codeine and/or optimization policies.
If you can share some of your experience/advice in how best to go about that port, I would really appreciate it.
Thanks!
From manual testing with clang 8.0, it seems that both __attribute__((constructor)) and __attribute__((__constructor__)) work for your purpose.
I was intended to import a third party map kit to my project.Before that I already used ASI as network module, and the compiler for C/C++/Objective-C was LLVM GCC 4.2.But it didn't work with my third party map kit.So I switched to Apple LLVM compiler 4.2,which is a default compiler,but lots of errors showed the redefinition of ASI classes.
Make Clean
Delete derived data
Advice switch to AFNetworking which is far more better that good old ASIHTTP. I used to love it and saved my arse hundreds of times.
There's an adapter for ASIHTTP code as well
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?