SOLID principles don't necessarily apply in any context, regardless of technology or programming language. Many developers choose to abide by them though, and it's certainly possible to do in Objective-C.
If you're interested in seeing test-first Objective-C, then take a look at BrowseOverflow: it's a completely test-driven app that makes use of UIKit and network services. I actually wrote it as the sample code for Test-Driven iOS Development, but if you're comfortable with the principles you can just look at the code. You can see there that even though the code was test-driven, it isn't brimming with protocols.
One reason for that is "duck typing". Objective-C, like Smalltalk before it and Ruby after it, doesn't actually care what type an object is, it just sends messages. The type safety system is entirely restricted to the compiler checking. You can therefore type a variable as specifically as you want and still (sometimes with some casting) supply a different type at runtime. As long as both types respond to the messages passed in your code, everything works. You can see that the tests in BrowseOverflow use this to pass in test fakes, even for variables that aren't typed using protocols.
In fact in historical Objective-C and Smalltalk (and in modern Ruby) many collaborating objects aren't typed at all: in Objective-C the
id type means "any object". That's less common now in ObjC, but a lot of Apple's framework code is old enough to have been around when this was the norm. You'll notice that newer frameworks, and newer API on existing frameworks, uses stricter typing and protocol types for non-delegate collaborators.
Is there a reason why an ObjC developer would only use protocols for delegates?
Personal choice. There's no underlying technical reason to follow that approach.
Does SOLID programming apply for ObjC?
Yes. Or rather, it can do, and many developers choose to follow SOLID principles.