Rob212 Rob212 - 1 year ago 163
Swift Question

Realm Swift Models separate or not?

I'm new to the world of iOS and Swift and am working on a new app which I want to use Realm for persistence. I have Entities in my code already which my Services access and populate for an HTTP API endpoint.

Now I want to persist certain Entities and wanted advice as to whether I should create new Realm specific Models for each of my entities to read and write from Realm. Or should I convert all my existing plain Swift Entities to Realm Entities. At first this felt wrong as I would be passing Realm Entities al around my app instead of just in the persistence layer.

However, the alternative is that every time I read/write entities to Realm I need to convert them back and forth from Entities to Realm Entities.

Any advice on the best approach to this?


Answer Source

Both strategies are fine and have their own advantages and disadvantages.

Value Objects + Realm Objects

  • ✅ Value objects are thread-safe
  • ✅ Value objects can be mutated anywhere, without worrying about side-effects
  • ✅ Value objects can be arbitrary defined and allow to use the full possibilities of the language, which allows to workaround constraints given by object persistence mapping
  • ❗️ No lazily-loading, which means the full object hierarchy has to be loaded into memory
  • ❗️ Can't express cycles
  • ❗️ Requires to maintain your model definitions twice
  • ❗️ Needs logic to map from transport encoding (e.g. JSON) to Swift Structs and from those to Realm Objects

Using only Realm Objects

  • ✅ Zero-copy, which means reading from them is less expensive
  • ✅ Live, which means their data is always up to date
  • ✅ Lazily loaded from the database: fewer disk reads
  • ✅ Can express cycles and arbitrary object hierarchies
  • ✅ Define your model in one place
  • ✅ If you can control the transport encoding and you can share naming conventions, you could rely mostly on Realm's integrated Foundation value type mapping logic used by create(_:update:_) and its friends.
  • ✅ Supports KVO, which allow easy integration with some reactive programming frameworks
  • ❗️ Adds constraints to the way how you define your model objects (Some language constructs are not directly supported as enums and require workarounds for now)
  • ❗️ Reference types need more care for mutations to avoid undesirable side-effects, in addition modifications are only possible within write transactions (which should be batched to be as large as possible)
  • ❗️ Realm Objects are not thread-safe


You lose many Realm features when opting out of Realm Objects and will have a hard-time to re-implement them yourselves. Depending on how much you need these and how your use-case looks like, you would buy thread-safety for a high cost.

In the long-term we're working on making Realm objects even easier to use and try to eliminate their disadvantages, so long being aware what those are will be helpful for making a well-informed decision.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download