You shouldn’t need to import any preview-only related module if you have those, yes.
What is the point of having a PreviewsModule
? Previews should be as close to the code they are previewing – I feel a module dedicated to previews is somewhat of an antipattern.
Yes, you should be able to, but again, this is not a setup I’d recommend.
One thing I’m missing here is also – what exactly doesn’t work? How is your issue manifesting?
I think I got it and found solution. @marekfort could you check is it right way?
At first my project folders:
MyApp/
├── Project.swift
├── Workspace.swift
├── Modules/
│ ├── App/
│ ├── SharedViews/
│ └── Previews/
└── Tuist/
All modules I make as targets and described in Project.swift
file. So:
- App - has .app product
- SharedViews - has .framework product
- Previews - has also …framework product
All works fine. Also, for now I think it is redundant to make separeted Previews
module because SharedViews
is individual module and can show SwiftUI previews without building the main app bundle.
Is it right approach? How I can improve it? For now I’m enjoyed and get all that I wanted at the start of the my investigation.
Exactly, that’s the setup I’d consider adoptiong.
For better app launch times, you might want to consider making SharedViews
a static framework instead of a dynamic one – but a dynamic framework is better for development (and it certainly makes previews more reliable). I suggest reading the following documentation page for the pros/cons of static/dynamic frameworks: Dependencies · Projects · Develop · Guides · Tuist