Rexios80
commented
1 month ago @wangela please pin this issue
Open wangela opened 1 month ago
Rexios80
commented
1 month ago @wangela please pin this issue
alexookah
commented
1 month ago 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
commented
1 month ago 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
commented
1 month ago 🚀 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
commented
1 month ago @wangela Thank you so much for this! I will start implementing this in google_maps_flutter_ios right now.
ThePragmaticArt
commented
1 month ago 🚀 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
commented
1 month ago We just landed the iOS heatmaps implementation thanks to this
And marker clustering is about to land soon
Thank you again for the work on this @wangela!
ThePragmaticArt
commented
4 weeks ago 🚀 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
(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.
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:
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.
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.
Roadmap for google-maps-ios-utils:
v5.0 (July, #444)
v6.0 (July, #479)
v7.0 (September)
Beyond