I'm writing a private pod. (I don't think this matters, but thought I should put in the full information).
It's a library used by a couple of apps that I'm writing.
I've recently created some new routines (which make some older routines obsolete). So, I thought I'd mark some of the older routines with a deprecated flag, like this:
- (void) myOldRoutine __attribute((deprecated("Use myNewRoutine instead")));
I'm expecting to get a warning when I compile, (just like other deprecation warnings I get). I'm just trying to add reminders to myself that I need to make newer calls in my client app.
However, instead of getting a warning, I'm getting an error.
I'm using other pods, some of which use older system APIs and always just generate warnings. Why does my use of this generate an error?
Related
Working with this team and I need to release next build to app store. After cloning project I have 37 compile warnings. Should I bring this to someones attention, fix these myself, or leave as is? How would I handle the warnings from 3rd party frameworks Unlock the file and fix myself? id rather not make changes to the 'socketEngine.swift` file that I don't know how works.
Below I've listed the types of warnings I'm getting.
- "characters is deprecated, please use storing or substring directly", and various other deprecations.
- "when calling this function in swift 4 or later, you must pass a () tuple.
- "This block declaration is not a prototype" - About 30 of these
When I run the app everything runs smoothly.
This project is objective-c and Im much better with swift so I don't want correct all of these changes at the moment if I don't need to.
Warnings do not prevent you from building and releasing an app. You can ignore the warnings.
What you should do is talk to your team and ask about any warnings that are part of their code. Why not talk to a teammate?
Do not unlock the files. If you are using a dependency manager, your edits may be lost and need to be repeated in the next release.
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.
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'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 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 = ...