Replace deprecated Carbon foregrounding on macOS with NSApplication

[damianrickard]

On macOS, the GUI was brought to the foreground using the Carbon Process Manager (GetCurrentProcess / TransformProcessType / SetFrontProcess via <ApplicationServices/ApplicationServices.h>). These APIs have been deprecated since macOS 10.9 and are removed from recent SDKs, making the current code a latent build/runtime break.

This moves the foregrounding into a small Objective-C++ helper, SetMacOSXAppForeground(), using the modern AppKit equivalents: [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular] (the documented replacement for TransformProcessType) and activateIgnoringOtherApps:. The call site in Main.cpp and its -psn_ guard are unchanged.

The helper lives in a new MacOSXAppActivation.mm/.h, following the same C++-callable pattern as MacOSXSecureTextFieldHotkeys, and is compiled/linked only on macOS (added to the existing MacOSX block in Main.make). No other platform is affected.

[idrassi]

Thanks for the PR. I agree that removing VeraCrypt’s direct use of deprecated Process Manager APIs is desirable, but I don’t think this implementation is safe as-is.

The new helper calls [NSApplication sharedApplication] from main before wxWidgets initializes the GUI app. On wxOSX, wxWidgets creates its own wxNSApplication subclass during DoInitGui for Cocoa event handling, including command-key key-up behavior. If a plain NSApplication singleton already exists, wxWidgets can't replace it with its subclass, which can cause subtle keyboard/menu event regressions.

Also, wxWidgets 3.2.10 already handles the non-bundled app activation case internally after creating wxNSApplication, by setting NSApplicationActivationPolicyRegular and activating the app. So I think the better fix is either to remove VeraCrypt’s pre-wx Carbon foregrounding block and rely on wxWidgets, or otherwise rework this so wx’s NSApplication subclass is created first.

One factual note: with the current Xcode SDK, these Process Manager APIs are still declared, so the issue is deprecation warnings, not immediate SDK removal.

Could you please revise the approach and include macOS runtime testing for:

• normal launch of /Applications/VeraCrypt.app from Finder,
• LaunchServices launch of the app bundle, including the -psn_ case,
• direct Terminal invocation of the executable inside the app bundle:
  /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt
• direct Terminal invocation with GUI command-line operations,
• background-task startup:
  /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt --background-task
• text-mode self-test:
  /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt --text --test
• basic Cmd-key/menu behavior in password fields.

[idrassi]

This creates/uses NSApplication before wxWidgets initializes the macOS GUI application. That is risky for VeraCrypt because wxOSX creates its own wxNSApplication subclass during DoInitGui to handle Cocoa events correctly, including command-key key-up handling. If a plain NSApplication singleton is created here first, wxWidgets cannot later replace it with wxNSApplication.

Please rework this so VeraCrypt does not create NSApplication before wxWidgets initialization. A safer direction is to remove the pre-wx Carbon foregrounding block and rely on wxWidgets existing macOS activation path, or otherwise ensure wxNSApplication is created first.

[idrassi]

This rationale should be adjusted. In the current Xcode/macOS SDK I tested, GetCurrentProcess, SetFrontProcess, and TransformProcessType are still declared; GetCurrentProcess and SetFrontProcess produce deprecation warnings, but this is not currently an SDK-removal build break. The change should be framed as deprecation cleanup, not as replacing APIs that are already removed.

[damianrickard]

Thanks, and good catches on both points. You're right that these APIs are only deprecated, not removed, on the current SDK — I've corrected the rationale to deprecation cleanup.

I went with your first suggestion and removed the pre-wx Carbon foregrounding block entirely rather than adding a native helper, so nothing touches NSApplication before wxWidgets installs wxNSApplication in DoInitGui. wxWidgets 3.2.10 already covers this in src/osx/cocoa/utils.mm: after creating wxNSApplication, its applicationDidFinishLaunching sets NSApplicationActivationPolicyRegular and activates the app when the executable isn't inside an .app bundle (and activates bundled accessory apps too). The PR is now just the deletion of the block and the ApplicationServices include.

Rebased onto current master. Testing on arm64 (macOS 26.5): --text --test passes, and launching the executable directly from Terminal foregrounds correctly (regular activation policy, Dock icon, working menus) with no Carbon code. I have not yet run the bundled-.app Finder / LaunchServices -psn_ launch, --background-task, or the Cmd-key-in-password-field checks against a packaged build — I'll do that against a signed .app and follow up here.

[damianrickard]

Built a signed .app and ran through the launch matrix on Apple Silicon (macOS 26.5.1). Using lsappinfo to read the activation policy: launching the bundle via LaunchServices comes up as a Foreground app and in front; launching the inner executable directly from Terminal — both with no args and with a volume-path argument (the case the removed Carbon block used to handle) — also comes up as a Foreground app; the -psn_ argument case launches the GUI normally; and --text --test passes. --background-task with nothing mounted exits immediately, but the current released build (with the Carbon block) behaves identically, so that's pre-existing and not affected by this change. I confirmed no code creates an NSApplication before wxWidgets — the only reference is the standard NSPrincipalClass in Info.plist, which wx subclasses as wxNSApplication, so command-key handling stays wx-native. Removing the pre-wx block rather than adding one makes that strictly safer than before.