--- title: Why Large Swift Projects Hit a Wall (And How to Break... description: Large Swift codebases run into recurring pain points: slow build times, complex modularization, flaky and lengthy test suites, lack of build/test insights, and... canonical: https://daily.dev/posts/why-large-swift-projects-hit-a-wall-and-how-to-break-through--b4kavywxi twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Why Large Swift Projects Hit a Wall (And How to Break Through) | daily.dev og:description: Large Swift codebases run into recurring pain points: slow build times, complex modularization, flaky and lengthy test suites, lack of build/test insights, and... og:url: https://daily.dev/posts/why-large-swift-projects-hit-a-wall-and-how-to-break-through--b4kavywxi og:image: https://api.daily.dev/og/posts/B4KavYwxI.png og:image:alt: Why Large Swift Projects Hit a Wall (And How to Break Through) og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why Large Swift Projects Hit a Wall (And How to Break Through) **[ Tuist ](https://daily.dev/sources/tuist-blog)** · 18 min read · 0 upvotes · 0 comments ## Summary Large Swift codebases run into recurring pain points: slow build times, complex modularization, flaky and lengthy test suites, lack of build/test insights, and issues stemming from derived data. The post walks through why Apple's toolchain struggles at scale, contrasts common escape routes like React Native and Bazel, and explains how Tuist's generated projects, caching, selective testing, and dashboards address these problems. It also touches on Apple's own efforts (mergeable libraries, buildable folders, content-addressable store, explicit modules) to fix root causes like derived data and implicit dependencies. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What caching improvements does Tuist offer for large Swift project build times? Tuist's caching system, which mutates the project graph to substitute compiled binaries for source modules, delivers build time improvements of up to 80% in some organizations, with Trendyol reporting a 65% improvement. Tuist's own public dashboard shows cache effectiveness around 84%, and in one test run 122 modules were replaced with binaries. _Teams weighing build-time fixes for Swift projects can track approaches like this via daily.dev._ ### Why do teams outsource Swift dependency graph complexity to SwiftPM and what problems does that cause? Teams push modularization complexity onto SwiftPM to avoid maintaining their own dependency graph, but this trades away developer ergonomics because SwiftPM resolves projects asynchronously and unpredictably, meaning a project that used to be ready to compile at launch now depends on a background SwiftPM process reconciling with Xcode's legacy logic, causing friction and unreliable editor behavior. _Developers debating SwiftPM versus project-generation tools can follow this tradeoff discussion on daily.dev._ ### Why does deleting Xcode derived data cause problems in Swift projects? Derived data allows projects to compile because dependencies are accidentally found there rather than explicitly imported, so implicit imports can break editor features like macro expansion and Swift previews when derived data is cleaned and those implicit binaries disappear. Apple is addressing this with a content-addressable store and explicit modules that use hashes to look up compilation artifacts instead of relying on a shared derived data directory. _Engineers debugging flaky Xcode previews or clean-build failures can dig deeper into derived data issues on daily.dev._ ## Similar posts on daily.dev - [Toss: Building less to ship faster](https://daily.dev/posts/toss-building-less-to-ship-faster-1arhtus0n) · Tuist · 4 upvotes · 0 comments --- Tags: [#swift](https://daily.dev/tags/swift), [#xcode](https://daily.dev/tags/xcode), [#build-systems](https://daily.dev/tags/build-systems) [View this post on daily.dev](https://daily.dev/posts/why-large-swift-projects-hit-a-wall-and-how-to-break-through--b4kavywxi) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Why Large Swift Projects Hit a Wall (And How to Break Through)","url":"https://daily.dev/posts/why-large-swift-projects-hit-a-wall-and-how-to-break-through--b4kavywxi","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/why-large-swift-projects-hit-a-wall-and-how-to-break-through--b4kavywxi"},"datePublished":"2026-08-23T12:22:12.213Z","dateModified":"2026-08-23T12:52:47.908Z","description":"Large Swift codebases run into recurring pain points: slow build times, complex modularization, flaky and lengthy test suites, lack of build/test insights, and...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d83ac539f33d808549e9b7ea0abe5a37?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d83ac539f33d808549e9b7ea0abe5a37?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"\n Tuist\n ","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"\n Tuist\n ","logo":"https://media.daily.dev/image/upload/s--3AYDH23h--/f_auto,q_auto/v1787487506/logos/tuist-blog?_a=BAMAMicg0","url":"https://daily.dev/sources/tuist-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/why-large-swift-projects-hit-a-wall-and-how-to-break-through--b4kavywxi","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"swift,xcode,build-systems","timeRequired":"PT18M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"\n Tuist\n ","item":"https://daily.dev/sources/tuist-blog"},{"@type":"ListItem","position":3,"name":"Why Large Swift Projects Hit a Wall (And How to Break Through)"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/why-large-swift-projects-hit-a-wall-and-how-to-break-through--b4kavywxi#faq","mainEntity":[{"@type":"Question","name":"What caching improvements does Tuist offer for large Swift project build times?","acceptedAnswer":{"@type":"Answer","text":"Tuist's caching system, which mutates the project graph to substitute compiled binaries for source modules, delivers build time improvements of up to 80% in some organizations, with Trendyol reporting a 65% improvement. Tuist's own public dashboard shows cache effectiveness around 84%, and in one test run 122 modules were replaced with binaries. Teams weighing build-time fixes for Swift projects can track approaches like this via daily.dev."}},{"@type":"Question","name":"Why do teams outsource Swift dependency graph complexity to SwiftPM and what problems does that cause?","acceptedAnswer":{"@type":"Answer","text":"Teams push modularization complexity onto SwiftPM to avoid maintaining their own dependency graph, but this trades away developer ergonomics because SwiftPM resolves projects asynchronously and unpredictably, meaning a project that used to be ready to compile at launch now depends on a background SwiftPM process reconciling with Xcode's legacy logic, causing friction and unreliable editor behavior. Developers debating SwiftPM versus project-generation tools can follow this tradeoff discussion on daily.dev."}},{"@type":"Question","name":"Why does deleting Xcode derived data cause problems in Swift projects?","acceptedAnswer":{"@type":"Answer","text":"Derived data allows projects to compile because dependencies are accidentally found there rather than explicitly imported, so implicit imports can break editor features like macro expansion and Swift previews when derived data is cleaned and those implicit binaries disappear. Apple is addressing this with a content-addressable store and explicit modules that use hashes to look up compilation artifacts instead of relying on a shared derived data directory. Engineers debugging flaky Xcode previews or clean-build failures can dig deeper into derived data issues on daily.dev."}}]} ```