Status and roadmap for google-maps-ios-utils

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](https://github.com/googlemaps/google-maps-ios-utils/issues/458#issuecomment-1998082436) 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)**

- [x] Support Maps SDK v8
- [x] Support installation of the utility library via Swift Package Manager in Xcode
- [x] Support for installation of the utility library via CocoaPods
- [x] End support for installation of the utility library via Carthage
- [x] Build SPM and CocoaPod from source (GitHub) instead of shipping SPM as a binary (XCFramework)
- [x] Update [build, test, and release action workflows](https://github.com/googlemaps/google-maps-ios-utils/actions) to use the latest methods to validate the library upon every pull request and merge to main.
- [x] Unit tests pass via both xcodebuild test and pod lib lint
- [x] Remove the side-by-side app as a build validator
- [x] Build the Podfile-based Objective-C sample app and Swift sample app as validation of CocoaPods-based build
- [x] Maintain Code Coverage and Dependabot security checks
- [x] Remove Dependabot action that automates dependency updates since we only have 2 dependencies on GoogleMaps and OCMock
- [x] Implement correct OS version minimums to ensure library compatibility with major version releases of the Maps SDK for iOS.
- [x] Add privacy manifest
- [x] Update the README with the new installation recommendations.
- [x] Fix #456, #458, #459, #464, #467, #468

**v6.0 (July, #479)**

- [x] Support Maps SDK v9 (Fix #475)

**v6.1.0 (November, #506)**

- [x] Support custom subclasses of GMSMarker in marker clustering (Fix #505)

**v7.0 (November)**

- [x] Convert source code from a mix of Objective-C and Swift to all Swift so the library can have a single target #511
- [x] Convert Objective-C unit tests to Swift unit tests so that all tests are Swift #512
- [ ] Add reference documentation #513

**Beyond**

- [x] P1 bug #321
- [x] P1 bug #342
- [ ] [P2 bugs](https://github.com/googlemaps/google-maps-ios-utils/issues?q=is%3Aopen+is%3Aissue+label%3A%22priority%3A+p2%22+label%3A%22type%3A+bug%22)
- [ ] [P2 feature requests](https://github.com/googlemaps/google-maps-ios-utils/issues?q=is%3Aopen+is%3Aissue+label%3A%22priority%3A+p2%22+label%3A%22type%3A+feature+request%22)
- [ ] 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).