Skip to content

Feature/macos intel support#334

Draft
blime4 wants to merge 35 commits intoZackriya-Solutions:devtestfrom
blime4:feature/macos-intel-support
Draft

Feature/macos intel support#334
blime4 wants to merge 35 commits intoZackriya-Solutions:devtestfrom
blime4:feature/macos-intel-support

Conversation

@blime4
Copy link

@blime4 blime4 commented Feb 4, 2026

Description

This PR adds support for Intel-based Macs alongside the existing Apple Silicon (ARM64) support.

Related Issue

[Link to the issue this PR addresses (e.g., "Fixes #123")]

Type of Change

  • Bug fix
  • New feature
  • Documentation update
  • Performance improvement
  • Code refactoring
  • Other (please describe)

Testing

  • Unit tests added/updated
  • Manual testing performed
  • All tests pass

Documentation

  • Documentation updated
  • No documentation needed

Checklist

  • Code follows project style
  • Self-reviewed the code
  • Added comments for complex code
  • Updated README if needed
  • Branch is up to date with devtest
  • No merge conflicts

Screenshots (if applicable)

[Add screenshots here if your changes affect the UI]

Additional Notes

[Add any additional information that might be helpful for reviewers]

blime added 30 commits February 4, 2026 22:58
… builds

Fixed critical issue where the "both" build option attempted to use the
non-existent Tauri CLI --universal flag. The workflow now builds both
architectures separately when "both" is selected.

Changes:
- Split single "Build Tauri app" steps into separate Apple Silicon and Intel builds
- Updated conditional logic to run both builds when build-arch is "both"
- Fixed verification steps to handle both architecture directories
- Updated artifact upload to include both aarch64 and x86_64 targets
- Enhanced build summary to show separate counts for each architecture

Technical details:
- Apple Silicon builds: target/aarch64-apple-darwin/
- Intel builds: target/x86_64-apple-darwin/
- Each architecture gets its own DMG, .app bundle, and signature files
- No universal binary creation (requires lipo, deferred to future work)

This fix ensures the "both" option will actually work instead of failing
with an unknown flag error.
…h builds

The term 'Universal' in macOS specifically means a single binary
containing both architectures (created via lipo -create). Our
'both' option builds separate binaries for each architecture,
so 'Multi-Arch' is the accurate terminology.
The "rustup install target" step was attempting to install
'universal-apple-darwin' as a Rust target, which is invalid because
it's a Tauri meta-target, not a Rust target. This caused the workflow
to fail with:
  error: target 'universal-apple-darwin' is not a valid target

Fixed by adding '&& inputs.target != 'universal-apple-darwin'' to the
condition. The required Rust targets (aarch64-apple-darwin and
x86_64-apple-darwin) are already installed by the "Install Rust stable"
step when building for universal macOS.

This ensures the workflow properly handles all macOS targets:
- aarch64-apple-darwin: rustup installs target
- x86_64-apple-darwin: rustup installs target
- universal-apple-darwin: skipped (targets already installed earlier)
Metal framework is available on both Apple Silicon and Intel-based Macs.
While Apple Silicon has additional CoreML optimizations, Metal GPU
acceleration works perfectly fine on Intel Macs for ML workloads.
- Update macOS installation instructions to mention both Apple Silicon and Intel builds
- Add comprehensive system requirements for macOS including Intel Macs
- Document GPU acceleration performance differences between Apple Silicon and Intel Macs
- Add performance comparison table in GPU_ACCELERATION.md
- Include Metal verification command for macOS users
This workflow allows testing Intel Mac builds without requiring
Apple code signing certificates. Useful for validation in forks.
Updated @tauri-apps/api from v2.6.0 to v2.10.1
Updated @tauri-apps/plugin-updater from v2.3.0 to v2.10.0
Updated @tauri-apps/cli from v2.1.0 to v2.1.1

This fixes the version mismatch error during tauri build.
Updated tauri from 2.6.2 to 2.10.1
Updated tauri-plugin-updater from 2.3.0 to 2.10.0
Updated tauri-plugin-log from 2.6.0 to 2.10.0

This matches the npm package versions (@tauri-apps/api v2.10.1,
@tauri-apps/plugin-updater v2.10.0) and resolves the version
mismatch error during tauri build.
tauri-plugin-log v2.10.0 does not exist on crates.io.
Latest available version is v2.8.0.
Added pull_request trigger to build-test and build-devtest workflows.
Tests will now automatically run when:
- PR is created or updated
- Changes are made to workflows, frontend code, or Tauri code

This allows automatic validation of changes without manual workflow dispatch.
The Tauri build requires llama-helper-x86_64-apple-darwin binary to exist.
Added steps to build llama-helper with Metal GPU support before
the main Tauri build step.
Set TAURI_BUNDLE_CREATE_UPDATER_ARTIFACTS=false to skip
updater .sig file creation which requires TAURI_SIGNING_PRIVATE_KEY.

This allows the build to complete successfully for testing without
requiring the private signing key.
Added pull_request event types [opened, synchronize, reopened]
Added push event trigger for feature/macos-intel-support branch

Now Actions will automatically run when:
- PR is created or updated (synchronize event)
- New commits are pushed to feature/macos-intel-support branch
Modified trigger from pull_request to pull_request_target
so it won't run on feature branch PRs which don't have
access to required secrets.

Build Test workflow requires code signing secrets which are
not available in PR testing. Build and Test - DevTest will
handle automatic PR testing instead (no code signing).
Set TAURI_SIGNING_PRIVATE_KEY to empty string if secret not available
Set TAURI_BUNDLE_CREATE_UPDATER_ARTIFACTS to false when no private key exists

This allows builds to complete in test workflows without requiring
TAURI_SIGNING_PRIVATE_KEY environment variable.
…e key exists

This prevents the updater artifact creation error in PR testing workflows
where sign-binaries=true but TAURI_SIGNING_PRIVATE_KEY is not available.
…ct error

Set sign-binaries to false in test workflow since:
1. Test builds don't need code signing
2. Avoids 'A public key has been found, but no private key' error
3. build.yml will now skip all signing and updater artifact creation
@blime4
Copy link
Author

blime4 commented Feb 11, 2026

fix : #77
nowadays macos intel can use
d1aee1ef946eef6ca6b64c9627f711af
657994f7c85498ed98e2b86aa15b1610
img_v3_02uq_3c9eda21-217e-4411-ab13-9f28a1b7a6hu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant