Please allow nativeNum FIT fields to override native fields in Garmin Connect

> They just want our money

Also, water is wet and the sky is blue

> Garmin favors and allows only THEIR app native fields it does not allow SwimSports to be published across to Strava o

The current behaviour described in this feature request doesn't prevent Strava from using nativeNum FIT fields.

As a matter of fact, Strava will accept power as a CIQ nativeNum FIT field (e.g. when Stryd Zones writes it), as long as actual native power hasn't also been written. (Native power always takes precedence over CIQ nativeNum power).

If Strava doesn't accept distance (for example) as a nativeNum field for swimming activities, then you will have to take that up with Strava. If the data is there, it's Strava's choice to accept it or not.

Even if Garmin fulfilled this feature request, it would not mean that Strava (or any other 3rd party site) would automatically start using nativeNum fields in favour of actual native fields. That would be additional work on their end. Nothing in the current behaviour prevents them from doing so, and nothing in this feature request would help to do so.

> They just want our money

Also, water is wet and the sky is blue

> Garmin favors and allows only THEIR app native fields it does not allow SwimSports to be published across to Strava o

The current behaviour described in this feature request doesn't prevent Strava from using nativeNum FIT fields.

As a matter of fact, Strava will accept power as a CIQ nativeNum FIT field (e.g. when Stryd Zones writes it), as long as actual native power hasn't also been written. (Native power always takes precedence over CIQ nativeNum power).

If Strava doesn't accept distance (for example) as a nativeNum field for swimming activities, then you will have to take that up with Strava. If the data is there, it's Strava's choice to accept it or not.

Even if Garmin fulfilled this feature request, it would not mean that Strava (or any other 3rd party site) would automatically start using nativeNum fields in favour of actual native fields. That would be additional work on their end. Nothing in the current behaviour prevents them from doing so, and nothing in this feature request would help to do so.