I'm getting a "new" kind of error in the provisioning hell from iPhone. Does anyone have an idea what's going on .. because reinstalling , redownloading of the profile doesn't work.
I've uploaded a screenshot.
http://img94.imageshack.us/img94/1559/picture15f.png
So the part where it says cannot be installed on devices?
If that is your distribution certificate (as your title implies) then the error message is correct. Distribution certificates are only for submitting applications to Apple for review.
Instead you will want to install a development certificate on your phone. That will allow you to load your phone with your own code for testing before submitting to Apple.
I would absolutely call it hell. Signing my first app for Apple is taking 100 times longer than it took for Android. I'm not quite sure why such tight security is needed. I've been spending an entire day on this security stuff. I'm sure once I figure it out it won't be too horrible, but this is a real pain so far.
Related
I am developing an app (for like a year) and it works fine , when it comes to submitting to App Store -> all my problems started:
1)The app store would me to make my app to run in a sandbox(Why Apple ? Why !?).
It took like 2 days to understand why just toggling "ON" in capabilities doesn't make it...
etc ... in the end I somehow managed to convince my app to run in sandbox.
2)now the app passing the validation fine and can be submitted to the bloody App Store
However when I checked the app before the submitting I discovered that it simply don't want to work (running from Xcode or product).
It just crashes before it comes to `applicationDidFinishLaunchingWithOptions"
The crash itself is even more epic "thread1: EXC_BAD_INSTRUCTION (code=EXC_i386_INVOP, subdued = 0x0)"
and I see a lot of assembly lines -> from the comments inside the assembly I understood that the app tries to "Open" a sandbox , but then comes the bad instruction :( ud2
The stuck I see is:
_libseinit_initialize_once
0 _libsecinit_setup_secinitd_client
1 _libsecinit_initialize_once
2 _dispatch_client_callout
3 dispatch_once_f
4 libSystem_initializer
5 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) ()
I think the rest are not relevant since they are all about some IMAGE loader :/
lately I ensured that removing the app sandbox key or setting it to NO Resolves my Issue but if I do so i getting back to issue number 1
so I kinda stuck with an egg and a turkey problem :(
maybe some 1 knows any interesting workaround or solution to submit the bloody app to the mighty app store ?
Sounds like what Apple document here:
OS X’s enforcement of container integrity impacts your development and
distribution cycle. This is because, in the course of creating and
distributing an app, the app is code signed using various signatures.
Here’s how the process works:
Before you create a project, you obtain three code signing
certificates from Apple: a development certificate, a distribution
certificate, and (optionally) a Developer ID certificate. (To learn
how to obtain these code signing certificates, read App Distribution
Guide.) When used in conjunction with the corresponding private keys
from your keychain, these certificates form three separate digital
identities. For development and testing, you sign your app with your
development identity. When you submit a version to the app store, you
use your distribution identity. If you are distributing a version
outside the app store, you use your Developer ID identity.
When the Mac App Store distributes your app, it is signed with an
Apple code signature. For testing and debugging, you may want to run
both versions of your app: the version you sign and the version Apple
signs. But OS X sees the Apple-signed version of your app as an
intruder and won’t allow it to launch: Its code signature does not
match the one expected by your app’s existing container.
If you try to run the Apple-signed version of your app, you get a
crash report containing a statement similar to this:
Exception Type: EXC_BAD_INSTRUCTION (SIGILL) The solution is to
adjust the access control list (ACL) on your app’s container to
recognize the Apple-signed version of your app. Specifically, you add
the designated code requirement of the Apple-signed version of your
app to the app container’s ACL.
I also had this problem, and although Droppy's answer was correct, it doesn't really resolve the problem (at least, not for me).
After messing around a bit, I found that the reason I had this problem is that, (although I had disabled keychain sharing in 'Capabilities' in Xcode's project editor) I still had a keychain value added. Removing this, or completely disabling all app capabilities (yes, including sandbox) will solve this problem.
Hopefully, this saves someone some time in the future.
I've created a Mac App for Mavericks that uses MapKit. It works fine during development and testing on Xcode 5.1. Now I'd like to submit it to the App Store and I need a Distribution Profile which I've created successfully. Trouble is, as soon as I add it to my project, the app doesn't run anymore - it crashes every time without fail with this error message:
When I change back to "no provisioning profile", or to the profile that Xcode created during development, the app runs again.
My question: Is this expected behaviour, or will the app be rejected by the review team? I know that iOS apps don't run with their distribution profiles, but I'm new to Mac Development. Any insights into this way too complex topic are appreciated!
My app was approved - and the crash was indeed no issue for the app review team.
I had a chat with Apple about this who were kind enough to call me back and explain the issue. Looks like this phenomenon is "kind of" expected behaviour: Mac Apps may or may not crash when run with a Distribution Profile.
To avoid this problem, we can add both a Development AND a Distribution Profile to our app, without one having to replace the other. This was news to me. Had I however opened my tired eyes a bit wider I would have perhaps spotted the little disclosure triangle myself:
Perhaps this helps those with the same issue.
In iOS6 I used to install some of my apps over an adhoc network without internet sharing. So the iPad had no internet connection. Therefore I use a typical html and plist file. Everything was alright.
Now, in iOS7 the installation is not working anymore. It is just stuck in "Waiting" and nothing more happens. (Note: It is still working on my iOS6 iPad)
First I thought something might be wrong with my plist, but then I copied the files to my IIS Server and installed it from there. Here I had a internet connection on my iPad and everything worked out.
Is it possible that the wireless distribution now needs an internet connection in iOS7 e.g. to check the ipa in the app store or something like that? Because this is the only difference I can see.
The app is signed with a valid distribution profile.
Thanks for your help.
It turned out the installation of apps over the air in iOS 7 really needs an internet connection now. The iPad tries to contact at least the following URLs before installing the app.
ax.init.itunes.apple.com: The device obtains the current file-size limit for downloading apps over the cellular network.
ocsp.apple.com: The device contacts this site to check the status of the distribution certificate used to sign the provisioning profile.
It seems in iOS6 it was ok if those URLs were not reachable and now in iOS 7 they have to be reachable.
Well i just had the same problem and I figured it out. At least on my xcode this is what happened. Turns out the application target release code siging identities auto set to developer and not their current state, from xcode 4.x, which is distribution. So when I went to distribute my application I kept getting the same error you had. So Click on your project name in your project explorer then click on the application target, not the project, and make sure the code signing identity is not set to developer for your releases. I have no idea why the code signing identities were automatically set to the developer profile, maybe there was some sort of bug when updating from xcdoe 4.x to xcode 5 that caused this. But now other devices are able to install the program. Hope this helps.
I have basically finished developing my App and I wanted to test it on the iPhone, however I wanted to know if this was possible without paying the 99€ fee. I dont plan to release it on the App store in the end...
Thanks,
Anthony
It's not possible unless you jailbreak your device.
You could have another developer who has registered, build your app, and then send you a signed developer copy to add to your phone. You would have to share the code with this developer though. If it is a one time deal, you can send to me, and I can build it.
Otherwise, Ole is correct, it is not possible.
I have a problem after upgrading my iPhone SDK 3.0. Xcode does not get the developer certificate, but it's in the key chain.
Sometimes the certificates are added to the system as opposed to the login keychains. When that happens XCode doesn't see the certificates. If this is the case, you have to go into "Keychain Access" (/Applications/Utilities) and add the certificate to the correct keychain (and optionally remove it from the wrong keychain).
These certificates are the bane of a lot of iPhone developers lives. I've lost a lot of time wrestling with them.
All I can suggest - as there's too much to cover in detail - is that you read very carefully the help text that goes along with each section on the iPhone Developer Portal, paying more attention to the ones in red.
I remeber having to delete and recreate them. And if you've up graded to 3.0.1, read this very carefully