I'm trying to make a screen saver using the cocoa screensaver framework. The project builds fine and generates the .saver file, but when I try to run it in the preferences test window, it displays the error message:
"You cannot use the screen saver with this version of Mac OSX. Please contact the vendor to get a newer version of the screen saver"
I have the xcode settings to Release | x86_64, and I am running OSX 10.6.6 on a 2.4 GHz Intel Core i5 Macbook Pro. I've searched around online, and most of the solutions to this error message seem addressed to making sure the build is 64-bit, which the x86_64 setting should indeed take care of. I am trying to play a QT movie in the screensaver, if that makes any difference.
I am at a loss, any help would be appreciated. Thank you.
Make sure the Garbage Collector settings is set to at least "Supported". A lot of hosted frameworks will now require this setting - for instance Preference Panels need to be at least at "Supported" or it will cause System Preferences to restart its self (as with 32bit)
Related
I'm developing an app in objective-c using Xcode 8. (because old computer)
Currently, my only options for the NSView's appearance are (Default) Aqua, and Aqua.
However, in SDKs starting in 10.14, they've included Mojave's Dark Aqua.
I've added the 10.15 SDK (https://github.com/phracker/MacOSX-SDKs/releases) and added it to XCode (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/) and set the project SDK to it. However, I still don't get the choice to use Dark Aqua.
What should I do? (Alternatively, I could use https://github.com/insidegui/AssetCatalogTinkerer, but when I build it [as it does not include a build with it], I get errors when using the .car it generates.)
With hope,
Conrad
What should I do?
Get yourself a VM app (e.g. VMWare Fusion, Virtual Box, Parallels) and build yourself a Mojave VM then develop & test your app within that.
You will pay a small performance penalty, that's an objective observation of course and YMMV – especially if you're doing heavy graphics – but developing in a VM is quite doable. Indeed when Apple release 10.16 betas, you want to get your software ready, and you don't have a spare machine, then installing it on a VM is far safer than risking it on your primary machine.
HTH
after reading the apple SDK guide
https://developer.apple.com/library/mac/#documentation/developertools/conceptual/cross_development/Overview/overview.html
I'm still confused of how to make the mac app backward compatible & how to test them properly
I have an app, I run it and tested it on Mountain Lion 10.8 without any problem, however I want to make this app backward compatible so that other users can run it on a mac 10.6 - 10.7 machine.
I have an apple developer id and I can download the old versions of 10.7 and 10.6, but the problem is, I have a 2011 macbook air which is currently running 10.8, and that's the only apple machine that I have. Can I test the 10.7 and 10.6 by using vmware or parallels?
in my project settings, I set the target deployment to 10.6 (as I want 10.6 users to run my app), but should I set my SDK to 10.8 or 10.7? if I set the SDK to 10.8 but having the target deployment set to 10.6, if I fix all the xcode warnings will it run successfully on 10.6??
from the SDK drop down, I can only set to 10.8 or 10.7, but 10.6 is missing, how do I fix that?
thanks in advance
I develop on a 10.8 box and support back to 10.5. Just a couple of months ago we dropped 10.4 PPC support, and I'm still cleaning out some of the 10.2-specific code. This may get a little rant-y, but I've been doing old versions for a long time. I have some opinions on the matter.
No matter what Apple says in their docs, if you want to support 10.6, then build with the 10.6 SDK. Do not rely on distribution target.
I have had this discussion with the Xcode engineers, and while they hold to Apple's party line that you should always build with the latest SDK, they also acknowledge that it's generally insane to do so. If you build against the 10.8 SDK and mark your deployment target at 10.6, you will get no warnings for using methods that do not exist on 10.6. The only way you will discover that you've used a nonexistent method is that it might give you strange bugs when run on 10.6. That's insane.
Remember, OS X doesn't crash when you send an unknown selector. It just aborts the current runloop. So the bugs are even harder to track down then on iOS, where it crashes the app.
Sure, you can do weak linking. Talk about dangerous.... Yes, there are a few times this is useful, but the compiler gives you no warning if you don't do it correctly. If I'm going to do weak linking like this, I go the other way, linking against the old SDK and copying the new function's prototype into my implementation. That way I have documentation of every function I think I'm going to weak-link.
Download the old SDKs and symlink them into your Xcode distribution.
Guard them jealously. Apple will try to delete them every time you upgrade Xcode. Make your own copies and stick them in /SDKs or somewhere else away from Xcode. I provide a script called fix-xcode to manage the symlinks automatically. Am I bitter at Apple for their relentless insistance on deleting my old SDKs? Yes, I am.
You can run 10.6 Server in a VM legally. You can run 10.7+ Desktop in a VM legally. These are good ways to test your code.
Or you can do what I do and have a small pile of old MacBooks each with two or three partitions on them that you reboot all the time.
Now that 10.7 comes from App Store, it's a little harder to make VMs. My strong recommendation is to snapshot your image immediately after install, and make a clean backup copy of it. You'll want to be able to clone that image from time to time when you need to get back to a "raw" machine.
Get in the habit of squirreling away SDKs as they come out. 10.8 will be old some day. You might as well make a copy now while it's easy.
Whether you support individual dot-releases or not, it can be very helpful to keep around the upgrade packages for individual dot releases. When you encounter customers running non-current releases, it's nice to be able to check whether an "unreproducible" bug in fact is easily reproducible on their specific version. Whether this is worth it or not depends heavily on your product and customers. It was a life-saver for me when 10.4.11 made major changes to WebKit during a dot release...
Invest in a small NAS or a big external USB drive (though I've had trouble with those failing when used extensively, so I prefer a RAID). You'll need the space. You want to hold onto lots of VMs and lots of SDKs and sometimes even old versions of Xcode.
Adding to Rob Napier's great in-depth answer:
To use an old SDK, put the SDK (or a symlink) to it here:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
With XCode 7.3 or later, you need you to open this file and change "MinimumSDKVersion" (otherwise XCode will refuse to use the old SDK):
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist
You can install multiple versions of Mac OS on a single machine, booting between each.
The SDK should be the latest (10.8).
See 2.
One alternative to 1 that I've considered (I am in the same boat) is to create a Snow Leopard Hackintosh using an old PC and just installing Lion and Mountain Lion on my MBP.
You need to do these settings :
1.Set the Base SDK to Current version of Mac (ex. 10.7)
2.Set the Deployment SDK to older version (ex.1.4)
Is there a way for me to create an Applescript as a run only application that would work on 10.5 and above?
I am running Lion. Whenever I save my script as a run only application it does not work with 10.5 and gives me a "does not work with this architecture" error.
The weird thing is that I saved it once and successfully launched it on the 10.5 machine but when I went to edit it and re-save it did not work anymore.
Thx
You can't and Apple's documentation isn't clear. My experience, based on a lot of trial and error, has been that when saving an Applescript as an application, that it has to be saved in the target environment, just as though you were targeting a specific OS when compiling for Xcode. In the past, I have had to make separate apps for 10.6 and 10.7 as well as PowerPC and Intel with the exact same code inside.
After some upgrades to Xcode i am experiencing a strange situation:
when i start instruments to profile my apps (both on ios or mac) it works well with all the instruments (for example cpu monitor, or i/o monitors) but i cannot use the memory management ones: Allocations, Leaks, Object graph. If i start the profile window by clicking on leaks it just opens an empty "Instruments document", and if i drag them from the library panel they don't show up, but all the others do. Anybody is experiencing this behaviour? Maybe some missing library?
My Xcode version is "Version 4.2 Build 4D199" and my instruments version is "Version 4.2 (4233)"
I solved this by updating Xcode to version 4.2.1 (Build 4D502).
One thing that I noticed, since I've installed Xcode using the Mac App Store, was that the update process behaves like the install - it downloads an app called "Install Xcode" which you run to install/update. So be sure to run the installation app after first time download or update.
I recently started creating applications for mobile devices and have successfully completed an application for the iPhone. I am now turning my attention to the Blackberry but haven't been able to find a convincing article or website that states that it can be done or a tutorial on how to do so. Can Blackberry apps be developed on Mac OS X? If yes, how do I go about doing so? Can anyone please point me in the right direction as I only have access to a Mac and really want to get this project on the road. Thanks in advance for your help.
UPDATE:
RIM has released a MacOS Eclipse plug-in for Blackberry Development: http://na.blackberry.com/eng/developers/javaappdev/macosx.jsp
While there is no built-in simulator, the plug-in DOES support USB tethered device debugging for the Torch 9800 handhelds. I plan to get one; they are ~$499 w/no contract. With a Torch and the new plug-in, Blackberry development is possible without using a VM. (Finally!)
PREVIOUS POST:
Building on MacOS works well once you set it up. I've had less luck with the simulator. On the whole though, being able to run Eclipse natively in MacOS and flip to a Windows VM only for debugging is a big win in my book.
You can get a MacOS version of preverify (see link below for details). I do my development with Eclipse on MacOS X and use Ant to build BB apps.
This blog is excellent and has many of the details to get you started:
http://www.azizuysal.com/2009/07/blackberry-development-on-mac-os-x.html (original link is dead. The "wayback machine" provides us with the original text content, but images and styling are lost to the sands of time. Still worth a read.)
The tricky part is getting the simulator to work. There is a Wine-based work-around, but on my computer, while the simulator was able to run under Wine, the LCD output was scrambled.
Currently, I build COD files from Mac, and my Ant build process drops them into a directory that is shared with a WinXP VM. I can run the simulator stand-alone in this VM. Debugging is also possible by installing Eclipse inside WinXP and pointing the debug configuration it at the source directories.
I've actually got a bit more magic. I enabled some of the Java 1.5 features by compiling against 1.5 and then translating the bytecode to 1.3 prior to the preverify script. (Blackberry only speaks a barbaric 1.3 java, flashback to circa 1992). It's not a silver bullet as some features still don't work, but it does cut down on the need to make everything an untyped Object reference.
Lately, I've been working on a x-platform framework to allow me to write app code once and build against both Android and Blackberry (both are Java). The Android part was easy. It's just a bitch to debug anything in Blackberry. Someone working at RIM decided that Blackberry didn't need to keep Exception stack traces unless there was a catch(Throwable), and then they could do something bizarre, non-standard, and undocumented (catching Throwable behaves weird). I've only kinda-sorta figured out a hack to get stack traces using JavaLoader.exe without breaking into the debugger, and it's barely worth it.
p.s., I now do x-platform development with a single code-base targeting Android, Blackberry, and Desktop. Desktop is great for testing app functionality, with very little Blackberry on-device testing needed once features work in the desktop 'simulator' (a Swing GUI built for debugging our games).
Even though certain components of the RIM development platform are java-based, such as the JDE - other components such as the preverifier and device simulators are implemented as native Windows executables.
Basically, the easiest way to do it is to install Windows on your Mac using Bootcamp or Parallels and run inside a real Windows environment on your Mac.
However, there are other "hackier" ways to do it using Wine, MacPorts, and a number of other tools - as an example see this blog post