We are building iOS OTA Enrollment system in our IT.
After reading Apple docs, i would not find reference how to set an expiration date on the Configuration Profile installed on the device.
My motivation is to create expiration date on profiles that i am going to install based on the device owner (they have to login before i install it)
Is there a way to control how long the Configuration Profile is valid for?
The configuration Profile has 2 keys:
RemovalDate
DurationUntilRemoval
Which takes a date or duration in seconds respectively, which when satisfied, will remove the profile. But maybe that wasn't what you're looking for?
The Configuration Profile supports the key "PayloadExpirationDate".
You can set the expiration date in the profile, and after the expiration, a new button inside the profile will appear to update the profile manually.
You can see the documentation in the following link:
https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html
Also, the Apple documentation "Over-the-Air Profile Delivery Concepts" says
Upon receiving the final encrypted profile, the device installs it.
Reconfiguration occurs automatically if the profile expires or if
a VPN connection attempt fails.
However, I wasn't able to update the profile, not manually and not automatically.
As far as I know, there is no way to control the expiration date.
Related
I'm wanting to view an existing profile that I have already installed on my iphone. I wanted to know where and how can i view the details?
Thanks
There is no such term as APN profile. There is provision profiles and there is APN certificates that embedded into provisioning profiles. You can check list of all provisioning profiles in Settings -> General -> Profiles. You will be able to get a minimal information about required provisioning profiles such as when it received and expires. You will also be able to remove it if you want. They do not provide any specific information related to APN through this UI.
In device , you can see it in
Settings->General->Profiles
In development system, You can see it in Keychain
Open the Finder->Applications->Keychain
In key chain you can use search option and use the searching string as "iphone".
You can see the installed provisioning profiles under Xcode->window->Organizer->Devices
It has been a long night chasing the problem within my in-app purchase trials yet I can not seem to solve this issue.My product identifier keeps returning as "invalid product identifier". Hopefully someone will point it out;
(With current provisioning profile and appId I got push notifications working)
My App ID is generated (with no wildcards) - inApp purchase is enabled
My IAP(In-App Purchase) is added in "Manage your in-app purchases" and cleared for sale.
My IAP is added 24 hours ago ( maybe couple of hours more) and is in "Waiting For Review" state
My App itself is developer rejected > and it is state "ready to upload", in-app purchase is added to the App.
My phone is not jailbroken (at least not anymore, didn't worked either way)
I am working with a 3GS, 5.1 iOS.
My current provisioning profile is a "Developer Profile" not a "Distribution Profile". "Distribution Profile" is used only while uploading the Application Binary.
I am building for iOS 5.0 and build configuration is set to Debug.
I deleted the app like 100 times now, literally.
All details are set in iTunes Connect, including bank details.
I have created a test user, and I logged in from "Settings > Store" on my device.
My SKProductRequest:
SKProductsRequest *productRequest = [[SKProductsRequest alloc]initWithProductIdentifiers:[NSSet setWithObject:#"com.my_site.my_app.my_product"]];
Any other information can be supplied.
I don't know how, and don't know will it remain valid. But here is the interesting solution which let me solve my problem.
According to the documentation, SKProductRequest should be;
SKProductsRequest *productRequest = [[SKProductsRequest alloc]initWithProductIdentifiers:[NSSet setWithObject:#"com.my_site.my_app.my_product"]];
Your product request should be like this;
com.my_site.my_app.my_product
but in my situation I just sent my product id, just like this and it WORKED;
SOLUTION #1
SKProductsRequest *productRequest = [[SKProductsRequest alloc]initWithProductIdentifiers:[NSSet setWithObject:#"my_product"]];
While digging in, I found that for some people this notation also worked;
SOLUTION #2
SKProductsRequest *productRequest = [[SKProductsRequest alloc]initWithProductIdentifiers:[NSSet setWithObjects:#"com.my_site.my_app","my_product",nil]];
There was nothing wrong with my setup, and the above listed things should be supplied, if anyone having problems with invalid product identifiers, I recommend them to visit Troy Brant's "Cause of Invalid Product ID's List", here . Also you can find his detailed walkthrough about implemeting and setting up IAP, here.
If you get desperate, I strongly recommend you to try both solutions, and they can save you from hours of frustration.
Please make sure you have not missed anything from below list.
Please remove the Existing application from the Device and Install
the fresh build from Xcode.
Have you enabled In-App Purchases for your App ID?
Does your project’s .plist Bundle ID match your App ID?
Have you generated and installed a new provisioning profile for the new App ID?
Have you configured your project to code sign using this new provisioning profile?
Are you using the full product ID when making a SKProductRequest?
Have you waited several hours since adding your product to iTunes Connect?
Are your bank details active on iTunes Connect?
Is your device jailbroken? If so, you need to revert the jailbreak for IAP to work.
If you answered No to any one of these questions, there’s your problem.
Please refer Reference
My paid applications agreement wasn't valid in iTunes Connect. As soon as I agreed to the new one, it fixed the problem.
In my case the problem was that I had previously created "StoreKit Configuration file" and then made change in Product Scheme:
Go to Product > Scheme > Edit Scheme and in Run/Debug tab under
Options I chose StoreKit configuration file.
Apparently this config was used instead of my App Store Connect IAP. So, the solution was to uncheck that option. You don't have to delete StoreKit Config file if you still need it for some reason.
You are using the latest provision profile right(which is downloaded after setting up in-app purchase).
Things ended up working for me:
I use Xcode automatic profiles and I got a bit confused on the app store connect webpage with the profile. I made sure ids matched on Xcode and on the webpage.
I just needed the product id, not the full com.company.app.product
took me like 2 hours to have things work, so maybe some refresh time on Apple's servers
Spends a couple of days at this. Here is what was missing from mine:
Make sure the BundleID in iTunes Connect matches that in your Xcode project.
I'm going to update an iphone app but I cannot Testing it on the itunes portal.
I made the update in itunes portal, I build it, and When I want to validate it, it doesn't runing because of certificate so I'm asking if I don't have to make a new certificate?
When I use the certificate that I used for the first submission:
Application failed codesign verification. The signature was invalid, or ti was signed with an Apple submission certificate.
The status of the certificate on the Portal is Active.
I put All the line of "Code signing" to iPhone Distribution and edit scheme>Archive>Release :
printscreen.
I re-sign the app with the same certificate when I try to validate it on iTunes...
Thanks to help me
EDIT : I make that but I still have the same problem:
Download certificate
Import it and deletete old one
set the new certificate overall ^^
Get the error xD
Please help me I need to do that before monday
If your old certificate has expired you need to create a new one to be able to update your app.
Are you using the certificate on the computer that generated it in the first place? If not, your public key doesn't match and you'll have to request a new one even if the current one hasn't expired.
It looks as if your code signing build settings are automatically detecting which certificate/profile to use. The image is cut off so I can't see what certificate/profile combo is being used, but it sounds as if it is selecting your Ad-Hoc combo and not your App Store combo. Try changing the code signing build settings for the target(s) you are using to build for the App Store manually to your App Store profile. If this makes no difference, can you please show the rest of your code signing settings (not chopped off on the right)?
I followed indications to make Ad-Hoc on the official portal : http://developer.apple.com/ios/manage/distribution/index.action. It says that we have to make a new entry on entitlements (get-task-allow at true) and I didn't delete the row in the entitlements file!!
Now all sounds OK, sumbitted !
I'm sorting through the various Apple docs, but haven't seen it yet.
Here's the deal: I've created a series of apps that are for a service for NPOs. These are hugely popular (albeit in a very small pond), and I have been asked to make customized versions for some of these organizations.
It's a FOSS app, but these outfits can't get iOS programmers to build and release the apps. They are willing to set up App Store accounts, but don't have the geeks on hand.
Due to the way the organization manages its IP, I am not allowed to release branded apps under my app store account. They need to release under theirs.
I don't want to set up an enterprise account for this. I haven't read up on that, but I'll bet that it would not be practical, anyway.
Is there a reasonable way for folks to take apps built on one account, and apply a new provisioning profile, and release it via another account?
Yes a company can take any developer app, sign it with their own certificates, and submit it using their own iOS enrolled team leader ADC account. They can even hire a contractor or temporary employee and legally authorize them to do this work for them.
If you do this type of subcontracting, you might want to get authorization in writing from the CEO, COO or chief legal consul of the company to do so.
you can use a different provisioning profile and deliver the app to the other guys. You can have multiple profiles in your X-Code and select with which one you want to sign the app when you create the archive.
You can either do this yourself by getting access to your client's app store signing certificates, or you can get your clients to use their codesign tool - details on the latter technique can be found on google - here is one example.
Enterprise accounts don't let you release on the App Store.
A typical way of handling this is for them to set up an account and give you the details for the team agent to log in. You then generate a key pair and a certificate signing request in Keychain Access. You log in as the team agent and use the certificate signing request to get a distribution certificate, which you then download and open - this will install into the keychain. Export the key pair and supply this to them so that they aren't screwed if you get hit by a bus or something.
From that point on, it's all stuff you should be used to. Xcode knows which private key to sign the build with because it matches the provisioning profile. It knows which provisioning profile to use because the app ID in the profile matches the app ID in the Info.plist file. Beta testing with ad hoc builds is the same as normal, except you register the UDIDs after logging into their account, not yours. Archives are not tied to your account.
When you submit the app through Xcode, you'll have to supply the team agent login details again. The submission will show up under their developer account, not yours.
Technically speaking, I think it breaks their developer agreement with Apple for them to supply a third-party (you) with their login details. However I don't believe it's possible to delegate all of the privileges necessary to submit an app to anybody other than the team agent, and the parts that can't be delegated aren't easy to explain to a non-technical person. You can script some of it to make it easier, but it's easy for them to get into a mess, so it's usually best if they let you handle it all.
I generated an ad-hoc profile which shows up the expiry date of June 25, 2079. Is this correct or a bug in the provisioning portal?
Thanks
I think it was a bug because Apple has revoked all the provisioning profiles we created in the last week that had this 2070 issue.
It appears that sometime this week Apple changed the rules on expiration for new distribution certificates. Instead of expiring when your program period runs out they are expiring in 2079. I've been able to successfully submit an app using the new certificate so at least right now this seems to be just fine.
2079 here for me too! Glad others are seeing no errors with it. I have been using the new Provision for Ad Hoc without fault. Googling 2079 and Provision brings us to this page.
I also had a provisioning profile with the 2079 expiration date. Apple let me submit one version of the app with this profile but as of today it says it is an invalid signature so I guess they changed the policy (without telling anyone).