Element Classic iOS for Matrix Collaboration

What Element Classic iOS Does

Element Classic iOS is a Matrix collaboration client for iOS. It is intended for people who communicate through Matrix rooms and for developers who maintain, extend, or integrate with the Classic iOS codebase. It is not presented as a general-purpose messaging framework or a server administration interface. Its role is the mobile client layer for participating in Matrix-based collaboration.

The repository contains both Swift and Objective-C, as indicated by its language badge. Code is divided into application areas such as `Riot/`, `RiotSwiftUI/`, `CommonKit/`, and `DesignKit/`, with separate entries for `BroadcastUploadExtension/`, `RiotShareExtension/`, and `SiriIntents/`. This layout describes a native iOS application with shared components, configuration, and extension targets.

The most important adoption fact appears near the beginning of the README: Element Classic iOS is a previous-generation Matrix client. It remains supported and receives security updates, but no new features or usability enhancements are being added. The README calls Element X the next-generation mobile app and recommends it instead. A team starting a new mobile deployment should therefore treat Classic as an existing product line rather than the default choice for every Element requirement.

That boundary does not make Classic unusable. Existing users, managed deployments, or integrations tied to the current application may still need the codebase. The decision depends on whether maintaining compatibility is more valuable than obtaining access to new mobile work.

MatrixSDK and the Client Architecture

Element Classic iOS is based on MatrixSDK. The README links to the MatrixSDK repository, and the repository structure includes `matrix-ios-sdk` as a top-level entry. This connects the application client to a separate SDK for Matrix operations rather than presenting the repository as a self-contained protocol implementation.

The available architecture evidence is structural. `Riot/` appears to contain the main application, while `RiotSwiftUI/` points to SwiftUI-specific code. `CommonKit/` and `DesignKit/` separate reusable application components and interface resources from the principal target. `Config/`, `Podfile`, `Podfile.lock`, `Brewfile`, and `Brewfile.lock.json` indicate configuration and dependency management as explicit parts of the development setup.

Other entries show that the project covers more than a single application screen. `BroadcastUploadExtension/` and `RiotShareExtension/` are distinct extension targets, while `SiriIntents/` indicates integration with system intents. The repository also contains `RiotNSE/`, although the README does not explain the exact behavior of that target.

The README does not document a room-level state sequence, event synchronization flow, encryption boundary, push-notification lifecycle, or account migration mechanism. It would therefore be speculative to claim exactly how events move between MatrixSDK and each interface component. Developers evaluating changes at those boundaries need to inspect the relevant source, the MatrixSDK documentation, and the files named by INSTALL.md.

Building Riot.xcworkspace with Xcode

The README provides a short source-build path for developers who already have the required tools installed. The commands generate an Xcode project, install CocoaPods dependencies, and open the workspace. Run them from the repository root. After the last command, Xcode should display `Riot.xcworkspace`, which combines the generated project with its installed dependencies.

$ xcodegen                  # Create the xcodeproj with all project source files
$ pod install               # Create the xcworkspace with all project dependencies
$ open Riot.xcworkspace     # Open Xcode

This workflow has two prerequisites implied by the commands. `xcodegen` must be available because `project.yml` is used to create the `.xcodeproj` with project source files. CocoaPods must also be available because `pod install` creates the workspace from the pod configuration. The repository includes lock files such as `Podfile.lock` and `Brewfile.lock.json`, but the README does not specify the relevant tool versions in its short build example.

Developers who lack those prerequisites are directed to `./INSTALL.md`. That file is the repository's stated source for installation requirements and advanced configuration, including use of a development version of MatrixSDK. The README does not document signing settings, bundle identifiers, deployment targets, required device types, or the exact scheme used for a first launch. Those details should be taken from INSTALL.md and the project configuration rather than guessed from the repository name.

For an end user rather than a source contributor, the README points to the Element listing in the Apple App Store. The project also documents a TestFlight Public Link for the latest beta build and directs questions about it to `#element-ios:matrix.org` on Matrix.

Security Updates Without Classic Feature Development

Element Classic iOS is not archived. Its last push was on 2026-09-24. The listed release history also includes `v1.11.41` on 2026-09-24, `v1.11.39` on 2026-06-23, and `v1.11.38` on 2026-05-27. These facts show repository and release activity after the Swift 5.x project badge was added.

Recent activity does not change the product boundary stated by the maintainers. The README explicitly says that Classic receives security updates but no new features or usability enhancements. Maintenance cost for an adopter is therefore tied to operating and integrating an established client. There is no documented commitment to adding new collaboration features or modernizing its user experience.

Upgrades can still create engineering work. The source build relies on project generation, CocoaPods, Xcode configuration, and MatrixSDK alignment. A fork may also need repeated review when dependencies or security fixes change. The README does not explain automated release deployment, App Store review timing, TestFlight enrollment limits, or a compatibility matrix for supported iOS and Matrix server versions.

The README lists `CHANGES.md` and the repository includes `changelog.d/`, but it does not explain how release notes are generated or how consumers should interpret individual version changes. Teams maintaining a Classic deployment should inspect those files for the relevant release instead of treating every repository push as a user-facing feature release.

Element Classic Licensing and Distribution Choices

The repository identifies Element Classic iOS as dual licensed by New Vector Ltd. The README presents two paths: use under the GNU Affero General Public License, either version 3 or, at the user's option, a later version, or use under a paid-for Element Commercial License agreement between the user and Element.

The commercial path is agreement-based. The README says that its terms may vary depending on what the parties have agreed, so the repository does not describe one fixed commercial price or one universal set of commercial permissions. The application is also distributed through an Apple App Store link, while the repository includes separate `LICENSE` and `LICENSE-COMMERCIAL` files.

Anyone modifying, redistributing, or commercially deploying the code should determine which license terms apply to the planned use and read the exact files. This review is especially relevant to forks, private distribution, and products that embed or adapt the client. The repository information establishes the available licensing models, but it does not answer whether a particular organization qualifies for either option.

The App Store download and the source repository serve different use cases. App Store users receive the published application, while source adopters take on Xcode, CocoaPods, configuration, signing, dependency, and release responsibilities. The README does not claim that source builds are automatically eligible for App Store distribution.

Choosing Between Element Classic and Element X

Element X is the documented alternative. The README describes it as the next-generation mobile app and recommends it for new users. That is a direct difference in product direction: Element Classic iOS remains a previous-generation Swift and Objective-C client based on MatrixSDK and receives security maintenance, while Element X is positioned as its successor.

The distinction should not be reduced to a claim that Element X is faster or simpler. No performance measurements, resource comparisons, feature matrix, or migration guide appear in the README. It does not explain whether account data transfers automatically, whether local encryption state is compatible, how push notifications change, or whether administrators can migrate managed devices in place.

Classic is the wrong choice when the application is being selected primarily for future feature development or usability improvements, because the maintainers explicitly exclude both from its current development scope. Classic becomes relevant when an existing user base, internal fork, test setup, or integration depends on the Classic client. In that case, the immediate questions are operational: whether security updates meet the organization's requirements and how much maintenance the fork requires.

Element X is the first project-specific check for a new deployment. Before choosing it, verify the Matrix server configuration, account migration expectations, managed-device support, notification requirements, and release channel against the organization's needs. Before staying with Classic, review the security changes in the intended release and confirm that the existing integration does not depend on undocumented behavior.

Editorial conclusion

Adopt Element Classic iOS when maintaining an existing Matrix iOS client or when compatibility with the Classic codebase matters. Do not select it for a new product when Element X is available, because the project explicitly limits Classic to security updates without new features or usability enhancements. Before committing, verify the required Apple development environment, inspect INSTALL.md, and assess whether existing integrations constrain the migration to Element X.

Frequently asked questions

Official sources

1. element-hq/element-ios on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases