wikipedia-ios: two schemes point at production servers

The setup script only works from the repository root

There is one prerequisite the readme states as a hard requirement: Xcode, at version 16.0 or newer.

After that there is a script, and it comes with a warning. Run it in the repository directory. Going into the scripts directory and running it from there will not work, because of relative paths. That is a small sentence with a large practical cost, because a script that fails on a path assumption tends to fail halfway through, after it has already installed things.

What the script does is worth reading before you run it. It assumes Xcode is already present, and it installs a package manager, a Swift linter and a C formatter, then creates a pre-commit hook that runs the formatter over Objective-C code.

There is an alternative for anyone who would rather not have a script modify their machine. The readme lists the three prerequisites to install yourself: Xcode, obtainable from the App Store or downloaded from the developer site if you have an Apple ID registered with an Apple Developer account; the Swift linter; and the C formatter.

Once one of the two paths is done, you open the Xcode project and run the app on the simulator using the scheme and target named in the description.

Two languages, two linters, two formatting configurations

The codebase is written in two languages and the tooling treats them differently.

For Objective-C, the coding guidelines are Apple's Cocoa guidelines, and formatting comes from a clang-format configuration file at the repository root, applied by the pre-commit hook the setup script installs.

For Swift, the coding guidelines are the API design guidelines published by the language's own site, and formatting is automatic through the Swift linter, using a separate configuration file for autocorrection and another for the rules themselves. All three files sit at the root.

Indentation is Xcode's default of four spaces, stated rather than enforced by a formatter.

The document is careful about its own authority. It calls these general guidelines rather than hard rules, and it points process and code review norms at a separate document inside the repository. So the difference in treatment is not an oversight: the Swift side can be machine-fixed, and the Objective-C side is left to a hook and a reviewer's judgement.

For a contributor, that means a Swift change will be rewritten by a tool and an Objective-C change will not, which is worth knowing before you spend an afternoon on formatting.

The unit tests only pass on an en-US device

Testing is documented in one short section and it contains a condition that will stop you.

The main scheme is configured to run the project's iOS unit tests, and you start them with a keyboard shortcut or a menu action from the product menu. Then there is the requirement: for the tests to pass, the test device's language and region must be set to a specific locale pair, in the general settings under language and region.

So this is a test suite with an implicit precondition on the machine it runs on. A developer with a phone set to any other language sees failures that have nothing to do with the code they changed.

The project knows it. The readme links a ticket filed to update the tests so that they pass regardless of language and region. That ticket existing is the useful detail: it tells you the constraint is known, tracked and not yet fixed, rather than something you have misconfigured.

For anyone evaluating the project, this is the single most concrete fact in the readme about what it costs to contribute: a device setting you have to remember before the tests mean anything.

A release build writes only warnings and errors to the console

The logging section describes a scheme you have to know before you read any output.

Log levels are shortened to emoji rather than words, and the readme enumerates them: a speaking face for verbose, a speech bubble for debug, an information mark for info, a warning triangle for warning, and a siren for error. So a line in a console log is prefixed with a symbol rather than a level name, which is compact and unambiguous once you know the mapping.

The part that matters comes next. The app writes only warning and error messages to the console, and it does so in both debug and release mode.

That means a release build from the app store is nearly silent. If a user reports a problem and you need to see what happened, the default level will not show you the informational lines that would explain it.

The escape hatch is documented and it is temporary by design. You change a level in the logging header file to the value that logs everything, and the readme frames that as something to do while troubleshooting rather than a setting to keep. So the answer to reproducing a production report is: rebuild with a raised level, which is more work than reading a log file, and is why the section exists at all.

Two schemes point at production, and a third defaults to it

The scheme list is the longest section of the readme and the most useful, because it is where an engineer's taps become requests to Wikimedia infrastructure.

The main scheme points at production servers. That is the default and it is what the quick start tells you to run.

The experimental scheme also points at production by default. It is described as being for one-off builds that demonstrate early development or prototype features, adjustable to any environment through temporary changes in the shared configuration, and the readme notes it is sometimes used for design review before a feature goes through review. So a scheme meant for prototyping is wired to production unless someone edits a property.

The local scheme is more reassuring and less absolute. It is for debug mode only, and it offers two switches: one pointing at a locally running page content service, and one pointing at a locally running announcements service. Both are selected by default. Then the sentence that matters: all other endpoints will point to production.

So even a fully local debug configuration talks to production for every endpoint nobody remembered to override. That is the honest reading of these three lines, and it is the one to check before you run anything.

Staging and Experimental reach TestFlight as separate apps

Two of the schemes are not only environments but separate shipped applications.

The staging scheme points at a beta cluster environment, and that option is described as a blanket setting: if it is selected, it also forces the beta cluster for page content on the article view, not just for most API calls. A second option points only the page content at a different staging environment. The beta cluster is also where developers test sandbox push notifications triggered across various wikis. That option is the default for the scheme.

The staging scheme also has feature flags turned on, which means it displays features that are still in development, and it is pushed to TestFlight as its own app.

The experimental scheme is pushed to TestFlight as a separate app too. Its stated uses are one-off builds, demonstrating early development or prototypes, and design review before a feature goes through pull request review.

So a tester installing from TestFlight can end up with three apps with the same name from the same project and different behaviour, and the only way to tell them apart is which scheme produced the build. That is worth knowing before you file a bug against the wrong one.

Four directories in the root have spaces in their names

Here is a layout detail that will cost somebody an afternoon.

Four of the top-level directories have spaces in their names: one for command line tools, one for test plans, one for the shared framework whose name begins with the project's three letter prefix, and one for sticker artwork.

The rest of the root is conventional: the main app directory, the widgets, the continue reading widget, the notification service extension, the components, data, localisations and test-kitchen directories, the Xcode project, the UI test and unit test directories, a configuration directory and an icon directory.

Spaces in directory names are a recurring source of quoting mistakes in shell scripts, in continuous integration paths and in tool configuration, and here they are in the root of a repository that has both a scripts directory and a CI scripts directory. Nothing suggests the project treats this as a problem; it is simply what the tree looks like, and it is worth knowing before you write a script that walks it.

The same root also carries two version pins for runtimes you would not expect in an iOS application, which the next section is about.

Three pinned runtimes for an app with two languages

A native iOS app does not usually need a Ruby manifest and a Node version file, and this repository has both.

At the root there is a version file for Ruby, a version file for Node, a gem manifest with a lock file, a release automation directory, a CI scripts directory, and a general scripts directory. The Ruby side is for the mobile release pipeline; the Node pin suggests some tooling runs on Node.

There is also a JavaScript lint ignore file at the root, which points at a JavaScript component inside an application whose primary language is Swift and which also contains Objective-C. So the build has three language toolchains, two of which are for tooling rather than for the app.

Add the lint configuration files and the picture is complete: a clang-format file for Objective-C, two Swift linter configurations, and a JavaScript ignore file. The app itself spans an app directory, a framework directory shared with its extensions, widgets, a notification service extension, and separate unit and UI test targets.

The release tags follow a pattern worth noting. The three newest are dated names inside a releases namespace, dated 2026.09.29, 2026.09.15 and 2026.09.04, and the corresponding releases were published a day, a day and four days later. A date-based tag rather than a version number means the branch name is the release identity.

Editorial conclusion

This repository fits an engineer who wants to work on the official app and is willing to accept a slow setup path in exchange for an accurate picture of how a Wikimedia app is actually built and reviewed. Three things to know before your first build. The setup script only works from the repository root, and it installs a package manager plus two linters on your machine without asking. The unit tests fail unless the device language and region are set to one specific pair, and a ticket is already filed about it. And two of the schemes point at production servers by default, with a third pointing everywhere it has not been overridden at production, so check which scheme your run action uses before you tap run. Everything else in the readme is either a link to MediaWiki or a link to a file in the tree.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes