Am 09.09.2026 wurde Julia 1.13.0 veröffentlicht und von Julia offiziell als aktuelle stabile Version geführt; eine native Apple-Silicon-Ausgabe ist verfügbar. Die offiziellen Julia-Downloads bestätigen diesen Versions- und Plattformstand. Daraus folgt die schnelle Entscheidung:

Symptom: Sie haben ein neues Forschungsprojekt oder müssen ein bestehendes Projekt auf einem Apple-Silicon-Mac prüfen. Schnellste Lösung: Installieren Sie Julia 1.13 für neue Projekte bevorzugt mit juliaup. Lassen Sie bei alten Projekten die bisherige Umgebung unverändert und testen Sie Julia 1.13 separat mit eigenem Project.toml und Manifest.toml.

Zuletzt aktualisiert: 19.09.2026. Versionsstand und Apple-Silicon-Verfügbarkeit wurden anhand der offiziellen Julia-Downloadseiten geprüft. Julia-1.13-Patchversionen, Paketkompatibilität und das Verhalten von juliaup können sich danach ändern.

Dieser Leitfaden richtet sich an Sie, wenn Sie nur Windows- oder Linux-Geräte haben, aber ein Julia-Projekt unter macOS arm64 prüfen müssen. Er ist ebenso für Forschungsgruppen gedacht, die ein älteres Projekt migrieren, sowie für Hochschul-Administratoren, die eine reproduzierbare Julia-Umgebung mit Fernzugriff bereitstellen sollen.

Die Ausgangslage anhand überprüfbarer Symptome einordnen

Bei einer Julia-Installation reicht es nicht, dass im Terminal die Eingabe julia eine Eingabeaufforderung öffnet. Drei unterschiedliche Ebenen können bereits auseinanderlaufen:

  • Julia wurde aus einer anderen Quelle installiert als vorgesehen und startet deshalb eine ältere Version.
  • Der Mac, die Julia-Binärdatei und eine externe Bibliothek verwenden unterschiedliche Architekturen.
  • Das Projekt lädt zwar seine Pakete, verwendet aber nicht die Abhängigkeiten, mit denen die ursprünglichen Ergebnisse erzeugt wurden.
Gerade bei wissenschaftlichen Projekten wird der Fehler oft erst spät sichtbar. Ein Paket kann sich zunächst auflösen lassen, während ein passendes Artifact, eine C- oder Fortran-Bibliothek oder ein externes ausführbares Programm später nicht geladen wird. Julia beschreibt Artifacts als paketbezogene Binärabhängigkeiten, die über die Paketumgebung verwaltet werden; das Verhalten ist in der [offiziellen Artifacts-Dokumentation](https://pkgdocs.julialang.org/v1.5/artifacts/) beschrieben.

Die erste Bestandsaufnahme sollte deshalb nicht mit einer Löschung beginnen. Sichern Sie vor Änderungen:

  • Project.toml
  • Manifest.toml
  • Quellcode und Skripte
  • Konfigurationsdateien
  • Testdaten oder deren reproduzierbare Bezugsquelle
  • bisherige Ergebnisdateien
  • Notizen zur Julia-Version und zum Betriebssystem
Die alte Umgebung ist ein Vergleichspunkt. Ohne sie können Sie später nicht mehr unterscheiden, ob ein Ergebnisunterschied aus Julia 1.13, einer neuen Paketauflösung, einer anderen Architektur oder aus einer Änderung im Forschungscode stammt.

Julia 1.13 auf dem Apple-Silicon-Mac mit dem passenden Kanal einrichten

Die offiziellen Plattformhinweise führen sowohl Installationswege als auch macOS-spezifische Informationen auf. Für ein neues Forschungsprojekt ist juliaup in der Regel die bessere Ausgangsbasis als ein beliebiger Paketmanager, der möglicherweise einen älteren oder anders gepflegten Build bereitstellt. Die Julia-Installationsanleitung beschreibt den offiziellen Installationskontext; die aktuelle Auswahl sollte vor der Installation nochmals auf der Downloadseite geprüft werden.

Erst den Installationsweg festlegen

Verwenden Sie bevorzugt juliaup, wenn Sie:

  • einen stabilen Kanal nachvollziehbar auswählen möchten,
  • für ein altes Projekt eine weitere Julia-Version parallel benötigen,
  • den aktiven Standard später ohne manuelle Pfadänderungen wechseln wollen,
  • die Einrichtung in einer Arbeitsgruppe dokumentieren müssen.
Ein direkter DMG-Download ist nicht grundsätzlich falsch. Er ist sinnvoll, wenn Ihre Hochschule Installationsdateien zentral prüft oder eine bestimmte Datei archivieren muss. Er ist aber kein Ersatz für die Versionsdokumentation. Notieren Sie auch in diesem Fall Downloadquelle, Dateiname, Installationsdatum und Architektur.

Nach der Installation erfassen Sie mindestens:

julia --version
julia -e 'println(VERSION); println(Sys.ARCH); println(Sys.BINDIR)'
juliaup status
command -v julia
uname -m

Die erwartete Architektur muss zum Apple-Silicon-System passen. uname -m liefert den Architekturhinweis des laufenden Systems, während Sys.ARCH die Architektur der Julia-Laufzeit ausgibt. Sys.BINDIR zeigt, aus welchem Installationsverzeichnis Julia seine Laufzeit verwendet. command -v julia hilft zusätzlich, eine alte Binärdatei im PATH zu erkennen.

**Achtung:** Installieren Sie nicht sofort Rosetta und löschen Sie nicht pauschal Ihren Benutzerordner. Wenn ein altes Paket nur als Intel-Binary verfügbar ist, muss zunächst nachgewiesen werden, dass tatsächlich diese Abhängigkeit fehlt. Eine globale Kompatibilitätsschicht kann einen Pfadfehler verdecken und die spätere Reproduzierbarkeit erschweren.

Stabil, LTS, alt oder Vorschau nicht vermischen

Für ein neues Projekt verwenden Sie den stabilen Julia-1.13-Kanal, sofern die benötigten Pakete und externen Abhängigkeiten ihn unterstützen. Ein LTS-Kanal kann für eine langfristig betreute Lehr- oder Produktionsumgebung sinnvoller sein, wenn die Stabilität über mehrere Wartungszyklen wichtiger ist als die neueste Laufzeit. Ein altes Paper sollte dagegen zunächst mit seiner dokumentierten Julia-Version reproduziert werden.

Eine Vorschau- oder Entwicklerversion gehört in eine ausdrücklich getrennte Testumgebung. Sie sollte nicht dadurch zum Standard werden, dass PATH zufällig auf die falsche Binärdatei zeigt.

Die Architektur nicht nur am Mac, sondern an der gesamten Abhängigkeitskette prüfen

Apple Silicon bezeichnet die Hardwarefamilie, nicht automatisch jede Komponente Ihrer Forschungsumgebung. Die relevante Kette lautet:

  1. Mac-Prozessor und laufende Systemarchitektur
  2. Julia-Binary
  3. Julia-Registry und Paketauflösung
  4. heruntergeladene Artifacts
  5. lokale C- oder Fortran-Bibliotheken
  6. externe Kommandozeilenprogramme
  7. grafische oder notebookbasierte Zusatzkomponenten
Ein Projekt kann deshalb „installiert“ wirken, obwohl ein späterer Berechnungsschritt scheitert. Typische Beobachtungen sind:
  • Das Paket wird in Project.toml eingetragen, aber instantiate bricht beim Artifact ab.
  • Julia startet, doch ein externer Solver wird wegen einer falschen Binary-Architektur nicht ausgeführt.
  • Eine Bibliothek lässt sich kompilieren, aber die erzeugte Datei wird beim Laden nicht gefunden.
  • Ein Plot-Befehl funktioniert im interaktiven Terminal, aber nicht in der vorgesehenen grafischen Sitzung.
Die [offiziellen Plattforminformationen für macOS](https://julialang.org/downloads/platform/#macos) sollten die erste Referenz für verfügbare Builds sein. Für externe Pakete müssen Sie zusätzlich deren eigene Dokumentation prüfen; aus der Verfügbarkeit der Julia-Laufzeit folgt nicht automatisch, dass jedes Forschungspaket bereits vollständig arm64-kompatibel ist.

Architektur anhand eines kurzen Befunds abgrenzen

Führen Sie die Prüfungen nicht nur in einem Terminalfenster aus. Wiederholen Sie sie in der Shell, aus der Ihr Projekt gestartet wird, und gegebenenfalls in der Entwicklungs- oder Notebook-Umgebung:

uname -m
command -v julia
julia --version
julia -e 'println(Sys.ARCH); println(Sys.BINDIR)'

Wenn command -v julia auf einen unerwarteten Pfad zeigt, ist zuerst der Einstiegspunkt zu korrigieren. Wenn Mac und Julia nativ erscheinen, aber ein externes Programm scheitert, untersuchen Sie dieses Programm separat. Eine erfolgreiche Julia-Ausgabe ist kein Beweis für die Architektur jedes nachgeladenen Bestandteils.

Das Entscheidungswerkzeug für Installation und Migration anwenden

Verwenden Sie die folgende Bedingungsliste als Freigabeentscheidung. Kreuzen Sie einen Punkt erst an, wenn der Befund dokumentiert ist; ein bloß gestartetes REPL-Fenster zählt nicht als Nachweis.

Wenn-dann-Entscheidung

  • [ ] Wenn es sich um ein neues Forschungsprojekt handelt und die benötigten Pakete Julia 1.13 unterstützen, wählen Sie Julia 1.13 über juliaup und legen ein neues Projektverzeichnis mit eigenem Project.toml und Manifest.toml an.
  • [ ] Wenn es sich um ein altes Paper, eine veröffentlichte Analyse oder ein laufendes Laborprojekt handelt, behalten Sie die bisherige Julia-Version und deren Manifest unverändert; erstellen Sie erst danach eine getrennte Julia-1.13-Testumgebung.
  • [ ] Wenn uname -m und Sys.ARCH zur nativen Apple-Silicon-Ausführung passen und die benötigten Artifacts geladen werden, geben Sie die native Julia-1.13-Umgebung für weitere Pakettests frei.
  • [ ] Wenn Julia nativ läuft, aber ein einzelnes externes Programm nur als Intel-Binary existiert, isolieren Sie diese Abhängigkeit und suchen Sie zuerst nach einer dokumentierten arm64-Version oder Alternative.
  • [ ] Wenn mehrere zentrale Abhängigkeiten nur in der Intel-Umgebung funktionieren, halten Sie die alte Umgebung getrennt und verschieben die Migration; Rosetta ist dann höchstens eine begrenzte Kompatibilitätsoption.
  • [ ] Wenn juliaup status, julia --version und command -v julia unterschiedliche Zustände nahelegen, reparieren Sie zuerst PATH, Shell-Konfiguration oder doppelte Installationspfade.
  • [ ] Wenn der Fehler beim Registry- oder Paketserverzugriff entsteht, klären Sie HTTPS, Proxy, Zertifikate und Firewall mit der Hochschul-IT, statt Sicherheitsprüfungen zu umgehen.
  • [ ] Wenn nur ein komplexes Paket scheitert, während ein kleines repräsentatives Projekt funktioniert, prüfen Sie die Paketdokumentation und dessen konkrete Julia-1.13-Unterstützung, statt die gesamte Mac-Umgebung als ungeeignet einzustufen.
  • [ ] Wenn Paketinstanziierung, Grafik, Datei-I/O, Ergebnisexport und der repräsentative Forschungsauftrag erfolgreich sind, geben Sie die Umgebung für den vorgesehenen Zweck frei.
  • [ ] Wenn Ergebnisse trotz identischer Daten und festgelegtem Zufalls-Seed abweichen, stoppen Sie die Migration und vergleichen Manifest, numerische Bibliotheken, Compilerpfade und Datenaufbereitung.
  • [ ] Wenn Sie keinen Mac besitzen, aber alle Projektdateien und Tests vorbereitet haben, nutzen Sie zunächst eine zeitlich begrenzte Remote-Umgebung auf einem echten Apple-Silicon-Mac, bevor Sie eine dauerhafte Anschaffung entscheiden.
Diese Bedingungen trennen drei Ergebnisse: **weiterverwenden**, **doppelgleisig testen** oder **zurückstellen**. Dadurch wird aus einer Installation eine überprüfbare technische Entscheidung.

Shell- und PATH-Konflikte ohne Datenverlust auflösen

Wenn unterschiedliche Terminals verschiedene Julia-Versionen anzeigen, liegt das oft nicht an Julia selbst, sondern an konkurrierenden Einstiegspunkten. Prüfen Sie zunächst, welche Shell Sie verwenden und welche Datei den Pfad verändert. Relevant sind unter anderem Shell-Startdateien, ein manuell installiertes Julia-Verzeichnis und der von juliaup verwaltete Einstieg.

Gehen Sie in dieser Reihenfolge vor:

  1. Führen Sie command -v julia aus und speichern Sie den vollständigen Pfad.
  2. Vergleichen Sie julia --version mit juliaup status.
  3. Prüfen Sie Sys.BINDIR, Sys.ARCH und VERSION.
  4. Öffnen Sie ein neues Terminal und wiederholen Sie die Abfragen.
  5. Vergleichen Sie die Ergebnisse in der grafischen Entwicklungsumgebung oder Notebook-Sitzung.
  6. Entfernen Sie erst danach einen nachweislich veralteten PATH-Eintrag.
Wenn juliaup den richtigen Kanal kennt, aber julia auf eine andere Datei zeigt, korrigieren Sie den Pfad statt die gesamte Umgebung zu löschen. Bewahren Sie Projektdateien und Benutzerkonfigurationen vor jedem manuellen Eingriff. Ein erneuter Download behebt keine falsche Shell-Reihenfolge und kann die Beweiskette Ihres alten Projekts zerstören.

Für eine Abnahme genügt deshalb nicht „Julia startet“. Sie brauchen dieselbe Versionsausgabe aus der Shell, aus dem Projektkontext und aus dem Werkzeug, mit dem Ihr Forschungsteam tatsächlich arbeitet.

Paketfehler nach dem Upgrade in der richtigen Schicht untersuchen

Ein Fehler bei der Paketinstallation ist zunächst nur ein Symptom. Julia kann an mehreren Stellen scheitern:

  • beim Zugriff auf Registry-Daten,
  • beim Paketserver,
  • beim Abruf eines Git-Repositories,
  • beim Download eines Artifacts,
  • bei der lokalen Kompilierung,
  • beim Laden einer externen Bibliothek.
Lesen Sie die erste sinnvolle Fehlermeldung und ordnen Sie sie einer dieser Schichten zu. Wiederholte Installationsversuche ohne diese Zuordnung erzeugen oft nur neue Zwischenstände.

Netzwerk, Proxy und Zertifikate getrennt behandeln

Funktioniert der Zugriff auf die offiziellen Julia-Dienste nicht, prüfen Sie gemeinsam mit der Hochschul-IT:

  • ob die benötigten HTTPS-Verbindungen erlaubt sind,
  • ob ein Proxy vorgeschrieben ist,
  • ob Zertifikate durch eine zentrale Richtlinie ersetzt werden,
  • ob Git-Zugriffe anders gefiltert werden als Paketserver,
  • ob Artifacts aus einem separaten Netzwerkpfad geladen werden.
Sicherheitskontrollen sollten nicht durch unverschlüsselte Quellen oder pauschales Abschalten von Zertifikatsprüfungen umgangen werden. Die [Pkg-Protokolldokumentation](https://pkgdocs.julialang.org/dev/protocol/) beschreibt die beteiligten Paketprotokolle und hilft dabei, den Fehler technisch einzugrenzen.

Für die erste Funktionsprüfung wählen Sie ein kleines, tatsächlich benötigtes Forschungspaket und ein begrenztes Projekt. Wenn dieses Projekt instanziiert werden kann, sagt das noch nichts über jedes komplexe Paket aus. Die Kompatibilität großer wissenschaftlicher Pakete müssen Sie jeweils anhand ihrer offiziellen Dokumentation und der konkreten Fehlermeldung bewerten.

Project.toml und Manifest.toml als Reproduzierbarkeitsgrenze verwenden

Eine globale Umgebung ist für einen kurzen interaktiven Test bequem, aber für eine Publikation, ein Seminarprojekt oder ein Gruppenprojekt ungeeignet. Das Projektverzeichnis sollte seine direkten Abhängigkeiten in Project.toml und den aufgelösten Zustand in Manifest.toml dokumentieren.

Aktivieren Sie die Umgebung im Projektverzeichnis:

julia --project=. -e 'using Pkg; Pkg.instantiate()'

Anschließend prüfen Sie, ob die erwartete Umgebung aktiv ist:

julia --project=. -e 'using Pkg; Pkg.status()'

Die Julia-Pkg-Dokumentation zu Umgebungen erklärt die Trennung von Projekt- und globaler Umgebung. Die TOML-Dokumentation ist maßgeblich für Aufbau und Zweck der Dateien.

Für ein altes Projekt erstellen Sie zunächst eine schreibgeschützte Kopie des ursprünglichen Zustands. Danach legen Sie die Julia-1.13-Variante getrennt an. Wenn ein Projekt mehrere Julia-Versionen benötigt, beschreibt die Dokumentation zu versionsabhängigen Manifest-Dateien, wie getrennte Manifest-Zustände verwaltet werden können.

Entscheidend ist: Ein erfolgreiches using beweist nur, dass ein Paket geladen werden konnte. Für die wissenschaftliche Freigabe müssen Sie zusätzlich vergleichen:

  • zentrale numerische Ausgaben,
  • Zufallszahlen mit festgelegtem Seed,
  • Datenbereinigung und Filterung,
  • exportierte Dateien,
  • Paketstatus und Manifest,
  • Warnungen und Fehlermeldungen,
  • Verhalten bei einer erneuten Instanziierung.
Wenn Linux und macOS dasselbe Projekt verwenden, teilen Sie nicht automatisch blind ein Manifest. Plattformabhängige Artifacts und externe Bibliotheken können unterschiedliche Auflösungen oder Binärdateien benötigen. Teilen Sie den Quellcode und die fachlichen Testdaten, dokumentieren Sie aber die Betriebssystem- und Architekturzustände getrennt.

Die Forschungsumgebung mit einer echten Aufgabe freigeben

Die letzte Prüfung muss über eine einfache REPL-Rechnung hinausgehen. Sie sollten mindestens diese Arbeitswege testen:

  • Berechnung im Terminal,
  • Projektstart mit aktivierter Umgebung,
  • Verbindung zur vorgesehenen Entwicklungs- oder Notebook-Oberfläche,
  • Plot-Erzeugung und Anzeige,
  • Lesen und Schreiben einer Datei,
  • Export der Ergebnisse,
  • längerer Lauf ohne sofortigen Abbruch,
  • erneute Verbindung nach einer getrennten Sitzung.
Verwenden Sie dafür veröffentlichte oder anonymisierte Daten und einen Auftrag, der die spätere Arbeit repräsentiert. Notieren Sie, ob die Umgebung beim ersten Mal instanziiert werden konnte, wie sich der erste Lauf verhielt, ob Grafikfenster oder Notebook-Ausgaben korrekt erschienen und ob ein unterbrochener Fernzugriff den Prozess beeinflusste.

Wenn Sie keinen eigenen Mac besitzen, können Sie diese Abnahme zunächst auf einem gemieteten echten Apple-Silicon-Mac durchführen. MACGPU stellt Informationen zu verfügbaren Mac-Umgebungen bereit; die passende Mietoption sollten Sie nach Projektlaufzeit, Datenschutzanforderungen und benötigter Zugriffsmethode auswählen. Für eine Entscheidung zwischen Kauf und zeitweiser Nutzung können Sie außerdem die verfügbaren Mac-Mietoptionen prüfen.

Freigabe nach dem Forschungsbefund

  • Wenn native Architektur, Paketinstanziierung, Grafik, Datei-I/O und der repräsentative Forschungsauftrag erfolgreich sind, geben Sie Julia 1.13 für ein neues Projekt frei.
  • Wenn nur ein altes Paket oder ein externes Programm scheitert, wählen Sie eine dokumentierte Doppelspur: alte Julia-Umgebung behalten, Julia 1.13 isoliert weiterprüfen.
  • Wenn Ergebnisse trotz identischer Daten und Seeds abweichen, stoppen Sie die Migration und vergleichen Manifest, numerische Bibliotheken, Compilerpfade und Datenaufbereitung.
  • Wenn der Fernzugriff die Grafik oder einen langen Lauf unzuverlässig macht, prüfen Sie den Workflow mit lokaler Ausgabe, Sitzungswiederaufnahme und geeigneten Fernzugriffsregeln, bevor Sie das System für ein wichtiges Experiment einsetzen.
  • Wenn zentrale Abhängigkeiten weiterhin nicht arm64-fähig sind, bleiben Sie vorerst bei der alten Umgebung oder der Linux-Ausführung, statt eine nicht reproduzierbare Mischinstallation freizugeben.

Häufige Fragen zur Julia-1.13-Installation auf Apple Silicon

Julia 1.13 mit juliaup oder direktem DMG installieren?

Für neue Projekte ist juliaup vorzuziehen, weil Versionen und Kanäle leichter getrennt dokumentiert werden können. Ein direkter DMG-Download bleibt vertretbar, wenn die Hochschul-IT Installationsdateien zentral prüft. In beiden Fällen müssen Sie Quelle, Version, Architektur, Pfad und aktive Umgebung festhalten. Die Wahl des Installationswegs ersetzt nicht die fachliche Projektabnahme.

Was tun, wenn ein Julia-Paket nach dem Upgrade nicht installiert werden kann?

Sichern Sie zunächst alle Projekt- und Forschungsdateien. Ordnen Sie die erste Fehlermeldung dann dem Registry-Zugriff, Paketserver, Git, Artifact oder lokalen Build zu. Prüfen Sie anschließend die Paketdokumentation für Julia 1.13 und Apple Silicon. Ein pauschales Löschen der alten Umgebung ist falsch, solange nicht feststeht, dass die alte Version nicht mehr benötigt wird.

Wie lässt sich die arm64-Ausführung auf einem Apple-Silicon-Mac belegen?

Verwenden Sie uname -m, Sys.ARCH, Sys.BINDIR und command -v julia. Die Ausgaben sollten gemeinsam ein konsistentes Bild ergeben: Apple-Silicon-System, native Julia-Architektur und der erwartete Installationspfad. Prüfen Sie danach die Architektur kritischer externer Programme. Erst wenn auch Artifacts und Bibliotheken funktionieren, ist die technische Basis für das Forschungsprojekt ausreichend belegt.

Wie testen Sie Julia ohne eigenen Mac unter macOS?

Nutzen Sie für die Abnahme zeitweise einen echten entfernten Apple-Silicon-Mac und übertragen Sie nicht nur den Quellcode, sondern auch Testdaten, Manifest und Startbefehle. Instanziieren Sie das Projekt neu, führen Sie eine typische Berechnung aus, erzeugen Sie eine Grafik und prüfen Sie die Wiederaufnahme nach einer getrennten Sitzung. Dokumentieren Sie jeden abweichenden Befund, bevor Sie eine längerfristige Lösung wählen.

Wie bleiben alte Abhängigkeiten bei Julia 1.13 erhalten?

Lassen Sie die alte Projektkopie unangetastet und erstellen Sie für Julia 1.13 eine getrennte Projektumgebung. Project.toml beschreibt die direkten Abhängigkeiten, Manifest.toml den aufgelösten Zustand. Bei mehreren Julia-Versionen können versionsabhängige Manifest-Dateien sinnvoll sein. Vergleichen Sie danach nicht nur den Ladezustand der Pakete, sondern auch Ausgaben, Datenprodukte und Zufallssequenzen.

Für Sie als Forschenden ist die Wahl damit klar: Neue Projekte beginnen mit Julia 1.13 und juliaup, sofern die benötigten Pakete nativ funktionieren. Alte Paper- oder Laborprojekte bleiben zunächst auf ihrer bekannten Version und werden parallel in einer isolierten Julia-1.13-Umgebung geprüft. LTS ist eine Stabilitätsentscheidung, kein automatischer Kompatibilitätsbeweis; Rosetta ist eine begrenzte Rückfalloption, kein Standardweg.

Wenn Sie bereits Projektdateien, Abhängigkeitsliste und repräsentative Tests vorbereitet haben, aber keinen Apple-Silicon-Mac zur Verfügung haben, ist eine kurzfristige MACGPU-Mietumgebung für diese konkrete Abnahme oft sinnvoller als ein ungeprüfter Sofortkauf. Sie können damit arm64, Paketinstanziierung, Grafik und längere Aufgaben unter realen Bedingungen testen. Erst das Ergebnis dieser Prüfung sollte bestimmen, ob Sie weiter mieten, einen eigenen Mac beschaffen oder Linux und macOS dauerhaft als getrennte Forschungsumgebungen betreiben.