Vielleicht hilft dir dies hier weiter: watchOS Tutorial: Kommunikation zwischen iPhone und Apple Watch.

Allerdings ist das Beispiel für Swift und SwiftUI.

Die Kommunikation zwischen iOS App und watchOS App sollte jedoch auch mit Objective-C so funktionieren.

Es kann sein, dass für aktuelle watchOS App nur noch Swift und SwiftUI funktioniert.

Storyboards wurden früher meines Wissens über die Info.plist verwaltet bzw. du konntest das über die Target-Einstellungen ändern.

Ich könnte mir vorstellen - weiss es aber nicht genau, dass bzgl. Oberfläche auf der Watch kein Weg an SwiftUI vorbei führt. Macht m. E. angesichts der übersichtlichen Gestaltung bei kleinen Formfaktoren auch durchaus Sinn.

Code-seitig kannst Du beliebig Objective-C und Swift mischen und per Bridging-Header bestehende ObjC-Klassen in Swift referenzieren (und umgekehrt): Das funktioniert gut und erlaubt Dir, SwiftUI aus Legacy-Code zu füttern - BTDT. Manchmal musste ich bei der Erstellung des impliziten Bridging-Headers im ersten Fall etwas aufpassen / tricksen, aber wenn's dann einmal läuft, macht es Spass (und die Code-Completion hilft bei Umsetzung mancher Variablenbezeichnungen sehr).

Bzgl. der Aktualität / Qualität von Apple's Dokumentation erspare ich mir jeglichen Kommentar: Die Zeiten, wo man gute und aktuelle Erläuterungen fand, sind lange vorbei, die Developer müssen wohl vorrangig "hot shit" implementieren...

Mattes

Sieht in Xcode doch gut aus. Was funktioniert denn dabei nicht?

Ok, ich habe es mal mit Xcode 14, 15 und 16 getestet. Ein neues Projekt für eine watchOS App wird immer mit Swift und SwiftUI angelegt.

Die Option für Objective-C und Storyboard scheint es, bei diesen Xcode Versionen, nicht mehr zu geben. Zumindest wurde mir dies nicht mehr angeboten.

Ich habe mir die Swift-Grundlagen - beim Umstieg von Objective-C - über den Kofler angelesen: Damals noch Swift 5 und ohne SwiftUI. Zusätzlich die Language Reference von swift.org und Apple: Das reicht m. E. bei Vorkenntnissen vollkommen.

Allerdings hatte ich den Anspruch, umfangreichere Klassen zukünftig grundsätzlich in Swift zu programmieren: Bei Dir reicht ja scheinbar ein kleiner Controller, der nur ein paar Alt-Klassen referenziert und einige Texte anzeigt: Da kommst Du wahrscheinlich schon mit etwas Google-fu zurande...

Mattes

Bei Udemy gibt es einige Kurse. Aber hier sollte man zum einen darauf achten, dass sich der Kurs auch auf die aktuelle Versionen von Xcode und den OS Versionen auf den entsprechenden Devices bezieht und zum anderen nur kaufen, wenn sie im Sale sind, weil man sonst unnötig Geld dafür bezahlt. Die Sales kommen immer wieder in regelmäßigen Abständen.

Bei den Büchern ist es ähnlich, wenn ein Buch auf dem Markt ist, ist die Entwicklung im System schon weiter. Gute Erfahrung als Nachschlagewerk habe ich aber mit dem Grundlagenbüchern zu Swift aus dem Rheinwerk Verlag gesammelt.

Und schließlich sollte man noch die Apple Developer Dokumentation selbst erwähnen. Hier ist es wichtig, nach den Grundlagen, sich immer auf dem Laufenden zu halten. Die vergangenen Developer Videos sind zum großen Teil online kostenlos samt Materialien- und Beispiele. Hierzu braucht man auch keinen kostenpflichtigen Developer Account, es reicht ein kostenloser Account. Den kostenpflichtigen Account braucht man erst, wenn man mehr braucht zum Testen z.B. Beta Versionen von Systemen und/oder eine App veröffentlichen möchte.

Ich warte zurzeit auf die neuen Betriebsysteme mit den ganzen Nummern. Wenn man frühzeitig sich mit den neuesten Techniken beschäftigen will, kommt man um den kostenpflichtigen Developer Account nicht herum.

Normalerweise sollte man immer nach vorne hin entwickeln. Es macht keinen Sinn, zu versuchen, mit Gewalt Techniken von gestern auf Systemen von morgen umzusetzen. Besser ist es, sich frühzeitig mit den Konzepten von Morgen zu beschäftigen.

Ich würde auch keine "Krücken" einbauen, um alten Code in neue Konzepte zu implementieren. Das sind Konzepte die dazu gedacht sind, wenn es anders gar nicht mehr geht, weil es im neuen noch nichts passendes gibt.

Die Website rund um Swift selbst, also wo über die Sprache- und aktuelle Entwicklungen berichtet wird, sollte man auch auf dem Radar haben. Viele Sachen findet man auch Beie Stackoverflow, aber auch hier ist Vorsicht geboten. Die Gefahr für einen Anfänger, bei Stackoverflow Konzepte zu finden, die so mittlerweile überholt sind ist sehr groß.

Also meine Empfehlung. Für die Basics ein Buch nehmen oder einen Kurs, der einigermaßen aktuell ist (auch schauen, ob der Kurs noch aktualisiert wurde oder nach dem Launch auf dem Stand stehen geblieben ist) und danach direkt versuchen, mit aktuellen Konzepten aus den Developer Ressourcen von Apple selbst zu arbeiten.

Bei kniffligen Fragen hilft manchmal auch die Apple Developer Community weiter. Hier sollte man sich auch trauen, mal eine Frage zu stellen, wenn man überhaupt nicht weiter kommt.

Viel Erfolg dann mit der App !

Ohne nun @hape42s Thread zu hijacken: Grundsätzlich gebe ich Dir zwar recht, aber bei Projekten mit zig Tausend Codezeilen bleibt die Verwendung von altem Code nicht aus - auch wenn man sich an neue Konzepte hält.

So programmiere ich (inzwischen) neue oder maßgeblich geänderte Klassen in Swift, stelle aber nicht "einfach so" die Coderbasis um: Nicht nur aus Kapazitätsgründen, sondern auch, weil jede Umstellung Risiken beinhaltet und getestet werden will - der bestehende ObjC-Code ist "gut abgehangen".

Und bzgl. Oberflächendesign sehe ich SwiftUI nicht als das alleinige neue Konzept, sondern Storyboards haben bei komplexeren UIs meiner Meinung nach noch immer ihre Berechtigung. Nur bei der Watch und Widgets sieht dies gemäß Apple's Vorgaben anders auch - deren Oberflächen sind aber meist eher schlicht gestrickt

Mattes

Hallo Mattes,

ja, Swift Oberflächen sind keine Performance Boosts, die Erwartung darf man auch nicht stellen. In meinen Augen ein Pendant zu Java aus konventioneller Sicht.

Klar, hardwarenahe oder Performance Orientierte Programmierung sind ein Thema für C. Dann aber bitte modern c++ im Standard 23. Das geht übrigens problemlos mit aktuellem Xcode - einfach die Command Line Tools installieren und den Anweisungen unter der Seite von Blender.org folgen, dann hat man eine c++ Entwicklungsumgebung am laufen.

Beispiele dafür sind ja auch OSS Projekte wie Blender 3D (die sind glaub ich grade im Standard 17).

Objective C ist doch ein Sonderfall eng verbunden mit der Historie des Betriebssystems. C mit Objekten halt und wenn es um Funktionen geht, die eben Mac OS
spezifisch sind, wird man nicht umhin kommen, es zu nutzen.

Die Frage ist halt immer auch nach der Zielplattform.

Generell ist es natürlich gut, wenn man sich mit Grundlagen beschäftigt hat und solange Objective C Bestandteil der Infrastruktur ist, ist man auch gut beraten, sich
damit auszukennen - keine Frage.

Die Frage wäre aber, ob sich der TE für seine Anwendung damit einen Gefallen tut, weil er ja noch Anfänger ist und Grundlagen lernen möchte.

Die Frage wäre auch, ob die App performance Lastig ist, oder eher nicht. Und hier ist es doch so, dass man abwägen sollte. Der erfahrene Entwickler weiß natürlich, womit am
am schnellsten zum Ziel kommt.

Aber als Anfänger halt - ich sehe da eher einen zusätzlich Workload, als ein schnelles Ziel.

Gutes Buch zu dem Thema Objective C ist natürlich von Aaron Hillegass - The Big Nerd Ranch Guide - es ist ein Standard Werk, was jeder Apple Entwickler im Regal stehen
haben sollte.

Ich fürchte, wenn man hier aktuell testen möchte was geht, wird man dem Developer Programm beitreten müssen, und Watch OS 26 laden nebst aktuellem XCode in Mac OS 26 - alles andere wird sonst Rätselraten bleiben.

Ich hätte aber auch keine Lust, meinen Rechner zu Testzwecken in eine Beta Test Maschine umzuwandeln, wenn ich ehrlich bin.

Es ist halt auch die Zielplattform, die hier einschränkt. Apple selbst scheint alle neue Funktionen für Watch OS 26 mit Swift UI umzusetzen, habe gerade mal in den Developer Beiträgen gestöbert. Es gibt allerdings auch noch eine Menge an Bugs.

In diesem Sinne - schönes Wochenende !

Hallo,

ich habe mir noch mal die Mühe gemacht, um explizit zu Recherchieren.

Der einzige Weg eine Multi Plattform App zu entwickeln, die auf Mac OS, Watch OS, iOS / iPad läuft - ist Swift UI. Es gibt keine Alternative - no Way.

Der einzige Weg außerhalb der Apple Infrastruktur zu entwickeln sind Apps, die ausschließlich auf Desktops laufen.Nur dort kann man z.B. auf andere Programmiersprachen z.B. C++ ausweichen und Apps außerhalb der Apple Infrastruktur und eines Developer Accounts in einem Paket packen und verteilen.

Bestes Beispiel dafür ist die App Blender 3D, die ja bekanntermaßen Multi Plattform außerhalb Apples App Store Infrastruktur ist. Es gibt noch andere Opensource Apps, die dann auch diesen Weg gehen.

Also muss eine grundlegende Entscheidung getroffen werden, ob die App innerhalb Apples System vermarktet werden soll oder außerhalb Apples System.

Bei der Entscheidung auf Apples Infrastruktur sind die Karten bereits gefallen zu Swift UI. Apple selbst entwickelt neue Teile ihres eigenen Frameworks ausschließlich in Swift UI.

Die Zukunft von reinen Desktop Apps ist ein Sonderthema. Hier ist die Hoffnung ja, dass die Welten irgendwann einmal verschmelzen.

Es gibt aber definitiv bisher keine App vom Funktionsumfang bisheriger Desktop Apps, welche Multi Plattform wäre - mir ist zumindest keine bekannt. Denn. die Pro Apps unterscheiden sich vom Funktionsumfang erheblich zu den mobilen Pedanten. Bestes Beispiel dazu wäre Logic Pro.

Die Apps sind dann vielmehr so entwickelt, dass z.B. Tablet App und Desktop sich verbinden lassen.

Das hängt mit dem Geschäftsmodell von Apple zusammen. Apple will halt, dass jeder alle Geräte von Apple kaufen muss. Es reicht also nie, einen Computer zu besitzen, man muss Desktop Rechner, Tablet, Uhr, Handy kaufen um alle Vorteile aller Geräte vereinen zu können. Und das ist meiner Meinung nach auch der Grund, warum es nie einen hybriden Computer geben wird, vergleichbar wie in der Windows Welt z.B. Notebook mit integriertem Touch, was zwischen Desktop Modus und Tablet Modus hin- und her schalten kann.

Und Zusammengefasst bedeutet dies:

Wenn die Ziel Plattform alles andere als ein Desktop Mac ist, muss zwingend Swift UI verwendet werden. Nur wenn die Ziel Plattform ausschließlich Desktop Rechner mit Mac OS sind, kann davon abgewichen werden.

Aber das nur am Rande - läuft doch dann Deine Lösung !

Viel Glück- und Erfolg dann weiterhin damit !