Status and roadmap for google-maps-ios-utils

[wangela]

This issue describes the current status and roadmap for the Google Maps SDK for iOS Utility Library. I will edit this top comment as progress is made or plans change.

It's been 4 months since my last comment describing the work that needed to be done, and we're all frustrated that a new version hasn't been released yet. Communication has been sparse because it's been hard to predict when the final issues would be resolved, since these are problems we haven't encountered before across my own team, consults with teams that manage other Google products for iOS developers, and (based on my searching on the web) many other Swift package and CocoaPods pod owners. Even documenting the goals for the next 2-3 releases here has been challenging as I've discovered new obstacles and solutions on a daily basis.

Design Considerations

Updating the Maps iOS Utils library to support Maps SDK for iOS v8 has been painful due to several factors:

Challenge	Plan
The library's build and release workflows are based on Carthage generating an XCFramework, which stopped being compatible with the Maps SDK for iOS since v7.	Build from source instead of using Carthage to generate an XCFramework and publishing a binary dependency. The pros and cons of binary vs multi-target Swift packages are weighed in this blog post.
Apple recommends depending on Swift packages built from source rather than binary dependencies.
Apple's build workflow for Swift packages has changed significantly since the original build workflows were written. We previously relied on Xcode Schemes to build and test the package and companion app.	Validate building and testing the package using recommended workflow for building and testing Swift packages targeting iOS (using `xcodebuild`) for building and testing Swift packages. The workflows will run on the GitHub Runnner selected by `macos-latest` until the latest encounters build errors.
Swift Package Manager built from source does not support mixed language targets (current proposal in Swift Evolution), so this library (with Objective-C code and Swift code) requires an Objective-C target and a Swift target.	Near-term: Use the undocumented @exported feature to import the Objective-C target to the Swift target. CocoaPods does not require this because CocoaPods supports mixed-language targets. This blog post describes one developer's journey and learnings from attempting it. Tests can be shared by both Swift Package and CocoaPods build and test workflows. Mid-term: Translate all source code and tests from Obj-C to Swift so the package is pure Swift and we only need one target that can be used for both SPM and CocoaPods.
Publishing to CocoaPods requires passing `pod lib lint` (local only validation) and `pod spec lint` (local+network validation) which is based on installing the library based on the Podspec. This runs a test target specified in the Podspec; as long as the import signatures for projects built with SPM vs CocoaPods are the same, these tests can be shared.
Unit testing in Objective-C requires mock Google Maps objects, but OCMock support for Swift Package Manager is incomplete.
Unit testing in Swift requires mock Google Maps objects, but there is no equivalent to OCMock for Swift.	Complete the Swift-based mock work in progress when we translate the Objective-C tests to Swift.

Roadmap for google-maps-ios-utils:

v5.0 (July, #444)

• Support Maps SDK v8
• Support installation of the utility library via Swift Package Manager in Xcode
• Support for installation of the utility library via CocoaPods
• End support for installation of the utility library via Carthage
• Build SPM and CocoaPod from source (GitHub) instead of shipping SPM as a binary (XCFramework)
• Update build, test, and release action workflows to use the latest methods to validate the library upon every pull request and merge to main.
  • Unit tests pass via both xcodebuild test and pod lib lint
  • Remove the side-by-side app as a build validator
  • Build the Podfile-based Objective-C sample app and Swift sample app as validation of CocoaPods-based build
• Maintain Code Coverage and Dependabot security checks
  • Remove Dependabot action that automates dependency updates since we only have 2 dependencies on GoogleMaps and OCMock
• Implement correct OS version minimums to ensure library compatibility with major version releases of the Maps SDK for iOS.
• Add privacy manifest
• Update the README with the new installation recommendations.
• Fix 4.2.2 does not allow updating to latest GoogleMaps (8.x) #456, Google maps utils compiler error in new Xcode Version 15.0.1  #458, empty field MinimumOSVersion for internal FB frameworks causes failure on uploading to App Store Connect with Xcode 15.3 #459, GoogleMaps don't compile at Mac's (is this ever getting fixed?) #464, Failed to build module 'GoogleMapsUtils'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 5.5.2 (swiftlang-1300.0.47.5 clang-1300.0.29.30)', while this compiler is 'Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)'). Please select a toolchain which matches the SDK. #467, Invalid Bundle. The bundle Frameworks/GoogleMapsUtils.framework does not support the minimum OS Version specified in the Info.plist #468

v6.0 (July, #479)

• Support Maps SDK v9 (Fix Support Maps SDK v9 #475)

v6.1.0 (November, #506)

• Support custom subclasses of GMSMarker in marker clustering (Fix IconView does not appear when a subclassed GMSMarker is added to GMUClusterManager. #505)

v7.0 (November)

• Convert source code from a mix of Objective-C and Swift to all Swift so the library can have a single target Convert source code to 100% Swift #511
• Convert Objective-C unit tests to Swift unit tests so that all tests are Swift Convert unit tests to Swift #512
• Add reference documentation Provide full reference documentation for this library #513

Beyond

• P1 bug Marker disappeared on cluster zoom  #321
• P1 bug SPM integration not working when archiving app for the AppStore  #342
• P2 bugs
• P2 feature requests
• Features and bugfixes are prioritized by triage of GitHub issues. Help us identify top issues that matter to you by upvoting as counted by comments and 👍 reactions to intial comment (these are the metrics that we're able to sort by in the GitHub browser UI).

[Rexios80]

@wangela please pin this issue

[alexookah]

So we wont be able to update to V9 google maps until google maps utils has done all these things mentioned in the roadmap and get to version 6.
Have I understood correct?
Has anyone successfully updated to google maps v9 with the current state of google maps utils (branch: wangela/8-0-0?

[ThePragmaticArt]

I appreciate the transparency and updates on this. Google has consistently lagged behind in reference to modernizing Apple technologies (SPM wasn't adopted until ... this year ... and Cocoapods has been a questionable staple for Google and Google alone).

Unsure why these migrations are painful and they negatively impact both developer experiences and recommendations on stacks.

It's the end of July now and this issue doesn't seem to be resolved yet with 9.x. Hopefully something coming soon?

[wangela]

🚀 v5.0.0 (supporting Maps SDK v8, minimum iOS 14) and v6.0.0 (supporting Maps SDK v9, minimum iOS 15) of the Maps SDK for iOS Utility Library are now available via SPM and CocoaPods.

See the Installation section of the README for guidance on how to install the version of your choice.

@alexookah With all the work that went into v5.0.0, our updates to this library should be much faster. It took less than a day to cut v6.0.0.

@ThePragmaticArt This library has supported SPM since 2020 but the SDK didn't support SPM until December last year. Every engineering team has to make difficult choices between modernization and feature development. For this library, the modernization debt we've held by relying on Carthage and a mixed-language codebase proved to be very painful. For our closed-source SDKs, public Issue Tracker is the best way to tell us what you want us to prioritize. For example, the upvotes on the IssueTracker issue requesting SPM support helped build the case for prioritizing that release modernization work. Similarly on another Apple-related modernization effort, we're looking for evidence that developers want full support for Google Maps in SwiftUI but we're not seeing many issues or upvotes raised about that yet.

Regarding CocoaPods, we still see CocoaPods being the channel of choice for many developers, and currently it's the only way of loading libraries for Flutter.

With our plan to translate this library to 100% Swift source next, we'll hopefully be able to return to developer experience improvements and feature development. I've added guidance to the initial comment on how to help us prioritize our feature roadmap.

[Rexios80]

@wangela Thank you so much for this! I will start implementing this in google_maps_flutter_ios right now.

[ThePragmaticArt]

🚀 v5.0.0 (supporting Maps SDK v8, minimum iOS 14) and v6.0.0 (supporting Maps SDK v9, minimum iOS 15) of the Maps SDK for iOS Utility Library are now available via SPM and CocoaPods.

See the Installation section of the README for guidance on how to install the version of your choice.

@alexookah With all the work that went into v5.0.0, our updates to this library should be much faster. It took less than a day to cut v6.0.0.

@ThePragmaticArt This library has supported SPM since 2020 but the SDK didn't support SPM until December last year. Every engineering team has to make difficult choices between modernization and feature development. For this library, the modernization debt we've held by relying on Carthage and a mixed-language codebase proved to be very painful. For our closed-source SDKs, public Issue Tracker is the best way to tell us what you want us to prioritize. For example, the upvotes on the IssueTracker issue requesting SPM support helped build the case for prioritizing that release modernization work. Similarly on another Apple-related modernization effort, we're looking for evidence that developers want full support for Google Maps in SwiftUI but we're not seeing many issues or upvotes raised about that yet.

Regarding CocoaPods, we still see CocoaPods being the channel of choice for many developers, and currently it's the only way of loading libraries for Flutter.

With our plan to translate this library to 100% Swift source next, we'll hopefully be able to return to developer experience improvements and feature development. I've added guidance to the initial comment on how to help us prioritize our feature roadmap.

I appreciate the update, although I'm baffled how out of touch the internal Google team is with the state of mobile externally.

Cocoapods has had a "swift" death in iOS outside of Google framework support for well over 4 years. Modern libraries will attest to this as it's almost non-existent to see a modern Swift library with Pod support.

https://github.com/onevcat/Kingfisher
https://github.com/pointfreeco/swift-composable-architecture
https://github.com/kean/Pulse
https://github.com/kean/Nuke

(Feel free to audit "older" vs "newer" libraries here, you'll be hard pressed for pod support https://github.com/matteocrippa/awesome-swift?tab=readme-ov-file)

You will simply not find any modern libraries supporting a system that's all but considered dead unless there are requirements crossing over with Google tied frameworks and many of us have hacked around this issue.

It's disappointing really. Google has such an impact and influence in the analytic and map market and fails to realize how much it holds the mobile community back (especially in enterprise).

In regards to the public issues tracker, as much as I would love the majority of the community to know where that is and engage with the tool, the fact of the matter is that you may receive engagement from < 5% of the community or consumer base at best. I certainly know I haven't engaged with this tool, nor the 100+ iOS or Android engineers at my prior gig, nor the 100s before that gig, nor the engineers at my current gig. Mind you, each of us having engaged and complained about a Google SDK.

I'm unsure where the lack of insights for realistic expectations are, but it's worth noting the lack of support for GoogleMaps + SwiftUI was a controversial topic at my last gig and a deciding factor on recommending Google Maps to this day for me. This is a no brainer -- and I have not filed an Issue. Ensuring Google offers a competitive product following best practices and market trends is not the community's responsibility. This is Google offering a product and they should know the market, clearly the business side doesn't.

Mind you, this is why the Firebase buy out was also so impactful and disappointing. Their team knew this.

[Rexios80]

We just landed the iOS heatmaps implementation thanks to this

• [google_maps_flutter_ios] iOS changes to support heatmaps flutter/packages#7314

And marker clustering is about to land soon

• [google_maps_flutter] Add marker clustering support - iOS implementation flutter/packages#6186

Thank you again for the work on this @wangela!

[ThePragmaticArt]

🚀 v5.0.0 (supporting Maps SDK v8, minimum iOS 14) and v6.0.0 (supporting Maps SDK v9, minimum iOS 15) of the Maps SDK for iOS Utility Library are now available via SPM and CocoaPods.

See the Installation section of the README for guidance on how to install the version of your choice.

@alexookah With all the work that went into v5.0.0, our updates to this library should be much faster. It took less than a day to cut v6.0.0.

@ThePragmaticArt This library has supported SPM since 2020 but the SDK didn't support SPM until December last year. Every engineering team has to make difficult choices between modernization and feature development. For this library, the modernization debt we've held by relying on Carthage and a mixed-language codebase proved to be very painful. For our closed-source SDKs, public Issue Tracker is the best way to tell us what you want us to prioritize. For example, the upvotes on the IssueTracker issue requesting SPM support helped build the case for prioritizing that release modernization work. Similarly on another Apple-related modernization effort, we're looking for evidence that developers want full support for Google Maps in SwiftUI but we're not seeing many issues or upvotes raised about that yet.

Regarding CocoaPods, we still see CocoaPods being the channel of choice for many developers, and currently it's the only way of loading libraries for Flutter.

With our plan to translate this library to 100% Swift source next, we'll hopefully be able to return to developer experience improvements and feature development. I've added guidance to the initial comment on how to help us prioritize our feature roadmap.

I appreciate the update, although I'm baffled how out of touch the internal Google team is with the state of mobile externally.

Cocoapods has had a "swift" death in iOS outside of Google framework support for well over 4 years. Modern libraries will attest to this as it's almost non-existent to see a modern Swift library with Pod support.

https://github.com/onevcat/Kingfisher

https://github.com/pointfreeco/swift-composable-architecture

https://github.com/kean/Pulse

https://github.com/kean/Nuke

(Feel free to audit "older" vs "newer" libraries here, you'll be hard pressed for pod support https://github.com/matteocrippa/awesome-swift?tab=readme-ov-file)

You will simply not find any modern libraries supporting a system that's all but considered dead unless there are requirements crossing over with Google tied frameworks and many of us have hacked around this issue.

It's disappointing really. Google has such an impact and influence in the analytic and map market and fails to realize how much it holds the mobile community back (especially in enterprise).

In regards to the public issues tracker, as much as I would love the majority of the community to know where that is and engage with the tool, the fact of the matter is that you may receive engagement from < 5% of the community or consumer base at best. I certainly know I haven't engaged with this tool, nor the 100+ iOS or Android engineers at my prior gig, nor the 100s before that gig, nor the engineers at my current gig. Mind you, each of us having engaged and complained about a Google SDK.

I'm unsure where the lack of insights for realistic expectations are, but it's worth noting the lack of support for GoogleMaps + SwiftUI was a controversial topic at my last gig and a deciding factor on recommending Google Maps to this day for me. This is a no brainer -- and I have not filed an Issue. Ensuring Google offers a competitive product following best practices and market trends is not the community's responsibility. This is Google offering a product and they should know the market, clearly the business side doesn't.

Mind you, this is why the Firebase buy out was also so impactful and disappointing. Their team knew this.

Sometimes the unspoken needs to be spoken

TLDR: We're still keeping it ticking, but we're being more up-front that CocoaPods is in maintenance mode.

https://blog.cocoapods.org/CocoaPods-Support-Plans/

It's important to acknowledge the fumbling that has happened here where this project wasn't migrated away from Cocoapods until Cocoapods itself has started solidifying it's EOL roadmap to the public.

[wangela]

I have updated the initial comment of this thread to update the roadmap. We've done some triage and cleanup on the open issues in this repository so we can provide you with greater detail about the upcoming work on this library.

• Reflect where we are in the Swift translation project (details in the individual linked issues under v7.0), which is nearly complete.
• Add mention of a new feature released today (v6.1.0) thanks to a community contribution.
• List the next 2 issues we are working on, P1 bugs.
• Add links to see the P2 bugs and P2 feature requests that will follow after that.