I think a big problem in standard iOS land is not doing shit on the main thread. It's too easy and after a while you accumulate small bits of main thread cruft, especially as your team / code size grows bigger.
It's a similar problem that AsyncDisplayKit was trying to solve, who's ideas later moved into the react world in general.
Another general design problem in iOS land is the MVC (massive view controller). View controllers tend to get huge as time goes on and become large 5000 line god objects that do everything. A general structure that encourages you to separate things out helps in avoiding this.
There is also a general trend of dependency management being singleton sharedInstance objects everywhere, which can make unit testing a pain. Especially in swift land today with it's lack of dyanmic mocking with OCMock.
Also I notice a general lack of unit / integration testing in mobile apps.
Another one is autolayout being a layout system that crashes your app. It doesn't let you recover in a more elegant way.
---
Now it's totally possible to avoid these caveats with skill, but the architecture of things in iOS land tends to land you into these problems naturally as your team and code size grows bigger. I don't know if react's architecture solves some of this, but those are general problems with standard iOS conventions I've noticed over 7 years with iOS dev.
I mostly agree (though I think massive view controllers are a code quality/poor developer discipline issue).
I've seen nothing in React's (or Katana's) architecture that avoids doing things on the main thread when you shouldn't. I'd also argue that GCD offers a nice, elegant approach to not doing things on the main thread when you shouldn't.
But I'd say that MVC-discipline and thread-discipline are baseline skills that I'd expect from competent iOS devs.
RE: dependency management/unit testing, that's an area I agree needs improvement in general for iOS (though I do not see anything in Katana that significantly helps with that). Swinject (as one example) is alright. I'm not hugely impressed.
(though I think massive view controllers are a code quality/poor developer discipline issue)
After almost 4 decades, I'd like to think that the "programming field" would finally get the clue and realize that "massive view controllers" are the result of powerful short term incentives. (MVC was popularized by Smalltalk, and "massive view controller" was a problem even then.)
Remember, if you are a genius being outsmarted by laziness, something is seriously wrong -- the other side is putting in so much less effort!
It's a similar problem that AsyncDisplayKit was trying to solve, who's ideas later moved into the react world in general.
Another general design problem in iOS land is the MVC (massive view controller). View controllers tend to get huge as time goes on and become large 5000 line god objects that do everything. A general structure that encourages you to separate things out helps in avoiding this.
There is also a general trend of dependency management being singleton sharedInstance objects everywhere, which can make unit testing a pain. Especially in swift land today with it's lack of dyanmic mocking with OCMock.
Also I notice a general lack of unit / integration testing in mobile apps.
Another one is autolayout being a layout system that crashes your app. It doesn't let you recover in a more elegant way.
---
Now it's totally possible to avoid these caveats with skill, but the architecture of things in iOS land tends to land you into these problems naturally as your team and code size grows bigger. I don't know if react's architecture solves some of this, but those are general problems with standard iOS conventions I've noticed over 7 years with iOS dev.