

The Pains of iPhone Ad Hoc Beta Testing - guybrush0
http://iphone.broadersheet.com/2009/09/the-iphone-ad-hoc-beta-testing-method-sucks/

======
patio11
Interesting. This problem is tractable with better software, and it seems to
be well within the capability of a single developer to solve. (Make a
dedicated beta client which automates all the stupidity for the end-user,
including sniffing GUIDs, downloading your distribution, and reporting errors
to you, and a web service for the beta clients to connect to to grab apps,
report errors, and _cough_ ensure that your customers succeed in paying for
your application.)

Unfortunately, while it is software that saves people pain (a plus) and helps
make people money (a big plus), it is also sold to developers (ouch), most of
whom are hobbyists (double ouch), would have to cost an awful lot in
comparison to what _they_ charge for software (triple ouch), and requires
Apple to remain clueless or else your investment gets vaporized with a patch.

~~~
gte910h
I actually think it could be sold as a framework completely legally.

~~~
patio11
I have no doubt it is legal. The competitive position is just suboptimal:

1) I charge money to make iPhone development not suck

2) iPhone development is primarily controlled by Apple, a company with ...

3) ... smart people who have ...

4) ... more money than God and ...

5) ... could teach Japanese electronics manufacturers about user experience
while ...

6) ... making hundreds of millions off the iPhone ...

7) ... justifying making any improvement available _free_ , and probably

8) ... announcing it at MacWorld, to the resounding cheers of their hundreds-
of-thousands strong cult of fanboys who whose very identity is predicated on
using Apple products.

------
tienshiao
A couple tips to address some of his issues:

Issue: .app directory is browsable, don't use Vista to decompress.

Solution: Package your app as an .ipa. It is now no longer a directory, and
your use can drag and drop this into iTunes. iTunes will handle the
decompression. I usually send the following link to the users to help them
through the install: [http://www.innerfence.com/howto/install-iphone-
application-a...](http://www.innerfence.com/howto/install-iphone-application-
ad-hoc-distribution?zip_file=AppName.app.AdHoc.ipa)

Issue: user needs to delete old version in order install new version. Can't
test upgrades.

Solution: Increment your Bundle Version for each version.

~~~
eelco
Yep. These are all things that simply take time to learn. It seems the author
is just bit a inexperienced in these and mostly wanted to blow off steam. I
was also annoyed by these things, but that's what drove me to figure out a
better way and/or automate them. I added the same tips (and some more) as a
comment to the blog.

------
dpapathanasiou
Ad-hoc testers using Windows Vista have a couple of obstacles to overcome.

Not only the default unzip problem the post mentions (I've found it's just
simpler to give the Vista testers an ipa file instead), but also removing the
provisioning profile from iTunes usually involves going into the local
filesystem and removing the .mobileprovision files manually:
<http://denis.papathanasiou.org/?p=139>

------
sil3ntmac
"Over 10% of our testers gave us the wrong number as their UDID."

It's not _that_ hard. There's a free app you can put on your device that will
email your UDID to where ever you want, or you can just copy it over from
iTunes/XCode. I haven't ever had a client give me the wrong UDID (they have
given me the same UDID twice though, forgetting that I already have that
device in the database). The hardest part usually is that it can sometimes
take 5-6 tries of dragging the app into iTunes (on Windows at least) for it to
work. But even that isn't too big of a deal, just quick and easy repetitive
motion (once they get the profile installed).

I think the biggest pain in the ass is on the developer's side. Anytime you
want to run the app on another device, you have to add another UDID to the
device list on Apple's site, regenerate your provisioning profile, download
it, delete the old adhoc profile from ~/Library/MobileDevices (good luck
trying to find out which of the profiles in there is your old adhoc, the files
are named with a random string of letters and numbers), install it to XCode,
open your project, and change your adhoc build profile settings to the new
profile.

Phew.

~~~
tienshiao
You can manage your provisioning profiles more easily through XCode -> Window
-> Organizer.

It'll list your profiles by name and expiration date. You can click on them to
see more details, and also delete them from there. You'll stil need to update
your project manually after you've swapped out the provisioning profile.

------
rahulvohra
Agreed. I often have to give people my UDID several times ... and then
sometimes it still doesn't work.

~~~
JustAGeek
You know, this is yet another thing why I really hesitate to start hacking for
the iPhone, there are just so many hoops to jump through and being used to
developing web apps this beta process just sounds insane... I wonder why so
many people are still putting up with all that.

~~~
gte910h
You can actually hack in the simulator quite easily.

It's just distribution to non-app store clients that is a pain in the ass (as
well as going through the approval process)

~~~
alex_c
> It's just distribution to non-app store clients that is a pain in the ass
> (as well as going through the approval process)

Yep... it's just distribution to non-app store clients, and distribution to
app store clients, that's a pain in the ass. Everything else is easy.

[http://www.alexc.me/android-distribution-vs-iphone-
distribut...](http://www.alexc.me/android-distribution-vs-iphone-
distribution/242/)

