Vivoactive 3 doesn't support BLE, but manifest file allows the combination to be selected

I had a user with a 645 (not music) asking if he could test the data field - unfortunately it really doesn't work on the real device either. So it matches the simulator.

I had a user with a 645 (not music) asking if he could test the data field - unfortunately it really doesn't work on the real device either. So it matches the simulator.

One thing to understand is that app migration can have issues based on the app itself and that's why there's an option to disable it on an app by app basis (I have it off on a number of things.)

The 23x/735 was interesting because the 23x was ciq1 and the 735, ciq2.  They had the same basics (screen shape and size, etc), but if a 735 variant was added, things could be auto migrated to it from the 23x which was a problem.  The va3 and s60 was another case where overall, CIQ was the same, but the S60 doesn't have a baro, and things could get auto-migrated to the S60 that depended on a baro.

There's no need for an extra flag (you'd need to add a whole bunch for similar situations with other things.).  All it takes is ensuring that a target works correctly in the sim when you add it to the manifest, and will can depend very much on the app itself and how it was written..  Tricks you learn over time.

Yep I realise now how the current flag works That's why I was suggesting a new flag instead of modifying the current one.

But how does App Migration in the store settings work when it says: "Allow the app store to add support for newly compatible devices?" When it can't know what devices are compatible with an app? Maybe a new device (e.g. 255) gets released in the future which doesn't support BLE, and a 655 gets released which does support BLE (and a 655 music which doesn't!). How would the app store know that my particular app will crash if BLE isn't supported and which devices to allow migration to. Or does App Migration never actually occur in reality?

Another example is the SensorHistory permission.  If the export process only built for targets with SensorHistory, you couldn't support things like Edge devices that don't have Sensor History, even though the app runs just fine on edge devices.  That's a case in a number of my apps.

The developer knows what targets are supported, and the very best the export process can do is guess.  If you app doesn't support a specific target, don't include that target in your manifest.  It's really simple for the developer to know.

The "flag" is a permission, and it's something an app "may" need.  Consider this - you set background permission on a watch face but your targets include older ones that don't have backgroundiing.  The app builds and runs just fine on older devices, but the watch face doesn't make use of a background process.

You really don't want to restrict targets based on a permission that an app may actually use.

The simple, easiest solution is don't include targets for apps that require a specific function if that target doesn't have that specific function.

Thinking about it the current BLE flag in the manifest is for "uses BLE" - maybe it would be useful to also have a "requires BLE" flag? I don't know how the current system works for automatically releasing apps for new future devices if they are compatible, but having a "requires BLE" flag seems like it would certainly help in that scenario.