I'm developing an app that will have two versions: one on the app store, and a limited edition that will be given away in a contest to one winner. My question is, how do I provision an app to give away to just one person? I'm guessing I need their UDID, and have to send them an Ad-Hoc distribution provisioning profile; but does this mean I will have to keep sending them new profiles every time it expires?
What would be the best way to do this?
Thanks,
chmod
Ad Hoc distribution certificates expire. Unless you want to give away a time-limited app (the duration of the Ad Hoc provision), the better option might be to gift the app to the winner's iTunes account, which will cost the developer 30%, or to use one of an App store app's 50 free redemption codes.
It depends on how you want to customize it.
If you have their UDID, you can check for it in code like this:
NSString *udid = [[UIDevice currentDevice] uniqueIdentifier];
From there you could simply switch out graphics or functionality based on whether the device matches the UDID or not.
Note: uniqueIdentifier is depreciated as of iOS5. It still works and may still work well into the future, but there is no guarantee of that.
Related
I have heard some rumours that Apple is rejecting apps for using the iOS5 deprecated method [UIDevice uniqueIdentifier]. Can anyone confirm that they have had their App rejected for this reason? I know of the alternatives to using this deprecated method, but one of our customers is requesting we use a 3rd party library that we know uses this method.
I would be surprised if this is the case as the API method has been deprecated and not made private.
Apple is not rejecting apps because of this. I collect device UDIDs along with tokens within my apps that support push notifications and they have all been approved. UDIDs are simply deprecated, meaning that Apple will eventually not allow you to access them. Everything still works and will be approved.
I heard that Apple deprecated access to UDIDs to prevent developers and third party analysts from being able to identify specific people. If it truly was because of issues with iCloud, Apple would clearly have fixed this instead of inconveniencing everyone else.
Edit: It looks like Apple is rejecting some apps for accessing the device's UDID. Just to be safe, I would use CFUUID to create a random unique identifier. You can use NSUserDefaults or the keychain to save it. The advantage to the keychain is that if the user deletes your app, the keychain items are not deleted so you can still access the UDID if the user reinstalls your app. It will only get deleted if the user restores their device.
Using Identifiers in Your Apps
Starting May 1, the App Store will no longer accept new apps or app updates that access UDIDs. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6. You can find more details in the UIDevice Class Reference.
Source: https://developer.apple.com/news/
It appears that App Review is enforcing this rule on apps that transmit the UDID without getting the user's permission -- as suggested by this post -- rather than ones that simply invoke the deprecated API.
We had an update in review for an app that would send the device UDID to our server, on which we would use it to index the user's account. We decided not to take any chances and change our code to generate an app-specific unique identifier, as proposed by documentation on the deprecation of the UDID
now Apps are not permitted to access the UDID and must not use the uniqueIdentifier method of UIDevice. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6
NSUUID *uuid = [[UIDevice currentDevice] identifierForVendor];
NSString *uuidString = [uuid UUIDString];
and must to add ADSupport framework
Since May 1, Apple is rejecting all apps which access to the UDID.
But it seems the only thing that they can do is to check if the string "uniqueIdentifier" is in the binary or not.
So even if you don't acces anymore to the uniqueIdentifier of the phone, but you give to one variable the same name, they will find it in the binary and they will reject it cause they can't do the difference.
If you want to know if you binary contain it, you can change the extension of the .ipa (export for ad-hoc deployment) to .zip, unzip it, and do fgrep -R uniqueIdentifier . in the terminal at the payload/ folder.
You can also do this command in your project folder to find the files which contain the string.
This worked for me.
I am an individual developer who has written an ipad app for a company. They have bout 30 devices they want to put it on, so my current plan is to create a provisioning profile that contains all the UDIDS for all those device. So here are my questions:
I surely will miss at least one device and have to either:
a. Create a new distribution provisioning profile for that device
or
b. Add it to the existing provisioning profile, in that case does it void the others
Could I submit something to the appstore that is obviously for internal use and password protect it? The company probably isn't willing to do an enterprise account, and I don't want to maintain it by getting them a new provisioning profile every year when they expire. Any ideas here?
Did you consider Ad Hoc distribution? That would allow you to add the app to a new device without having to make a new provisioning profile.
I haven't done it myself, but this looks useful:
http://www.iphonedevsdk.com/forum/iphone-sdk-development/35818-unofficial-ad-hoc-distribution-guide.html
I love TestFlight for small distributions. Also, see the Apple enterprise distribution documentation. It goes over signing and wireless distribution.
Rather if this is going to be used by the company for a longer period of time then I would advice you to go for iOS Developer Enterprise Program.
The main highlighting lines about Enterprise Program is
"Gain access to resources that will help you develop proprietary, in-house iOS apps that you can distribute to employees or members of your organization."
So you can distribute the app among your company employees directly without need to submit it on app store. That would surely be a better option.
For more details on iOS Developer Enterprise Program, you can check out this link..
iOS Developer Enterprise Program
Is it possible to give an ad hoc build for iPhone, without asking for device id?
I want to deploy the app to a couple of people but I don't want to ask for device id to create a profile and all that stuff.
Is that possible?
if not, what is the easiest way to do it?
Simply put, no.
If you're concerned about the complexity of getting the UDIDs from your testers, I recommend having them install & use Ad Hoc Helper, which makes the process very simple (as long as they have e-mail set up on the device).
You can't do an AdHoc build without device ids as that would give you a distribution channel outside of the appstore. AdHoc is designed for testing only
An enterprise account does not have any device id requirements for deployment but you do need to be a company with DnB number etc and pay the $300 annual fee.
Not easily.
Apple likes to control the distribution channel. If you could distribute your app without knowing device IDs in advance, you could make a competing app store. Apple requires that you list device IDs and limits you to 100-some devices, which presumably should be enough for development/testing purposes.
Some possible solutions:
If you're distributing to other developers, they can re-sign the app with their own provisioning profile and certificate (i.e. replace MyApp.app/embedded.mobileprovision, CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate codesign -f -s 'iPhone Developer' MyApp.app. Additionally, you might need to specify entitlements).
The iOS Developer Enterprise Program presumably has a higher limit, but I suspect you still need to list device IDs.
A jailbroken phone will run unsigned apps.
No, it's not possible (unless you (and your people) work with jailbroken devices).
Assuming you are not going to put your app on iTunes, I guess you have to ask their device ids, at least for once.
However, once you have their ids, the remaining part would be as simple as to give them an URL. They just go to the URL with their mobile Safari, and can directly download the app.
Here's a link to show how to do that:
http://www.readwriteweb.com/mobile/2010/12/apple-best-kept-secret-how-to-do-ad-hoc-installs.php
So, I basically developed and tested my app using a developer provisioning profile.
now i'm almost ready to submit my app to the app-store, and I was going to use the app-store provisioning profile. so I don't really need to mess with the ad-hoc one at all right?
(I think it's some kind of voodoo magic for multiple developers or something?)
thanks
You only need ad-hoc if you want to test further with others. It is basically the same as the final approval provisioning. You have up to 100 users that can install your app.
Ad-hoc provisioning helps you test at a larger scale than your single developer test.
Testers will always find a way to break your app, so it is a good practice to use this step to help reduce your bug count and smooth your approval process.
Ad-Hoc distribution is outside the App Store. You must sign your app with the Provisioning Profile approved for Distribution and for you app. That is to say if you are specifying an App ID. That latter is common if you are doing Push Notifications or In App Purchases.
As Jason said, you will need to go through the provisioning process in order to submit your app to the App Store. It can be a tedious process the first time - but you can't avoid it.
That said, Distribution builds (non-Debug builds) are different executables. So, it makes sense to test them as such. It is unlikely that problems that were absent in the Debug build will suddenly manifest themselves in the Distribution build - but it's possible.
Also, unless you have at your disposal every iDevice with every combination of iOS releases that you are targeting, then it's nice to have others help make sure that there are no gotchas.
Bottom line: I wouldn't consider submitting an app to the App Store without first deploying Ad Hoc an build on all my devices and sharing it with a few other iDevice users. But, YMMV.
No, it's not necessary. :)
The background story:
I work for a company that develops and manufactures a commercial product which can have up to 100+ dedicated PC's in a farm.
We only get a handful of new customers per year.
We developed an iPod/iPhone app that lets us send commands to the farm and pull data. Our parent company has major concerns about putting this app on the AppStore. (I really dont know the details of the paranoia, but I know its probably not a winnable battle).
We planned to distribute the App via Ad Hoc using ONE or TWO new iPods each time we sell a "farm". I have just learned that the Ad Hoc distribution expires after 90 days.
The Question:
Are there any alternatives for permanently loading our app onto an iPod Touch or iPhone without going through the App Store?
Our app has absolutely no use to anyone without our other product. We only plan to load this app on a handful of iPods a year. I doubt this matters, but maybe somebody has another solution?
Apple has an an enterprise distribution program, which might allow what you're trying to do. There's also jailbreaking the iPods. That would let you run unsigned code, so you could build your apps without ad-hoc certs.
I know this post has been marked as answered but i am in the same situation so i though i should share what i have experienced.
There is NO legal solution for this. You can't have an app distributed with out the annoying expiry dates.
I have been onto the ADC support and you can't get an extension on the certificates, you can renew for more than 1 year at a time and they have no interest in helping you.
I have clients who will not let the content of their apps hit the app store. There for they are stuck with sending all the devices back to renew certificates (i know you don't need to xcode etc.. to install the certs but try getting end users to do it...).
I am in the luck situation that i can try send the shell of an app to the appstore and then once verified (i.e. once off login - ssl to our server with the device id and a guid password) the app will download all the sensitive content to the phone.
I don't know if this will work for all apps - i.e. loading classes or libraries dynamically but for me it is only the content that is sensitive.
if anyone would like more info i am happy to talk it over, but i haven't tried getting the app through the store yet. I will try soon, so i can keep you posted if you are interested.
cheers
kle
As of September 2010, Apple has removed the 500-employee requirement. Go nuts!
See my post about setting up an Enterprise Program account (which moderators keep trying to close!):
https://stackoverflow.com/questions/1876333/how-long-does-it-take-to-get-an-iphone-app-into-the-app-store-closed
Issues with getting an Enterprise Program account:
-You need 500 employees.
-You can only provide the app to employees.
Make sure you check the detailed terms and conditions of using Ad Hoc distributions to be sure you are allowed to distribute them as you are doing. On the face of it you are probably okay (Apple link here), but worth checking the fine print. I know the Enterprise Program had a lot of fussy fine print, e.g. needing procedures to recover apps from employees when they leave the company, etc.
If you jailbreak the iTouch/iPhone then you can easily disable Apple's code signing checks. You can then build your app and load it onto the device as normal without worrying about expiry or anything else.
The only problem is that jailbreaking on newer batches of the 3GS is not particularly end-user friendly. For something to give to a client I think you would need to stick with the iTouch.