Xcode Setup für Objective-C in 2025

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Xcode Setup für Objective-C in 2025

    Liebes Forum,

    würde gerne in Amin Negm Awads Buch arbeiten und frage mich nach den besten Einstellungen in Xcode (v16.2)
    Freue mich über Gedanken und Hilfe hierzu.
    Möglicherweise sind es ja nur ein paar Handgriffe...

    DANKE!

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von TryNot ()

  • TryNot schrieb:

    würde gerne in Amins Buch arbeiten und frage mich nach den besten Einstellungen in Xcode.
    Ich bin mir ehrlich gesagt gar nicht besonderer Xcode-Einstellungen bewusst - wobei ich vielleicht die ein oder andere Anpassung vergessen habe. Hier ein paar Punkte, die mir wichtig, aber natürlich Geschmacksache sind:
    • Ein geeigneter Font, der die Darstellung von Null und dem Buchstaben "O" deutlich unterscheidet und monospaced ist.
    • Das Einblenden der Debug-Konsole während der Run-Phase (und Ausblenden danach)
    • Indention mit Tabs = 4 Zeichen
    Wichtiger sind eigentlich kleine Helferlein oder Angewohnheiten beim Programmieren. Hier entwickelt jeder seinen Code-Style, wobei es natürlich Best-Practices gibt. Ein kleiner Auszug bei mir:
    • Meine Klassen beginnen immer mit einem (App-eigenen) Prefix, das vermeidet ungewollte Namenskonflikte.
    • Sprechende Bezeichnungen, mit camelCase zwecks besserer Lesbarkeit
    • Geschweifte Klammern stehen in eigenen Zeilen, um Blöcke deutlich zu machen (Allman Style). Hier probiere ich gerade in neuem Swift-Code die inzwischen gängige Variante, die Anfangsklammer am Zeilenende zu lassen (K&R Style). Egal was, Hauptsache konsistent.
    • Eine angepasste NSLog-Funktion, die nur bei Debug-Läufen Ausgaben inkl. Funktionsnamen und Zeilennummern erzeugt (definiert in einem Prefix-Header)
    • Eine Build-Phase, die automatisch die Versions- / Build-Angaben aus der Source-Code-Verwaltung (git) generiert
    • Eine Projektstruktur in Xcode nach UI-Klassen, Backend-Klassen, Ressourcen etc. ... hier macht Xcode es einem inzwischen etwas schwer
    • Einen allgemeinen Breakpoint "All Objective-C Exceptions"
    Ich habe bestimmt x Sachen vergessen und bin gespannt auf die Tipps und Tricks der anderen ;)

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • oh, das ist ein feine Antwort, lieber Mattes. Ich bin - glaube ich - erstmal auf der Suche nach der Anpassung der richtigen Source Code Version und dem Ort in Xcode, wo man dies vernünftig angibt.


    MyMattes schrieb:

    Ich bin mir ehrlich gesagt gar nicht besonderer Xcode-Einstellungen bewusst - wobei ich vielleicht die ein oder andere Anpassung vergessen habe.

    Ich habe gelesen, dass es eine Möglichkeit zur automatischen Erkennung der Source Code Version eines Projektes geben soll(??).

    Der Ursprungscode müßte jedenfalls in der Richtung MacOSX 10.6 liegen. Ich hänge mal meinen derzeitigen Stand der Fehlermeldungen als Screenshot nach dem Download zu Card Game (Stand Ordner 73) an.

    Quelle : cocoading.de/Books/

    (aus Band 2, Objective-C und Cocoa, Amin Negm-Awad)

    Ich hoffe, man kann daraus ein wenig erschließen, wo ich anfangen könnte, wenn nötig, Xcode manuell auf den Stand zur Adaption des Obj-C Projektes zu bringen...

    Ich habe bereits den Interface Builder soweit, dass er mir das Layout mit den Elementen anzeigt. Hier habe ich folgendes eingestellt:
    Identity Inspector>Interface Builder Document > macOS 10.6 and Later. Scheint jedenfalls zu funktionieren.

    Jetzt muss ich mal an die ganze "deprecated" - Geschichte des Source Codes, vermute ich...
    Würde mich jedenfalls sehr freuen, wenn ich zum Obj-C Buch mitcoden könnte - und das Setup mit etwas Hilfe abkürzen kann

    DANKE!!
    Dateien
    • issues_Obj-C.png

      (355,55 kB, 4 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 13 mal editiert, zuletzt von TryNot ()

  • Du suchst nach dem „deployment target“, das angibt, ab welcher macOS-Version Deine App laufen soll. Das ändert nichts daran, dass sie mit dem (wahrscheinlich neueren) SDK Deines Xcodes übersetzt wird. Im Falle veralteter Methoden / Properties / Konstanten wirst Du Meldungen bekommen, wenn das Deployment Target diese nicht mehr unterstützt. Auslaufend (=„deprecated“) ist aber zunächst nur eine Warnung, dass eine Funktion zukünftig wegfallen wird, aber noch verfügbar ist. Im Zweifelsfall in die Apple-Doku schauen, da steht das drin.

    Grundsätzlich würde ich nicht mit derart altem Material lernen, es hat sich zu viel geändert. Und selbst ich würde jetzt kein Objective-C mehr verwenden, sondern auf Swift setzen … es sei denn, Du hast sehr gute und konkrete Gründe.

    Mattes

    P.S.: Das Deployment Target setzt Du in den Projekt-Eigenschaften

    P.P.S.: Ich habe aus Neugier einmal gegoogelt - das Buch ist 15 Jahre alt: Lass‘ es! Warum sollte man das wollen? Überlege einmal, was sich in der Zeit an Frameworks etc. ändert, von der Sprache ganz zu schweigen.
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes ()

  • @MyMattes
    Ich schaue mir mal das Deployment Target thema genauer an. Wenn das wikliches Gefummel wird, bringt es natürlich nichts.
    Schade um die schönen (deutschsprachigen) Bücher. Ich habe ein größeres Projekt hier, das noch auf Obj C ist, dass ich weiter pflegen wollte, vermutlich lohnt sich inzwischen - zumindest parallel - ein Neuaufbau der App-Konzeption. Es ist nichts Kommerzielles, daher bin ich auch etwas zurückhaltend hier viel Zeit und Energie im Forum für allzu Traditionelles zu beanspruchen.
    DANKE!!
  • Das Deployment Target ist kein „Gefummel“, aber Du reitest hier ein totes Pferd - womit ich mehr veraltete Konzepte und Frameworks meine, als Objective-C als Sprache. Überhaupt ist Kenntnis der Apple Frameworks m. E. weit wichtiger (und aufwändiger) als die eine oder andere Programmiersprache zu lernen.

    Daher würde ich eben nicht mit veralteten Unterlagen lernen … und aktuelle werden Swift verwenden.
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Lieber Mattes,

    der Code des Buches ist aus 2009 den Eintragungen der Files nach. Das Deployment Taget konnte ich umschalten, allerdings gibt es immer wieder errors. Einer besagt, dass der Range des Deployment targets erst ab 10.13 als minimumversion startet. Usw. also: Totes Pferd.
    Wenn man einwenig in der Tradition schauen möchte, wird es gewissermaßen einen letzten Stand bei Obj-C geben, der in aktuellen Xcode Versionen unproblematischer läuft - und entsprechendes Lernmaterial. Ich gehe mal davon aus, daß Apple in Obj-C nichts weiter entwickelt (auch bezüglich Frameworks). Ich habe Obj-C Stanford Kurse aus 2013 gefunden, mal sehen, was da so passiert.
    Tim
  • TryNot schrieb:

    Ich gehe mal davon aus, daß Apple in Obj-C nichts weiter entwickelt (auch bezüglich Frameworks).
    Es geht in Objective-C noch recht viel - und das wird m. E. aufgrund des großen Code-Bestandes (auch bei Drittentwicklern) auf absehbare Zeit so bleiben. Ansonsten würde Apple den Ast absägen, auf dem sie sitzen. In meiner "Leib-und-Magen"-App sind z. B. >90% der Klassen noch in Objective-C und deren Umstellungsaufwand und -risiko lässt sich nicht rechtfertigen.

    Aber neue Klassen (oder auch umfangreiche Anpassungen) mache ich in Swift, um nicht in einer "historischen Sackgasse" zu enden. Bestes Beispiel für die von Dir oben genannte Situation der Frameworks: StoreKit 2. Diese API ist Swift-only, aber um solche Längen besser als das vorherige StoreKit, dass ich dies für besagten Swift-Wechsel zum Anlass nahm: Er erlaubte mir, bei In-App-Purchases auf Abhängigkeiten zu OpenSSL und Receigen zu verzichten.

    Oder auch an anderer Stelle: Momentan ersetze ich XIBs mit NSSplitView durch Storyboards mit NSSplitViewController ... weil letzterer einen Umstieg auf Liquid Glass und eine moderne UI (z. B. mit Inspector) wesentlich leichter macht.

    Man macht sich keinen Gefallen, gegen die Entwicklung des Eco-Systems an zu programmieren :)
    Diese Seite bleibt aus technischen Gründen unbedruckt.