I'm not OP, but one key complaint I have is that there isn't much in the way of testing. Unit tests are somewhat well-developed, integration testing is a complete mess.
Much of the iOS community still creates software by the seat-of-your-pants model (i.e., write code, boot it up, does it look like it works? ship it). Engineering rigor is still a concept relatively foreign to iOS, and it shows. Apple has little-to-no built in support for anything that smells like TDD.
When you're talking to your server-side peers who have good test coverage, good regression testing, and more generally just sound engineering processes, you can't help but get bit jealous.
I was a test zealot all my academic life (it's perfect for building compilers). But in my experience as an iOS contractor, most apps are polished Thin Clients for a remote backend. Which incidentally is the only thing that Objective C is really awesome for. As soon as I write any interesting logic, it is actually a bug, because it should be pushed into the backend. After all, it must behave the same on Android and on the web client.
That leaves us with bug classes like: multithreaded Core Data misuse, "UI can be broken by using three fingers exactly like this", popping a navigation controller as a reaction to a network operation while it is currently being pushed (based on network latency), networking code that does not properly handle session extensions while multiple concurrent threads are in progress, labels use the wrong font, code uses UIKit on the main thread, ...
Good luck writing tests for that and being more cost-effective than code reviews & manual testing.
I feel like this has less to do with iOS and more with the challenges of testing client-side code vs server-side code. Even Android projects are quite tricky to test despite Java having a strong heritage when it comes to unit testing.
Part of it just comes down to the way the GUI framework (whether it's Cocoa or Android) cuts across all aspects of the application, making it difficult to isolate individual components to test. Add to that a bunch of asynchronous code (which is almost always necessary when you start dealing with the database/network/filesystem) and you have something quite tricky to automate testing for.
Most of the server-side code I've dealt with has been an order of magnitude easier to test, but I think a lot of that comes down to the nature of their respective domains.
Actually this is still the reality in most corporations out there.
I seldom see TDD, unit testing, continous integration and so on outside the startup world.
Most of the projects I do in the enterprise start agile and slowly evolve to a mix of agile and waterfall. When stress for delivery raises, many entrerprise project managers just kill unit testing related tasks.
Much of the iOS community still creates software by the seat-of-your-pants model (i.e., write code, boot it up, does it look like it works? ship it). Engineering rigor is still a concept relatively foreign to iOS, and it shows. Apple has little-to-no built in support for anything that smells like TDD.
When you're talking to your server-side peers who have good test coverage, good regression testing, and more generally just sound engineering processes, you can't help but get bit jealous.