I've been using the excellent mergBLE succesfully on iOS; but I want to use it on desktop (OS X) as well. The package includes a .bundle as well as .lcext; but the instructions concentrate on iOS. I've got the bundle theoretically loading (per the externalpackages of stack "Home") in LC 6.6.2 (but not in LC 7.1, probably a separate problem). But using the mergBLEInitialize command, in the IDE on OS X, throws a "can't find handler" error.
Red herring. The problem is that I was running this on MacOS X 10.8.5; mergBLE requires a newer version of CoreBluetooth than is included in that version of OS X. So it doesn't load properly - LC notes that it loaded it - hence the presence in "the externals" but doesn't report the fact that it didn't complete loading. I found this by looking at the Console while LC launched - which reported the failure to load the CoreBluetooth library referenced from mergBLE.
Related
I'm working on an app that, due to restrictions that are beyond my control, is being built as an x86_64 app using an outdated macOS SDK (in this case the macOS 10.15 SDK).
It runs fine on an Apple Silicon mac using Rosetta 2, but the app needs to get the current version of macOS, and the available APIs lie to it under these conditions, consistently reporting the version is 10.16 when really it should be macOS 11.x or 12.x.
In other circumstances where the system API lies, I've been able to get the real info using sysctl, but in this case calling sysctlbyname("kern.osproductversion", ...) still lies to my app and reports 10.16.
How can I get the true version of macOS under these circumstances?
The only solution I've found so far is to launch the sysctl command line utility as a separate process and use it to query the system version. Here's a C++ implementation using Qt:
QProcess *p = new QProcess;
p->setProgram("/usr/sbin/sysctl");
p->setArguments({"-b", "kern.osproductversion"});
p->start();
if (!p->waitForFinished(2000)) {
// handle unlikely error here
}
QByteArray systemVersion = p->readAllStandardOutput();
On the bright side, this only ever needs to be executed once as the system version presumably won't change over the course of a process's life. Nonetheless I'll leave this question open in case someone has a better solution.
I have problems with running OSX applications with XCode. Sometimes (about 30% of the time) the application doesn't start and "XCode cannot run using the selected / Choose a destination with a supported architecture in order to run on this system." message is displayed instead.
This is NOT a duplicate of other questions, because this is not a problem with a project file (in such case the app would never run, and in my case the behaviour is random - sometimes it starts, sometimes not). This only happens with OSX applications.
XCode 5.0.2 (5A3005), OSX 10.9.3, but I had this problem since the first version of XCode 5 on both OSX 10.8 and 10.9.
Have you ever encountered similar issue?
Go ahead and attempt to check these settings: changing architecture settings. I have a feeling that sometimes your running on the 32 bit sim and sometimes the 64 bit sim so your running into the issue below.
Here's another link referencing how to change the standard Architecture for OSX: Changing OSX Architecture and ensure you're no longer set to be using gcc and only using LLVM: Other adjustments to bundle plist
I am developing an app using Xcode 4.6 on an OS X 10.8 machine. The app deployment target is set to 10.6, which is what we need to support. But when I archive the app (compile, link and embed resources+frameworks) and deploy (aka copy) it to the 10.6 test machine, it crashes with a generic Segmentation fault. It works fine on 10.7.
I can't compile the project in Xcode on the older Mac because the app is built using the newer compiler (it uses ARC, implicit property synthesis, the new objective-c literal syntax, etc.). It also wouldn't type check because the base SDK is 10.8 and it references some 10.8 tokens which the compiler on the 10.6 machine doesn't know about.
Any suggestions on how to go about debugging the app?
I'm not affiliated with this company/software in any way, but Deploymate is a paid app which can scan your app for SDK usage and tell you when you are calling selectors and APIs that are unavailable on older OS versions. This can help you track down exceptions and crashes relating to API usage.
You are very likely using one or more 10.7+ APIs that crash on 10.6. With a 10.8 target SDK you allow all the calls to function that are available in that SDK. However apps are bound late so this doesn't crash when you do not actually call those functions. You need an explicit check similar to this (here for the full screen feature):
#if MAC_OS_X_VERSION_MAX_ALLOWED > MAC_OS_X_VERSION_10_6
if (runningOnLionOrLater) {
[mainWindow setCollectionBehavior: NSWindowCollectionBehaviorFullScreenPrimary];
[toggleFullscreenItem setHidden: NO];
}
#endif
One way to determine the current version is:
int macVersion;
if (Gestalt(gestaltSystemVersion, &macVersion) == noErr) {
runningOnLionOrLater = macVersion > MAC_OS_X_VERSION_10_6;
}
For debugging the problematic calls simply set the base SDK to 10.6 and XCode should mark those functions that are not available there.
While there is no real good solution to this (I've seen simply different behaviors on different macOS versions) and no way to simply simulate an older macOS version, if you have a machine to spare:
It is possible to use an external HD, partition it and install different macOS versions. They all can be bootable and it's a matter (pain) of restarting the machine for every OS version.
I was developing an application using xcode 4 to target snow leopard (10.6)
Now, nearly the end of the development, I've been asked to support 10.5+.
I have set the Mac OS deployment target to 10.5 and compiled.
The compiler (LLVM 2.0) and linker seems to be happy with the change
but I came across a feature I've used from NSWindow (isOnActiveSpace) which is states as AVAILABLE_MAC_OS_X_VERSION_10_6_AND_LATER
This I understand states that it won't work (throw exception?) in 10.5 but no warning were raised when building.
I currently don't have a leopard installation and it will take our QA some time to arrange a computer for that, so in your experience, what should I do next? how can I go over the code and make sure that all the APIs I've used are in fact safe for 10.5?
Set MAC_OS_X_VERSION_MAX_ALLOWED to 1050 and see what symbols disappear. More info in TN2064.
I've been building a basic Cocoa application with Core Data and Interface Builder, and no extra coding, frameworks, or header files. I sent it to someone to test on their machine (a last-gen G5 iMac), and they got a message saying that their machine couldn't run it. I discovered the switch to compile for PPC, so I built a PPC version of the application to try out, and that produced the following error message:
You cannot use this version of Application on this version of Mac OS X.
I'm running Xcode 3.2.1, Interface Builder 3.2.1, and OS 10.6.2. The conversation with my tester was a bit confusing; at first it sounded like she only had Tiger on her machine, saying Leopard was incompatible (I corrected and said that Leopard should be, it's Snow Leopard that isn't), and then by the end of the conversation she was about certain that her machine was running Leopard, but had already shut it off by then. So I'm not sure which version of OS X is on the offending iMac, but it's the latest version of either 10.4.11 or 10.5.8 (the tester is in a remote location, so I can't verify personally at the moment).
What can I tweak to try and improve compatibility on my tester's machine?
If they're seeing that message, it's most likely because your app has the LSMinimumSystemVersion key (Minimum system version) set in the Info.plist. You should take this key out or set it to the actual the minimum OS X version you support.
Once you do this, you may well run into the next problem. (Probably a dynamic linker error as a result of using a framework or API that didn't yet exist on 10.4 or 10.5.)
The main problem here is that you're sending it out to a system where you haven't actually tried it. If you plan to support 10.4, 10.5, or both, I highly recommend that you find a spare hard drive, partition it up, and install 10.4.11 and 10.5.8. There are many issues that will crop up on older OS's and if you haven't tried it yourself, it's unlikely it will work smoothly on the first try.