[ios] cocoapods support
Hey, thank you for the great work of keeping this lib fixed and alive, filed a few PRs in original for improvements so far in the past and them are still there... will plan to send here too so we can have them working.
Was wondering if you have any plan of support cocoapods, having a repo to replace the old lib as framework and avoid any manual build and drag and drop.
Basically build with
make xcframework BUILDTYPE=Release
And catch the dynamic result in a pod?
We distribute iOS build as Swift Package, see https://github.com/maplibre/maplibre-gl-native#ios
@petr-pokorny-1 yeah I see, I was thinking if also pods was a viable way to add to a project, just to avoid to mix package with cocopods that I see doesn't work that well so far (made a few quick test and was not working for me so far that combination).
Idea was more to cover older projects that are still using the pod way.
Ok, I see. Unfortunately the team is small currently and we have a lot to do so I dont see the team here could implement cocoapods support anytime soon. PR from the community would be greatly appreciated!
@petr-pokorny-1 here's a starting point https://github.com/matteocrippa/maplibre-cocoapods Double checked locally and seems to work as a kinda fast replacement for any previous lib.
Now to double check the whole flow it would be great to:
- create similar repo under the org of maplibre
- using a maplibre account publish the pod file ( https://guides.cocoapods.org/making/making-a-cocoapod.html )
We refer directly to the zip with the release so it will be much easier to manage, also prolly worth considering a bit of scripting to later make this flow automatic.
MapLibre as a Swift Package should work famously with the CocoaPods or Carthage depedency managers. Please file an issue if MapLibre delivered as SPM fails. I agree that we should have more demo apps or automated tests that show this.
MapLibre as a Swift Package should work famously with the CocoaPods or Carthage depedency managers. Please file an issue if MapLibre delivered as SPM fails. I agree that we should have more demo apps or automated tests that show this.
I was adding as swift package but I start having issue during the archive, because at the end I had to add the package to the pod too because it was not able to find the Mapbox with import.
The trick above with a dedicated podspec that point to the released should make the life more easy to whom have old project and won't mix pod and swiftlint
Btw was more curious if can be a viable way to produce the pod using the repo I suggest or is totally out of plan, I see that basically is just to inherit it and deploy with a maplibre controlled account the lib
Mapbox had support for cocoapods indeed, we could try to update and migrate original scripts to MapLibre. See https://github.com/maplibre/maplibre-gl-native/blob/master/platform/ios/platform/ios/scripts/deploy-to-cocoapods.sh and related. The most work here is to properly integrate cocoapods stuff into automated build process.
@petr-pokorny-1 consider that in the repo I created https://github.com/matteocrippa/maplibre-cocoapods I had to adapt a bit because maplibre zip is different and uses a xcframework.
I was testing it locally using a github reference into the pod and works already.
The missing part is basically:
- having it pushed in cocoapods so you can refer into any project like
pod Maplibre - tweak the code to update automatically once a new zip version has been released
I just wanted to mention that this might have the benefit of Maplibre being able to be used as a drop-in dependency when using for example Mapbox Navigation, as mentioned in #66.
So if cocoapod support is considered (and navigation isn't forked as well), it might make sense to keep the version and naming intact.
bumping here, I think it is possible to make it work, at least something like this works already:
Pod::Spec.new do |s|
version = '5.13.0-pre.1'
s.name = 'MapLibre'
s.version = version
s.license = { :type => 'BSD' }
s.homepage = 'https://github.com/maplibre/'
s.authors = { 'MapLibre' => '' }
s.summary = 'Open source vector map solution for iOS with full styling capabilities.'
s.platform = :ios
s.source = {
:http => "https://github.com/maptiler/maplibre-gl-native/releases/download/ios-v#{version.to_s}/Mapbox-#{version.to_s}.zip",
:flatten => false
}
s.ios.deployment_target = '9.0'
s.ios.vendored_frameworks = "**/Mapbox.xcframework"
s.dependency "MapboxMobileEvents", "0.10.2"
end
It's more to add an automation that creates that and make a pod trunk push to the repo
If you would like to push this effort forward @matteocrippa, feel free to submit a pull request. I am happy to review it...
@matteocrippa Thanks for introducing the podspec, adding to this, because I've faced a problem and took me sometime to figure out, this problem was with installation, usually i ended up with error like 'No such module found', because the zip wasn't being downloaded first time
to fix this, repo has to be specified as a "Source" not as a "GIT" so in your podfile, it has to be something like this
pod 'MapLibre', '5.12.2', :source => '[email protected]:i0sa/maplibre-cocoapods.git'
I also created a fork of your repo that introduces the podspec, to add folder and version, since 'source' looks for version
Hi @matteocrippa Do you mind adding [email protected]
pod trunk add-owner MapLibre [email protected]
Then I can try publishing a new version of the library to Cocoapods.
Done!
@louwers I think we can close this issue, what do you think?
@matteocrippa We can, I will create a separate one for automating the release.
Thanks everybody!