I am using XCode 6 and building the IPA. I have been following many posts in Stackoverflow and have gather information and the steps as to how to create the provisioning profiles and build the IPA.
I have been able to build the AdHoc IPA and have been successful in deploying it in my device. The application gets launched and is running fine. Now my query is that, as I am able to install the application on my device without any issues, does it mean that the IPA when uploaded to Apple will also get approved. (I am not using any private APIs. I am building my application using Appcelerator).
No, it doesn't mean that at all.
You've proven only the following:
That you have an app that compiles.
That you have an appropriate provisioning profile to load to your device.
Apple cares about a lot more than just that. For instance, you say it's "running fine", but Apple will test it fairly thoroughly to see if they can get it to crash. From personal experience, they might even find a crash that you can't replicate on your end (which is terribly frustrating!).
Also, Apple has gotten more picky about their approval process. I submitted an app that had an extra feature that linked to another app that was related but distinct. Apple ruled that my app was incomplete as it required another app to be fully-functional. What did I do? I removed the extra feature, and then Apple approved the app. Yes, I took away a feature and my app went from "incomplete" to "complete". My point? Apple's review process is fairly subjective and it can depend on who looks at your app and what kind of day they're having.
On your first app submission, be prepared for several back-and-forth sessions where they reject your app and you have something to fix. On the plus side, they're generally pretty specific about the problem they found, so it makes it easier to fix it!
You may get approved the first time out, but it's a higher bar you have to pass than just the items you mentioned in your post.
EDIT
Also, you need to make sure that you have an appropriate Distribution profile. For loading to your device, you are most likely using a Development profile. Make sure you've gone through the steps to create an App Store Distribution Profile (which also required a Distribution Certificate, by the way).
Related
I think similar questions may have already been asked but cannot find quite the right answer.
I have an app that I build using Fastlane and then deploy to both TestFlight and MS AppStore. We want to be able to have our testers test the app on AppStore but I cant quite wrap my head around the whole provisioning profile story in that case.
I currently have one build going up with ad-hoc profile and another with development profile. I can access it with my phone but my device is on both profiles so it works flawlessly.
When my manager or product manager try download it... well firstly it tells them that "The developers are working on a version for your device. You'll receive an email once this app is released" but then if they follow the link from the email it attempts to install then gives the lovely message of "This app cannot be installed because its integrity could not be verified" which from Googling suggests an issue with the provisioning profile... which makes sense because their devices aren't on the profile.
I came across the possibility of using in-house profiles but for that you need to be a part of Apple Enterprise Program, which, we are not. And that is intended for internal-use apps. Which I guess testing will be but also no.
The only thing I can think of would be to add their UUIDs to the provisioning profile but what bugs me with that is that I would need to make a new build every time theres someone else that wants to test the app which is ugly (not to mention that I'd need to get their devices UUID and can you imagine me trying to get the big boss to give me their devices UUID so that they can have the app in their hand and play with it)
Another thing is we are wanting to do automation testing, and that will run on random devices, so no idea how I would deal with provisioning those
Please if anyone can point me in the right direction?
Also could someone please explain to me the differences between the different provisioning profile types?
AppStore is one that gets resigned by AppStore
Ad-hoc as far as I understand is anyone on the provisioning profile can use it
Development, I have no idea what the difference between development and ad-hoc is
Theres also development id? not sure what that is
Enterprise/In House as far as I understand is a self signed and anyone can use the app but its designed for internal only apps.
theres apparently validation and package too, no idea.
Please and thank you for any assistance
We are developing an iOS application for a customer who manages his apps under his own name in iTunes Connect.
I was wondering if there was a feasible way to validate an ipa when you are not the final instance which will actually upload the bundle to the App Store. A common scenario is that you deploy an application bundle to a customer so that he will be the one who manages the app in iTunes Connect, but you still want to make sure that everything checks out once the app is in your customers hands.
To be clear: we don't have access to our customers iTunes Connect but we archive the application with their distribution profile.
The idea which came to mind is to create a mock application in our own iTunes Connect without the intention to actually release the application. One could expand on this and actually do a pre-review of the app to make sure the app will not cause unpleasant surprises after we sent the archive to or customer. Will Apple throw any rocks in this path? I could imagine that they won't be happy that developers will let review the same app version twice...
You ask about whether the final Xcode archive could be tested. Yes, it can be tested. You should ask your customer to send you a copy of the submitted application, as it appears in the Xcode organizer). They would have to resign the bundle with THEIR AdHoc profile that should contain YOUR device, and send the IPA to you. You would then be able to check the final submitted app.
For the second part of your question, which is most interesting: It would be great to release the app in your account and then let the customer release it again. There are two problems: if the reviewer is the same, then your customer's app may be rejected. And: if the reviewer is not the same, it could pass validation with the first reviewer and fail with the second one.
So I took over an existing iOS app from a client, that is currently available for public use through the App Store. When I was given the project in xcode, I noticed that all provisioning profiles associated with the app had expired and all were under the name of the previous developer.
So, I added myself as a developer and joined the team and code signed the development copy under my credentials. I created a new ad hoc provisioning profile for testing, and released a version through TestFlight to some registered devices. No problems. The app is greenlighted to go live.
Can someone please help me out with the release process from this point on? Do I create a third new provisioning profile for App Store release, and tie it to the code signing in XCode? Is this going to be problematic considering the version that is live now is under completely different (expired) profiles from a different developer? Is there some alternative way I need to do it through Apple? I'm trying to be super cautious here... if for some reason I release the app and its crashing because of some step I didnt take by accident, the poop will hit the fan.
You're going to have to release it under a new name on the App Store and forfeit all the ratings and reviews. Apple won't let you swap developer profiles on an existing app.
Other developers may disagree, but it looks like a huge PITA. See here
Transferring ownership of an iPhone app on the app store
The official answer seems to be NO
I didn't interpret the question as regarding change of ownership of an app.
I read the question as: I've inherited maintenance of an app and we'll want to submit an update as the same seller.
In this case, you can generate your own certificates and distribution profiles, and you can then build and submit the app.
I have done this numerous times. That is, I have inherited responsibility for an app that I did not necessarily craft originally. I easily created new signing and provisioning credentials, appropriate for the app the be submitted as the seller (not me) on their behalf.
And for what it's worth, the App Store Distribution profile is necessary, but only used when the app is submitted, so Apple can ensure that it is coming from a developer that has the right to submit it. (Remember, these profiles are signed with the same certificates used to sign your app package.) If that Distribution profile should expire or change, it has no bearing on an app already in the App Store.
I've been trying to find some guidelines on the overall process for releasing an iOS app. The documentation on Apple's iOS Dev Center doesn't seem clear. I've found some sites that try to explain aspects of the process, but I haven't been able to find a clear, conscise guide that explains some of my questions, such as:
What do I have to do within my project (ie info.plist file changes, target/build settings, etc.)
I am using In-App Purchases. It is working in my sandbox, but what do I need to do (if anything else) to make sure this works when my app is released? As far as I can tell from what I've read, there is no way to test this in live environment until after the app appears on the app store.
Is there any other provisioning/certificates needed beyond what I have used when developing my app?
Anything else that I am overlooking?
If you know of a site (or sites) that explains this in more detail, it would be much appreciated. After searching for hours I can't seem to find answers to these questions.
Thank you.
Have you seen this document from Apple on "preparing for app store submission"? It's pretty clear on the steps you have to take to get onto the app store.
In short:
No specific changes, but you have to archive for a device rather than building for testing.
In App Purchasing will work on the app store without any more configuration
You need a distribution certificate for when you build an archive for the app store, make it in your iOS Provisioning Portal, under Provisioning page and Distribution tab.
We have an iPad app that we would like to distribute internally. We're looking into "Enterprise Distribution". The set of requirements I have been given include that the method for distribution is to be that a user goes to a secure website from an iPad, logs in, and downloads the app. The app then works for them.
Users who do not have access to the website should not have access to the application. We can easily prevent them from downloading the app by forcing them to log in. However, it is not obvious to me that after they download the app (via an .ipa file?), that they couldn't just give it to someone else, something that is not allowed.
It looks like a way around this is to have Distribution Provision Profiles, which determine whether a given app will run on the device. However, it's not obvious to me that those couldn't just be copied as well.
http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
Once you create the enterprise distribution provisioning profile, download the
.mobileprovision file, and then securely distribute it and your application.
Sadly, I don't know enough to know exactly what I should be asking, but here goes:
Can ipa files just be copied from one Ipad to another, allowing anyone to use any given app? (assuming there is no other protection on the app)
If the answer to 1 is yes, is there any reason to believe that .mobileprovision files will help me?
Every device has a UDID, a unique identifier. This is how Apple enforces the 100 development devices rule for individual developers. You collect UDIDs as part of the download process, issuing the provisioning profiles to registered users.
To answer your questions:
Yes, theoretically, without DRM or provisioning, an ipa can be synced to iTunes (or manually copied with third party tools) and then moved to another dewvice.
Yes, .mobileprovision files include UDIDs in them which are pretty much unique to a given device. (The exception may be on jailbroken devices, which, if I recall correctly, can spoof a UDID.)
EDIT:
Just to clarify, in response to your requirements:
The set of requirements I have been given include that the method for distribution is to be that a user goes to a secure website from an iPad, logs in, and downloads the app. The app then works for them.
I would add a middle step.
User logs in.
User submits device info
You create a provision for the device
The user then downloads the app and the provision.
This does not stop the user from giving out the app to others, but it's the best you've got. You can also require the user to log in inside the app, with the same email as the one used to register the UDID, theoretically.
It's now July 2012. Apple's documentation on how to create and distribute an Ad-Hoc iOS application remains stuck at iOS 3, is over-complicated, overwhelming, and often wrong.
With an Developer Enterprise Program license (and a fair bit of patience), you can create an .ipa file, which you can stick on your website.
Your users can then navigate to this webpage on their iPad's Safari, click on a download link to download and install your app onto their device. No iTunes required.
Your app will need (amongst other things) to be signed with a distribution certificate, which you create on the Apple Developer website, but my point is that once you have jumped through all of these badly documented hoops, you can just stick an .ipa and .plist file on a webpage, and ANY user can install your app with it.
Even your Aunt Gladis, who lives 200 miles away and doesn't work for your company.
Mind you, if Apple finds out that you have distributed your app to anyone who doesn't work in your company, they will pull your license.
Getting the Enterprise Account takes a lot of work. Apple will want your DUNS and possibly other proof that you're who you say you are (and that you're an enterprise).
Going the other route (individual developer) will allow you to post your app (make it free so your users will not have to pay!) in the store. Your app can require an account on your local service that no one outside your company will be able to acquire, which will prevent people outside the company from using it. The risk here is that Apple will reject your app for this reason.