I have created an Observable Class, show below.
My intent is to be able to easily provided me with data that will be needed by the various views I have.
Is what I have done acceptable, knowing that each property do seperate things and are not directly related?
class DataModel { var fileName = "No file selected" var windowTitle = "WSPR Analysis " var recordArray: [[String]] = [] }
Your question is a little broad, and sort of tough to answer well without more context.
Assuming this is a root-level data model, there's nothing necessarily wrong with the schema you have here, but as your application grows, you should definitely keep an eye on the overall schema you're creating and whether or not it makes sense to you.
As-is, this schema is so simple that there probably isn't much reason to try and introduce anymore abstraction or organization.
So from a standpoint of "is it acceptable to be a reference type via a class?" Yes, @Observable not only makes sense for reference semantics but requires it. Namely because you have to have a concept of identity to know what you are observing.
From the standpoint of related data, often design patterns favor a concept of "isolation of control" in that like things are grouped together such that their mutation or responsibilities of that data are logically grouped together. In more complex systems than say this example it might be good to have diligence around this to ensure that team members know what data is stored where (making the human scale of things easier). Functionally there is little to no difference storing 5 properties in one class and 4 in another versus 9 properties in one type if they share the same lifetime and such. I would get worried when you are perhaps talking about storing hundreds of properties however (I would start to worry about the performance of compile times at that point).