<div dir="ltr">As our iOS project has grown, compile times have also increased, all the way upto 12 mins for a clean build, for around 600 swift files.<br><br>I was going through how to improve build times and found this archive<br><a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160815/002739.html">https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160815/002739.html</a><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">On Wed, Apr 13, 2016 at 5:18 PM, Samantha John <<a href="https://lists.swift.org/mailman/listinfo/swift-dev">sam at gethopscotch.com</a>> wrote:
Hi Jordan,
The thing that sticks out in the dependency analysis is the treatment of external dependencies. The entire module has the same list of external dependencies which causes a lot of needless recompiles- especially if you start with a large swift project and slowly start to move things into modules.
So to me the lowest hanging fruit would be to only mark files for recompilation that explicitly import the external dependency. This seems pretty safe since you can't compile unless the dependency is explicitly imported. Has anyone on the list tried this before? </pre></blockquote><div><br>We've been planning to move our project files to smaller frameworks/modules.<br>But the problem we'd face would be changing any file in any of the smaller framework/module would lead to a full rebuild because this framework will be listed as a dependency in every swift file in the project.</div><div><br></div><div>So i'm planning to only mark the current imports on the swift files as the external dependency for that file.<br>Before i begin i wanted to confirm if this will work, or if someone has already tried this.<br>Any help is appreciated.<br><br>Thanks,<br>Asif </div></div>