M1-Macbook angetestet

Apples Ankündigung im Jahr 2020 von MacBooks mit dem eigenen, neuen M1-Chip waren sehr vielversprechend. Viele Leistungsberichte und Graphiken ließen erahnen, dass M1-Geräte alle vorherigen MacBooks klar in den Schatten stellen würden.

Von Apple entwickelte Prozessoren

Apple führt damit die Eigenentwicklung von Chips auf MacBooks und Mac minis fort. Für mobile Geräte wie z.B. iPhone und iPad nutzt Apple schon einige Jahre eigene Chip-Designs. Durch die Entwicklung ist Apple weniger abhängig von externen Komponentenherstellern, wie z.B. Intel und kann Hardware und Software besser aufeinander abstimmen, bzw. die Weiterentwicklung gezielter festlegen.

Eine Besonderheit von M1 ist u.a., dass der Arbeitsspeicher integriert ist und somit schneller angesprochen werden kann.
Mit Hilfe der in macOS integrierten Emulationssoftware Rosetta 2 können viele Programme ausgeführt werden, die eigentlich für Intel-x64-Prozessoren erstellt wurden.

Vor kurzem hatte ich die Möglichkeit ein 13″ MacBook Pro mit M1 (16 GB RAM) von meinem Arbeitgeber Lotum für etwa 1-2 Tage zu testen.

Kleine Geschwindigkeitstests

Zunächst habe ich mir angesehen, ob das M1-MacBook das 2019er-Intel-MacBook Pro (16″, 64 GB RAM) in der täglichen Software-Entwicklung mit Flutter bereits komplett ersetzen könnte.
Während einer Clean Build vorher knapp zwei Minuten dauerte benötigte das M1-MacBook jeweils ca. 15 Sekunden länger. Auch andere Entwicklungstasks, die eine gewisse Zeit laufen, benötigen geringfügig länger.
Ich könnte mir vorstellen, dass in der Praxis die Unterschiede größer sind, wenn mehrere Programme gleichzeitig genutzt werden, die viel Arbeitsspeicher beanspruchen wie z.B. Android Studio, Xcode, Photoshop, Browser.
Um dies zu überprüfen war mein Testzeitraum aber zu kurz.

Akkulaufzeit

Was ich aus Zeitgründen auch nicht überprüfen konnte war die verbesserte Akkulaufzeit. die nicht nur daraus resultiert, dass mehrere Komponenten wie der Arbeitsspeicher integriert sind (“System in a package”), sondern u.a. auch durch den verbesserten 5nm-Fertiggungsprozess.
Bei manchen langen Meetings wurde ich bislang überrascht, wenn ich mich nicht um eine Stromquelle bemüht hatte. Nach dem nächsten Hardware-Wechsel sollte dieses Problem somit seltener auftreten.

Zwischenfazit

Insgesamt macht das 13″-M1-MacBook Pro einen guten Eindruck. Auch wenn man bedenkt, dass das Gerät etwa nur die Hälfte kostet von dem ca. 1 Jahr älterem Intel-Macbook. Damit haben die M1-Geräte derzeit sicherlich das beste Preis-Leistungs-Verhältnis unter allen verfügbaren MacBooks. Das etwas ältere Intel-MacBook scheint immer noch etwas schneller zu sein. Der 4x-größere Arbeitsspeicher könnte auch dazu beigetragen haben.

iOS-Apps unter macOS

Besonders gefallen hat mir, dass man viele iOS-Apps auf dem Mac installieren kann. So kann man Apps und Spiele verwenden, die man bereits auf iOS-Geräten gekauft bzw. herunter geladen hat. Die meisten aktuell gehaltenen Apps haben bei meinen Tests sehr gut funktioniert oder benötigten kaum Anpassungen durch den Entwickler. Nur bei einigen älteren, nicht mehr gepflegten iOS-Apps gab es Probleme beim Installieren oder Starten.

Als App-Entwickler bekommt man dadurch eine weitere kleine Plattform dazu. Gibt es bei einzelnen Apps doch zu große Inkompatibilitäten so lässt sich die Verfügbarkeit dieser Apps in App Store Connect deaktivieren.

Weitere bzw. detailliertere Informationen gibt es auf Peter Steinbergers Blog.

Start-Probleme von Things 3 unter MacOS Big Sur Beta

Die ToDo-App Things 3 startete nicht mehr nach einem Update auf die Beta-Version von MacOS Big Sur. Einerseit kann man nicht erwarten, dass alle Programme auch unter den neuesten Beta-Versionen von MacOS laufen. Zumal der Hersteller bereits ein Update für diese OS-Version angekündigt hat. Da ich die Synchronisierung von Things gerne auf allen Geräten nutze wollte ich nicht so lange warten.

Das alleinige Entfernen der Thins.app aus dem Applications-Ordner und die anschließende Neuinstallation hat nicht geholfen.

Auf Reddit habe ich gesehen, dass auch andere User von dem Problem betroffen sind, aber offensichtlich nicht alle. Da bei mir die App direkt beim Start crashed halfen auch die dortigen Lösungsvorschläge, wie das Deaktivieren von Kalender und Erinnerungen nicht.

Glücklicherweise bietet der Hersteller Cultured Code genaue Anleitungen an, um die App mitsamt Daten zu deinstallieren. Diese Schritte bin ich durchgegangen und konnte die App nach einem System-Neustart endlich wieder starten. Nach einem Login waren wie gewohnt die Things-Daten über die Cloud wieder hergestellt und ich kann die App auch auf dem alten Macbook mit Beta-MacOS wieder nutzen.

Mir hat gefallen, dass die Deinstallation so genau beschrieben ist, da oft auch so manche Uninstall-Programme nicht vollständig löschen und Daten-Reste übrig lassen.

Firebase App Distribution von iOS-Apps via buddybuild

Jahrelang haben wir gerne Crashlytics Beta für die interne Verteilung von Testversionen unserer iOS-Apps verwendet. Crashlytics Beta wird von Google Ende März 2020 eingestellt.

TestFlight ist wohl die bekannteste Alternative. Der Dienst wurde bereits vor mehr als fünf Jahren von Apple übernommen. Die Nachteile von TestFlight waren u.a., dass die Bereitstellung oft durch eine automatisierte Verarbeitung etwas verzögert wurde. Außerdem müssen sich Personen zum Testen auf den jeweiligen Gerät mit ihrer Apple-ID anmelden.

Mit Firebase App Distribution bietet Google einen Ersatz an. Tester nutzen einen Google-Account. Einladungslinks für die Test-Versionen können leicht über die Firebase Console erstellt werden. Außerdem kann man Testpersonen und Testgruppen anlegen und verwalten.

Einige Continuous Integreation Systeme, wie z.B. bitrise, bieten bereits vorgefertigte Integrationen für Firebase App Distribution an. buddybuild unterstützt Firebase App Distribution nicht von Haus aus, man muss die Integration selbst mit Hilfe von eigenen Build Steps durchführen:

Da Firebase CLI verwendet wird muss man sich zunächst ein Firebase CLI Login Token erstellen.

Dieses Firebase Token sowie die Firebase App ID hinterlegt man dann in buddybuild als Environment Variablen FIREBASE_TOKEN bzw. FIREBASE_APP_ID.

Dann kann man die Custom Build Steps für buddybuild ergänzen.

In das Root-Verzeichnis des iOS-Projekts legt man zwei Shell-Script-Dateien. In die Datei buddybuild_postbuild.sh wird der eigentliche Befehl eingetragen, ob die Test-Version der App via Firebase bereitzustellen:

firebase appdistribution:distribute $BUDDYBUILD_IPA_PATH --app $FIREBASE_APP_ID --groups "my-test-group" --token $FIREBASE_TOKEN

Für den obigen Befehl werden die Firebase Tools auf dem CI-Server benötigt. Diese werden global installiert. Dabei stoß ich auf das Problem, dass die globale node.js-Version nicht kompatibel war. Daher versuche ich vor der Firebase CLI Installation zunächst die globale node.js zu aktualisieren. Dafür werden folgende Zeilen in der Datei buddybuild_postclone.sh ergänzt:

echo "Updating global node.js version…"
sudo npm install -g n
sudo n stable

echo "Installing global Firebase CLI…"
npm install -g firebase-tools

Diese Schritte führe ich vor dem eigentlichen Build-Prozesses des iOS-Projektes durch, damit im Fehlerfall der Workflow frühzeitig abgebrochen wird und man so Verzögerungen vermeiden kann.

iOS Simulator CoreTelephony-Log-Spam reduzieren

In neueren Xcode-Versionen wurde ich oft mit Infos über CoreTelephony, wenn ich Apps im iOS Simulator getestet habe. Offenbar wird dieses Verhalten von manchen Frameworks hervorgerufen, u.a. Firebase. Dies habe ich kürzlich in einem GitHub Issue gelesen.

Dort findet man auch den nützlichen Tipp, um diese Log-Ausgaben zu deaktivieren. Im Terminal den folgenden Befehl ausführen:

xcrun simctl spawn booted log config --mode "level:off" --subsystem com.apple.CoreTelephony

Der Befehl muss jeweils auf jedem Computer ausgeführt werden, auf dem die App via iOS Simulator laufen soll.

Textänderung in Datei auf Kommandozeile ausgeben lassen

Mit dem diff-Programm lassen sich in der Kommandozeile einfach Änderungen an Dateien ausgeben lassen. Dies nutze ich z.B. um alle Änderungen bei einem Übersetzungsupdate sehen zu können:

  • Datei.txt temporär kopieren nach AlteDateiversion.txt
  • Änderungen an Datei.txt durchführen
  • diff –side-by-side –suppress-common-lines AlteDateiversion.txt Datei.txt
  • AlteDateiversion.txt löschen

Mit den obigen Parametern zeigt diff nur gelöschte, hinzugefügt und geänderte Zeilen an und stellt die Änderungen zweispaltig da.