Is it just me or do the provisioning profiles created on the developer portal expire every 2 months? Why is that insanity?
Is there any way to create a provisioning profile that will last for the entire period of the annual subscription?
I have contacted Apple, but they simply did not answer. Is Apple insane?
Provisioning Profiles have shorter lifetimes now, yes.
I don't think Apple is insane, they probably have a good reason for it. Does it jive with what you want out of life? It appears not, but I would think that they have a legitimate reason for wanting to change the limitations and it is not because of a lack of sanity. Besides, Apple would have to be collectively nuts and I don't think that that is the case or even really possible.
It barely takes a moment to renew an expired one, and then each developer on your team has to update as well - and that also barely takes a moment.
Most iPhone app dev cycles probably hover around the 2 month range anyway so this shouldn't be a big deal to most.
So like the guy in that PS3 commercial - gonna file this one under not an issue.
Related
I signed up for an iPhone development program last December hoping to develop an app but got carried away by other projects in my life. Now I get messages from Apple that my developer account is expiring in a week. I will not be able to post anything in the App Store for the next 6 months at least, thus the question -- if I let it expire now, can I renew, say, in summer of the next year? And, will it have any consequences on my apple ID?
PS. I currently do not have any apps in the App Store, nor that I plan on testing my apps on a real device.
Yep, you can renew/reactivate. Went through a similar experience myself.
The answer is no. There no consequences. You can let your apple Dev expire since you don't have any apps and not wanting to test you don't need it for now. When you get ready again apply and get another one.
This is a conceptual workflow problem. I'm converting an app with an existing user base from Paid to Free with an in-app purchase (FWIAP) to remove ads. The problem I'm trying to avoid is having the existing paid customers updating the app and now suddenly seeing ads and being insulted/assaulted with the "option" to pay again to remove the ads they never bought in the first place.
Luckily, I do have some breadcrumbs in the form of persistent data (pData) that will indicate whether the app was already installed. So my thought is to have the new version check for existing installs before deciding whether to proceed with displaying the ads.
One problem I foresee is later updates then considering all those first-generation users as now eligible for ads again, so I'd have to then add another persistent flag (pFlag) to identify the two groups of users and then hope to remember for even later updates (i.e. third-gen., etc.) to check against the pFlag instead of the pData, as the pData values would have long changed by then.
Does this seem like a sound approach or is there another good known solution to this?
The problem with breadcrumb schemes is with users who upgrade, or have to get a replacement device, and don't have backups to restore from. When they re-download your app, there will be no breadcrumb.
I don't think you'll ever be able to support cases where someone has bought the paid version and installs it directly from the app store on a new device or a device where the app has been deleted.
We recently had this problem in the opposite direction. We have a FWIAP app that customers wanted to be able to purchase through the volume purchase program, which doesn't apply to IAP. So we built a paid version and sell it as a separate app, and it generates as many sales as the FWIAP version, basically doubling revenues (so far).
I think the simplest approach is to just release a separate app. If you convert the existing app, the biggest risk is negative reviews, which could drive down your star ratings and thus downloads. So if you do take that route, I'd have as generous a customer support policy as possible--give anyone who claims to have purchased the paid version a code that lets them unlock the FWIAP version.
But that's likely to be a headache in the future, and from my limited experience, you may make more money by just having both versions in the store.
The paid to free-with-inapp-purchase workflow is supported; it’s referred to as paid-to-fremium and is discussed in the 2013 WWDC video:
Using Receipts to Protect Your Digital Sales https://developer.apple.com/videos/play/wwdc2013/308/
I have an iPhone application in the App Store. I submitted 1.1 to the app store a few days ago, and selected to "Hold for Developer Release." I found out that there is a very serious bug in the approved version. I need to pull this binary.
From what I can tell, Apple doesn't support this. I have sent them an email, but there's another bug in the current version that needs to be fixed also, so time is of the essence.
I've heard that you can release the update in some random country (where I would have no sales) and then release the next (fixed) update in all countries. If I only release 1.1 in, say, Luxembourg, is the old version (1.0) pulled from the other stores? Are the chart ratings reset? I'm relatively high in the charts, and I don't want to lose the momentum the app currently has.
Until Apple supports rejecting approved binaries, I'm looking for the quickest alternative.
Craig. Let me answer some of your questions. First, if you release an update, regardless of what country it is released in, it will replace the old binary for every country. Thus, if you only select Luxembourg, you are not only releasing the update to all countries, but also removing the app entirely from every app store except Luxembourg.
Second, it would appear that even Apple has no say over the iTunes Connect website in terms of altering the process for one person. I believe you should be able to reject an approved update, I don't see why they would want to disallow this. However, since they do not right now, it's best to forget about it.
You basically have 2 options. One, you can release this new version to the world, which keeps your standing in the App Store and warn users of the bug and promise them a fix. At that point, you can appeal to the Review Board for an expidited review, which they may not give you. Remember, if you release the update, I would upload another update immediately after.
You're not going to avoid your problem but there are things you can do to minimize the impact of your mistake.
Second, you can remove the App from Sale, accept the new update, and upload a new one for review, and put the app back up for sale again once approved. The problem here is that you will most likely lose your store ranking and the app will be unavailable for about a week. Not what I would do. I would go with the first solution.
From my experience, customers are ok if you need to issue a fix and they're fairly understanding. Make sure you tell them exactly what's going on in the app description AND the "What's New" section. Make sure they see it. They'll be ok with a few days of inconvenience in return for your honesty and reassurance that the issue has been fixed in a near-future update.
Hope this helps.
Cheers!
You can reject an app that is on "Hold for developer release". You need to click "Binary Details", and there you should find the reject button.
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.
I am going to ask users on public forums to take part in my app beta testing using ad-hoc method. So if user interested in testing/reviewing he sends me UUID and I send him app binary.
The main question: is it safe to give anyone app binary file? I heard some terrible stories on Apple iphone developer forums that some guy found his app published someone else using another company name and different icon. So the app was absolutely the same except company name and graphics. He told that someone else got his app binary, cracked it and post it on appstore for profit.
So is it possible to steal my app and publish it on appstore if I give my app binary using ad-hoc?
thx
Yes, as it is possible for the same to occur for apps that are in the app store.
There are tools that can unpack the signed binaries which can then be repacked.
In the same light, someone could crack Visual Studio to show a different company name and then release it as their own.
In both cases, there are serious legal ramifications, and in both cases it is actually very rare to occur.
In the case of iPhone apps, it is very unlikely someone would want to bother stealing your app. If you really think there is a risk, I wouldn't recommend sending ad-hoc copies to random people you don't know.
While it is technically possible, (IANAL) I believe such an act is a violation of the DMCA, giving you legal ground to go after them, any and all profits they make off of what they stole, etc.
If you feel that threatened, you can add an "expiration system" to your app. Check if the date is later that, say November 2009 and kill it. I don't think someone will go into the trouble of removing your code signing, signing it with his own identity after he has cracked the expiration failsafe. You app should be pretty awesome.
I've never heard of code that can't be decompiled/disassembled. I guess this applies to iPhone as well. So yes.
Yes, technically they can take the binary and resign it using their keys. They could do that either to install it on their device, or submit it to the store.
They won't have the source, so making any sort of fixes or changes (including to deal with a submission rejection) would be remarkably difficult, and it should not be to hard to prove a copyright violation and get it taken down (though you might need to pay some lawyers).
At the end of the day I wouldn't worry about it... this sort of thing just doesn't happen in practice.