Suggestion: Activate SweetPad only per relevant workspace/project (avoid global UI in non-iOS projects)

[RbBtSn0w]

Background

SweetPad is a great extension for iOS/Swift development in VS Code and Cursor. It aims to provide a full Xcode-like workflow inside the editor. Many thanks to the maintainers and contributors!

Problem
Currently, SweetPad activates and shows its UI (panel/sidebar/views) even in workspaces or projects unrelated to iOS/Swift/etc. For example, when working on a pure Python or frontend (JS/TS) project, SweetPad still loads its UI and possibly services, cluttering the VS Code interface and affecting the user experience. This is especially problematic for developers who work on many types of projects in a single editor, or in large monorepos with mixed languages.

Why does this happen?
The extension is globally activated or uses broad activationEvents. As a result, it doesn't check if the current workspace is relevant (contains Xcode projects, Package.swift, Podfile, etc.), so it always loads regardless of project type.

Proposal / Suggestions

• Use more specific activationEvents in package.json (e.g., onLanguage:swift, workspaceContains:Package.swift, workspaceContains:Podfile, onCommand:sweetpad.openPanel).
• Add a runtime check in the extension's activate() function: scan the workspace for iOS/Swift markers (e.g., .xcodeproj, .xcworkspace, Package.swift, Podfile). Only fully activate/register UI if such files exist.
• Provide a user/workspace config (sweetpad.autoActivate) so users (or workspaces) can opt to always, never, or only-on-detect activate SweetPad.
• Register non-intrusive commands (such as 'Open SweetPad Panel') as onCommand activation events so users can still force-load if needed.

Pros

• Greatly improves multi-language and mono-repo developer experience—users aren't distracted by unrelated panels.
• Reduces unnecessary extension/service startup in non-iOS workspaces, possibly improving performance.
• Aligns with common VS Code best practices for "smart" workspace-specific extensions.
• Fewer bug reports and confusion from users working outside Swift/iOS projects.

Cons / Trade-offs

• Detection logic (for iOS/Swift relevance) may need refinement/maintenance to catch all cases.
• Slightly more complex activation code may be required.
• A (rare) user with a single Swift file might miss automatic activation (but can still use the command to enable manually).

Request for Comments
Would the maintainers and community consider improving SweetPad's activation as described? Preferred default: only enable SweetPad when iOS/Swift/Xcode markers are detected, but allow override via configuration.

Thank you all for your excellent work on SweetPad!