I just got rejected on my Free app from app store. I uploaded 3 apps, HD(iPad), PayedIphone and freeiphone. In the free-version I had a link to the fullversion.
Apparently I need inAppPurchase in the free-version rather than linking to the fullversion.
How should I implement this in the easiest way? All I want is a button that says Buy full version and then the free-version becomes the full version. Is it possible to use just those two or do i need to create another full version for this purpose.
I have no idea how to make the inAppPurchase except the tutorials Google give me, any recommendations or example code I can use?
I found this site very helpful in setting up an in-App purchase:
http://troybrant.net/blog/2010/01/in-app-purchases-a-full-walkthrough/
I got it working after watching this tutorial on u-tube. I can really recommend it.
http://www.youtube.com/watch?v=xGDGO5P95Dg
All you need is this: http://blog.mugunthkumar.com/coding/iphone-tutorial-%E2%80%93-in-app-purchases/
By far the easiest In-App storekit to implement... He walks you through the whole thing and then there is a link at the bottom with the source code zip file. Make sure you read it and get a good understanding. Rule of thumb: Never implement any one else's source code without understanding it first. You will save yourself a lot of headaches with debugging later.
Remember though: Now you have to build in a network check to see if a network exists prior to them clicking the "upgrade" button or else your app will get rejected once again. Luckily, I have just the thing for you: How to check for an active Internet connection on iOS or OSX?
Also, I agree that NSUserDefaults are the best way to go, and luckily that source code link above does all of that for you! It seriously doesn't get any easier. Props to this guy
No way. The proper way to do that is to include all the functionality of the fill version in the free version and only unlock those functionalities whenever the user buy your inApp purchase item.
start by attentively (details really matters when inApp purchase is concerned) reading the inApp purchase developer guide at developer.apple.com
There is a sample project here..
http://www.theapptree.com/samples
Related
After making an update to an iPad app I released some time ago, I've been getting reports that people are unable to actually update the app without deleting and re-installing. However, as far as I know, nothing in the update should be causing this. (All the update deals with is letting people email PDF documents, nothing major.) When people attempt to update, they're asked for their iTunes password, but after entering it, it merely goes back to the update screen and nothing happens. Additionally, it would seem that this only happens with my app, the people in question aren't having any issues with the other various apps on the App Store. Does anyone know what might be causing this and how I could fix it?
Thanks in advance!
(Also, if it matters, the app is a custom B2B app, the general public can't purchase it.)
I'm removing the text of my answer because it's so inaccurate it's embarrassing. I mistook "B2B" for "Enterprise" and answered based off of that. To make up for it, I'll look into the problem a bit more and if I find anything I will edit this answer accordingly.
Edit:
Okay, I can see why you put a bounty for this question on SO; there's not really any data on a problem like this anywhere. Frankly, there's not much available information on B2B in general. I'll post what I found anyway, in case it can be of any help to you.
I found the details reason behind Maggie's question, there. Per Editing and Updating App Information:
Updates keep the same Apple ID and bundle ID, which means they are
associated with your first version and free to your customers
Also, apparently, "You can't change the CFBundleIdentifier of a released app if you want to release updates for it, the App Store will automatically reject it when you upload." which is something I can vouch for, having experienced this with a normal app. I do know that for a B2B app you do have to submit it to Apple for review, but I can't tell from the documentation I found if you need to actually submit it to the App Store, so it may not go through the various checks that normal apps go through, so this could be your problem.
Aside from that, according to the VPP guide, if your customers are installing the apps on the devices with Apple Configurator (broken right now, per app store reviews) the updates also have to be done with the Configurator. You haven't said that Configurator was involved, but I did find this tidbit.
• Use Apple Configurator to install apps on new or supervised devices.
Apple Configurator on a Mac makes it easy to mass configure and deploy
devices that are centrally controlled. Redemption code spreadsheets
acquired through the Volume Purchase Program can be imported by Apple
Configurator, tracking the number of apps installed on each device. To
update deployed apps using Apple Configurator, you must reconnect to
the same Mac from which the apps were installed. Learn more at
itunes.apple.com/us/app/apple-configurator
Anyway, good luck. Wish I could be more help.
What you are describing (assuming that it is accurate) would certainly be a bug on Apple's side. If users are trying to update the app and the update is not being processed, then in one way or another that is a bug that Apple needs to address. Nothing that you do as a developer should be able to cause that situation to happen. I would suggest contacting Apple and possibly filing a bug report.
It seems that apple wants you to develop the Iphone apps in the latest build. Sometimes this cause issues between realeases (diferent versions of Itunes, OSX, IOS, etc) when you try to update your apps.
Try to publish the app in the latest version of xcode.
That happens a lot in iphone development testing.
Hope this help.
When updating an app, iOS looks for the bundleId and if there is another app with the same bundleId, it updates the app with the highest version number. Maybe the version number is not set correctly or maybe people have issues because an other app (from the AppStore or an other B2B app) have the same bundleID but a higher version number.
I'm by far not an iPhone expert, but it seems something related might have been fixed in iOS 6.0.1.
Fixes a bug that prevents iPhone 5 from installing software updates
wirelessly over the air
I am trying to submit my first iPhone app that has in-app purchasing features. Needless to say, I have been banging my head against the wall for a while. I have read through several tutorials, such as: http://troybrant.net/blog/2010/01/in-app-purchases-a-full-walkthrough/ and http://blog.mugunthkumar.com/coding/iphone-tutorial-%E2%80%93-in-app-purchases/ but it seems these are outdated? For instance, I can't find where the developer is to reject the submission on iTunes connect.
Additionally, I am submitting the app the in-app purchase features included in the bundle(I don't have them stored on the server- I just want to unlock the code when the user purchases the feature). What is the best way to do this?
Thanks!
Some of the information in the linked tutorials is in fact outdated: I could create in app items in iTunes connect without having to submit (and reject) a binary first. Just be sure NOT to submit your items for review while you are testing. Also changes to the items (e.g. price tier) have been processed almost immediately and I did not had to wait 24 hours.
To unlock your feature, you may use storing and retrieving the purchased status in NSUserDefaults . But this could easily be tempered with by users with jailbreak or acces to the apps folder. Have a look at http://maniacdev.com/2011/08/open-source-ios-keychain-wrapper-for-easily-securing-user-data-for-your-app/ . This offers a simple way to store data in the keychain. Still this will not prevent someone to 'hack' your app and enable the purchased feature without actual purchase, but it's not that easy...
In-App Purchase development is definitely a pain point in iOS development - their sandboxing model for this is ridiculous.
Needless to say - the articles you're reading are still up to date. The developer reject is definitely the way to go (I think can do from within the binary details). One thing to remember is that you need to have accepted the appropriate contracts and tax schedules also - if you haven't then the store "just doesn't work".
One thing that caught me: when you submit your final version of the app - make sure you tick the in-app purchases to be included; else the in-app purchases won't be reviewed (and accepted)!
Update: Although it's pretty long... you may want to flick through this: https://itunesconnect.apple.com/docs/iTunesConnect_DeveloperGuide.pdf
Explains how to developer reject etc.
I want to use "in app purchase" for trial version of my application. But I don't have a clear idea about "in app purchase". My problem is how to implement "in app purchase" in my application and uploading process. I have already uploaded a full version of the application. Please help me.
Well, the best way to understand the InApp process is to read the Apple rules about it at http://developer.apple.com/ Everything about how to implement it in your application is described over there. See for example: https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html
I have successfully implemented In App purchase and i would strongly recommend this excellent blog.
It really helped me to go ahead with successful implementation and submission.
Cheers
Sir i had developed an iphone application and released on cydia, which i seen it to be cracked in with in a day, later i came to know about the DRM , can any one please help me how to intehgrate DRM with my application
Thanks in advance
I agree with BoltClock, its semi-pointless to have app protection in your app, I have several in Cydia. With my largest app, I do have my own implementation of "security". I wont give away my secret, but there's a way you can check against the Cydia Store API to see if your app has been legitimately purchased. Get with Jay Freeman (saurik) on how to obtain the API for this. He has written up a few guides on his backend API for Developers to check if the app has been purchased.
Alternatively, you can provide a "Free" version of your app, or a "Trial" to allow users to try your app, and if they like it, they can buy it.
A time-sensitive feature may be useful too, that is something you can look into.
This link shows a video where an app upgrade is "forced" from within the app itself:
http://buzzworks.de/blog/update-ios-beta-apps-from-within-the-app
The App Store is not called in and it's said to work only for AdHoc
apps.
Anyone knows how is this possible?
edit: please give a look to the video before answering. AdHoc apps are signed by the developer and they do not come from the App Store. This sort of forced update is useful when doing beta testing and in enterprise applications.
I've found that it's all explained here:
http://developer.apple.com/iphone/library/featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html
The developer should create an .ipa with the app and a manifest in plist format with the URL to the .ipa and a few other things.
The app can optionally implement its own way to find if an update is available and open
the URL to the manifest.
I didn't it's really possible because the app has to somehow sign itself. The best I can think of right now is that the app is not signed?
You can always force people to go to the app store when a new version is out. Simply make the app connect to a webservice first. Other solutions are not accepted by Apple, or will quite simply not work because of other issues (signing is one of many).
You could also design your app in such a way that forced updates are never a requirement. You can load your user interfaces from the web (Apple has presented some valuable information about that during the previous WWDC), your data can come from the web, and if there is any other correction to do just ensure your app is backwards compatible.
That's how the app store works. And it never requires a 'forced update' ... Well, almost never ;-)