WWDC: Viele interessante, kleinere Neuerungen für Anwender und Entwickler

Die Keynote der WWDC 2019 liegt hinter uns – präsentiert wurde der neue Mac Pro, ein Apple-eigenes Display und neue Versionen von allen Betriebssystemen. Nun zählt Apple insgesamt fünf verschiedene Systeme: iOS, macOS, tvOS, watchOS und nun auch iPadOS. Viele Neuerungen abseits der Endkundenfeatures gingen aber fast vollständig unter. Hier eine Übersicht, welche Neuerungen Sie möglicherweise verpasst haben.


CoreData on CloudKit
CoreData ist ein Framework von Apple, welches vorrangig die objektorientierte Entwicklung mit SQLite vereinfacht. CloudKit hingegen ist eine NoSQL-Datenbank auf iCloud, welche sich perfekt zur Synchronisierung von Daten über alle Apple-Geräte hinweg eignet. Dummerweise sind beide Technologien bisher komplett getrennt und jeder Entwickler muss sich selbst um die Schnittstelle zwischen beiden kümmern.

Mit CoreData on CloudKit will Apple dieses Manko abschaffen: Mit iOS 13 und macOS Catalina soll es für Entwickler nun möglich sein, CoreData-Datenbanken einfach über CloudKit synchron zu halten. Wie stabil und gut Apples erstes Umsetzung ist, wird sich erst in den kommenden Monaten zeigen –die Implementierung einer solchen Lösung ist für Apple alles andere als einfach.

Neue Watch-Komplikationen
Auf der Bühne wurde vorrangig die Umgebungsgeräusch-Komplikation vorgeführt, doch watchOS 6 bringt noch weitere neue Zifferblatt-Zusätze mit: Die neue Wind-Komplikation zeigt auf Wunsch die aktuelle Windstärke an. Außerdem steht nun eine Ziffernblatt-Erweiterung zur Verfügung, welche die aktuelle Mobilfunk-Empfangsstärke zeigt. Viele Anwender rufen die Wetter-App auf der Watch auf, um nachzusehen, wie hoch die Regenwahrscheinlichkeit ist. Auch diese Information lässt sich in watchOS 6 nun als Komplikation anzeigen.

Notarisierung nun Pflicht
Bisher können Entwickler Apps noch selbst mittels Developer ID signieren – völlig egal, welchen Code diese beinhalten. Fällt Apple auf, dass der Entwickler beispielsweise Malware vertreibt, wird das Developer-ID-Zertifikat widerrufen. Apple führte mit macOS 10.15 daher den "Notary Service" ein, mit dem jede App und jede Version der App speziell von Apple zu "beglaubigen" ist. Die App wird zu Apple hochgeladen, analysiert und dann mit einem Stempel versehen, welcher das Ausführen erlaubt.

Dies ist mit macOS Catalina fortan Pflicht: Alle Kernel Extensions, Installer-Pakete und Mac-Apps müssen nun notarisiert sein, um ausgeführt werden zu können. Apple zieht hier in Zukunft die Daumenschrauben auch für Entwickler außerhalb des Mac App Stores an: Es ist zu erwarten, dass Apple Einschränkungen wie zum Beispiel die App-Sandbox zukünftig für alle Entwickler vorschreibt. Auch ist davon auszugehen, dass Apps, die private Programmierschnittstellen verwenden, in mittelfristiger Zukunft nicht mehr notarisiert werden.

zsh nun die Standard-Shell
Bisher verwendet Apple bash als Standard-Shell auf allen macOS-Versionen. Mit macOS Catalina wechselt Apple aber auf "zsh". In einem Support-Dokument erklärt Apple, wie man auch unter macOS Mojave oder früher auf zsh umsteigen kann und dass man vorhandene Shell-Skripte mit zsh testen sollte.

"Grapher" nicht mehr Bestandteil von macOS Catalina
Seit Mac OS 9 war Grapher (damals noch "Graphing Calculator") Bestandteil des Mac-Betriebssystems. Mit macOS Catalina beerdigt Apple leider das von vielen lieb gewonnene Programm – es ist nicht mehr Bestandteil der Installation. Aktualisiert man aber einen Mac von Mojave auf Catalina, bleibt das Grapher-Programm auf der Festplatte erhalten und kann weiter genutzt werden.

Kommentare

aMacUser
aMacUser04.06.19 13:52
Wird SwiftUI eigentlich auch unter Linux funktionieren? Einen Linux-Compiler für Swift stellt Apple ja bereit und SwiftUI soll ja auch komplett in Swift geschrieben sein. Eine Kompatibilität wäre schon richtig cool.
0
LoCal
LoCal04.06.19 13:57
aMacUser
Wird SwiftUI eigentlich auch unter Linux funktionieren? Einen Linux-Compiler für Swift stellt Apple ja bereit und SwiftUI soll ja auch komplett in Swift geschrieben sein. Eine Kompatibilität wäre schon richtig cool.

Ich denke eher nicht … Objective-C gibt es ja auch auf verschiedenen Plattformen … AppKit nicht.
Auch ist das Grundsystem von macOS/iOS schon immer OpenSource, aber die Frameworks waren es nie und waren auch nie ausserhalb macOS/iOS verfügbar.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+1
netspy
netspy04.06.19 14:14
Hat schon mal jemand eine SwiftUI-App in Xcode 11 zum Laufen bekommen? Hab mit der Beta einfach eine neue App erstellt und eine SwiftUI-View erzeugt. Das Vorschau-Fenster wird mir jedoch nicht angezeigt.
0
Macmissionar04.06.19 14:20
Ich hoffe, es sind weiterhin kleine Eigenentwicklungen mit dem Skript-Editor, also Bordmitteln von AppleScript, möglich.
A Mac is like a Wigwam: No Windows, no Gates, no Backdoors, Peace, Harmony – and an Apache inside.
0
Paperflow04.06.19 14:23
„Low data mode“ klingt interessant.

Kürzlich versehentlich der „Here“ App die LTE-Nutzung für die Stauwarnung erlaubt. Kurz darauf gab es ein Karten-Update und es hat mir gleich 1 GB Daten runter geladen. Genauso mit dem Hotspot. Kurz für mein MacBook zur Verfügung gestellt, und schwups waren gleich 500 MB weg, obwohl ich nur iMessage kurz testen wollte.

1. Schön wäre eine Warnung bei erhöhtem verbrauch (einstellbar, z. B. ab 10MB).

2. Standardmäßig darf jede neu installierte App über LTE den Datenvolumen aufbrauchen. Nach jeder Installation muss ich deshalb unter „Mobiles Netz“ den Schalter deaktivieren.

Nach der Installation sollte eine App standardmäßig um Erlaubnis fragen um das Mobile Netz nutzen zu dürfen.

Gibt es evtl. eine App die sowas kann?
0
ssb
ssb04.06.19 14:31
Das Ende von Objective-C würde ich massiv bedauern. Von der Struktur und dem Ansatz ist Objective-C anderen Sprachen inkl. Swift weit überlegen. Es ist in der Laufzeit und Struktur einfach nah dran an SmallTalk benutzt aber doch überwiegend die C-Syntax. Es gibt da so viele Features, die ich an Objective-C einfach genial finde - und das "Late Dynamic Binding" von Objective-C ist bislang ungeschlagen...
+2
riessi04.06.19 14:43
Paperflow
Genauso mit dem Hotspot. Kurz für mein MacBook zur Verfügung gestellt, und schwups waren gleich 500 MB weg, obwohl ich nur iMessage kurz testen wollte.

Gibt es evtl. eine App die sowas kann?

für den Mac gibt es Trip Mode - da kann man einstellen, welche Programme bei einem Hotspot eine Internetverbindung bekommen.
0
verstaerker
verstaerker04.06.19 14:46
Notarisierung nun Pflicht
heisst das es können keine Apps ohne Apple-Signierung mehr ausgeführt werden?
+2
Dirk!04.06.19 14:53
netspy
Hat schon mal jemand eine SwiftUI-App in Xcode 11 zum Laufen bekommen? Hab mit der Beta einfach eine neue App erstellt und eine SwiftUI-View erzeugt. Das Vorschau-Fenster wird mir jedoch nicht angezeigt.

Das geht leider nur, wenn Xcode 11 unter Catalina Beta läuft.
+1
sierkb04.06.19 15:09
Macmissionar
Ich hoffe, es sind weiterhin kleine Eigenentwicklungen mit dem Skript-Editor, also Bordmitteln von AppleScript, möglich.

Apple: macOS 10.15 Beta Release Notes :
Apple, macOS 10.15 Beta Release Notes
[…]

Scripting Language Runtimes

Deprecations

  • Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
  • Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165)

[…]

Drauf aufmerksam geworden via:

MacPorts.org, macports-dev-Mailinglist (Jun 4, 2019): Deprecation of scripting languages in macOS


Hmmm, gehört die Scripting Language namens AppleScript nun dazu zu dem von Apple beispielhaft aufgezählten aber nicht unbedingt darauf begrenzten Sprachen-Reigen, oder nicht?
Bzgl. Python bin ich etwas verwundert, nutzt das System selber vor allem Python recht exzessiv für alle möglichen Tasks auf System-/Unix-Ebene selbst für einfachste Shell-Befehle und -System-Skripte, um den Betrieb überhaupt zu gewährleisten. Was wird stattdessen Ersatz sein, wenn sie sogar Python rausschmeißen?
+1
Mojo6604.06.19 15:24
Mit CoreData on CloudKit will Apple dieses Manko abschaffen: Mit iOS 13 und macOS Catalina soll es für Entwickler nun möglich sein, CoreData-Datenbanken einfach über CloudKit synchron zu halten. Wie stabil und gut Apples erstes Umsetzung ist, wird sich erst in den kommenden Monaten zeigen –die Implementierung einer solchen Lösung ist für Apple alles andere als einfach.

Würde mich mal interessieren wie der Autor da drauf kommt. Ich selbst benutze bei meinen Apps sowohl CoreData als auch CloudKit. Das ist kein Hexenwerk das zu synchronisieren, die Herausforderung liegt einzig und allein darin, dass CloudKit extrem asynchron ist und es gleichzeitig sehr viele verschiedene Möglichkeiten gibt dass etwas schief geht. Das muss man alles mühselig abfangen.

In ähnlicher Form gibt es das übrigens als Community Project unter dem Namen YapDB.

Also "alles andere als einfach" würde ich gerne genauer wissen.
0
macStefan04.06.19 15:28
Mojo66
Also "alles andere als einfach" würde ich gerne genauer wissen.

Wahrscheinlich sind hier die Erfahrungen gemeint, die App-Entwickler mit iCloud Sync gemacht haben in den ersten Jahren von Apples Wolkenaktivitäten. Das ganze war so wenig zu gebrauchen, dass viele Apps über kurz oder lang doch wieder eigene Sync-Services angeboten haben. Diese Probleme wurden erst Jahre später ausgeräumt und da Apple allgemein nicht der große Online-Service-Macher ist kommt es wohl zu dieser Einschätzung.
+2
LoCal
LoCal04.06.19 15:50
macStefan
Mojo66
Also "alles andere als einfach" würde ich gerne genauer wissen.

Wahrscheinlich sind hier die Erfahrungen gemeint, die App-Entwickler mit iCloud Sync gemacht haben in den ersten Jahren von Apples Wolkenaktivitäten. Das ganze war so wenig zu gebrauchen, dass viele Apps über kurz oder lang doch wieder eigene Sync-Services angeboten haben. Diese Probleme wurden erst Jahre später ausgeräumt und da Apple allgemein nicht der große Online-Service-Macher ist kommt es wohl zu dieser Einschätzung.

Das wollte ich auch gerade schreiben, trotzdem gehört so eine subjektive (oder sollte ich polemische schreiben?) Anmerkung nicht in einen sachlichen Artikel?

Weiss jemand ob es schon den SampleCode gibt? Hab vorhin einen kritischen Tweet zum Sample-Code von CoreData on CloudKit gelesen und kann dazu weder auf den WWDC-Seiten noch im DeveloperPortal was finden.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
0
Mojo6604.06.19 15:53
macStefan
Wahrscheinlich sind hier die Erfahrungen gemeint, die App-Entwickler mit iCloud Sync gemacht haben in den ersten Jahren von Apples Wolkenaktivitäten. Das ganze war so wenig zu gebrauchen, dass viele Apps über kurz oder lang doch wieder eigene Sync-Services angeboten haben. Diese Probleme wurden erst Jahre später ausgeräumt und da Apple allgemein nicht der große Online-Service-Macher ist kommt es wohl zu dieser Einschätzung.

Ich erinnere mich dunkel. Hast du zufällig einen Link parat?
0
macStefan04.06.19 15:54
Mojo66
Ich erinnere mich dunkel. Hast du zufällig einen Link parat?

Ne, das ist auch mehr eine Zusammenfassung meiner eigenen Erfahrungen als Entwickler und den Aussagen von anderen Entwicklern populärer Apps.
0
Mojo6604.06.19 15:57
Platforms State of the Union ist jetzt online:
+1
C6404.06.19 16:10
Oha.. Grapher war schön... Muss ich doch nur noch Geogebra verwenden
+1
Mojo6604.06.19 16:20
Wow die Demo von SwiftUI...hammerhart. Ich lasse bei meinen Apps einen Zähler mitlaufen für jedes Build das ich mache, bei den meisten Apps geht der hart auf die 10.000 zu. Mit diesem SwiftUI Dingens wird der wohl in Zukunft kaum mehr vierstellig werden.
0
Frost04.06.19 21:26
verstaerker
heisst das es können keine Apps ohne Apple-Signierung mehr ausgeführt werden?

Das kann ich mir nicht vorstellen, wenn ich z.B. Anaconda
auf dem Mac Installiere und darin meine Python Anwendungen
schreibe kann nicht jede Anwendung vor dem Ausfuehren
von Apple getestet und signiert werden.
0
Weia
Weia05.06.19 03:37
MacTechNews
macOS Catalina wie auch iOS 13 bringen Frameworks mit, welche sich nur noch aus Swift heraus ansprechen lassen. Ein Beispiel ist das neue Combine-Framework zur asynchronen Event-Abarbeitung: Dies liegt nicht mehr in einer mit Objective-C kompatiblen Fassung vor.

Es ist zu erwarten, dass neue Frameworks, welche Apple in den kommenden Jahren präsentiert, wohl nur noch mit Swift nutzbar sind. Dies markiert den Anfang vom Ende von Objective-C in der Apple-Welt, da Entwickler mittel- bis langfristig auf Swift umschwenken müssen.
Hmm, liegt das beim Combine-Framework nicht einfach daran, dass das deklarativ ist und das eben Swift voraussetzt?

Oder andersherum: Wie sollte eine Swift-only App denn auf die Unix-Basis von macOS, die nunmal in C geschrieben ist, und auf die in C++ geschriebenen Treiber zugreifen können?

Wird es nicht eher so sein, dass manches nur in Swift geht und manches nur in Objective-C?

Aber ich gebe zu, mir gefällt die Entwicklung gar nicht, auch im Sinne von …
ssb
Das Ende von Objective-C würde ich massiv bedauern. Von der Struktur und dem Ansatz ist Objective-C anderen Sprachen inkl. Swift weit überlegen.
… was ich nur doppelt und dreifach unterstreichen kann.

Und dann noch
sierkb
Apple, macOS 10.15 Beta Release Notes
  • Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages.
Klingt irgendwie, als wollten Tim Cook & Co, nachdem sie auf der Hardware-Seite die Infantilisierung des Macs als iPad nicht durchdrücken konnten, das jetzt auf der Software-Seite versuchen.

macOS als Sandkasten für Apps statt als akademisch ernstzunehmende Unix-Plattform – Gar nicht schön … 
+1
gauloisesbert05.06.19 09:16
Weia
macOS als Sandkasten für Apps statt als akademisch ernstzunehmende Unix-Plattform – Gar nicht schön … 

Akademisch ernstzunehmende User wissen, wie man Interpreter/Compiler zum Laufen bekommt.

Trotzdem: Mit dem Weglassen spart eigentlich gar nichts.

Andererseits zB: Wir nutzen hier spezielle Simulationssoftware unter Linux - und die bringt tatsächlich ihre eigenen Interpreter bzw. Gnu-Utils mit. Und greift nicht auf die CentOS standard-installierten Tools zurück.
0
Mojo6605.06.19 12:34
Der Wechsel von bash auf zsh soll was mit GPL v2/v3 zu tun haben, vielleicht hat das Weglassen von python auch was damit zu tun.
0
Weia
Weia05.06.19 13:01
gauloisesbert
Akademisch ernstzunehmende User wissen, wie man Interpreter/Compiler zum Laufen bekommt.
Das ist schon klar, zumindest, solange GateKeeper & Co sie noch lassen. Es hat aber in jedem Fall Symbolwirkung und ist bei jeder neuen Maschine erneut Arbeit. It just works geht anders …
0
Weia
Weia05.06.19 13:02
Mojo66
Der Wechsel von bash auf zsh soll was mit GPL v2/v3 zu tun haben
Seufz!
0
Steffen Stellen05.06.19 17:03
Als jemand der jeden Tag mit anderen UI-Frameworks arbeiten muss, fand ich die Präsentation von Swift UI einfach nur das absolute Highlight. Die Echtzeitvorschau des UIs ist nichts Neues, aber wenn Apple es hinkriegt, dass das auch bei komplexen UIs funktioniert, dann haben sie sich die Krone aufgesetzt.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.

OK MacTechNews.de verwendet Cookies unter anderem für personalisierte Inhalte, Seitenanalyse und bei der Auslieferung von Google-Anzeigen. Dies war zwar schon immer so, auf Wunsch der EU muss nun jedoch explizit darauf hingewiesen werden. Durch Nutzung der Website erklären Sie sich damit einverstanden. Weitere Informationen