Protobuf v38 will end Objective-C support. The 37.x line gives developers more time

Protocol Buffers will drop Objective-C support in its v38 release, according to the project's October 21 notice. The existing 37.x long-term-support line provides a transition period: the latest announcement says Objective-C remains supported there until the first quarter of 2028. This is a maintenance decision for a particular dependency, not an announcement that Objective-C applications stop working on that date.

The change is tied to another approaching deadline. CocoaPods trunk is scheduled to become read-only on December 2, 2026. Together, the two developments make this a good moment for Apple-platform developers to identify which part of their build actually depends on the Objective-C Protobuf implementation.

A package manager and a runtime are different dependencies

Protocol Buffers describes structured messages in schema files and generates language-specific code for reading and writing them. Runtime libraries supply the shared functionality used by that generated code. An application can therefore depend on Protobuf through a library or SDK even if its own developers rarely edit a schema.

That distinction changes the first question to ask. Finding CocoaPods in a project does not establish that the project uses Objective-C Protobuf. Finding Protobuf does not establish that its Objective-C binding is the relevant one. A useful inventory follows the actual dependency chain, rather than treating either name as a reason for a wholesale rewrite.

The new support notice also says there are no plans to publish this Objective-C implementation through Swift Package Manager, citing demand and non-ARC code support. Switching package managers is therefore not a promised drop-in route to continuing this particular package on the new release line.

Read-only does not mean the archive disappears

The CocoaPods plan, originally published in 2024 and subsequently updated, concerns new submissions to the central trunk repository. It says existing builds should continue and distinguishes private specification repositories and vendored dependencies from trunk. The December change is not described as deleting the existing package archive.

The practical loss is the ability to receive newly published versions through that route. An old dependency continuing to install is reassuring for reproducibility, but it does not establish that the dependency is still maintained. Teams need to keep those two questions separate when checking the health of a build.

These are published plans, not proof that the future changes have already happened. Protobuf's removal is tied to v38; the CocoaPods date belongs to the package repository. Combining them into a single “everything ends in December” deadline would misstate both.

Keep generated code and its runtime together

Protobuf's cross-version compatibility rules warn against pairing newly generated code with an older runtime. A newer generator may emit calls that the older library cannot supply. Pinning only the runtime while allowing code generation to advance is therefore not a complete transition strategy.

For a team maintaining an older Apple-platform application, the concrete job is to record the generator, generated files, runtime and delivery channel, then identify who owns the affected library. If the dependency comes through another SDK, its maintainer's migration path matters more than a top-level package-manager preference. This is planning work that can start without disrupting a working release.

The 37.x support period buys time to make that decision deliberately. Its value is not that an old build can be forgotten for longer. It is that developers can move the relevant dependency before continued installation becomes their only evidence that it is still safe to rely on.