You can use XCode to create AppleScript Studio applications where your code is mostly in AppleScript, and you can access Obj-C code from within that script if you are willing to work at it (I did so a long time ago, but don't remember the details). Your GUI is constructed in InterfaceBuilder, almost exactly like a Obj-C project (but you don't bind it the same way).
And then there is the relatively new method of putting an AppleScript interpreter inside Obj-C, but that is more useful for interfacing with other programs through their AppleEvents handles (what AppleScript uses).
And then there are the other scripting bridges such as the ones for Python and Ruby. There you can use modules in those languages to more directly substitute for Obj-C, so long as you use the appropriate XCode template (it has some Obj-C code to set things in motion). You make and bind your GUI in the exact same way as for Obj-C (especially if you use bindings), and you can mix-and-match Obj-C and the template language very easily (although you can't use more than one language + Obj-C).
The AppleScript bridge is not quite as good as the Ruby and Python bridges. It is a bit older, but there was some talk out of Apple engineers at WWDC a year ago about that bridge being brought in line with the others, but I did not make it to this years conference to hear the latest status on that.