Open phongvhd93 opened 2 years ago
@phongvhd93 how about the status of this RFC? 🙏
@phongvhd93 When using uFeatures
, we will be based on the tuist
tool and ignore the .xcodeproj
file, did you aware of this?
@phongvhd93 I am really interested in these uFeatures
, so I plan to convert my IC to use this to have a real feeling about it.
Will get back to you with feedback soon 👍
@phongvhd93 When using
uFeatures
, we will be based on thetuist
tool and ignore the.xcodeproj
file, did you aware of this?
Yes, it require to ignore the .xcodeproj
file
Issue
Apps are made of features. Typically these features are part of the same module or target where the whole application is defined - monolithic architecture. The natural inclination of the team is to continue building features. As a result, the application grows in complexity which manifests in bugs, bad compilation times, and team performance. What seemed to be good architecture didn't work out well in large codebases or teams.
The
µFeatures
main motivation is to support a scalable application. Features, helpers, and extensions can be separated into multiple modules and are called viaprotocols
. With this implementation, the build system won't have to build the whole project due to small changes in the implementation files, thus, reducing the build time. Secondly, features come with an example in each module so the developer can quickly test their implementation.µFeatures
missions:Also, applying
µFeatures
in the project will open a new door to build tools likeBazel
orBuck
, drastically reducing the build time.Benefits:
Solution
This POC is a working template of
µFeatures
template; what we need to do will be:monolithic architecture
orµFeatures
when initiating the project.POC
to match our project structure and adapt it to our template. (Most of the crucial codes locate inModule.swift
andProject+Templates.swift
).Who Benefits
iOS chapter
What Next?
µFeatures
.