Feedback from trying out Tuist Previews

I wanted to try tuist previews finally. Here’s some of the issues I ran into.

AppNameMobile for the Debug configuration was not found. You can build it by running tuist build AppNameMobile

Why does the output recommend tuist build if it’s deprecated over xcodebuild? I was wondering if release builds aren’t supported as the documentation only shows debug builds also. But later I found the —configuration flag so this was just a temporary confusion.

I was wondering, if caching should be used for these previews. Or standard advice applies debug yes, release not?

Then I had a target vs product name issue. I figured this out because passing a derived data app path worked. I did some debugging by running tuist share locally in Xcode. But the product name is used. The problem was that my product name was somehow wrong in the Graph even though it’s correct in the generated workspace. The root cause is that I didn’t know about the productName argument in the Target init. That init is very long. In hindsight I should have just copied and formatted to read it. I configured all my Tuist projects with a product name in the base settings dictionary e.g. base: [ “PRODUCT_NAME”: “App”]. Because that worked when I first learned how to use Tuist and I adapted my Project.swift from my first converted project.

Tuist could try to consider applying settings from the manifest for tuist share so it just works. It could also warn / inform the user to use this superior productName API.

The problem is also that these generated Swift API files don’t do formatting out of the box. I guess we can’t change that?

public static func target(name: String, destinations: ProjectDescription.Destinations, product: ProjectDescription.Product, productName: String? = nil, bundleId: String, deploymentTargets: ProjectDescription.DeploymentTargets? = nil, infoPlist: ProjectDescription.InfoPlist? = .default, sources: ProjectDescription.SourceFilesList? = nil, resources: ProjectDescription.ResourceFileElements? = nil, buildableFolders: [ProjectDescription.BuildableFolder] = , copyFiles: [ProjectDescription.CopyFilesAction]? = nil, headers: ProjectDescription.Headers? = nil, entitlements: ProjectDescription.Entitlements? = nil, scripts: [ProjectDescription.TargetScript] = , dependencies: [ProjectDescription.TargetDependency] = , settings: ProjectDescription.Settings? = nil, coreDataModels: [ProjectDescription.CoreDataModel] = , environmentVariables: [String : ProjectDescription.EnvironmentVariable] = [:], launchArguments: [ProjectDescription.LaunchArgument] = , additionalFiles: [ProjectDescription.FileElement] = , buildRules: [ProjectDescription.BuildRule] = , mergedBinaryType: ProjectDescription.MergedBinaryType = .disabled, mergeable: Bool = false, onDemandResourcesTags: ProjectDescription.OnDemandResourcesTags? = nil, metadata: ProjectDescription.TargetMetadata = .default) → ProjectDescription.Target

I also struggled a lot to login to the Tuist iOS app, because automatic password fill in or 1Password somehow breaks the Tuist login page. I posted a video in Slack.

Now that this works I’ll continue try using previews and report back, if I encounter anymore issues.

Hey, thanks for the feedback! That’s really helpful.

Right, I’ll update this to mention xcodebuild, we missed this when initially deprecating tuist build.

Yes, you can use caching for previews. We only don’t recommend using caching for app store builds.

I don’t know how common this is, but yeah, I suppose we could introduce a linter that recommends not to use this setting.

We could try to respect the PRODUCT_NAME from settings, yeah :+1:

No Swift files are doing formatting out-of-the-box? That’s been always dependent on third-party tooling.

We’ll fix that.

Merged the initial PR fixing the documentation/error message: fix(cli): replace deprecated tuist build recommendation in previews by fortmarek · Pull Request #9562 · tuist/tuist · GitHub

Thank you for the fixes.

No Swift files are doing formatting out-of-the-box? That’s been always dependent on third-party tooling.

AFAIK this is some generated header / interface file. I don’t think Tuist can fix this as this is for Apple / Swift / Xcode to fix, but I could be wrong.

I’d like this big func to use new lines for each argument.

The product name thing won’t matter to me anymore as I learned about the proper API now. I also don’t know how common it is. But it took me some hours to figure out why my product name doesn’t work.

Yeah, I don’t think there’s much we can do beyond moving to a builder pattern, unfortunately.

This should be fixed now: fix(server): Fix login slowness on Safari iOS by pepicrft · Pull Request #9599 · tuist/tuist · GitHub. Thanks for reporting it and let us know if you keep having issues with the login :slightly_smiling_face: