I am trying to compile a "WebViewGold" ios app on an M1 processor MacBook Pro, using XCode latest (13.4.1) version.
I have greatly struggled to find a solution to those XCode error codes.
I have browsed related answers in threads like: building for iOS Simulator, but linking in object file built for iOS, https://stackoverflow.com/questions/32687105/framework-not-found-in-xcode,https://stackoverflow.com/questions/9458739/ld-warning-directory-not-found-for-option.
Nothing mentioned in the above answers worked!
Any idea about what I should do?
There is a possible, very simple solution provided by this answer.
Basically, freshly upgraded versions of XCode (for example, 13.4.1) running on Apple Silicon-powered Macs (like my M1 MacBook Pro), have components that cannot properly use/output the appropriate object files in all the output platform combinations you need.
This leads to some "interesting" issues and error message cross-overs that find "almost correct" answers on StackOverflow. Hence the many suggestions to exclude "arm64" platform and similar from the build options.
The simple answer to all of that is... to just run XCode with Rosetta enabled. Rosetta will engage with the components that miss the needed cross-platform capabilities.
Here is an example of how to enable an application to use Rosetta.
You select the app icon, then go to the File menu and select "Get Info".
Then click the "Open using Rosetta" checkbox.
It does seem that Build Active Architectures Only = NO is the issue, at least in Debug mode. I can successfully produce a Release archive, so I'd suggest just leaving it alone unless you're trying to debug the Intel version. Try a library, as you can ship the binary that way.
I am new to macOS development and am having a terrible time trying to get my code signed. The documentation to me seems to be horrible.
My specific situation...
I am building a cross-platform app that runs on Linux, Windows, macOS and eventually iOS and Android.
It is a console app that runs as a service or LaunchDaemon
It has a UI served by WebView, http, or console commands depending on the scenario.
It is built with Go 17 in VScode.
I am not using xCode other than the command line tools.
My goal on macOS it to distribute it as a package (pkg) and not as an app.
I have been using MunkiPkg to build it
I am hung up on understanding how the various certificates need to be set up. I have not been able to get a successfully signed package notarized.
Can someone please point me to some documentation that explains how my scenario works? Most of what I found requires it to be built in xCode. And the Apple docs seem mostly to focus on how great their tools are without actually explaining how to use them.
Help!
I'm a new Mac Os user, before I worked on windows.
I'm trying to write programs on pawn, but on mac there is not "real" version on it.
I found on official website that you can you can run the program PAWNO threw Xcode, but I can't do it properly.
I got a error - User Defined Issues, what does it mean and how to fix it?
Thanks.
And link where I found it.
http://www.compuphase.com/pawn/pawn.htm
You are building for a 64-bit Intel architecture but the header file you're using doesn't support that (i386). Try setting your project/target settings for building as a 32-bit application.
As always when Apple updates OS X, the latest XCode 4.4 dumps the older (10.6) SDK and I find myself needing to use the 10.7 SDK (or 10.8 I suppose) and setting my deployment target to 10.6 to maintain compatibility.
I prefer linking to the older SDK because I know that I cannot by mistake introduce calls to APIs that do not yet exist. Something that I found myself doing regularly when I last tried the inverse approach.
What I find myself doing is that I use the code completion feature in XCode to choose the "right" call for a simple class like NSWorkspace, then everything works fine during development, I forget about it and when I release a new version: Kaboum! The whole application explodes on earlier OS X releases at run-time; often in those hard-to-reach places :-)
Or at least this was the situation for me a few years back.
Surely, by now there's a way to either:
making sure you don't introduce API calls that are not yet available in your deployment target even if though they are defined in the SDK
detecting such calls during build or static analysis time
I'm sure I've missed something, somewhere along the line.. Please enlighten me!
Best regards,
Frank
Surely, by now there's a way to either:
making sure you don't introduce API calls that are not yet available
in your deployment target even if though they are defined in the SDK
detecting such calls during build or static analysis time
No there is not. Yes, you should open a radar (bugreport.apple.com) against it. If you like, you can dupe mine: rdar://11985733
Yes, the only viable solution, despite Apple's recommendation, is to copy the old SDKs and link against them.
I spent quite some time talking with the Xcode team about exactly this issue at WWDC 2012. They agreed that it's broken. There is not currently a plan to fix it. Escalating radar's is how we influence Apple on these things.
I'm generally copy SDK from older versions to the newer one so that compiler will blain me if i use something not supported.
Also you can simply look at Quick Help when calling some methods that you are not sure about, like in screenshot you can see that launchApplicationAtURL method is only available from 10.6
I've had this annoying problem on iOS too. It's actually even more annoying on iOS as the user has to sync their device with iTunes and enable crash report sending before the crash report gets sent unlike Mac OS X where you don't need to do all that. Recently, I managed to add a compile-time check for checking APIs against older versions of the SDK. I'll first explain how I did it for iOS first and then try and help you to adapt this technique for Mac OS X. I don't code much for Mac atm so I can only really guide you in the right direction from my experience with iOS but I'll test my suggestions later today once I get back from work and give a definite answer.
So here's what I did for iOS:
I first had to get the older Simulator SDK I wanted to get. I could easily get this by downloading older Xcode 3 (not 4) versions which included the SDK needed.
I next had to install the SDK. This wasn't too hard, so I won't explain much here. But the SDKs are stored in the Packages folder. This folder is clearly visible in earlier Xcode 3 versions but is hidden in later versions. You can easily open it anyway through Terminal. Also, after the change in Xcode 4.3 where the Developer folder moved to within Xcode.app, so I had to install the SDK into a tmp folder and move the SDK into Xcode.app yourself. I would then need to restart Xcode if I had it open.
After that, I duplicated my debug configuration in your project and named it, in my case, something like iOS 4.3 API Check or something like that - doesn't really matter. Then I changed the Base SDK of this new configuration to the old SDK which I installed. The SDK I installed was not listed though so I had to select other and enter, again in my case, iphonesimulator4.3.
Finally, when I needed to check against older versions of the SDK, I changed the configuration for the Run <appname>.app in my project scheme to my iOS 4.3 API Check configuration. And there we go, a compile-time check against iOS 4.3.
As for Mac OS X, I'm sure you can achieve the same goal with this same method. There isn't Simulators for the Mac SDK so I think the regular SDK will work for this. As for getting the older SDK, if you have Xcode 4.2 still installed (after Xcode 4.3 changed it so the Developer folder is within Xcode.app) then you should find the 10.6 SDK there. If you don't, I'd imagine that Apple has a similar thing to iOS where the SDK downloads are available in the Dev Center or somewhere on the internet...
As for setting the Base SDK, if it's not listed then I think the name is MacOSX10.6 or whatever version you are after.
Everything else should be the same, but as mentioned earlier, I'll test this method later today and edit my answer to give a more definite answer but I would imagine this method would work for the Mac SDK.
i also assumed that the compiler will warn me about "too new" API usage for the deployment target OS version. but it turned out that the compiler doesn't warn you about it by default. one of the reasons might be you could still use the new API by checking the availability during runtime with "respondsToSelector:", for example, on a newer OS version even when the deployment target version was older. you would need to add the compiler option -Wpartial-availability which is available on Xcode 7.3+ (to be confirmed) in order to get the "warning: 'something' is partial: introduced in macOS 10.x" warning message.
on macOS 10.12.3 with Xcode 8.2.1:
$ cat foo.m
#include <Foundation/Foundation.h>
BOOL foo()
{
return [#"foo" containsString:#"bar"];
}
$ cc -mmacosx-version-min=10.9 -Wpartial-availability foo.m -c -o foo.o
foo.m:5:20: warning: 'containsString:' is partial: introduced in macOS 10.10 [-Wpartial-availability]
return [#"foo" containsString:#"bar"];
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:132:1: note:
'containsString:' has been explicitly marked partial here
- (BOOL)containsString:(NSString *)str NS_AVAILABLE(10_10, 8_0);
^
foo.m:5:20: note: explicitly redeclare 'containsString:' to silence this warning
return [#"foo" containsString:#"bar"];
^
1 warning generated.
see also: Is there a way for XCode to warn about new API calls?
I check my code by hacking around Availability.h to get the compiler to flag weak-linked symbols as warnings/errors. In my current (Xcode 5/llvm) incarnation, I'm using the code below. It warns whenever I use a symbol introduced in iOS 6.0 or later. I think it's fairly self-explanatory. The macros seem to need updating at each and every SDK update, so tread carefully. Oh, and you loose deprecation warnings too, so I only use this once in a while to double-check my conditional code.
#undef __NSi_6_0
#define __NSi_6_0 deprecated=1.0
#undef __NSi_6_1
#define __NSi_6_1 deprecated=1.0
#undef __NSi_7_0
#define __NSi_7_0 deprecated=1.0
#undef __NSd_6_0
#define __NSd_6_0
#undef __NSd_6_1
#define __NSd_6_1
#undef __NSd_7_0
#define __NSd_7_0
See also http://iphone.m20.nl/wp/2013/10/xcode-5-and-flagging-weak-linked-unavailable-symbols-from-a-newer-sdk/
Since Xcode 9 there is a build setting doing exactly this, turning on the warning -Wunguarded-availability and/or -Wunguarded-availability-new.
The former warns when an API newer than the deployment target is used. The latter only warns when an API introduced newer than macOS 10.13 or iOS 11 is used in a similar manner.
For an existing project, the former is off by default, and the latter is on by default.
This setting is called “unguarded availability” within Xcode’s build settings pane, and you can choose one of Yes, Yes for all versions, or No from the GUI.
For more details, see the WWDC17 session 411, “What's New in LLVM”, https://developer.apple.com/videos/play/wwdc2017/411/ .
I don't have the Apple 79€/year account. In iOS 5.0 and Xcode 4.2.1 I changed SDKSettings.plist ecc... And it works. In iOS 5.1.1 and Xcode 4.3.2 no, I already changed settings ecc but don't work, the app installs on device but crash on launch... How can I run my app on device without crashes? Thanks, and sorry for my english.
I have had this issue before on a jailbroken device. You have a few solutions depending on the exact issue. First you can install app sync in order to allow unsigned code to work on your device if you are not using a valid code signing identity. The second option is to actually get a valid code signing identity along with the provision profile so you can run the application correctly. This involves paying for the developer program so this may not be the best option.
Last is a very common issue with jailbroken devices. Which is that you will receive an error such as "failed to get the task for process xxxxx". This tends to happen a lot with jailbroken devices. This is because Xcode notices you are not using a provision profile that is required to report error logs. All you have to do is launch the application again on the device and everything should work.
This is just Xcode not being able to fully launch your application because of the missing provision profile so it results in a crash. If none of these solutions solve your problem please post a more detailed explanation of the issue you are having.