b)There really isn't a clean way to talk between applications. You can send files, but it's really a drop box, I can COPY(not link!) something into another apps area, but after that the file is no longer mine. So if I want to send something to another app to process and then get it back to do some processing by my application I have to hope the app tells me about the changes, and considering the app may not even know I exist(nor should it, thats the beauty of decoupling), thats a lot to ask.
Indeed, there's not a great way to share data between apps on iOS; the 'file sharing' in iOS 3.2/4 seems pretty dreadful and awkward to use. You can push some data around via URLs, but I've not been able to find a system for discovering URL handlers, or having a way to declare support for particular types of data instead of manually listing some application-specific URL schemes.
Android's system for "Intents" is a bit nicer; you can combine some typed or structured data (say text/plain) and an action ('send') and just shove that off to whatever apps will take it. That's how the 'share' buttons in Gallery, Twitter, etc are implemented, and how you launch email dialogs, etc. Much more flexible, though still tends to be UI-driven rather than behind the scenes.
I can *sort* of understand 1 from a performance standpoint, if you allow user created dynamic libraries every time the application is swapped out of memory you have to find which dynamic libraries it uses, make sure nobody else is using them, then unload them. However as memory increases the rationale behind needing to constantly load/unload them starts to disappear.....
Dynamic libraries don't really work that way; when your program is loaded, the linker pops over to your libraries and pokes a few bits in memory that make the function & data references work correctly. The untouched parts of the library can be shared between processes because the executable code is memory-mapped from the file into address space directly; the kernel's memory manager deals with knowing what's using it, so at the system level there's no special need to go looking for what process is using what library.
There can be performance issues with dynamic libraries because the dynamic linker has to, well, link more things when your program is loaded. :) But the biggest issue here is probably simply that of filesystem management. The preferred application model on Apple's systems (both Mac OS X and iOS) is for most individual apps to be self-contained: any libraries that aren't bundled with the system should be bundled into your application, so they don't have to be separately installed or uninstalled.
On iOS you're even more restricted because user-installable apps are kinda funkily sandboxed from each other, and the app distribution/installation infrastructure is totally geared towards individual, standalone app bundles. If you've got no place to put shared libraries that will share them, there's not much point to using dynamic linking (unless you're going so far as to manually load/unload the libraries and link symbols yourself to keep from having to load them, which is probably not very beneficial these days; it might be better to just link statically and avoid fixups. :)