Seem to me that you are considering making an enterprise single sign-on portal. Of course you can combine everything into a single app, but a more graceful solution can exist.
Just to correct a misunderstanding, iOS dyld can load dynamic libraries if carried as part of the application bundle (and there is a hack that allows on-the-fly patching of the in-memory libdyld to load libraries downloaded from any arbitrary address, but that involves lots of black magic and Apple can reject it if found out.) Also external binaries can be used - there is an App Store app called iSSH that carried its own signed version of PuTTY cross compiled for iOS. As mentioned, you can launch other apps by URL schemes. This is also a method of inter-app communication as you can encode data into the URL string. You can design a family of apps that requires a SSO and a SSO portal. When a client app is launched directly it redirects the user to the SSO portal, telling the portal who called it. The portal then redirects the user back to the app with whatever information needed for the session to continue after authentication. It seem to me that Facebook used this scheme in the wild (that is, Facebook app is the SSO portal and apps using Facebook SDK is signing on using Facebook app itself.) Sent from my iPad > On 2013年10月11日, at 12:31, Jens Alfke <j...@mooseyard.com> wrote: > > >> On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev <rufa...@agbank.az> wrote: >> >> I also saw another approach they give a link to app store from application >> and downloaded other app from App Store separately but managed them from >> another app like a service ... It’s a pity that I could not get more details >> on implementation! > > Do you mean just launching another app programmatically? You can definitely > do that; the typical way involves having the app register a custom URL > scheme. But the other apps are just regular apps, not services or anything > hidden. > > ―Jens > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com > > This email sent to xcvi...@me.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
