Can support be added for /usr/bin/open -F which causes an app to open in a fresh state without restoring other windows?

@nickkaczmarek would you like to go ahead an open a PR?

Hi, @nickkaczmarek. I’m Dosu, and I’m helping the tuist team manage their backlog and am marking this issue as stale.

Issue Summary

• You requested support for the /usr/bin/open command’s -F flag in Tuist to open apps in a fresh state.
• This feature aims to help avoid package resolution errors when working with multiple projects.
• You suggested an option like --no-open to enable this behavior without changing existing defaults.
• A maintainer encouraged you to submit a pull request to implement this feature.
• The issue remains unresolved with no further updates or contributions.

Next Steps

• Please let me know if this feature is still relevant to the latest version of Tuist by commenting on this issue.
• If I do not hear back within 7 days, I will automatically close this issue.

Thanks for your understanding and contribution!

Thanks @dosubot

I think this request still has value but I just haven’t had time to work on it.

@pepicrft Could you please assist @nickkaczmarek with this feature request for the /usr/bin/open -F flag support in Tuist? Thanks!

@pepicrft Could you please assist @nickkaczmarek with this feature request for the /usr/bin/open -F flag support in Tuist? Thanks!

I have that draft MR open. I just have to actually do the work. But like I said I still think this would be a good behavior to enable for users.

Don’t think I need much more assistance here in the issue. I just need time to do the work.

@nickkaczmarek which API do you have in mind? Would the following make sense:

let tuist = Tuist(project: .tuist(generationOptions: .options(
  openArguments: ["-F"]
)))

@nickkaczmarek which API do you have in mind? Would the following make sense:

let tuist = Tuist(project: .tuist(generationOptions: .options(
  openArguments: ["-F"]
)))

I was thinking this would be something we’d pass as part of a generation command via the cli. Essentially what I’m going for is I have many Xcode things open, I’ve quit Xcode, and now I’d like to generate but have only the thing I’m generating open.

My particular use case is at work I often have many instances of Xcode open and sometimes I’d like a clean slate when opening our monorepo. So what I do today is quit Xcode then run open -F to get a clean Xcode and then generate.

Importantly though I see this as an option and not a default. I don’t want to always clean open but I’d like the option to without having to know how open works.

I guess this might also be useful for things like edit and other commands I’m less familiar with. The issue that led me to the behavior is that every instance of Xcode freezes if even one of them does and to mitigate that I just close them all unceremoniously.

In that case, what about:

tuist generate --open-args "-F"

That way the caller has full flexibility to decide which arguments they’d like to pass to the underlying open process.

In that case, what about:

tuist generate --open-args "-F"

That way the caller has full flexibility to decide which arguments they’d like to pass to the underlying open process.

Yeah that seems like it would work. Though I wonder if that implies other open options are available.

Hi, @nickkaczmarek. I’m Dosu, and I’m helping the tuist team manage their backlog and am marking this issue as stale.

Recap

• You opened this issue to request an opt-in way for Tuist to pass /usr/bin/open -F when generating/opening projects.
• The goal is to start Xcode in a fresh state so it doesn’t restore previously open windows, which can help avoid package resolution and stability issues.
• @pepicrft suggested exposing this as a CLI flag such as tuist generate --open-args "-F", and you said that approach would work.
• The issue is still unresolved, and you mentioned you still intend to work on it but haven’t had time yet.

Next Steps

• If this is still relevant on the latest version of Tuist, please comment here to keep the discussion open.
• Otherwise, this issue will be automatically closed in 7 days.

Thanks for your understanding and contribution.