QuranEngine opens the Quran.com iOS app as a six layer Swift package

This is the app itself, minus about one percent

QuranEngine is the open source iOS library that powers the Quran.com iOS app, and the repository contains approximately 99% of the Quran.com iOS App code, which the README frames as providing a well tested foundation to build Quran related applications. That framing matters for judging what you are adopting. This is not a collection of reusable snippets. It is the production application, packaged so that its layers can be consumed selectively, and the example project called QuranEngineApp mimics the Quran.com iOS app and lives under the Example folder. The stated reason for opening the code is in the intended use section, that the maintainers see benefits in allowing developers to build on top of what has already been built so that developers do not have to re-implement the foundation and can innovate on the idea itself. The licence is Apache-2.0, and the repository is not archived with the last push on 2026-10-19.

Swift Package Manager only, and version pinning is done by commit

The requirements are specific and narrow on purpose. Xcode 26 or later is needed, with CI building with Xcode 26.2, and the deployment target is iOS 15 or later. The distribution method is Swift Package Manager, and the README states plainly that CocoaPods and Carthage are not supported and are not planned to be. Adding the package looks like this:

.package(url: "https://github.com/quran/quran-ios", branch: "main")

Then you depend on one or more of its targets, and every target is available as a product, for example:

.product(name: "AppStructureFeature", package: "quran-ios"),

The pinning story has a catch worth reading carefully. To pin a release you use the commit of its tag with a revision, and releases are tagged with the app's version. Version requirements such as from: do not work, because QuranEngine depends on a package that is pinned to a branch. That is a structural limitation of the dependency graph rather than a preference, and it means a consumer who wants reproducibility has to resolve the commit by hand.

Six layers with the arrows enforced by the package manifest

The architecture is the most reusable thing in the repository, and the constraint is enforced in code rather than in a convention. The library is split into six layers, each a top level directory. Core holds general purpose libraries that work with any app, with the Localization library named as the exception the maintainers aim to make more universal. Model contains simple entities that facilitate building a Quran app, and these mostly work together without extensive logic. Data covers persistence and networking, namely SQLite through GRDB, Core Data, downloads, authentication and the sync backed stores, with these libraries abstracting away the underlying technologies. Domain is where the business logic resides, depending on Model and Data. UI houses the design system used by the app, called NoorUI, built with SwiftUI while navigation stays in UIKit, and it may depend on Core and Model but not on Domain or Data. Features comprises the screens making up the app, and features can nest inside features, with AppStructureFeature hosting all the others to create the app. A layer may import any layer it can reach by following the arrows, plus other targets in its own layer.

Package.swift refuses to load a manifest that breaks the layering

The dependency rules are not advisory. Package.swift enforces them, with TargetType.validDependencies listing what each layer may import and validateDependenciesStructure stopping the manifest from loading when a target breaks the rule. That is a stronger guarantee than a documented convention, because a violating target is a build failure rather than a review comment. The dependency graph is drawn in the README as a flowchart, and the arrows carry the whole rule set. Features depend on Domain and UI, Domain depends on Data, Data depends on Model, UI depends on Model, and Model depends on Core. The sync package, mobile-sync-spm, appears as a dashed dependency of Data, Domain and Features, with the note that QURAN_SYNC builds only. The rest of the top level directories support the build rather than the architecture. Example holds QuranEngineApp, Tools holds developer scripts such as terminal SwiftUI previews and app icon export, Documentation holds guides for specific workflows, and AllTargetsTests links targets without their own tests so coverage reports include them.

Every build and test command states its sync mode explicitly

The build system is a Makefile rather than an Xcode scheme marathon, and one decision runs through all of it. Every build and test command names its sync mode. QURAN_SYNC turns on Quran.com account sync, which adds the mobile-sync-spm package, and the -no-sync and -sync targets set it explicitly so a value left in your shell never changes the build. Code behind the conditional compilation flag must compile in both modes, which is the constraint that makes the two variants meaningful rather than one being a neglected copy. The commands are short:

# Build the package, or one scheme
make build-no-sync
make build-sync TARGET=NoorUI

# Run the complete package test plan
make test-no-sync
make test-sync

# Run one test target through the package test scheme
make test-no-sync TARGET=AyahMenuFeature
make test-sync TARGET=AyahMenuFeatureTests

# Check formatting
make format-lint

For test commands the TARGET variable accepts either the production target or its Tests target, and new test targets must also be added to QuranEngine-Package.xctestplan, which is the file that runs the whole plan. The Makefile also carries the simulator plumbing, with a destination defaulting to an iPhone 17e on the latest OS, and a shell expression that asks simctl for the newest installed runtime version, because the tool needs a concrete runtime to locate the device.

Running the example app is one make target and a simulator

The quickest way to see the whole stack work is the example application, and the entry point is a single target:

make run-example-no-sync

That builds QuranEngineApp, boots an iPhone simulator on the latest installed iOS, installs the app and launches it, and there is a sync enabled counterpart, make run-example-sync. The Makefile variables show what the example build controls. The project and scheme point at Example/QuranEngineApp.xcodeproj and QuranEngineApp, the bundle identifier is com.quran.QuranEngineApp, and the resources directory is Example/QuranEngineApp/Resources, with derived data written to .build/DerivedData. There is also a Tools directory for developer scripts, and the documentation links explain how to run a file's SwiftUI previews on a simulator with make preview, and how to do local development against the mobile-sync checkouts including the OAuth settings.

The maintainers ask for a conversation before a large pull request

The contribution guidance is specific about process, which is a good sign for a repository that is mostly one application. The project welcomes contributions and encourages contributors to tackle open issues, with the instruction to start a conversation in the Discussions section. For small contributions the maintainers say a pull request can be created directly, while for larger ones they ask for a discussions post first, and the reason given is practical, that it lets them make sure nobody else is working on the same feature and lets them plan for upcoming features in case the contribution depends on another one. AGENTS.md is the file that describes the conventions for architecture, UI, concurrency and tests, with the instruction to run make format-lint before opening a pull request. The maintainers also state a known gap plainly, that UI and Features still have less test coverage than the foundational layers, so new behaviour there should include focused tests where practical. The repository carries swiftlint.yml, a .swiftformat configuration, a .swift-version file and a .swiftpm directory.

Where QuranEngine is the wrong choice

Three situations argue against it. The first is a project that only needs Quranic text. A reading application with a list of surahs and a text view needs data and a screen, not a six layer stack with a design system, a sync engine and an account backend, and the maintainers themselves note that you may need to bring your own data. The second is a team that cannot work inside the toolchain constraints. Xcode 26, iOS 15, Swift Package Manager only and no CocoaPods, plus the fact that from: version requirements do not resolve because a transitive dependency is pinned to a branch, means the onboarding path is steeper than a typical package. The third is a non-Apple platform. The whole repository is Swift with SwiftUI components and UIKit navigation, and while the text data itself is portable, nothing in the engine is. The licensing and reuse terms are worth reading in one place as well. The project is Apache-2.0, and the intended use section asks that the QuranEngineApp example not be republished without modification, which is a narrower restriction than the licence itself and one that matters if you were planning to ship the example app as your own product.

Editorial conclusion

Adopt QuranEngine when you are building a Quran reading or memorisation application and want the data layer, sync and design system of the Quran.com app rather than writing them, and skip it if you only need text of the Quran, which does not require a full application stack. Verify first that you can pin a release, since version requirements such as from: do not work because the package depends on something pinned to a branch, so you pin the commit of the tag instead, and read AGENTS.md for the architecture, UI and concurrency conventions before contributing.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. quran/quran-ios on GitHub
4. README
5. Releases