getting device info details

also is there a way to know which API is running in the device 
same reason, i don't want to crash because the API does't support.

storage.setValue

for example 

You're asking things the opposite way of how IMHO most of us do. You decide which devices you want to support. The decision can be based on many different things, i.e: what devices you have, how big screen your app needs, do you want to support rectangle displays, is there a feature you have to have (so you can't support devices with lower CIQ), how much time you want to spend on developing the views, what technique you use to draw your views (i.e xmls that need support for new display sizes vs dc draw functions, where if you design it cleverly it'll easily work on any future display that is rectangle or round). etc

In the SDK docs you can see for each function, class, const from which CIQ level it's available and where applicable also on which devices. You can also use the "has" check to see in your code if the device your app runs on has a specific feature (note that the has check can be evaluated either at compile or run time depending on compiler parameters)

Thanks,
I understand,  I developed my WF the same way. I made sure it worked on my devices and then uploaded it.
It’s just a free, simple watchface that others can benefit from.

Most of the functionality is supported by 1.4.x, and I can live without persistent storage if the watch doesn’t support it. The same goes for loading settings: (if the documentation says to use getValue instead of getProperty, I’d rather follow the recommended approach whenever possible, and only fall back to the deprecated one when it’s the only option).

In other words, my case is one where I’d rather not clutter the CIQ store with multiple versions of essentially the same app, when a simple if statement in my code can handle all the cases. Does that make sense?

Yes. I also prefer 1 app for another reason: when all the downloads count towards the same app, then it gets higher in the store listing.

I even have different functionality depending on capabilities or even just the memory available on different devices. In my apps I also have a user friendly approach to the settings where possible. I only show the relevant settings (unlike some apps that have the same settings for all devices and in some they write something like : "Feature X (only on devices with barometer) " In my app I would not have this in the xml for devices w/o baro.

If there is no way to get the API in the device
For now I am doing this:
I have a function that check the Width and height and if they are
208 x 208
205 x 148
218 x 218
215 x 180

then i treat it as old API

which filters the problematic watches but also filters some new watches that could benefit...

but solves the problem for the most part

I would paste the function but the foum thinks it's too much formatting

Again. This doesn't seem to be the best way. It's certainly not future proof, and maybe not even true for all existing devices. Instead check for the feature like: 

if (Toybox has Storage) {

   use Storage.getValue(...)

} else {

   use the old API

}

There are other good solutions as well. I like to do it mostly in jungle, especially for datafields where the memory is tight. I care less about code size for others.

You can get the CIQ version at runtime, but as flocsy pointed out, the preferred way to do things is to use has checks (when possible).

If you do want the CIQ version at runtime, look at DeviceSettings.monkeyVersion.

From the linked doc:

using Toybox.System;
var mySettings = System.getDeviceSettings();
var version = mySettings.monkeyVersion;
var versionString = Lang.format("$1$.$2$.$3$", version);
System.println(versionString); //e.g. 2.2.5

There are certain differences which may not be able to be *directly* ascertained via has checks, like certain differences in device behaviour between CIQ 3 and CIQ 4 with respect to widgets/glances. (I'm not going to into this, as it's an esoteric edge case, and it may not be a good example anyway.)

There are also cases where you have to be smart about how you use has checks.

For example, AppBase.getProperty is deprecated, but you may be tempted to do something like this:

if (AppBase has :getProperty) {
  // use the old API: AppBase getProperty() (deprecated, except for CIQ < 2.4.0)
} else if (Application has :Properties) {
  // use the new API: Application.Properties.getValue()
}

This isn't optimal, as the CIQ team has been trying to remove AppBase.getProperty/setProperty for years, but devs won't stop using them, so they leave the functions in even though they're deprecated. In this admittedly bad example, the code assumes that if the old API exists, it's ok to use it.

This would be better (check for the new API first, then fall back to the old API):

if (Application has :Properties) {
  // use Application.Properties.getValue()
} else {
  // use AppBase getProperty() (deprecated, except for CIQ < 2.4.0)
}

Ofc this isn't a great example, as probably nobody would write the first bit of code on purpose. Anyone who's still using AppBase.get/setProperty on newer devices is probably doing so unconditionally, either unintentionally or on purpose (because they like certain things about how AppBase.get/setProperty work).