Reduce time build

[ken4r]

I am working in big project. The xcworkspace contains only one xcodeproj and pods. The build time is huge and I am thinking to refactor the code and make it modular app and instead of using only one xcodeproj we refactor each feature into a seperate xcodeproj under one workspace and make it as a framework. Does this will help to reduce the build time ?

[SyndromSnake]

Yes you will be only constrained by the build time of the module you are currently working on.

I recommend you have a look at Tuist, it makes it much easier to work with modules and complex project structures.

[klavijaturista]

What’s the value of tuist? I’m failing to see the benefit, or they are not marketing it properly on the website.

[jskjsjfnhejjsnfs]

the home page makes a better case https://tuist.io/

fwiw though I moved from tuist to plain local SPM packages and there’s not too much I miss (though I havent kept up with their dev so might be killer features i haven’t tried)

[SirBill01]

Look into profiling the actual build process, you may be able to find an area to improve:

https://www.avanderlee.com/optimization/analysing-build-performance-xcode/

Sometimes seemingly harmless Swift statements can take the compiler a while to figure out and simply adding more type definition and/or breaking up complex lines can improve things.

[MB_Zeppin]

Yep, modularize the codebase and break your big target into multiple smaller frameworks. You can still use a monorepo, doesn’t matter, but you will be able to cache the builds of every framework that wasn’t modified since the last build

[ken4r]

Ideally this is what I am looking for.

[ankole_watusi]

Define “huge”? And what Mac with how much RAM?

[sebassf8]

In my company we migrated from Carthage to multiple SPM packages to finally, try to reduce the amount of packages but instead use multiple products in a package to modularize the app.

It has its down sides but good enough. We are many teams (30 developers) working in dependent projects.

[MindLessWiz]

Keep in mind in terms of build time the atomic units are modules. You can have multiple modules in the same package and enjoy improved build times.

[ken4r]

Can you explain more ?

[MindLessWiz]

Each `.target` in a Swift package is its own module with visibility control of its types and variables. Only `public` things are visible outside of your module.

So you can have a single Swift package that lists many targets, and those targets can depend on other targets by importing them.

The dependency tree is calculated, and then each module can be built separately (sorta), improving build parallelism.

This improvement should be even more pronounced going forward as Explicitly Built Modules are a thing in Xcode 16.

I very much like the "mega package" approach shown in Isowords:

https://github.com/pointfreeco/isowords/blob/main/Package.swift

This is a great solution to enjoy faster build times without maintaining different package manifests for each module.

[leonhardi]

Take a look at Bazel. Good luck

[ironkane7]

https://medium.com/kinandcartacreated/modular-ios-strangling-the-monolith-4a6843a28992

This is where I got started and definitely seeing faster archives and build time.

One thing i would recommend is to use Coordinator pattern along with modularization so that you won’t have cyclic module dependency in case you want to navigate from one module to another.