# Mapbox Maps SDK for iOS is a Metal renderer for style spec tiles > mapbox-maps-ios is the Swift source for the Mapbox Maps SDK for iOS, which takes map styles conforming to the Mapbox Style Specification, applies them to vector tiles conforming to the Mapbox Vector Tile Specification, and renders with Metal. The repository is contributor facing rather than user facing, and its one decisive piece of news is that CocoaPods distribution ends in December 2026. **mapbox/mapbox-maps-ios** — Interactive, thoroughly customizable maps for iOS powered by vector tiles and Metal - Repository: https://github.com/mapbox/mapbox-maps-ios - Website: https://www.mapbox.com/mapbox-mobile-sdk - Stars: 601 · Forks: 198 - Language: Swift - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/mapbox-mapbox-maps-ios ## The pipeline is style spec, vector tiles, Metal The one paragraph that explains the library is the opening description, and it is worth reading closely because it names the three specifications the implementation is built around. The Mapbox Maps SDK for iOS is a public library for displaying interactive, thoroughly customizable maps in native iOS. It takes map styles that conform to the Mapbox Style Specification, applies them to the vector tiles that conform to the Mapbox Vector Tile Specification, and renders them using Metal. That is three layers, and the order matters. The style is a declarative document describing layers, sources, paint and layout, and it is not specific to any renderer. The vector tile is the transport format, a specification rather than a particular tile service. Metal is the GPU API on the rendering side, which is what makes this an iOS and macOS implementation rather than a cross platform one. The two specifications are shared assets rather than something this repository defines. A style written against the style specification will behave the same in the other Mapbox renderers, and a tile server that emits conforming vector tiles works with any client that reads them. That separation is the reason a styling tool can target the SDK without knowing anything about Swift. The topics recorded for the project are ios, map, mapbox, maps, metal, priority and swift, and the primary language is Swift. ## This repository is for contributors, not for users The Getting Started section says something that changes how the whole repository should be read: the README is intended for developers who are interested in contributing to the Mapbox Maps SDK for iOS, and readers are pointed to the Mapbox documentation site for general information and instructions on using the Maps SDK in an iOS application. So the repository deliberately contains almost no usage guidance. No installation snippet, no sample view controller, no API walkthrough. What it contains instead is the machinery of an actively developed commercial SDK. The file listing shows that machinery clearly. There is a Package.swift manifest and a MapboxMaps.podspec, so both Swift Package Manager and CocoaPods distribution are represented. There is a Sources directory and a Tests directory, a codecov.yml, a .swiftlint.yml, a .depsvalidator.yml, a .pre-commit-config.yaml, a .yamllint, a CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, a DEVELOPING.md, and a STYLE_README.md. The build itself is generated rather than hand maintained, with project.yml, Examples.yml, a Gemfile and Gemfile.lock, an xcodegen directory, a scripts directory and an Examples.xcodeproj directory. That set of files describes a project that regenerates its Xcode projects from YAML definitions, lints with SwiftLint, keeps a dependency validation file to catch drift in the dependency graph, and runs its own formatter through pre-commit hooks. For a reader deciding whether to fork or contribute, that tells you more about the project's engineering discipline than any feature list would. ## CocoaPods is being sunset in December 2026 The single most consequential piece of information in the README is a deprecation notice, and it is marked as important. CocoaPods support is being sunset by December 2026. Mapbox plans to discontinue distributing the Maps SDK for iOS via CocoaPods by that date. After it, no new releases will be published to CocoaPods and the existing podspec will no longer be maintained. The project strongly recommends migrating to Swift Package Manager, which it describes as Mapbox's preferred and actively supported distribution channel for iOS, and asks users to plan the migration ahead of the December 2026 deadline. The mechanical consequences are clear. A build that resolves the SDK through a Podfile will keep working with whatever version it pinned, but it will receive no updates, and any fix shipped after the cut will only be available through SPM. A project with a long lived dependency lock and no intent to upgrade can coast, but a project that expects SDK fixes, especially on a platform where users are on old OS versions, cannot. The repository reflects the transition rather than resisting it. Both MapboxMaps.podspec and Package.swift sit at the top level, and the notice is written as a planned migration with a date rather than a vague deprecation. For an integrator, the practical question is not whether CocoaPods works today but whether you want to be on the distribution channel that stops receiving releases. ## Where the substance of the SDK actually lives Because the README is thin, the honest way to assess this project is to look at what is in the repository rather than what is written about it. The Sources directory is the SDK itself, and the fact that it is a directory rather than a single file tells you the SDK is a multi module Swift package. The Tests directory exists and codecov.yml is present, which is the minimum indication that coverage is measured on pull requests. The Examples.xcodeproj directory and the Examples app are described in the README as showing how to use many of the features in the Maps SDK, and they are generated through xcodegen from the YAML files, with a dedicated Examples.yml. The scripts directory and the .depsvalidator.yml together suggest an automated dependency review, and the .pre-commit-config.yaml and .swiftlint.yml suggest formatting and lint enforcement before a commit lands. The Gemfile and Gemfile.lock are there for the release tooling, and .fastlane at the top level points to an automated release pipeline, which is consistent with the release cadence visible in the tags. A developer who wants to build the SDK is pointed to DEVELOPING.md for information on setting up, running and building it, so the actual build instructions live in that file rather than in the README. That is a reasonable split, and it also means the README alone does not tell you what toolchain you need. ## Issue handling is split between templates and support channels The issue section of the README is unusually prescriptive, and the reasoning is stated rather than implied. Bugs are reported with a bug template, and feature requests and enhancements have their own template. The project kindly asks that you avoid using the issue tracker in this repository for questions, and to use the support channels instead, which are the Mapbox support site and a Discord channel linked from the README. The reason to note this is that it tells you what kind of repository this is. A library that splits questions away from its tracker is a library whose user base is large and whose maintainers are trying to keep the public issue list focused on defects and proposals. It also means that if you are evaluating the SDK and have a question, the answer will not come from the issue tracker, and if you are integrating it, your support path is Mapbox's commercial support rather than the community. The historical note at the end of the README adds one more piece of context. This repository is a continuation of the Mapbox Maps SDK for iOS that was previously available at mapbox/mapbox-gl-native-ios. The rename reflects the shift from the gl native era, where the SDK was a port of the cross platform gl native core, to a native Swift and Metal implementation, and it is worth knowing if you have old links, blog posts or dependencies pointing at the previous repository name. ## What a Mapbox SDK dependency actually commits you to Three constraints deserve attention before you adopt this in an application. The first is that this is a client for a service, not a self contained map renderer. The SDK renders styles and tiles that conform to Mapbox specifications, and the tiles come from a tile service you configure. The styling document itself is part of the Mapbox platform, and the repository points to docs.mapbox.com for using the Maps SDK within your iOS application. Adopting the SDK means adopting a Mapbox account, a token and a billing relationship, and a map that cannot load tiles is not a degraded map, it is a blank view. The second is the platform. Metal is the renderer, and the project is an iOS library, so there is no Android, web or server equivalent in this repository. The cross platform path is a different set of projects with a different licensing and billing model, and if your application ships on more than one platform you are maintaining two map stacks. The third is the licence. The project records a licence that GitHub cannot classify, with the terms in LICENSE.md, so the file itself is what governs. That is worth reading rather than assuming, especially if you are shipping a commercial application or embedding the SDK in a product you distribute. The realistic alternative, if you want maps without a vendor relationship, is to use an open tile and rendering stack instead: a MapLibre style renderer over OpenStreetMap data, which is free of per-request billing and of account gating, at the cost of a different tile usage policy, a self hosted or contracted tile source, and generally fewer of the hosted styling and geocoding tools that come with the commercial platform. The decision is not about map quality so much as about whether you want a client that is a front end to a paid service, or a renderer you host. ## Conclusion mapbox-maps-ios is the right place to look if you are building a Mapbox based iOS application and need to know how the rendering pipeline is put together, or if you intend to contribute to the SDK, and it is the wrong place to look for setup instructions, since the project explicitly redirects usage questions to the Mapbox documentation site. Before you plan an integration, check three things: that your build uses Swift Package Manager, because CocoaPods distribution is being sunset in December 2026 and the podspec will no longer be maintained, that your account and billing situation still work with the Mapbox platform as it stands now, since the SDK is one component of a commercial service rather than a standalone map renderer, and that the licence in LICENSE.md is acceptable for your use, because the project records a custom licence that GitHub cannot classify. The last push was on 2026-10-20 and the release cadence is fast, with 11.33.0 on 2026-10-16 and 11.32.3 on 2026-10-20. ## FAQ ### What is mapbox-maps-ios? It is the Swift source repository for the Mapbox Maps SDK for iOS, a public library for displaying interactive, customizable maps in native iOS. It takes styles conforming to the Mapbox Style Specification, applies them to vector tiles conforming to the Mapbox Vector Tile Specification, and renders them using Metal. ### Is CocoaPods support being removed from the Mapbox Maps SDK for iOS? Yes. The README states that CocoaPods support is being sunset by December 2026, that no new releases will be published to CocoaPods after that date, and that the existing podspec will no longer be maintained. The project recommends migrating to Swift Package Manager. ### How do I set up the Mapbox Maps SDK for iOS in my app? The repository does not contain setup instructions for consumers. The README says it is intended for developers interested in contributing, and directs users to docs.mapbox.com/ios/maps/guides for general information and instructions on using the SDK. An Examples app in the repository shows many features in use. ### Where do I report a bug in mapbox-maps-ios? The README asks that bugs be filed with the repository's bug template and feature requests with the feature template, and asks that general questions go to Mapbox support channels rather than the issue tracker, including the support site and a Discord channel. ### What replaced mapbox-gl-native-ios? This repository is a continuation of the Mapbox Maps SDK for iOS that was previously available at mapbox/mapbox-gl-native-ios. The README notes this as a historical point for anyone following older links or dependencies. ## Sources - [Issues](https://github.com/mapbox/mapbox-maps-ios/issues) - [mapbox/mapbox-maps-ios on GitHub](https://github.com/mapbox/mapbox-maps-ios) - [Project website](https://www.mapbox.com/mapbox-mobile-sdk) - [README](https://github.com/mapbox/mapbox-maps-ios/blob/main/README.md) - [Releases](https://github.com/mapbox/mapbox-maps-ios/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mapbox-mapbox-maps-ios