Re: NSSearchField problem

[Michael de Haan]

Hi Jerry
> 
> If I remember correctly, the way the "search" happens for a recent search is 
> the same as the way the search happens for a typed-in-with-keyboard search, 
> which is that the search field sends its action.

Works perfectly.
Cannot believe I missed this.  I think it's called overthinking!Well, I 
guess it's a lesson that will not be forgotten. 
Thank you.
___

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

NSInputStream vs GCD's Dispatch Sources

[Todd Heberlein]

I’m building a new Cocoa client app that will asynchronously receive data over 
a TCP connection from a server. I was reviewing my options, and I am a little 
uncertain.

On one hand there is the NSStream option (e.g., NSInputStream). It looks a 
moderately awkward setting up an initial connection (not as nice as 
NSURLConnection), and then it seems I schedule it on a run loop (probably the 
main run loop?).

On the other hand is the GCD Dispatch Sources. This appears to be pretty low 
level (C APIs as opposed to Objective C objects), but I get the feeling this 
(leveraging GCD in general) is the future. Lots of the WWDC talks over the last 
few years seem to stress getting IO off the main thread.

Is this a good interpretation?

That is, if starting with a fresh Cocoa app (no legacy code), would you 
recommend GCD’s Dispatch Source approach?

Thanks,

Todd


___

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

Re: NSInputStream vs GCD's Dispatch Sources

[Marcelo Alves]

Check the CGDAsyncSocket project. 

--
:: marcelo.alves 


> On 13/10/2013, at 19:18, Todd Heberlein  wrote:
> 
> I’m building a new Cocoa client app that will asynchronously receive data 
> over a TCP connection from a server. I was reviewing my options, and I am a 
> little uncertain.
> 
> On one hand there is the NSStream option (e.g., NSInputStream). It looks a 
> moderately awkward setting up an initial connection (not as nice as 
> NSURLConnection), and then it seems I schedule it on a run loop (probably the 
> main run loop?).
> 
> On the other hand is the GCD Dispatch Sources. This appears to be pretty low 
> level (C APIs as opposed to Objective C objects), but I get the feeling this 
> (leveraging GCD in general) is the future. Lots of the WWDC talks over the 
> last few years seem to stress getting IO off the main thread.
> 
> Is this a good interpretation?
> 
> That is, if starting with a fresh Cocoa app (no legacy code), would you 
> recommend GCD’s Dispatch Source approach?
> 
> Thanks,
> 
> Todd
> 
> 
> ___
> 
> 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/marcelo.alves%40me.com
> 
> This email sent to marcelo.al...@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

Re: NSInputStream vs GCD's Dispatch Sources

[Jens Alfke]

On Oct 13, 2013, at 3:18 PM, Todd Heberlein  wrote:

> On one hand there is the NSStream option (e.g., NSInputStream). It looks a 
> moderately awkward setting up an initial connection (not as nice as 
> NSURLConnection), and then it seems I schedule it on a run loop (probably the 
> main run loop?).

You’re right, it is awkward to set up. In particular, to avoid using the 
deprecated NSHost class, you should create the streams by calling 
CFStreamCreatePairWithSocketToHost — this creates CFStreams, which are 
toll-free bridged to NSStreams.

You can schedule it on any runloop you want. Using the main runloop is 
convenient, and probably OK if your callbacks don’t take very long to run. 
Otherwise you can create a new NSThread and start it up on that.

> On the other hand is the GCD Dispatch Sources.

Here I agree with Marcelo that GCDAsyncSocket is the way to go. The only 
downside is that there’s more API to learn, and you’re adding a dependency on a 
3rd party (open source) library. But it’s a lot more modern and capable than 
the creaky NSStream stuff.

—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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

RE: collection of applications

[Rufat A. Abdullayev]

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  wrote:
> 
> 
>> On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev  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

Re: collection of applications

[Quincey Morris]

On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev"  wrote:

> Yes I'm planning to create a portal (enterprise in the meaning that all our 
> apps could be used/called from one app). 

I'm not sure how relevant this is, but it may be that creating a portal will 
get your app rejected. Look at the app store submission guidelines, section 2.8 
and (especially) 10.4.

___

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

Re: collection of applications

[Maxthon Chan]

App Store rules does not apply to in-house enterprise apps.

On Oct 14, 2013, at 12:13, Quincey Morris  
wrote:

> On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev"  wrote:
> 
>> Yes I'm planning to create a portal (enterprise in the meaning that all our 
>> apps could be used/called from one app). 
> 
> I'm not sure how relevant this is, but it may be that creating a portal will 
> get your app rejected. Look at the app store submission guidelines, section 
> 2.8 and (especially) 10.4.
> 
> ___
> 
> 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

Re: collection of applications

[Maxthon Chan]

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  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  wrote:
>> 
>> 
>>> On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev  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

RE: collection of applications

[Rufat A. Abdullayev]

Hi Quincey

Thank you for noticing that.


One say: "2.8

Apps that install or launch other executable code will be rejected

Your app, again, can't mess with the system and install other apps. Enterprise 
apps can however do that with a dedicated special Apple certificate.
"


And another: "10.4

Apps that create alternate desktop/home screen environments or simulate 
multi-app widget experiences will be rejected

This one came at the release of the iPad. Apple doesn't want the iPad to be 
like a desktop computer."

Regarding: 
http://appadvice.com/appnn/2010/09/apples-app-store-review-guidelines-annotated-explained

So only enterprise apps could install apps, right?




From: Quincey Morris [mailto:quinceymor...@rivergatesoftware.com]
Sent: Monday, October 14, 2013 8:14 AM
To: Rufat A. Abdullayev
Cc: Cocoa-dev
Subject: Re: collection of applications

On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev" 
mailto:rufa...@agbank.az>> wrote:


Yes I'm planning to create a portal (enterprise in the meaning that all our 
apps could be used/called from one app).

I'm not sure how relevant this is, but it may be that creating a portal will 
get your app rejected. Look at the app store submission guidelines, section 2.8 
and (especially) 10.4.

___

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

RE: collection of applications

[Rufat A. Abdullayev]

The problem is all our apps are with GUI
So probably I will not be able to use NSTask in that case



From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:23 AM
To: Rufat A. Abdullayev
Cc: Jens Alfke; Cocoa-dev
Subject: Re: collection of applications

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 
mailto: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 
mailto:j...@mooseyard.com>> wrote:



On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev 
mailto: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

Re: collection of applications

[Maxthon Chan]

You can use a model like this, with a SSO portal app and a bunch of apps that 
requires it:

When the portal itself is casually brought up, terminate itself. (method call 
-[UIApplication _terminate], it is private but since your apps are in-house you 
are not bind to the rules)
When an app that requires SSO is brought up, use a URL-based scheme to 
switchover to the portal for credentials, and switch back to proceed operations.

On Oct 14, 2013, at 12:26, Rufat A. Abdullayev  wrote:

> The problem is all our apps are with GUI
> So probably I will not be able to use NSTask in that case
>  
>  
>  
> From: Maxthon Chan [mailto:xcvi...@me.com] 
> Sent: Monday, October 14, 2013 8:23 AM
> To: Rufat A. Abdullayev
> Cc: Jens Alfke; Cocoa-dev
> Subject: Re: collection of applications
>  
> 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  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  wrote:
> 
> 
> 
> On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev  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

Re: collection of applications

[Maxthon Chan]

Rule 2.8 disallow you execute code that is foreign to your application bundle 
but use of auxiliary executables are still allowed, in the example of iSSH app.

On Oct 14, 2013, at 12:23, Rufat A. Abdullayev  wrote:

> Hi Quincey
> 
> Thank you for noticing that.
> 
> 
> One say: "2.8
> 
> Apps that install or launch other executable code will be rejected
> 
> Your app, again, can't mess with the system and install other apps. 
> Enterprise apps can however do that with a dedicated special Apple 
> certificate.
> "
> 
> 
> And another: "10.4
> 
> Apps that create alternate desktop/home screen environments or simulate 
> multi-app widget experiences will be rejected
> 
> This one came at the release of the iPad. Apple doesn't want the iPad to be 
> like a desktop computer."
> 
> Regarding: 
> http://appadvice.com/appnn/2010/09/apples-app-store-review-guidelines-annotated-explained
> 
> So only enterprise apps could install apps, right?
> 
> 
> 
> 
> From: Quincey Morris [mailto:quinceymor...@rivergatesoftware.com]
> Sent: Monday, October 14, 2013 8:14 AM
> To: Rufat A. Abdullayev
> Cc: Cocoa-dev
> Subject: Re: collection of applications
> 
> On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev" 
> mailto:rufa...@agbank.az>> wrote:
> 
> 
> Yes I'm planning to create a portal (enterprise in the meaning that all our 
> apps could be used/called from one app).
> 
> I'm not sure how relevant this is, but it may be that creating a portal will 
> get your app rejected. Look at the app store submission guidelines, section 
> 2.8 and (especially) 10.4.
> 
> ___
> 
> 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

RE: collection of applications

[Rufat A. Abdullayev]

Thanks Chan,

Our top management also would like all other apps that will be called by that 
main app to be hidden from springboard… i.e. no app icons are visible on the 
desktop.

I could only do it by converting other apps binaries to dynamic library and 
include that into main app bundle



From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:30 AM
To: Rufat A. Abdullayev
Cc: Jens Alfke; Cocoa-dev
Subject: Re: collection of applications

You can use a model like this, with a SSO portal app and a bunch of apps that 
requires it:

When the portal itself is casually brought up, terminate itself. (method call 
-[UIApplication _terminate], it is private but since your apps are in-house you 
are not bind to the rules)
When an app that requires SSO is brought up, use a URL-based scheme to 
switchover to the portal for credentials, and switch back to proceed operations.

On Oct 14, 2013, at 12:26, Rufat A. Abdullayev 
mailto:rufa...@agbank.az>> wrote:


The problem is all our apps are with GUI
So probably I will not be able to use NSTask in that case



From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:23 AM
To: Rufat A. Abdullayev
Cc: Jens Alfke; Cocoa-dev
Subject: Re: collection of applications

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 
mailto: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 
mailto:j...@mooseyard.com>> wrote:




On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev 
mailto: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

RE: collection of applications

[Rufat A. Abdullayev]

That's interesting!

How could I call "auxiliary executables" ?
Are they visible on springboard?

I need to dig more into that

From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:35 AM
To: Rufat A. Abdullayev
Cc: Quincey Morris; Cocoa-dev
Subject: Re: collection of applications

Rule 2.8 disallow you execute code that is foreign to your application bundle 
but use of auxiliary executables are still allowed, in the example of iSSH app.

On Oct 14, 2013, at 12:23, Rufat A. Abdullayev 
mailto:rufa...@agbank.az>> wrote:


Hi Quincey

Thank you for noticing that.


One say: "2.8

Apps that install or launch other executable code will be rejected

Your app, again, can't mess with the system and install other apps. Enterprise 
apps can however do that with a dedicated special Apple certificate.
"


And another: "10.4

Apps that create alternate desktop/home screen environments or simulate 
multi-app widget experiences will be rejected

This one came at the release of the iPad. Apple doesn't want the iPad to be 
like a desktop computer."

Regarding: 
http://appadvice.com/appnn/2010/09/apples-app-store-review-guidelines-annotated-explained

So only enterprise apps could install apps, right?




From: Quincey Morris [mailto:quinceymor...@rivergatesoftware.com]
Sent: Monday, October 14, 2013 8:14 AM
To: Rufat A. Abdullayev
Cc: Cocoa-dev
Subject: Re: collection of applications

On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev" 
mailto:rufa...@agbank.az>> wrote:


Yes I'm planning to create a portal (enterprise in the meaning that all our 
apps could be used/called from one app).

I'm not sure how relevant this is, but it may be that creating a portal will 
get your app rejected. Look at the app store submission guidelines, section 2.8 
and (especially) 10.4.

___

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

Re: collection of applications

[Maxthon Chan]

That is NOT visible on Springboard and they have to be command-line 
executables. So not much use actually.

On Oct 14, 2013, at 12:39, Rufat A. Abdullayev  wrote:

> That’s interesting!
>  
> How could I call “auxiliary executables” ?
> Are they visible on springboard?
>  
> I need to dig more into that
>  
> From: Maxthon Chan [mailto:xcvi...@me.com] 
> Sent: Monday, October 14, 2013 8:35 AM
> To: Rufat A. Abdullayev
> Cc: Quincey Morris; Cocoa-dev
> Subject: Re: collection of applications
>  
> Rule 2.8 disallow you execute code that is foreign to your application bundle 
> but use of auxiliary executables are still allowed, in the example of iSSH 
> app.
>  
> On Oct 14, 2013, at 12:23, Rufat A. Abdullayev  wrote:
> 
> 
> Hi Quincey
> 
> Thank you for noticing that.
> 
> 
> One say: "2.8
> 
> Apps that install or launch other executable code will be rejected
> 
> Your app, again, can't mess with the system and install other apps. 
> Enterprise apps can however do that with a dedicated special Apple 
> certificate.
> "
> 
> 
> And another: "10.4
> 
> Apps that create alternate desktop/home screen environments or simulate 
> multi-app widget experiences will be rejected
> 
> This one came at the release of the iPad. Apple doesn't want the iPad to be 
> like a desktop computer."
> 
> Regarding: 
> http://appadvice.com/appnn/2010/09/apples-app-store-review-guidelines-annotated-explained
> 
> So only enterprise apps could install apps, right?
> 
> 
> 
> 
> From: Quincey Morris [mailto:quinceymor...@rivergatesoftware.com]
> Sent: Monday, October 14, 2013 8:14 AM
> To: Rufat A. Abdullayev
> Cc: Cocoa-dev
> Subject: Re: collection of applications
> 
> On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev" 
> mailto:rufa...@agbank.az>> wrote:
> 
> 
> Yes I'm planning to create a portal (enterprise in the meaning that all our 
> apps could be used/called from one app).
> 
> I'm not sure how relevant this is, but it may be that creating a portal will 
> get your app rejected. Look at the app store submission guidelines, section 
> 2.8 and (especially) 10.4.
> 
> ___
> 
> 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

RE: collection of applications

[Rufat A. Abdullayev]

Yeah really! What a pity :(

So only URL scheme or included libraries



From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:41 AM
To: Rufat A. Abdullayev
Cc: Quincey Morris; Cocoa-dev
Subject: Re: collection of applications

That is NOT visible on Springboard and they have to be command-line 
executables. So not much use actually.

On Oct 14, 2013, at 12:39, Rufat A. Abdullayev 
mailto:rufa...@agbank.az>> wrote:


That's interesting!

How could I call "auxiliary executables" ?
Are they visible on springboard?

I need to dig more into that

From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:35 AM
To: Rufat A. Abdullayev
Cc: Quincey Morris; Cocoa-dev
Subject: Re: collection of applications

Rule 2.8 disallow you execute code that is foreign to your application bundle 
but use of auxiliary executables are still allowed, in the example of iSSH app.

On Oct 14, 2013, at 12:23, Rufat A. Abdullayev 
mailto:rufa...@agbank.az>> wrote:



Hi Quincey

Thank you for noticing that.


One say: "2.8

Apps that install or launch other executable code will be rejected

Your app, again, can't mess with the system and install other apps. Enterprise 
apps can however do that with a dedicated special Apple certificate.
"


And another: "10.4

Apps that create alternate desktop/home screen environments or simulate 
multi-app widget experiences will be rejected

This one came at the release of the iPad. Apple doesn't want the iPad to be 
like a desktop computer."

Regarding: 
http://appadvice.com/appnn/2010/09/apples-app-store-review-guidelines-annotated-explained

So only enterprise apps could install apps, right?




From: Quincey Morris [mailto:quinceymor...@rivergatesoftware.com]
Sent: Monday, October 14, 2013 8:14 AM
To: Rufat A. Abdullayev
Cc: Cocoa-dev
Subject: Re: collection of applications

On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev" 
mailto:rufa...@agbank.az>> wrote:


Yes I'm planning to create a portal (enterprise in the meaning that all our 
apps could be used/called from one app).

I'm not sure how relevant this is, but it may be that creating a portal will 
get your app rejected. Look at the app store submission guidelines, section 2.8 
and (especially) 10.4.

___

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

Re: collection of applications

[Maxthon Chan]

URL schemes or just bake in.

On Oct 14, 2013, at 12:45, Rufat A. Abdullayev  wrote:

> Yeah really! What a pity L
>  
> So only URL scheme or included libraries  
>  
>  
>  
> From: Maxthon Chan [mailto:xcvi...@me.com] 
> Sent: Monday, October 14, 2013 8:41 AM
> To: Rufat A. Abdullayev
> Cc: Quincey Morris; Cocoa-dev
> Subject: Re: collection of applications
>  
> That is NOT visible on Springboard and they have to be command-line 
> executables. So not much use actually.
>  
> On Oct 14, 2013, at 12:39, Rufat A. Abdullayev  wrote:
> 
> 
> That’s interesting!
>  
> How could I call “auxiliary executables” ?
> Are they visible on springboard?
>  
> I need to dig more into that
>  
> From: Maxthon Chan [mailto:xcvi...@me.com] 
> Sent: Monday, October 14, 2013 8:35 AM
> To: Rufat A. Abdullayev
> Cc: Quincey Morris; Cocoa-dev
> Subject: Re: collection of applications
>  
> Rule 2.8 disallow you execute code that is foreign to your application bundle 
> but use of auxiliary executables are still allowed, in the example of iSSH 
> app.
>  
> On Oct 14, 2013, at 12:23, Rufat A. Abdullayev  wrote:
> 
> 
> 
> Hi Quincey
> 
> Thank you for noticing that.
> 
> 
> One say: "2.8
> 
> Apps that install or launch other executable code will be rejected
> 
> Your app, again, can't mess with the system and install other apps. 
> Enterprise apps can however do that with a dedicated special Apple 
> certificate.
> "
> 
> 
> And another: "10.4
> 
> Apps that create alternate desktop/home screen environments or simulate 
> multi-app widget experiences will be rejected
> 
> This one came at the release of the iPad. Apple doesn't want the iPad to be 
> like a desktop computer."
> 
> Regarding: 
> http://appadvice.com/appnn/2010/09/apples-app-store-review-guidelines-annotated-explained
> 
> So only enterprise apps could install apps, right?
> 
> 
> 
> 
> From: Quincey Morris [mailto:quinceymor...@rivergatesoftware.com]
> Sent: Monday, October 14, 2013 8:14 AM
> To: Rufat A. Abdullayev
> Cc: Cocoa-dev
> Subject: Re: collection of applications
> 
> On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev" 
> mailto:rufa...@agbank.az>> wrote:
> 
> 
> Yes I'm planning to create a portal (enterprise in the meaning that all our 
> apps could be used/called from one app).
> 
> I'm not sure how relevant this is, but it may be that creating a portal will 
> get your app rejected. Look at the app store submission guidelines, section 
> 2.8 and (especially) 10.4.
> 
> ___
> 
> 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

Re: collection of applications

[Maxthon Chan]

Maybe you have to tell your management that it is technically infeasible to do 
so in iOS without jailbreaking. Either you bake them all in/use separate 
SpringBoard icons or the dynamic libraries will not be loaded in vanilla iOS 
device without black magic.

On Oct 14, 2013, at 12:37, Rufat A. Abdullayev  wrote:

> Thanks Chan,
>  
> Our top management also would like all other apps that will be called by that 
> main app to be hidden from springboard… i.e. no app icons are visible on the 
> desktop.
>  
> I could only do it by converting other apps binaries to dynamic library and 
> include that into main app bundle
>  
>  
>  
> From: Maxthon Chan [mailto:xcvi...@me.com] 
> Sent: Monday, October 14, 2013 8:30 AM
> To: Rufat A. Abdullayev
> Cc: Jens Alfke; Cocoa-dev
> Subject: Re: collection of applications
>  
> You can use a model like this, with a SSO portal app and a bunch of apps that 
> requires it:
>  
> When the portal itself is casually brought up, terminate itself. (method call 
> -[UIApplication _terminate], it is private but since your apps are in-house 
> you are not bind to the rules)
> When an app that requires SSO is brought up, use a URL-based scheme to 
> switchover to the portal for credentials, and switch back to proceed 
> operations.
>  
> On Oct 14, 2013, at 12:26, Rufat A. Abdullayev  wrote:
> 
> 
> The problem is all our apps are with GUI
> So probably I will not be able to use NSTask in that case
>  
>  
>  
> From: Maxthon Chan [mailto:xcvi...@me.com] 
> Sent: Monday, October 14, 2013 8:23 AM
> To: Rufat A. Abdullayev
> Cc: Jens Alfke; Cocoa-dev
> Subject: Re: collection of applications
>  
> 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  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  wrote:
> 
> 
> 
> 
> On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev  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.

RE: collection of applications

[Rufat A. Abdullayev]

Thank you a lot, guys!

I highly appreciate your help!

Cheers,
Ruf

From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:46 AM
To: Rufat A. Abdullayev
Cc: Quincey Morris; Cocoa-dev
Subject: Re: collection of applications

URL schemes or just bake in.

On Oct 14, 2013, at 12:45, Rufat A. Abdullayev 
mailto:rufa...@agbank.az>> wrote:


Yeah really! What a pity :(

So only URL scheme or included libraries



From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:41 AM
To: Rufat A. Abdullayev
Cc: Quincey Morris; Cocoa-dev
Subject: Re: collection of applications

That is NOT visible on Springboard and they have to be command-line 
executables. So not much use actually.

On Oct 14, 2013, at 12:39, Rufat A. Abdullayev 
mailto:rufa...@agbank.az>> wrote:



That's interesting!

How could I call "auxiliary executables" ?
Are they visible on springboard?

I need to dig more into that

From: Maxthon Chan [mailto:xcvi...@me.com]
Sent: Monday, October 14, 2013 8:35 AM
To: Rufat A. Abdullayev
Cc: Quincey Morris; Cocoa-dev
Subject: Re: collection of applications

Rule 2.8 disallow you execute code that is foreign to your application bundle 
but use of auxiliary executables are still allowed, in the example of iSSH app.

On Oct 14, 2013, at 12:23, Rufat A. Abdullayev 
mailto:rufa...@agbank.az>> wrote:




Hi Quincey

Thank you for noticing that.


One say: "2.8

Apps that install or launch other executable code will be rejected

Your app, again, can't mess with the system and install other apps. Enterprise 
apps can however do that with a dedicated special Apple certificate.
"


And another: "10.4

Apps that create alternate desktop/home screen environments or simulate 
multi-app widget experiences will be rejected

This one came at the release of the iPad. Apple doesn't want the iPad to be 
like a desktop computer."

Regarding: 
http://appadvice.com/appnn/2010/09/apples-app-store-review-guidelines-annotated-explained

So only enterprise apps could install apps, right?




From: Quincey Morris [mailto:quinceymor...@rivergatesoftware.com]
Sent: Monday, October 14, 2013 8:14 AM
To: Rufat A. Abdullayev
Cc: Cocoa-dev
Subject: Re: collection of applications

On Oct 13, 2013, at 21:06 , "Rufat A. Abdullayev" 
mailto:rufa...@agbank.az>> wrote:


Yes I'm planning to create a portal (enterprise in the meaning that all our 
apps could be used/called from one app).

I'm not sure how relevant this is, but it may be that creating a portal will 
get your app rejected. Look at the app store submission guidelines, section 2.8 
and (especially) 10.4.

___

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