"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
As far as I know, a lot of iPhone apps are shipped with App key and secret key. (For example, an open source project for sharing requires you to put your app's secret key: http://getsharekit.com/)
Regardless, if you read the documentation that I keep referring (and even linking to), it has a very clear (if arguably stupid seeming) mechanism for desktop applications to operate: you use the OAuth 2.0 flow, but have the landing page be a specially designated page on Facebook's server. Then, as you are running in an insecure web browser (as you are inside of a desktop app), the desktop app can notice that URL being hit and steal the session token, and at no point did this require a secret key.
Now, if you have a session token, and for some reason you need a secret key for the API you are working with, as you cannot use your secret key (as that would involve disclosing it, which Facebook is very clear you should not ever do), you need to obtain a "temporary session secret key", which you can do by "promoting" your session token, using the client API flow that Facebook tells you to use at this point.
Documentation for the way I happen to know of for promoting a session token is at the following link. (Whether there is a newer way to do this that does not involve activating "legacy APIs" for your application, I do not know.) https://developers.facebook.com/docs/reference/rest/auth.pro...
With the process you described, it would be really easy for apps to simply use another app's id. So, it seems that Facebook has implemented additional measures to prevent this. (e.g. using bundle ID and iTunes app store ID for iPhone apps)
Also, Facebook published iOS SDK that required secret key, but has since updated it to remove that requirement.