I'm trying to get a reference to my app delegate from a UIViewController but I keep getting an this error message:
'sharedApplication()' is unavailable: Use view controller based solutions where appropriate instead.
I've been reading all the articles dealing with this kind of message but my problem seems unrelated as I'm not using any third party framework. While a Today Extension is part of my app, the class in which the error occurs is totally unrelated. I even created a completely new class and keep getting the same error:
When I do the same thing in a playground it works fine. What am I missing?
Problem solved. I've been to the Build Settings of my app again and stumbled over
Require Only AppExtension-Safe API
all set to YES. The default though is NO. When I set this to NO the error disappeared.
I sure don't remember ever touching or even knowing about this but luckily now it works.
I ran into the same error when I created and added a new target to my project (a Remote Service Notification target) and added the target definition incorrectly in my podfile.
I was following directions from a third party notification platform and they were unclear as to where to place the target definition. Initially, I added the target definition within my main target, much like the Tests target definition. This mistake led me to this error.
I ended up moving the remote service notification target definition outside of my main target to the bottom of my podfile and that resolved my problem.
In case anyone came through this error after 3 years from the question time.
Make sure that the swift file target Membership doesn't include a Today Extension.
In my case, I have not defined import Foundation in the file causing the error.
silly and late but could help an absent-minded like me. Cheers.
Related
Looks like the Xcode introduces more and more new problems to developers.
Does anyone know what the hell is this issue and how to get rid of it?: The property is defined on XXX, and may not be available in this context.
The property exists in this scope and the code runs without any problems, but auto-complete is broken as always...
I resolve this issue by checking pods versions installed, upgrade or downgrade pods to access this method.
In project folder delete pods folder and reinstall it.
Check the pods versions twice which is needed to be update.
So what I'm noticing is that ever since upgrading from Xcode 12 to Xcode 13, instead of a property not displaying in auto-complete (because it is inaccessible in the current scope), it seems that Xcode 13 displays it in auto-complete with the warning/error that the property may not be available in the context. In other words, Xcode 13 seems to recognize the property exists somewhere but, in theory, shouldn't be available in the current scope
In short, I suppose this (seemingly new?) warning is basically Xcode telling you it thinks the property isn't available in the scope but can't be 100% sure, so it allows you to use it at your own risk (although usually Xcode is right and you mistakenly think it should be accessible when it isn't).
You might get that message if you're accessing a property from a header inside a framework, and the header is not added to the framework's umbrella header.
In that case, the solution is to add the header to the umbrella header.
I had a similar issue with undoActionName and redoActionName. The fix was easy - I simply added undoManager. in front. undoManager inherits from UndoManager. So, try putting the class XXX.table.
I have finally come across something that no one else seemed to have come across (at least from what I can tell). I trying to build an F# type provider using TypeProviders.SDK.
As soon as I build the solution I get the error: "FS0810, Property 'CultureName' cannot be set, \LemonadeProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs" on line 2090 and again at 3162 in the design time project of the solution.
I do not think this is useful but the Test project also fails as it can not find the LemonadeProvider.Runtime.dll. I am assuming this will get created when the Runtime project will build successfully.
PS: As of right now I am just tring to build the provided template, I have not changed the code or added anything to it. Hence I have not attached any code, but please feel free to ask for it.
The corresponding issue is https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/353
Known workarounds
Change minimum target to net461. Replace all instances of net45 with net461, except for in netfx.props, where you can just delete the lines referencing net45* frameworks (I suspect the removal of those lines isn't strictly speaking necessary).
I did this workaround but am now facing these kinds of errors: (like 2000 of them)
C:\Users\user\source\repos\HelloWorldProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs(34,7): error FS0074: The type referenced through 'System.Attribute' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard'. [C:\Users\user\source\repos\HelloWorldProvider\src\HelloWorldProvider.DesignTime\HelloWorldProvider.DesignTime.fsproj]
I found out that the issue lied with the ProvidedTypes.fs and ProvidedTypes.fsi files created by the SDK.
The issue was solved for me when I replaced the files with the ones found in 'SDK-dsyme-patch-7' which provided compatibility for different .Net environments which was missing from the original SDK. There might be other differences but this is the one I found and it fixed the problem for me.
The files can be found under '/src/' in the dsyme patch.
The code I am referring to is as follows and has been added twice to the ProvidedTypes.fs:
#if NETSTANDARD
asmName.CultureName <- System.Globalization.CultureInfo.InvariantCulture.Name
#else
asmName.CultureInfo <- System.Globalization.CultureInfo.InvariantCulture
#endif
asmName
I am not aware if there is a new SDK that has solved the problem. But at the time when the question was asked, this is what worked for me.
I absolutely can not understand how it works. I started with a simple one: created framework using "Cocoa Touch Framework" template and add some code to source files. Then using cocoapods I installed some pods to this framework-project. All looks good (maybe not so good actually) and build fine. After that there was an attempt to connect my framework to other xcode project. I did this as follows: just took my test.framework file from Product folder and transferred to another project. At first everything was not bad. The import was successful and I can use my framework-code in another project. But when I run it I have error: dyld: Library not loaded: Reason: image not found. I tried all of the answers to this problem, but nothing helped me.
After that, it was decided to try to connect my framework to other project. This time I got a completely different behavior: namely, I was able to connect the framework, but I could not access the code inside it. I'm completely confused, because I did not change anything. I just did the same with another project.
Please help me. What am I doing wrong?
A related questions:
Can I connect the framework just moving test.framework file into
another project?
For some reason, I should use the approach described above, is there a chance in the theory of success or all that I have done before is not correct?
I tried it a lot with the same result you get , until I posted the problem in Apple forums and they respond with Nested frameworks are not supported in IOS
I am using one third party SDK, where there are some variables declared as
I have clean and build the project and also erased the derived data, still i'm getting this error.
How to get rid off this issue?
Finally, I have found were I am wrong,
I have done a stupid thing that I installed a SDK through cocoapods
and also used the same SDK by drag and drop, so the same properties repeated twice in my code leads to this error.
Thank you for your suggestions.
I have an iOS project in Xcode. It contains a load of linked libraries including GoogleInteractiveMediaAds.framework as well as an internal player library that I believe is also linked against this framework. Both are also embedded binaries.
The project compiles just fine but at runtime I get the following error:
Class GAD_GTMStringEncoding is implemented in both
/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds
and APP_PATH. One of the two will be used. Which one is undefined.
On simulator the app works as expected every time despite this warning - I get the pre-roll, mid-roll and post-roll ads that I'm expecting. Every time. On device it's a different story with the ads sometimes working and sometimes not. I'm aware that the above issue results in different behaviour on different targets and I suspect this conflict is to blame for the broken functionality on devices.
Solutions I've found here on SO suggest either changing the namespaces or removing the linkage from either my app or the library that I'm linking against. The problem is, if I remove the embedded binary in my project then it fails to compile:
dyld: Library not loaded:
#rpath/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds
Referenced from: APP_PATH
Reason: image not found
(lldb)
I've seen a few people suggest what would be removing the linkage from the app and using the player's internal instance (where I then have to hope that the player is compiled against the version that I need), but how on earth do you do that? And would that even work in this case?
Also, is there a way to find out for sure where this other instance of GoogleInteractiveMediaAds.framework is coming from? I'm only assuming that it's inside the internal player library but I don't know for sure as I don't have the source. The error message just provides me with the path to the compiled app which is of little help since there's like 30 linked libraries inside it.
Thanks in advance.
After initially insisting that the issue was somewhere in our code, the Google team responsible for this framework were eventually forced to admit (after we provided a sample app) that it was a problem with their code and not ours. It was resolved in an update.