I had almost given up on getting any traffic here. So, I'm excited that I got some good questions. Let me try to answer them.

1. It is kind of a bummer that we don't support Swift. As silly as it is, probably the main reason for this is that at FB we only really code in ObjC (at least for the near term), so we wouldn't have any local use cases (which both drive our development and help us validate that the concept is useful).

It is also true that the need for this type of system is a lot greater in ObjC. Like you said, Swift is awesome in terms of its support for immutable objects and it even supports something a lot like ADTS out of the box (they call them "Associated Values" in their enums).

Because Remodel makes these nice concepts available in Objective-C, it's a useful tool for people who like Swift but are, for whatever reason, working in a Objective-C codebase.

Also, at some point we may make a Swift output option and it would have value in terms of the plugins that can make simple operations like encoding / decoding or other basic helpers.

2. A .ts file is a TypeScript file, which is a language that Microsft developed which compiles to JavaScript. TypeScript looks a lot like JavaSript, but it has types.

We chose TypeScript for the implementation of Remodel because we liked the fact that it's based on JavaScript which is extremely popular, well-known, and also suited toward functional programming. TypeScript uses JavaScript's familiar syntax but adds compile-time support for strong types and generics, filling in one of the major gaps in the language.

3. I actually wasn't aware of mogenerator -- but looking through it, I can see that there is some overlap and also important differences.

One of the best benefits of Remodel is that once you start generating your models through it, people cannot add custom code to them.

This lines up with a big section in the blog about architecture ("Modeling Your Architecture"). To sum it up here: there are a lot of benefits to keeping models completely free of custom logic and instead putting that logic into behavior classes.

In mongenerator, however, it appears that every entity gets a subclass to add custom code, which is at odds with this philosophy.

There are also some differences around the focus on CoreData in mongenerator while Remodel objects are completely free of assumptions about how they're stored, transported, etc.

4. Remodel generates simple encode/decode methods for you out of the box, and the plugin system we have could allow you to generate other transformation logic for your models.

I honestly don't work with CoreData that much, so I'd need more details to give a better answer to this question.

5. You're right that we're not talking about xcmodels here. Overall, Remodel objects operate very much as vanilla Objective-C objects, so the workflow is pretty basic and familiar:

* Create a .value file, for example MyModel.value:
MyModel {
NSString *prop1;
}

* Run '$ remodel-gen MyModel'
* This yields 2 new files (MyModel.h and MyModel.m)
* Add MyModel.h and MyModel.m to your project
* Make behavior classes that use the Model for something interesting
* That's pretty much it :)

There's no support right now for going back and forth between a .value file and a CoreData .xcmodel file. In theory that shouldn't be too hard to create if there's demand for it.