Can you clarify this? What is the kind of apps where a "type system would really shine"? How can you avoid writing them?
I don't think that's really what Obj-C was designed for.
eg. For some reason your app has the ability to use Postgres instead of SQLite, even though you always use SQLite.
eg. For some reason your app supports Postgres/MYSQL/SQL Server because every enterprise you sell to wants to run their preferred database instead of the one that works best with your product.
In short 'enterprise' apps.
Are you saying the main application of type systems is writing overengineered enterprise apps? Do you think type systems have no place in well-architected and/or minimalist apps?
Can you elaborate more?
Eg.rewriting base classes to use IWritableStream instead of looking up the write method and calling it.
The type system of swift is much closer to java than to that of haskell. (Or whatever language you think has a 'great' type system)
For example in F# if you just use one method the type system will infer that you need an object that has that method. (especially if that method is an operator)
eg. let add a b = a + b will work on any pair of objects that have the + operator defined. That is a good and useful type system, what swift has just makes you type more for little benefit.
eg. making types is easy, reflecting methods is hard. (it should be noted that swift effectively doesn't support reflection)
I'm not sure what reflection has to do with this. I'm sure you're aware there are "great type systems" which do not use reflection.
It's hard to realize most of the performance benefits when everything you're interacting with requires objc_msgsend or uses NSArray / NSDictionary.
As well, it's far less 'scripty' than Obj-c. The type system in swift really leaves something to be desired in terms of typing types. The point of Obj-C was kind of to avoid writing the kinds of apps where a great type system would really shine, swift lets you build those kind of apps, but in my opinion most of the time we shouldn't be building them.
Your project probably doesn't need 1,000 developers on it who need solid interfaces and type checking to make sure that everything is going according to the UML diagram. It probably needs 2 or 3 developers who talk to each other, add asserts to their code, and a type system thats a little forgiving.
ObjC is a language that has everything you really really need, and left out the 1 thing you kinda wanted in exchange for leaving out the thousand 1 little things that everyone else wanted too. Like for example exceptions, sure they're there, but it's not idiomatic and when you program without them you realize what a crappy idea they were in practice. In day to day coding NSError is 1000x better than exceptions.