I borrowed my friends Iphone 4 and had a go with String. Not with the SDK (I have no mac) but just the sample app.
I am really impressed by the speed of marker detection when it comes into view. It is basically instantaneous with no visible delay. Marker detection is faster then with QCAR frame markers. and the frame markers are in turn faster then the QCAR image targets. The String jitter is about the same as with QCAR frame markers. Jitter seems to be worse with image targets then with frame markers. With String, you cannot zoom in too much as the entire marker must remain in view. So you can only compare String to QCAR frame markers, and not with image targets.
String outperforms QCAR frame markers. However, String is ridiculously expensive. So QCAR only being slightly slower but free, I would still rule in favor of QCAR.
I purchased the String AR SDK and had a go with it. I'll compare the QCAR Unity plugin vs the String AR Unity plugin.
Both with QCAR and String quite easy. Both contain sample projects for Unity. The latest update from String doesn't require the Xcode modifications as well.
String doesn't need to download camera settings from the web while QCAR does. This shouldn't be too much of an issue normally but this QCAR "feature" created many headaches for me due to a lack of internet connection at times, or the OSX beta version not willing to download the settings at all.
Preview on PC/Mac:
String has a camera preview feature which enables you to see the augmented reality graphics on your mac instead of the mobile device. Very neat. It allows you to develop apps much faster. Especially debugging is much easier. I have yet to get it to work on my Hackintosh though.
With String, you don't need to upload your markers to an online server to have it processed. You just copy a png to the Unity project folder and the local software takes care of the marker recognition.
With String, the speed of a marker being recognized after it has been lost is very, very fast. In fact, it seems to be instantaneous while there is a visible delay with QCAR.
String has not much latency between moving the physical camera and the entire scene (camera picture plus augmented 3d content) moving with it. It is quite snappy. QCAR has a visible delay. Low latency is very important for a convincing AR scene. And the problem isn't with the android phone because the build-in camera-snapshot mode has no visible delay between moving the camera and the screen moving with it.
With String, the marker is still being tracked during rapid camera movement. QCAR looses the marker easily with rapid camera movements. This might have to do with the camera quality though, as camera movement creates blur if the exposure time is too long. Not sure what is causing the difference... And no documentation from both QCAR or String on how to change the exposure time, if it is possible at all...
With String, the rotational jitter is much less then with QCAR. This is most noticeable for large objects in relation to the marker, or when objects are placed far away from the marker. The latest QCAR update fixes this a bit, but String is still more stable at tracking rotation.
Multiple marker coordinates:
QCAR has the ability to have multiple markers in world space while if you want to use multiple markers with String, you can only have their position and orientation relative to the camera. With String, this creates issues if you want to use multiple markers with physics enabled. Your content will be flying all over the place as the world is rotated around the camera. But QCAR has it's own issues with this. The first marker tracked will be the world center so you will have to keep track of the gravity vector as well. It depends what you are using it for I guess.
With QCAR it is easier to detect whether a certain marker is visible or not. With String, this requires some code which is undocumented.
QCAR supports partially occluded markers (image targets) while the markers from String have to be (nearly) fully in view.
So in my opinion, technology wise String is superior. However. As I said before, String is very, very expensive if you want to publish you work. But this is not the main problem. The main problem is that you have to pay every year for your license. So you better make sure you have enough people buying your app every year, otherwise you will make a hefty loss. Or make people pay every year to use your app, but you are going to be very unpopular if you do that. And it creates all sorts of licensing issues, like what happens if you cancel your subscription. Do the people who already purchased your app loose their right to use the app?
Because of this silly licensing system, I would still prefer to use QCAR. Mobile devices are becoming faster every year so the speed advantage String has, will soon disappear I believe. And the rotational jitter issue with QCAR will be resolved at some point I am sure.