google-api-objectivec-client-for-rest: a REST client for every Google API, generated

Most of this library is generated code

The Google APIs Client Library for Objective-C for REST is written by Google, and the README calls it a flexible and efficient Objective-C framework for accessing JSON APIs. It is also described as the recommended library for accessing JSON-based Google APIs for iOS, macOS, tvOS and watchOS applications.

The structure of the repository explains what kind of project this is. The Sources/ directory contains a GeneratedServices folder with the pre-generated interfaces for the Google APIs, and the Tools/ directory holds the ServiceGenerator, which produces source for any other service that has a discovery document.

That is the key concept. Google's REST APIs are described by machine readable discovery documents, and the generator turns a discovery document into Objective-C classes with methods, request builders and model types. So the library is not a set of hand written wrappers, it is a general client plus a large body of generated code, and the two halves have different lifecycles: the client changes when Google changes its conventions, the generated services change when a service changes its API.

The platform list is worth noting too. iOS, macOS, tvOS and watchOS are the four targets, which tells you this is the client for Apple platforms rather than for cross-platform mobile work, and the code is Objective-C rather than Swift.

For a reader, the practical consequence is that using a service that is not pre-generated is a two-step job: find or obtain a discovery document, run the generator, and compile the result. The README points at the discovery document reference for the resource representations the generator needs.

CocoaPods and SwiftPM are both first class

The repository carries two distribution mechanisms, and the CI badges show that both are tested.

There is a GoogleAPIClientForREST.podspec for CocoaPods and a Package.swift for Swift Package Manager, and the workflow badges at the top of the README are for CocoaPods, SwiftPM and the ServiceGenerator respectively. Three separate workflows means the podspec, the Swift package and the generator are each verified on every change, which is a reasonable investment for a library that most teams will consume through one of the two package managers.

The test directories reflect the same split. There is a SwiftPMTests/ directory and a UnitTests/ directory, so the test suite itself is organised per package format rather than as one blob.

The presence of Package.swift in an Objective-C library is the detail that matters most for anyone starting a project today. The library predates Swift as a mainstream language for Apple development, but the Swift package manifest means a Swift codebase can pull it in as a package dependency, and the tests for that path live in their own directory.

The repository also carries an update_version.py script at the root, which is the sort of tooling that appears when a package version has to be bumped in several files at once, and a DEVELOPMENT.md next to the user-facing USING.md, so the two documents are aimed at different audiences. CONTRIBUTING.md completes the set.

The licence is Apache-2.0, the default branch is main, and the release history is regular: v5.3.0 on 2026-05-12, v5.4.0 on 2026-08-04 and v5.5.0 on 2026-10-12, with the last push on the same day as the newest release.

Four examples, and a document that does the explaining

The Examples/ directory holds CalendarSample, DriveSample, StorageSample and YouTubeSample, along with a README of its own. That is the complete set, and the README explains why with a sentence that is refreshingly honest: there is not an example for every service, as there are just too many services.

So the intended workflow for anyone using a service without a sample is to read USING.md, which the README calls the place to get started with Google APIs and the Objective-C client library and refers to for detailed information. The examples are there to answer shape questions, such as how a service call is structured, while the document is there to answer behaviour questions, such as how authorisation is configured.

The examples directory in the repository listing shows one more thing, an Examples/README.md, which suggests the samples are indexed and described rather than left to be discovered by browsing.

The service surface is enormous, which is why the README pushes two other things instead. It points at the GTM Session Fetcher, the separate project the library is built on top of, and it notes that to work with some remote services the library also needs authentication and authorisation, with a section of USING.md devoted to that. It also mentions the much older library for XML-based Google APIs, which is still available as its own repository, for anyone who has to work with an API that has not moved to JSON.

The Google Toolbox for Mac is offered as a source of other useful classes for Mac and iOS developers, which is a reminder that the client is one component in a larger set of Google-provided iOS building blocks rather than a self-contained framework.

A bug report is expected to arrive with HTTP logs

There is a small procedural instruction in the README that tells you a lot about how this library is supported.

If you have a problem or want a new feature, you are asked to join the discussion group, and the instruction is to include HTTP logs for requests and responses when posting questions, with a pointer into USING.md for the section on logging HTTP server traffic. Bugs may be submitted on the issues list instead.

Why logs matter here is easy to see once you know what the library does. A Google API request carries a token, and the interesting failures are the ones where the request is malformed, the scope is wrong or the service returns an error you have not seen before. Without the raw request and response, the maintainers are debugging blind. Asking for logs up front is the difference between a question that can be answered and one that becomes a long exchange of screenshots.

It also has a privacy dimension worth thinking about. HTTP logs contain the request headers, and the request headers contain the authorization token, so a log pasted into a public issue or a discussion group is a credential in the wrong place. The documentation section on logging is presumably where that is explained, and it is worth reading before the first time you need it, because the moment you need it is the moment you are in a hurry.

The discussion group is the older of the two channels, a Google Groups posting list, and the issues list is the newer one. For a project with a version 5.x and a steady release every few months, the split between asking questions and reporting defects is a sensible division of labour.

What the version numbers say, and what to check before you build

The releases are minor version bumps, three of them across 2026: v5.3.0 in May, v5.4.0 in August and v5.5.0 in October, each published with a release title. There are no patch releases in the list, which for a generated client library is a reasonable pattern, because the generated code for a given service does not usually need fixing on its own, while the shared client layer does change when Google's conventions change.

The consequence for a consumer is that a minor version bump can bring a new generated API surface, and the version you depend on should be one you have read the release notes for rather than whatever the resolver picks on the day you build. The update_version.py script in the repository is the maintainers' tool for that, and the same script is the reason the version appears consistently across the podspec, the package manifest and the source.

Three things are worth checking before a team commits to this library.

The first is whether the service you need is in the generated sources or can be generated from a discovery document. The generator needs the latter, and a service without one is a blocker rather than an inconvenience.

The second is the language. The library is Objective-C, and even where the Swift package manifest makes it consumable, a Swift-first team should be clear that the interface they will be calling is Objective-C.

The third is the authentication and authorisation section of USING.md, which the README singles out as a requirement for working with some remote services. That is where the tokens, the scopes and the client object are set up, and it is the part of the integration where a mistake shows up as a confusing failure rather than a compile error.

Beyond those, the last push and the newest release share the date 2026-10-12, so the repository is in a good state: a released version and current commits on the same day.

Editorial conclusion

Adopt the Google APIs client library for Objective-C if you are building an iOS or macOS application that talks to a Google REST API and want typed interfaces and the standard authentication handling rather than hand written HTTP. Do not adopt it if the service you need has no discovery document, because the generator needs one, and expect to read USING.md rather than an example, since only four services have samples. Before you build, check that the service you need is present in the generated sources, plan for the fact that the library is Objective-C rather than Swift, and remember that a bug report is expected to include HTTP logs of the request and response.

Frequently asked questions

Official sources

1. google/google-api-objectivec-client-for-rest on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases