WordPress for iOS: building the official app from the open source repository

What the WordPress-iOS repository actually gives you

This is the official repository for WordPress for iOS, written primarily in Swift and licensed under GPL-2.0. The homepage points at ios.wordpress.org, and the topics list covers cocoapods, ios, objective-c, swift, wordpress and xcode. That combination tells you what kind of project it is: a large, long-lived Apple-platform client, not a small library with a single entry point.

The intended audience is narrow and specific. The README is a build guide for people who want to compile the app, log into WordPress.com with it, and work on it. There is a CONTRIBUTING.md for reporting issues and contributing code, a CODESTYLE.md, a Dangerfile, SwiftLint and swift-format configuration, and a docs directory described as containing development practices. Those are signals of a project that expects outside patches, but through a defined process rather than a quick fork-and-tweak.

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent: 27.2.0.2 on 2026-08-21, 27.2 on 2026-08-30, and 27.3.0.0 on 2026-09-21. If you are looking for a maintained Apple client codebase to read, this is one.

How the build is wired: Rake, Xcode and Gutenberg XCFrameworks

The mechanism is a Rake-driven bootstrap around an Xcode workspace. The README assumes you work from a command line inside the repository, and the top-level layout confirms it: a Rakefile, a Gemfile and Gemfile.lock for Ruby tooling, a fastlane directory, BuildTools, Scripts, and WordPress.xcworkspace as the thing you eventually open.

There are two dependency layers. The Ruby layer is pinned by .ruby-version and resolved through Bundler. The Apple layer is the workspace itself, plus binary Gutenberg artifacts. The Makefile is explicit about the second one: a dependencies target calls ./Scripts/download-gutenberg-xcframeworks.sh, described as downloading and caching Gutenberg XCFrameworks. That is the editor layer of the app arriving as prebuilt frameworks rather than as source you compile.

The repository also carries Package.swift and Package.resolved alongside the CocoaPods-era topic tags, so Swift Package Manager is part of the picture. The README does not explain how the workspace and the Swift package relate, and that gap matters if you plan to depend on modules directly rather than build the app. Sources/, Tests/ and Modules/ are the directories to read before assuming anything about module boundaries.

Installing the toolchain and running your first build

The README's Getting Started section is three steps: install Xcode, clone the repository, run rake dependencies. The minimum Xcode version is not written in the README; it points at the .xcode-version file in the repository, so read that file rather than guessing.

rake dependencies

That target configures or updates the third party tools the project uses, and the Makefile's dependencies target downloads and caches the Gutenberg XCFrameworks. Expect it to take a while on a cold checkout because it is fetching binaries.

Before any of that, the Ruby side has to match. The README recommends a version manager such as rbenv so the interpreter follows .ruby-version, and gives the exact recovery step if your local Ruby does not match.

rbenv install

Then credentials. The app authenticates against WordPress.com through OAuth2, so you need your own application. Create a WordPress.com account, then create an application at developer.wordpress.com/apps with Website URL set to any valid host, Redirect URLs set to https://localhost, and Type set to Native. The README notes the Website URL, Redirect URLs and Javascript Origins fields are required but unused for the mobile apps, so https://localhost is the value to use everywhere.

With the client ID and client secret in hand, the README gives two ways to supply them: rake init:oss, described as configuring your computer and the app to run and log in to WordPress.com, or rake credentials:setup, which prompts for the two values. Then open the workspace.

rake xcode

rake xcode checks dependencies before launching Xcode. You can also open WordPress.xcworkspace by double-clicking it or through File > Open in Xcode. If the build succeeds, the README says you can compile to a device or simulator and log in. One constraint is stated twice in the README: the only WordPress.com account you can log in with is the one used to create the client ID and client secret.

The credential model is the first real wall

The single-account restriction is not a footnote, it is the shape of the whole development loop. You cannot hand a build to a colleague, a tester or a client and let them log in with their own WordPress.com account. They need the credentials tied to the OAuth application, which means either sharing secrets or each person registering their own application and running credentials:setup.

That makes this repository a poor fit for distributing an internal build to non-developers. It also makes it a poor fit for anyone who wants a generic WordPress client they can point at arbitrary sites without a WordPress.com identity in the middle. The README's framing is login to WordPress.com first, with the WordPress.com REST endpoint and OAuth2 docs linked as further reading.

A second wall is toolchain drift. The build depends on a specific Ruby version, a minimum Xcode version recorded in .xcode-version, and binary Gutenberg frameworks fetched from a script. The README does not document rollback if rake dependencies leaves the checkout in a bad state, and it does not describe how to pin or verify the downloaded frameworks. On a team where machines drift, that is where builds start failing differently per developer.

When a different approach fits better

If the goal is to run a WordPress site on an iPad rather than to build the app, this repository is the wrong tool entirely. Nothing here installs or serves WordPress; it is a client. The README's only login story is WordPress.com OAuth2, and the app is compiled from Swift and Objective-C sources into an iOS binary.

If the goal is to integrate WordPress content into your own app, the more direct route is the WordPress.com REST API and the OAuth2 documentation the README links to. You would write your own networking layer instead of pulling in this codebase, its Ruby bootstrap, its fastlane setup and its Gutenberg XCFrameworks. The trade-off is real: you lose the app's existing editor and account handling, and you take on the OAuth flow yourself. What you gain is a dependency graph you control and none of the Xcode version pinning.

If the goal is to contribute a fix to the official app, there is no alternative. This is the repository, CONTRIBUTING.md is the entry point, and the #mobile channel on the WordPress Slack is where the README says to ask setup questions.

Licence, releases and what upgrades cost you

The project is covered by the GNU General Public License version 2, per the LICENSE file and the README's License section. For anyone forking or shipping a modified build, that is a copyleft obligation to understand before you distribute, and it is worth reading the licence text rather than a summary. Nothing here is legal advice.

Upgrade cost is driven by the release cadence. Releases 27.2.0.2, 27.2 and 27.3.0.0 landed within about a month of each other, so if you track trunk you are rebasing against a moving target. The repository keeps RELEASE-NOTES.txt and MIGRATIONS.md at the top level, which is where a breaking change to an internal API would be recorded; the README itself does not describe a supported upgrade path for downstream consumers.

There is also a secrets directory, .a8c-secrets/, and a .configure-files/ directory. The README does not document what those contain for outside contributors, and the open source path it describes is the manual credentials route. Treat anything beyond rake init:oss as undocumented from the outside.

Editorial conclusion

Adopt this repository if you are contributing to the official WordPress iOS app, testing it against a self-hosted site, or building an internal client on top of WordPress.com REST and the Gutenberg XCFrameworks. Do not adopt it if you want a WordPress site running on an iPad, or if you expect a drop-in SDK you can add to an unrelated app: the README's setup is oriented around building and logging into this app, and login is restricted to the WordPress.com account that owns your client ID and secret. Before you invest time, check .xcode-version and .ruby-version against what you have installed, confirm you can create a Native application at developer.wordpress.com/apps, and decide whether you need the full workspace or only Package.swift.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. wordpress-mobile/WordPress-iOS on GitHub