Ich persönlich bevorzuge benutzerdefinierte Objekte (oder Structs for Swift), weil ich so leichter erkennen kann, welche Eigenschaften die Objekte haben. Wenn Sie nur Wörterbücher weitergeben, wird es (meiner Meinung nach) viel schwieriger, sich daran zu erinnern, welches Objekt Sie haben, welche Schlüssel es hat und welche verschachtelten Objekte es auch hat. Wenn Sie benannte Klassen haben (wiederum sollten diese Structs in Swift sein), dann können Sie (und der Compiler) leicht wissen, welche Eigenschaften sie haben. Außerdem können Sie auf einfache Weise Instanzmethoden für Ihre Objekte erstellen.
Und wenn Sie nicht wollen, dass die Schmerzen der Analyse sie selbst gibt es Frameworks, die Verwaltung der Server-Antwort in Objekte verwalten (z. B. RestKit https://github.com/RestKit/RestKit).
Wenn Sie Beispielcode von Apple als eine "Empfehlung" von Apple betrachten, können Sie hier sehen, wie sie ein Datenmodell in ihrem "Start Developing iOS Apps" machen: https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/Lesson6.html. Ja, das Beispiel ist für Swift, aber die meisten Konzepte sind vergleichbar.
Apple hat auch "Cocoa Core Competencies" (https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/ModelObject.html), wo sie ein modales Objekt als "in der Regel eine Unterklasse von NSObject oder ... eine Unterklasse von NSManagedObject."
Folgende Trends folgen? Was ist das für ein Unsinn? Wir schreiben stabilen Code, wir folgen keinen Trends. Apple empfiehlt nichts. Ich weiß, was zu tun ist, um stabilen Code zu schreiben. – gnasher729