What you're describing is basically a session hijacking attack, using a session ID from one app (SF1) to create a session in another app. I am doubtful whether this is technically possible — even if you did get the session ID from SF1, it is likely tied to SF1's OAuth client ID. And if it is possible, it is a surefire way to bait Salesforce security into globally revoking the OAuth client ID for your partner app, and then you're in a really bad spot.
Moreover, you said:
I'm looking to not require the user to log in to SF from inside the iOS app as I know about them already from inside the SF1 app.
Respectfully, this is not your call to make. You cannot assume that a user who has granted access to one app (SF1) would want her credentials used, without her knowledge or consent, to authenticate another app. Even if the second app were a first-party Salesforce app, and even if you had the user's consent, you can imagine the security and access control implications of additional apps hijacking credentials in this manner.
The instance/partner server URL, however, is definitely fine to share with a partner app, and it'd surely be a big improvement to the partner app experience if your user no longer needs to type in their server URL.