No, it doesn’t always look right. It often looks wrong on the non-retina display, especially for smaller canvases. You just can’t cram two pixels into one algorithmically and get the same result as using an image designed for the lower resolution. Why do you think that Apple (and all developers) goes to all the trouble to maintain two sets of graphics for each image? This “trick” has been discussed on the forum before, here’s one thread
[quote=245487:@Jonathan Ashwell]I’m using this method to determine if my app is running on a retina display.
Declare Function BackingScaleFactor Lib "AppKit" Selector "backingScaleFactor" (target As WindowPtr) As Double
Return BackingScaleFactor(w)
If the returned value is > 1 it’s retina.
But I’m finding that on a new 5K iMac running El Capitan the value returned is always 1. Is there a problem with the Declare?[/quote]
From experience, going down this route leads to suffering, suffering leads to anger and anger leads to the dark side.
Certain members keep flashing this declare, and even Xojo’s doc suggest using this declare (<https://xojo.com/issue/34924>) whilst Apple, actually recommend against it.
I wrote the Retina Kit because of all the troubles that I had after trying to ‘hack’ my way through getting a correct Retina interface. It uses the same APIs as apps built with Objective-C and Swift, making it virtually invisible and worry free. You can download a trial version http://www.ohanaware.com/retinakit/
P.S. The Feedback case also includes the Apple recommend replacement for BackingScaleFactor (but not all the functions in the Retina Kit).
The good news is that 2016r1 will have built-in retina support that will make this a lot easier. I highly recommend anybody in the beta program to try it out as soon as the first beta comes out so that we can catch any design issues or bugs.
Does that mean I’m now depreciated?
developer: Sam Rowlands - depreciated_Xojo_2015r1
@Michel
EC, using macOSlibrary ,and wrapping with AppWrapper:
if self.ScalingFactor = 2 then
msgbox “2”
end if
So, no issue at this end.
[quote=245657:@Sam Rowlands]Does that mean I’m now depreciated?
developer: Sam Rowlands - depreciated_Xojo_2015r1[/quote]
Ugh, it’ll take me a while until I get used to this whole “2016” thing.
Not depreciated… deprecated… but appreciated 
Note: This may be useful or useless, I do not know.
.debug application (created when you run your project in the IDE have a plist file. Beside reading it, I do not know what one can do with it.
I believe Retina Kit still has some way to go, as a number of users have not upgraded even to 2015Rx, some are still using RB, and something tells me they may not get to 2016R1 right away.
Besides, and that may be total speculation on my part, but chances are even when 2016R1 will show support for Retina, there could be areas where a third party support remains necessary.
Reading your question right now, it might be already answered: I am using Sams’ Retina/ AppWrapper scripts. Solid piece of work, never have had problems in El Cap or in Mac App Store with them. So I strongly suggest to stick to Sam. 
Wait we’re in 2016!
Thanks Dave 
[quote=245677:@Michel Bujardet]I believe Retina Kit still has some way to go, as a number of users have not upgraded even to 2015Rx, some are still using RB, and something tells me they may not get to 2016R1 right away.
Besides, and that may be total speculation on my part, but chances are even when 2016R1 will show support for Retina, there could be areas where a third party support remains necessary.[/quote]
Thanks Michel; I guess we’ll have to wait and see, but first I gotta get into 2016!
Its your apps preferences. On a Mac, you can write and read it via NSUSerDefaults. Instead of the shell script above you can also write a boolean value true to the NSHighResolutionCapable key to the UserDefaults. The same is true for other keys like appNapDiasabled. The preferences file works the same for a debug- and the final app, so yes, you can use it during debug phase too.
Technically the shell script does the same: It writes into the apps defaults which are stored in a plist file.
BTW, the main drawback in using only the high-res image and scaling it down on non-Retina screens seems to be the time it takes to scale when you the the graphics objects renderQuality to High. The result is usually very good, much better than a simple resize in Photoshop. The reason Apple doesnt use this setting as default is you buy the faster design time by putting much more load on the project in runtime, which is especially bad on mobile devices. And, of course, in some cases you can encounter artifacts you wouldnt have on a manually optimized low-res image. This might especially be true where the image contains text which is often designed a bit differently (or was it only in PostScript times? Help, Michel!) for smaller sizes = resolutions.
By using two (or on iOS three) differently resolved images, on the first occasion the necessary image version is cached and available instantaneously whenever you load the same image, which if you use a lot of custom images on your UI can make the difference between a fluid and a rather laggy interface.
Tools like Affinity Designer which use vector images and can render them to different PNG sizes with one click help you to forget you design twice the number of images.
You can also use PDF files as in-app graphics, these being vector render nicely under various resolutions.
Is this the recommended file format for using Retina-capable graphics?
Its one of the formats thats usable but it ONLY works for OS X so if you need hidpi in a cross platform way they’re not that useful
There are 3 recommend ways:
#1 Use vector if you can.
#2 use multiple PNGs.
#3 use a multi-image tiff.
For the later two formats, check out my ICNSmini, it can create the multiple reps and compress them at the same time.