I would do a mixed approach. Get your client to join at $99 per year, and to
have you as a team member. They would include at least one of your devices in
their list, so you can test installs, and you would be able to build for up to
100 devices. If they only need about 10, that would cover
I've used Ad Hoc Distribution for this a few times before - it can become a
bit of a pain because employees join and people get new devices - you have
to manage updates to the provisioning profile manually - more often than
you'd think.
A better option is if you can get the client to join
That's what I tried to make clear. It would be a violation of the
license conditions, but I don't know if Apple would ever find out.
Personally, I would recommend the customer to pay a little extra.
However, they may be other options.
--
Best regards,
Mark Schonewille
Economy-x-Talk
In all the time I’ve had a personal iPhone developer account I haven’t
submitted an app under my own account. All the apps I’ve done have been under
other accounts. But I have used, and updated, my list of 100 devices quite a
bit. Apple have never complained.
On Mar 18, 2015, at 9:19 AM,
Am 18.03.2015 um 12:16 schrieb Colin Holgate colinholg...@gmail.com:
I would do a mixed approach. Get your client to join at $99 per year, and to
have you as a team member. They would include at least one of your devices in
their list, so you can test installs, and you would be able to
Hi,
Ad hoc distribution is only for beta testing. Using it for deployment
would violate Apple's license conditions. It might be ok to do this,
unless Apple decides to review your account and discovers that you're
updating the list of devices every year without releasing new beta
versions or
I take this the other way: I want more control, not less. I take it
personally when something I build isn't freaking awesome. I consider other
enterprises' employees to be part of my team when I write something for
them. I am their IT guy, so the last thing I want to do is take a chance
on
I have some points to consider here having done it both ways a few
times:
1) I'd definitely have them give you sufficient permissions to manage
the certificates, keys and profiles yourself in their account. You still
do everything apart from sign-up, pay and sign (click through) contracts
with
The reason for explicitly provisioning (and therefore multiple developer
ID's), and banning a device is that you get an extra layer of protection
for your corporate clients from having just anyone with their random device
get access to the corporate app. That also means when someone leaves you
://runtime-revolution.278305.n4.nabble.com/semi-OT-Distributing-apps-for-iOs-outside-iTunes-tp4690319p4690344.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit
Glad it helped!
Simon
Ralph DiMola wrote
Simon,
You the Man! Worked first... well second time. I needed to add the mime
types in IIS. Sweet.
Ralph DiMola
IT Director
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/semi-OT-Distributing-apps-for-iOs
Sent: Wednesday, March 18, 2015 7:03 PM
To: use-revolut...@lists.runrev.com
Subject: Re: [semi-OT] Distributing apps for iOs outside iTunes
Here is my write up for distribution
http://forums.livecode.com/viewtopic.php?f=49t=22832
I get reports from the iOS device so I know when to take the link
I've used ad-hoc provisioning as a free and simple per device licensing
mechanism before but it doesn't offer any protection. Devices get lost and
stolen and you can't remote kill the app via the provisioning mechanism.
Anything with a real data security requirement has to have a user
Hi list
One of my clients needs an app for his employees that will run
on their iphones or itabs. Those employees are very few (less than
10) and no one else will be interested in the app because it's
related to a very specific activity, therefore using iTunes doesn't
seem relevant.
I took a look
14 matches
Mail list logo
