Skip to main content

ADR-005: Bundle ID User Experience Improvements

Status​

Proposed

Context​

The Per-App Profiles feature requires users to specify application bundle IDs (e.g., com.apple.Safari) to associate profiles with specific applications. The current implementation requires manual text entry of bundle IDs, which presents significant usability challenges.

Problem Statement​

Users must manually input exact bundle IDs, which:

  1. Requires technical knowledge most users don't have
  2. Is error-prone (typos are silent failures)
  3. Requires external tools (e.g., Terminal commands) to discover bundle IDs
  4. Creates friction in what should be a simple workflow

Current Workflow​

1. User wants to create profile for Safari
2. User must somehow discover "com.apple.Safari"
   - Option A: Run `osascript -e 'id of app "Safari"'` in Terminal
   - Option B: Find Info.plist in /Applications/Safari.app
   - Option C: Search online
3. User manually types bundle ID into text field
4. User may make typos that silently fail

User Research Findings​

From v4.9.0 feedback:

  • "Cumbersome Bundle ID input" - explicit user complaint
  • Users expect app picker similar to accessibility preferences
  • Manual bundle ID entry is a significant barrier to adoption

Decision​

Implement three complementary approaches to improve Bundle ID UX, to be implemented incrementally:

Phase 1: Current App Detection (v4.10.0)​

Add a "Use Current App" button that detects the frontmost application:

<button on:click={useCurrentApp}>
  Use Current App
</button>

Implementation: Already partially exists in ProfileManager.svelte (line 66-71). Needs to be surfaced more prominently and improved.

Trade-offs:

  • Pros: Simple to implement, no new dependencies
  • Cons: Requires user to switch apps, limited discoverability

Phase 2: Running Apps List (v4.11.0)​

Display a dropdown/list of currently running applications:

interface RunningApp {
  name: string;
  bundleId: string;
  icon?: string; // Base64 encoded app icon
}

async function getRunningApps(): Promise<RunningApp[]>

Implementation: Requires new Tauri command using macOS NSWorkspace API.

Trade-offs:

  • Pros: Shows familiar app names, works with running apps
  • Cons: App must be running, may show background processes

Phase 3: Application Picker (Future)​

Full file picker for .app bundles:

async function pickApplication(): Promise<{name: string; bundleId: string}>

Implementation: Use Tauri dialog API to select .app, then extract bundle ID from Info.plist.

Trade-offs:

  • Pros: Complete solution, works with any installed app
  • Cons: More complex, requires file system access

Implementation Details​

Phase 1: Enhanced Current App Detection​

  1. Make "Use Current App" more prominent - Move to primary button position
  2. Show current app info - Display name and icon of frontmost app
  3. Auto-populate on focus - When profile form opens, show current app suggestion

API Changes (Phase 2)​

// New Tauri command
#[tauri::command]
pub async fn list_running_apps() -> Result<Vec<RunningAppInfo>, String> {
    // Use NSWorkspace to get running applications
    // Filter to user-facing apps (exclude background processes)
    // Extract bundle IDs and icons
}

#[derive(Serialize)]
pub struct RunningAppInfo {
    pub name: String,
    pub bundle_id: String,
    pub icon_base64: Option<String>,
    pub is_frontmost: bool,
}

Platform Considerations​

PlatformCurrent AppRunning AppsApp Picker
macOSNSWorkspaceNSWorkspace.runningApplicationsFile dialog + Info.plist
WindowsN/A (Phase 2)N/AN/A
LinuxN/A (Phase 2)N/AN/A

Note: Per-App Profiles is currently macOS-only due to NSWorkspace dependency.

Consequences​

Positive​

  1. Improved usability: Users can select apps by name, not bundle ID
  2. Reduced errors: Eliminates typos in bundle ID entry
  3. Lower barrier: Non-technical users can create per-app profiles
  4. Better discoverability: Visual list shows available options

Negative​

  1. Platform-specific: macOS-only implementation initially
  2. API complexity: Multiple approaches need maintenance
  3. Privacy consideration: Showing running apps may be sensitive

Neutral​

  1. Manual entry remains: Power users can still type bundle IDs directly
  2. Incremental delivery: Phases can be prioritized based on user feedback

Alternatives Considered​

1. Bundle ID Autocomplete​

Autocomplete from a database of common bundle IDs.

Rejected: Database would be incomplete and require maintenance.

2. Accessibility System Integration​

Use system accessibility APIs to observe app switches.

Rejected: Requires additional permissions, over-engineered for the use case.

3. App Store Metadata​

Look up bundle IDs from App Store metadata.

Rejected: Not all apps are on App Store, requires internet, privacy concerns.

References​