NSTask. Also you can use traditional UNIX fork/exec to execute the secondary binary. However the secondary must be a command-line binary not an application bundle.
On Oct 14, 2013, at 12:06, Rufat A. Abdullayev <rufa...@agbank.az> wrote: > Hello Chan and other guys, > > Thank you a lot for your answers. > > Yes I'm planning to create a portal (enterprise in the meaning that all our > apps could be used/called from one app). > > Chan, > your reply was interesting especially regarding - "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." > > How they could call external binaries? I assume binaries are not visible on > springboard (no any external app icons exists) > > > Thanks, > Ruf > > > > -----Original Message----- > From: ChanMaxthon [mailto:xcvi...@me.com] > Sent: Friday, October 11, 2013 10:41 PM > To: Jens Alfke > Cc: Rufat A. Abdullayev; Cocoa-dev > Subject: Re: collection of applications > > 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
