|
90 days for Ad Hoc distribution, 365 days (the duration of the subscription) for Enterprise distribution. This confusion of yours lead me to suspect you might confuse the 2 schemes altogether.
Regarding date and time being changed by the user, you really can't deal with that correctly in all cases. To begin with, the setting defaults to date and time being set automatically. If the user chooses to dive into that setting, disable it, and then
screw the device date/time, then s/he is on her own. S/he could also dip the device in hot lava while s/he is at it. Further, s/he could also set the date/time to *earlier* than any App Profile validity and see all her apps break. Or not. I don't know for
sure, because this is silly.
JD
wrote:
Is it? but i think its for 90 days. and there is another problem, if user change the date and time of the device exceed to the provisioning profile expiry date. then he/she will not be able to use the app.
Any way i have been fade up by telling them, but they do not understand. So i just make a binary and hand over to them. let them deal with that. :)
On Mon, Sep 24, 2012 at 3:09 PM, Jean-Denis MUYS
<email@hidden> wrote:
Not every 90 days. Every 365 days.
It seems the best way out is still for your TL (Team Leader?) to go back to your client, and tell him, that thanks to his hard work, he found an even better way. Now the client will not even have to go through Apple for validation any more, saving a lot
of time (and therefore money), headache (and therefore money), especially when updating the application. This better is called by Apple "Enterprise Distribution", and it fits your client scenario even better than the previously discussed B2B scenario.
Regards,
Jean-Denis
wrote:
Thats correct Mr. Diederik Meijer.
We have to update the provisioning profile every 90 days and put it on our portal.
Yeah, i have discussed with the client actually i am just developer (but i know how app store works) but my TL had communication with him and he said to the client that he will upload to app store without knowing that Apple will never review such kind
of app which is not usable for public. But as he already made that promise with the client and he is now forcing me to just make the build/binary and upload to the app store for sake. I know that is totally waste of time. :(
On Mon, Sep 24, 2012 at 1:46 AM, Diederik Meijer | Ten Horses
<email@hidden> wrote:
Jean-Denis,
In my experience, the Enterprise Developer provisioning profiles expire after one year. It takes renewing the licence and rebuilding with a new profile to continue running the apps once the first year has lapsed. So there is a 90 days, but it's 365...
I would also advice iPhone Lover - in this case - to schedule a meeting with the client to thoroughly discuss distribution options and their respective requirements. It is never wise to proceed a confusing path based on misunderstandings..
IMHO…
diederik
On Sep 24, 2012, at 10:13 AM, Jean-Denis MUYS < email@hidden> wrote:
Wow, reading between the lines here, I am afraid you might not have understood what the enterprise distribution method is.
Enterprise distribution is a scheme whereby a company (your client) distributes an app to their employees **outside** the App store. It is different from the B2B program which still goes through the App Store. It is similar to, but different from, the
Ad Hoc distribution scheme that you mention: both allow for app distribution of Apps outside the App Store, and with no Apple approval required. Both allow for installation using iTunes, the iPhone configuration utility, or over the air (e.g. TestFlightApp).
They differ in that Apps distributed with the enterprise scheme have two desirable features:
- they can be installed on any device, without UDID registration ahead of time
- they have no 90 days expiration time. In fact they don't expire at all.
So why don't all developers use that scheme instead of the Ad Hoc scheme? Because the Enterprise Distribution scheme is not available in the regular developer program. You need to subscribe to the Enterprise Developer program for that, which cost a bit
more ($300 a year IIRC), and also does *not* allow distributing Apps through the App Store at all.
I wanted to point that out as I am that was underlying in several answers but not totally explicit. In your case, it really sounds like your client should subscribe to the Enterprise program. Thereafter, there is no headache associated with distribution,
at least no 90 days issue.
Cheers,
Jean-Denis
wrote:
Thanks Jonathan,
Well i proposed them to go with custom B2B, and thanks for explain me in detail about the B2B app store. But i do not know how In-house app store works ? Its kind of build up our internal server and let the internal employee to download the app? if it
is so then do we need to update the profile(as it expires after every 90 days), and its too hectic.
On Mon, Sep 24, 2012 at 2:24 AM, Jonathan Prescott
<email@hidden> wrote:
Would it not be simpler to either use the custom B2B developer option, or have your client purchase an in-house enterprise app development license (as the web site states, enterprises can hire others to develop an app as long
as everyone agrees on the ownership certificates). The custom B2B app sounds like it might fill your bill (you go through pretty much the same development and review process; when you go through the submittal process, you set up certain switches to limit
to specified Volume purchases, your client gets a Volume purchase agreement with Apple, and, depending on your whims when you submit the app, they are the only company that can download the application). I think you may run into problems with your approach.
When you withdraw the program from the App Store, existing downloads may work, but, new downloads won't be possible, and you won't be able to put existing copies on new phones for new owners because certificates won't jibe.
On Sep 23, 2012, at 4:39 PM, IPhone Lover wrote:
Thanks Jim,
I have submitted 4 to 5 apps to App Store without any problem. But this is the first enterprise app which i am going to submit to the app store for review(and i know we do not actually need to get the review, but my client is insane) and trying to pretend
that we will put on app store.
And i am 100% sure, that apple will reject the app, if we are asking to the user for login credential to get into the depth of the app.
On Mon, Sep 24, 2012 at 2:02 AM, Jim Geist
<email@hidden> wrote:
It's your app, and your (and your client's) risk to evaluate. I'm just pointing out something that you might want to consider, not trying to tell you what to do.
On Sep 23, 2012, at 1:29 PM, IPhone Lover wrote:
On Mon, Sep 24, 2012 at 1:53 AM, Jim Geist
<email@hidden> wrote:
The point of review in Apple's process is to ensure the app is appropriate for publication on the app store.
Yeah, that is why we are just pretending that we are going to publish it on app store. and we are providing them the login credential to get into the app.
Once they approve it, the only thing that stands between it and the app store is you or anyone else with access to the account not making any mistakes and accidentally releasing it in ITC.
Yeah and once they approve, we will reject the binary from our end.
I'm not saying it *will* happen, I'm saying from the perspective of security defense in depth, it's a potential risk.
Well, our data is not that much confidential. it just for internal employee.
On Sep 23, 2012, at 1:19 PM, IPhone Lover wrote:
How? We are putting up for review to just get the approval from Apple that we are making the best app. and i don't think Apple will reveal any confidential data to others.
On Mon, Sep 24, 2012 at 1:44 AM, Jim Geist
<email@hidden> wrote:
It's worse than pointless. If the app is an enterprise app which is a portal to confidential data, then putting it up for review opens the possibility that it will become available to the general public, which is a non-trivial security risk.
On Sep 23, 2012, at 1:05 PM, Seth Willits wrote:
> On Sep 23, 2012, at 12:27 PM, IPhone Lover wrote:
>> • Will apple will accept such kind of app for review which is not useful for public …
> If the application is not useful the public, it will be rejected. It is absolutely pointless to submit it for review.
>
> --Seth Willits
>
>
>
> _______________________________________________Do not post admin requests to the list. They will be ignored.Xcode-users mailing list (email@hidden)Help/Unsubscribe/Update
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list ( email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list ( email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list ( email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|