Any news from this? Im with the same problem.

@wdhilliard If any one of you are dealing with the blue fill color on iOS. here is my workaround.

In node_modules/react-native-maps/lib/ios/AirGoogleMaps/AIRGoogleMapPolygon.m, add this after _polygon = [[AIRGMSPolygon alloc] init];

_polygon.fillColor = [UIColor clearColor];

i just tried circle, it has the same issue

As you might have guessed from the comment above, I decided to work around the quirks of the Google SDK and implement a fix directly in react-native-maps. Could you please try out the beta version and report back to me if it fixes the issue?

I wasn’t satisfied with the workaround as it still introduces a flash of default blue before the polygon updates, so I did some experimenting and found some leads. Maybe someone with more iOS experience than I have can chime in, but it’s looking like something in the realm of an async/threading race condition to me.

First, the temporary fix: insert a short delay before the polygon gets added to the map here: https://github.com/react-native-community/react-native-maps/blob/master/lib/ios/AirGoogleMaps/AIRGoogleMap.m#L135-L136

I changed to:

    AIRGoogleMapPolygon *polygon = (AIRGoogleMapPolygon*)subview;
      
    // Including a short delay before adding the polygon to the map fixes an issue where
    // the polygon would be default blue colored on initial render.
    // https://github.com/react-native-community/react-native-maps/issues/3057
    double delayInSeconds = 1.0;
    dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayInSeconds * NSEC_PER_SEC));
    dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
        polygon.polygon.map = self;
        [self.polygons addObject:polygon];
    });

I initially tried only a dispatch_async, but found that the below code still showed default blue polygons sometimes (most of the time it worked though):

      dispatch_async(dispatch_get_main_queue(), ^{
        polygon.polygon.map = self;
        [self.polygons addObject:polygon];
      });

I’m going to patch-package for now as I don’t think this is the actual fix, but I’m hoping some iOS dev out there can identify the underlying issue take it over the finish line.

tested with new react-native-maps 0.31.0 and GoogleMaps 6.1.1. Same issue

Here the polygons were rendered on the second render with blue/purple fill. Initial render was always using the provided fillcolor. It only happened on iOS, but probably not the older iOS version.

We “resolved” it, by using the 2.5.0 pods with version 0.26.1. So far, there are no problems. (Android works fine without any adjustments.)

To make the patch persisintent we added a postinstall script to npm to copy the following file to ./node_modules/react-native-maps/react-native-google-maps.podspec:

require 'json'

package = JSON.parse(File.read(File.join(__dir__, 'package.json')))

Pod::Spec.new do |s|
  s.name         = "react-native-google-maps"
  s.version      = package['version']
  s.summary      = "React Native Mapview component for iOS + Android"

  s.authors      = { "intelligibabble" => "leland.m.richardson@gmail.com" }
  s.homepage     = "https://github.com/react-native-community/react-native-maps#readme"
  s.license      = "MIT"
  s.platform     = :ios, "8.0"

  s.source       = { :git => "https://github.com/react-native-community/react-native-maps.git" }
  s.source_files  = "lib/ios/AirGoogleMaps/**/*.{h,m}"
  s.compiler_flags = '-DHAVE_GOOGLE_MAPS=1', '-DHAVE_GOOGLE_MAPS_UTILS=1', '-fno-modules'

  s.dependency 'React'
  s.dependency 'GoogleMaps', '2.5.0'
  s.dependency 'Google-Maps-iOS-Utils', '2.1.0'
end

The workaround https://github.com/react-native-community/react-native-maps/issues/3025#issuecomment-538345230 appears to work in all versions of GoogleMaps 3.+ as long the wrapper component sets a property with a non null value on any visible element. I have updated the demo code to toggle the wrapper with a single button.

It seams like that we should not wait for an update of the GoogelMaps pod, but that there is a tiny bug in the iOS code here. Any ideas where to start investigating?

Yes it’s a super annoying problem for us since we need GoogleMaps 3+ to have geolocation services working right in our app and we can’t go backward. Hope a fix will come out sooner than later

I wonder how many more years will this take to fix since reproducing it is so easy 😢

I filed an issue with Google IssueTracker here: https://issuetracker.google.com/issues/218789650

we’re facing this issue too while using the <Geojson/> component! setNativeProps wont work for us in that case since we’ll have to get the ref for each of the <Polygon> components being rendered by the Geojson component.

I continue to have this same issue with Polygons and Circles. Props work half the time. Using v0.28.0, which includes changes from @ddarren , the problem still persists. The “workarounds” using setNativeProps, while ultimately displaying the correct color are not a fix as the correct props are not applied on first render. This results in a flash of the blue styles and then a correction to the styles defined in props

Adding comment to keep this issue alive, unless someone can tell it’s fixed.

I’m experiencing the same problem on the project I’m working on with react-native-maps version 0.26.1 , as a temporal fix I applied this solution: https://github.com/react-native-community/react-native-maps/issues/3025#issuecomment-522968087

Although, on the project, we have one specific case where it’s not working 100% perfect (sometimes it shows the correct styles, sometimes it doesn’t), but as temporal fix, we can cope with it…

Does anybody know if this bug related with Google Maps is already being addressed and an official solution will arrive soon? If I’m not mistaken, this is happening since July 2019 (v0.25.0) 😕

@rborn I have just tested it with GoogleMaps 3.5.0, but this reintroduced the bug. Before we went backwards and tested with the versions we found in the commits. 3.2.0, 3.1.0 and 3.0.3 did not work, but 2.5.0 did.

According to the changelog, the bug was introduced/documented with 3.0.0. I did not find any indication that it is resolved yet. Nor did I find it in the issue tracker to verify its status. Maybe it is related to that issue.

Now after reading through the changelog we tested 2.7.0 and this works fine so far. So we will keep that for the time beeing.

I am not sure if that should be patched by just reverting the version number back to 2.7.0. There are probably some valid use cases that do not need correctly rendered polygons but depend on some features of version 3.