Re: a new guide: How Not To Install Ad-Hoc iPhone Apps
Re: a new guide: How Not To Install Ad-Hoc iPhone Apps
- Subject: Re: a new guide: How Not To Install Ad-Hoc iPhone Apps
- From: Ray Kiddy <email@hidden>
- Date: Tue, 24 Feb 2009 15:35:45 -0800
On Feb 24, 2009, at 2:23 PM, Nathan Ramella wrote:
In your bundle identifier try using 'com.wykiwyk.iphone.*' if thats
what you have your provisioning profile setup as.
I tried that and it did not work, but I am curious why you thought it
would work. Do you not use wildcard AppIDs?
Well, I was hopeful. I figured that perhaps nobody is using wildcard
IDs. But I went and created a new (non-wildcard) ID, just for this
app, and then a new provisioning profile, just for this app, and
downloaded it and so on and so forth and .... it does not install.
Same totally useless response from iTunes.
So, does anyone use wildcard IDs and make them work?
What does you AppID look like? What do you put into the Identifier in
the Properties pane for the main target?
I got this info from the
iphone_developer_program_user_guide__standard_program_v2.4.pdf. Maybe
I am just completely mis-interpreting all of this.
I take this to mean that if I get a provisioning profile made for
AppID "com.foobar.*", then I can use that AppID to create a profile
for App1 and use the CFBundleIdentifier = "com.foobar.app1" and use
the same app ID and create another provisioning profile and use the
CFBundleIdentifier = "com.foobar.app2". Am I wrong about this? If I
am, then what the heck does using the wildcard provide?
- ray
from middle of page 19:
If you are creating a suite of applications that will share the same
Keychain access (e.g. sharing passwords between
applications) or have no Keychain Access requirements, you can create
a single App ID for your entire application suite
utilizing a trailing asterisk as a wild–card character. The wildcard
character must be the last character in the App ID string.
Example App IDs for this situation could be:
R2T24EVAEE.com.domainname.* or R2T24EVAEE.*
In these wildcard situations, you’ll simply replace the asterisk with
whatever string you wish in the CF Bundle Identifier field in
Xcode. For iPhone OS 2.0 development, use a wildcard App ID for all of
your applications.
from bottom of page 19:
4. Enter a Bundle Identifier in the free-form text field. The
recommended usage is a reverse-domain name style string, e.g.,
com.domainname.applicationname. For a suite of applications sharing
the same Keychain access, you should use a wildcard
character in the Bundle Identifier (e.g. com.domainname.* or *). This
Bundle Identifier will need to match whatever CF Bundle
Identifier you use for your application in Xcode.
On Feb 24, 2009, at 12:35 PM, Ray Kiddy wrote:
On Feb 24, 2009, at 11:56 AM, Nathan Ramella wrote:
Ray,
What's your Info.plist say for the CFBundleIdentifier? It isn't
called out on your webpage.
-nar
Identifier: com.wykiwyk.iphone.InstallTest0001
My understanding that I can use any string that starts in
"com.wykiwyk.iphone." and it would work.
Will update the web page.
thanx - ray
On Feb 24, 2009, at 10:38 AM, Ray Kiddy wrote:
No ranting. Really. I mean, so what if I have been able to
install apps in the past? Then, upgrading from SDK 2.2 to 2.2.1
broke me and I could not, and had to find out what barely
documented hacks were taken out that now break things.
Now, a project that was installable last week, and not changed,
is not installable. A few things in the project look different.
The project's reference to the Entitlements.plist was missing and
I am positive I did not take it out. And I found a few other
things. Makes me wonder what random crap got changed that I did
not find....
Do you have a problem ranting in bugreporter bugs? I do. But I
figured something out. We are a cargo cult, waiting for info from
some weird noisy thing up in the sky. File a bug with no effort
put into it. "Dupe. Thanks and you'll never hear from us about
this again." File a bug with lots of info and steps on
reproducing. "Dupe. Thanks and you'll never hear from us about
this again." Or better yet, you get: "A bug. Thanks and you'll
hear from us about this sometime in this millennium." I have
decided that ranting in some of these bugs might be ok. After
all, what is Apple going to do? They could not give me
information.... Oops! They already do that. Do they let us see
the 'Workarounds' field in the bug? No. Do they update us about
the bug's status? No. There is a _lot_ of information in the
Radar bug that Apple sees and we see none of it. There is really
not much they could do to be more unhelpful, so if ranting makes
me feel better, why should I not?
Anyway....
If you are interested, please see: http://www.wykiwyk.com/iphone/HowToNotInstall/index.html
There may be something that seems obvious to you that I am
missing. I would actually like to turn this into a "How To"
instead of a "How Not To". I bet that I can write a targeted "how
to" document and keep it under 52 pages.
For now, I have several iPhone apps I want to start to
distribute. But if random stuff like this is going to happen, why
bother? It is not as though one can get past the security
barriers to actually see what is going on. Switching to Android
development may be better for my blood pressure. We'll see.
- ray
_______________________________________________
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