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".
Related
I have an Objective-C project whose .ipa was tested with this tool online: https://www.immuniweb.com/mobile
It reports that my app has a high risk security issue, pointing to the canAuthenticateAgainstProtectionSpace in the NSURLConnectionDelegate protocol.
This method has been deprecated by iOS after 8.0 version. My app is not using it directly anywhere and I suppose this is not used by apple also even indirectly, since it is deprecated.
I tried a sample ipa (new project with nothing in it) with Objective-C project and the same issue came for that as well. But it did not come for a sample ipa which supported Swift. Even if this is just a warning, is there a way to fix other than just supporting Swift language only?
The tool has detected that the .h file that defines the NSURLConnectionDelegate protocol declares the canAuthenticateAgainstProtectionSpace function. This is, of course, to be expected.
It would make more sense for the tool to report implementations of the method, not simply declarations of it
Since you haven’t implemented this method you don’t need to worry about flaws in your implementation.
As for getting rid of the issue...Don’t use the tool? It doesn’t seem very good based on this.
Is there an option to tell it not to scan .h files?
TBH it seems like a bug in the tool if not any of your Libraries or Frameworks internally uses that.
In your test for the sample Objective C project it's reported as bug however for a sample swift project it's not reported Hence I guess it's more of bug from the tool side.
I would suggest you to report this issue to them.Hopefully they will get you back with some suggestions.
or
you can try some other pen-testing tools as well.
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'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?
I am using an fmod plugin for Unity3D. Compiling to Windows and OSX is fine because I can dynamically load the DLL/dylib.
The problem comes when I compile for iOS. I use
[DllImport("__Internal")]
Because iOS requires statically linked libraries. When I compile though I get a
SystemException: Duplicate native method found : FMOD_System_CreateSound. Please check your source carefully.
I am quite sure I don't duplicate the symbol. I think this might be due to the fact that Unity imports FMODs itself and that the two might be colliding... But if this is the case, I am surprised that FMOD_System_CreateSound is the first one to get caught. Is there a way around this? thx!
As always, I will be happy to provide any additional details!
Here is a sample project that will cause the error:
Sample Unity Project with FMod
EDIT:
The conflict was caused by iOS not allowing functions to have the same name even though they don't have the same signature. After removing the same-named functions (thus removing some FMOD features that I didn't need), I can compile to iOS, but as expected, I still get an error when Initializing because FMOD is already initialized by Unity.
Unity3d already has a limited version of FMOD that is bundled with it, which is causing the conflict you are seeing. Unfortunately, it doesn't seem possible to disable it at this time, so that you can use the full version of FMOD
In reference to your edit and after looking at the sample, it is true that you cannot have two methods of the same name as the compiler will not recognize which to link to.
The easy fix is to obviously name them differently.
As for the initialization, if you can access the FMOD that Unity 3D already created, then you don't have to reinitialize it.
I assume that a pointer to that object will be sufficient to remove the duplicate initialization. Hope this is clear.
I had built PJSIP 2.7.1 and was integrating it for an iOS app written in Swift. Everything worked so I believed it was built the right way, all libs and headers were in the right place too, until one day I was trying to call lib functions from an external thread so I had to register this thread by using pj_thread_register() and declared a pj_thread_t type variable, the compiler started to complain about that the type pj_thread_t was undeclared.
I found the pj_thread_t was declared in pj/types.h and was defined in pj/os_core_linux_kernel.c. The types.h was already included in the header search path and I supposed it should work. I guess I must have missed something here.
I met the same problem in my Swift project. My solution is create a kind of wrapper file in ObjC. Swift and ObjC works with memory in different ways. This is why my wrapper works good. Now I can call pj_thread_t inside my wrapper file.
pjsip (C) --> MyWrapper file (ObjC) --> myProject' files (Swift)
MyProject-Bridging-Header.h file contain only one row:
#import "MyWrapper.h"