Julia starts, but packages fail to load, the wrong version appears, or a compiled dependency reports an architecture error.
The fastest safe fix is to install Julia 1.13 through the official juliaup route, verify the Mac and Julia architectures, then create an isolated Project.toml and Manifest.toml for each research project.
This guide is for you if:
- Your lab mainly uses Windows or Linux, but you must validate a Julia project on macOS arm64.
- You are moving an older research project toward Julia 1.13 and cannot risk overwriting its working environment.
- You support a university group that needs a reproducible Julia setup and remote Apple Silicon access.
**Last updated:** September 19, 2026. Version status and installation guidance were checked against the [official Julia downloads and platform documentation](https://julialang.org/downloads/platform/).
Establish the version baseline before changing anything
Julia 1.13.0 was released on September 9, 2026, and is listed by the Julia project as the current stable release as of September 19, 2026. The official distribution includes an Apple Silicon build, and the typical installation path for ordinary users is juliaup rather than an unofficial package source. Confirm the current state on the official manual downloads page before you begin, because patch releases and channel behavior can change.
Do not treat “the julia command opens” as proof that the environment is ready. Record three separate facts:
- The Julia channel selected by juliaup.
- The actual Julia version returned by the executable.
- The architecture used by both the Mac and Julia process.
juliaup status
julia --version
which -a julia
uname -m
julia -e 'println(Sys.ARCH)'On an Apple Silicon Mac, uname -m should normally report arm64, while Julia should report its corresponding 64-bit ARM architecture. The exact display can vary by Julia release, so compare the result with the official platform installation guidance, rather than relying on a copied terminal screenshot.
The distinction between release channels matters:
- Stable: use this for a new paper, course project, or production research workflow unless a dependency requires another release.
- LTS: use the LTS channel when a lab policy or an older validated workflow explicitly depends on long-term support.
- Older fixed version: retain this for a paper or project whose results were generated with that version.
- Development or nightly build: use only for testing an upcoming Julia change, not as the default research environment.
Install Julia 1.13 on an Apple Silicon Mac with a clean baseline
For most researchers, juliaup is preferable to downloading an arbitrary installer because it gives you a version-aware channel interface and makes parallel versions easier to manage. Use the command published in the current Julia installation manual rather than copying an installation command from an old lab wiki.
After installation, select the intended channel and confirm the result:
juliaup status
julia --version
julia -e 'println(VERSION)'The exact juliaup channel name should come from the current Julia distribution metadata. Do not invent a channel name from a future patch version or assume that a version string shown in a blog post is still available.
A direct macOS download is not automatically wrong. It can be appropriate when:
- Your institution requires a manually reviewed installer.
- You are reproducing a historical installation procedure.
- A deployment system distributes a signed package to managed Macs.
- You need a specific binary and have verified its architecture and source.
Should Julia 1.13 use juliaup or a direct DMG? Choose juliaup for a new Apple Silicon research environment or any setup that needs stable and older channels side by side. Choose a direct download only when institutional controls or a fixed reproducibility record requires it, and document the exact file and architecture.
Do not remove existing Julia directories at this stage. First copy or commit:
Project.tomlManifest.toml- Source code and scripts
- Environment variables used by the project
- Small representative input data or a documented data hash
- The old Julia version and package status
Separate arm64 failures from package failures
A package can resolve successfully and still fail when Julia tries to load an artifact, a C library, a Fortran library, or an external executable. That is why architecture verification must happen before repeated package reinstalls.
Use this evidence set:
uname -m
arch
julia -e 'println(Sys.ARCH)'
julia -e 'println(Sys.BINDIR)'
file "$(which julia)"Also inspect important external commands:
which gcc
which gfortran
which python3
file "$(which gcc)"
file "$(which python3)"The goal is not to make every tool identical at any cost. The goal is to identify which process loads which binary. An arm64 Julia process calling an Intel-only external executable can fail even when the Julia package itself installed correctly. Conversely, a package may select an artifact successfully while a locally compiled dependency still lacks an Apple Silicon path.
Typical symptoms include:
- A package precompiles, but loading it fails.
- An artifact download completes, but a dynamic library cannot be opened.
- A C or Fortran wrapper reports an invalid executable format.
- A command works in one terminal but not from VS Code or a notebook.
- A project runs on Linux but fails when it reaches a platform-specific binary.
Decision rule:
- If Mac, Julia, and required dependencies are arm64, continue with native package troubleshooting.
- If Julia is Intel on an arm64 Mac, reinstall or select a native Julia channel before changing packages.
- If one required binary is Intel-only, isolate that dependency and test it separately under the required compatibility layer.
- If the dependency has an arm64 release, prefer that route over Rosetta.
Repair PATH and juliaup conflicts without deleting your setup
A common failure is not a broken Julia installation. It is a shell finding an older executable first.
Compare the command source in every shell where the issue appears:
which -a julia
type -a julia
juliaup status
echo "$PATH"If Terminal, VS Code, and a notebook report different versions, check how each application starts its shell. GUI applications may not read the same startup files as an interactive shell. Record the path and version before editing .zshrc, .zprofile, or another shell configuration file.
Use this low-risk order:
- Save the output of
which -a julia,juliaup status, andjulia --version. - Identify duplicate Julia entries rather than deleting them blindly.
- Confirm that the intended juliaup-managed executable appears first.
- Reload the shell or open a new terminal.
- Repeat the same checks from the shell used by VS Code or your notebook launcher.
- Re-run the project only after the version and path agree.
julia command resolves to that channel in the environment where the research task runs.
If the terminal still opens the old Julia version, what should you do? Do not reinstall immediately. First determine whether PATH points to a manually installed copy, a stale symlink, or a different shell startup file. Remove or reorder only the duplicate entry after preserving the project files and recording the original path.
Treat campus network errors as separate failure layers
“Package installation failed” is not a diagnosis. Julia may fail at several different network layers:
- The registry cannot be reached.
- The package server is blocked or unavailable.
- A Git repository cannot be downloaded.
- An artifact URL fails.
- A package downloads but cannot compile locally.
- A certificate, proxy, or TLS policy rejects the connection.
For example, a registry timeout points toward network access. A compiler error after the source has downloaded points toward local tools or architecture. A certificate error points toward the institution’s proxy or trust policy. These require different owners and different remedies.
Do not bypass campus security controls by disabling certificate checks or switching to an untrusted mirror. Ask the university network administrator to verify access to the Julia project’s official HTTPS endpoints, proxy requirements, and certificate inspection policy. Record the approved proxy configuration in the project setup notes if the lab requires it.
Start with one small, documented scientific package rather than the largest package in the project. Then activate the project and instantiate it:
mkdir julia13-check
cd julia13-check
juliaup run 1.13 --project=.
julia --project=. -e 'using Pkg; Pkg.activate("."); Pkg.instantiate()'If the project already contains a manifest, do not replace it casually. Copy it to a read-only comparison directory and test a separate working copy.
Julia research packages still fail after the upgrade. If the first error occurs while resolving or downloading, investigate registry, package server, Git, or artifact access. If the first error occurs during compilation or loading, investigate architecture and local toolchains. If a specific package remains uncertain, check that package’s own official compatibility documentation rather than assuming that Julia 1.13 is the sole cause.
Keep Project.toml and Manifest.toml as project evidence
A global environment is convenient for trying a package. It is not a sufficient record for a paper, course, or lab workflow. Each research project should have its own Project.toml and Manifest.toml.
Activate the project explicitly:
julia --project=/path/to/projectInside Julia, check the active environment:
using Pkg
Pkg.status()Project.toml describes the project’s declared dependencies. Manifest.toml records the resolved dependency graph and versions. The [Pkg TOML documentation](https://pkgdocs.julialang.org/dev/toml-files/) explains their roles and limitations.
Do not assume that a Linux manifest can always be copied unchanged to macOS. Julia’s package resolution can select platform-specific artifacts, and a dependency may have different binary behavior on arm64. The project files can be shared as source control inputs, but the resulting environment must be instantiated and tested on each target platform.
For projects that must support more than one Julia line, use separate version-specific manifests where appropriate. The official guidance on different manifests for different Julia versions is the safer model than repeatedly overwriting one manifest during migration.
Can Julia 1.13 preserve an old project’s dependency versions? Yes, if you preserve the old project files and test Julia 1.13 in a separate working copy or version-specific manifest. Do not run a broad update in the only copy of a published project. A migration is successful only after the old result path remains available and the new path produces acceptable results.
Use this decision matrix before approving the environment
| Situation | Preferred setup | Evidence required | Score |
|---|---|---|---|
| New research project on an Apple Silicon Mac | Julia 1.13 through juliaup with a dedicated project | Version, path, arm64 checks, successful instantiate | 5/5 |
| Existing project with a validated older Julia release | Keep the old environment and add an isolated Julia 1.13 test path | Old manifest preserved and representative results compared | 5/5 |
| One dependency has no native arm64 route | Native Julia plus a documented isolated compatibility dependency | Exact failing binary identified and separate test recorded | 3/5 |
| Julia works, but packages fail during artifact loading | Stop and audit architecture and external binaries | Artifact and executable paths captured | 2/5 |
| Only a global environment exists | Create a project-local environment before migration | Project.toml and Manifest.toml committed or archived | 2/5 |
| The project runs only after disabling TLS or security checks | Do not approve the setup | Campus administrator review required | 0/5 |
Validate the complete research workflow, not just the REPL
A successful arithmetic command proves very little. Before approving Julia 1.13, test the interfaces your project actually uses:
- Terminal computation: activate the intended project and run a deterministic small task.
- Package loading: load the critical packages from a clean process.
- Editor or notebook access: open the project from VS Code or the selected notebook tool.
- File handling: read an input file and export a result to a known directory.
- Graphics: generate the project’s representative plot or visualization.
- Long-running behavior: run a reduced version of the real task and record whether the session survives the expected connection method.
- Reproducibility: compare key numerical output, random seeds, processed row counts, and dependency status with the reference environment.
Remote access adds another acceptance layer. If you are using a remote Apple Silicon Mac because the lab has no Mac, verify that the project can be transferred securely, that the terminal or notebook connection remains usable, and that graphical output works through the permitted remote method. A package loading test alone does not prove that an interactive research workflow is practical.
How can you test a Julia project’s macOS compatibility without owning a Mac? Prepare the project files, dependency list, representative data, and acceptance commands first. Then run the same checklist on a remote Apple Silicon Mac and compare outputs with Linux or Windows. This is safer than renting access before defining what “compatible” means.
For a broader remote environment review, use the remote Mac research environment acceptance guide when deciding which connection, file-transfer, and access checks belong in your lab record.
Decide whether to continue, keep two tracks, or stop the migration
Choose continue with Julia 1.13 when the native architecture checks pass, the project instantiates, critical packages load, graphics work, and representative outputs match the accepted tolerance.
Choose a dual-track environment when the old project is still needed for published results, but the Julia 1.13 path is viable for new work. Keep the old Project and Manifest read-only, and document which Julia version produced each result.
Do you need Rosetta for Julia 1.13 on Apple Silicon? No, not for a native Julia 1.13 installation or a dependency that provides an arm64 path. Consider an isolated compatibility route only after identifying a specific Intel-only dependency and confirming that no native alternative is available.
Can a remote Apple Silicon Mac run graphical Julia tasks? It can, but approval depends on the remote connection and the application path. Validate the actual plotting, notebook, or visualization workflow rather than assuming that a working REPL guarantees graphical support.
Stop the migration and return to the preserved environment when:
- The project’s published result cannot be reproduced within its accepted tolerance.
- A critical dependency has no supported arm64 or controlled compatibility route.
- The campus network blocks required official endpoints and no approved proxy path exists.
- The team cannot identify which Julia version or manifest produced a result.
- The remote session cannot reliably complete the representative task.