In my opinion, your rule is a good one (or at least it's not a bad one), but only because of the situation you are describing. I wouldn't say that I agree with it in all situations, so, from the standpoint of my inner pedant, I'd have to say your rule is technically too broad.
Typically you wouldn't define immutable objects unless they are essentially being used as data transfer objects (DTO), which means that they contain data properties but very little logic and no dependencies. If that is the case, as it seems it is here, I'd say you are safe to use the concrete types directly rather than interfaces.
I'm sure there will be some unit-testing purists who will disagree, but in my opinion, DTO classes can be safely excluded from unit-testing and dependency-injection requirements. There is no need to use a factory to create a DTO, since it has no dependencies. If everything creates the DTOs directly as needed, then there's really no way to inject a different type anyway, so there's no need for an interface. And since they contain no logic, there's nothing to unit-test. Even if they do contain some logic, as long as they have no dependencies, then it should be trivial to unit-test the logic, if necessary.
As such, I think that making a rule that all DTO classes shall not implement an interface, while potentially unnecessary, is not going to hurt your software design. Since you have this requirement that the data needs to be immutable, and you cannot enforce that via an interface, then I would say it's totally legitimate to establish that rule as a coding standard.
The larger issue, though, is the need to strictly enforce a clean DTO layer. As long as your interface-less immutable classes only exist in the DTO layer, and your DTO layer remains free of logic and dependencies, then you will be safe. If you start mixing your layers, though, and you have interface-less classes that double as business layer classes, then I think you will start to run into much trouble.
Best Answer
Don't worry about it. If you know enough C to be able to write function calls, understand and write arithmetic expressions, and deal with pointers, you'll probably be fine. You'll still need to learn Objective-C, of course, but much of the code that you'll write will be more Objective-C than plain old C. Getting used to Objective-C style and learning Cocoa Touch will consume much more of your time than brushing up on C.
I usually tell people who are starting from zero to learn C before jumping into Objective-C. I stand by that advice -- learning C will teach you basic knowledge that you need in order to work effectively in Objective-C. You need to know what a function is, how to use control structures like loops and conditional statements, how the various basic data types work, what a struct is and so on. And since all of C is fair game in Objective-C, the more C you know the better you'll be prepared to understand code you might run across. That said, many tasks are done differently in Objective-C, so standard C idioms aren't necessarily standard Objective-C idioms. NSString and NSArray take the place of C-style arrays. Pointers are ubiquitous, but they're used mainly to refer to objects -- pointer arithmetic doesn't come up very often. Instead of allocating memory directly, you create objects.
The same goes for C++... you won't need much C++ to get along fine in Objective-C. At some point in the future you might need to increase your C++ knowledge in order to integrate some existing C++ code into an app, and at that point you might need to spend some time learning, but don't let a lack of C++ knowledge stop you from trying your hand at iOS programming.