I'm doing iphone application which has two versions Lite and Full.
People who uses lite version has the ability to save images etc.
When they download full version, i want them to access the saved images etc from full version.
Is it possible to pass the data from Lite to Full or version or is it possible for Full version to access data from lite version or some solution.
There is one such application in itunes app store which is working similar to what I'm expecting.
Related
I have an app on the App Store. After the first version, I decided to create a free Lite version of the same app.
I've followed the instructions all over the web to create a multi-target application and I managed to install both version on my iPod.
What is the correct procedure to upload both my apps in the app store? Should I create a new app, named "Myapp Lite", and upload the binary as a completely different apps or maybe is there a way to tell Apple that those two apps are fundamentally the same?
If your lite version is a separate target, it's a separate product in iTunes and you have to do all the same steps as for the regular version.
The only alternative would be to make the lite version the only product and use in-app purchasing to upgrade to the full version.
You will need two create to app, one 'Lite' and one normal one.
yap you should create a new app, named "Myapp Lite", and upload the binary as a completely different apps. If you upload as same app it will be considered as newer version.
I am developing a messaging app. It uses an SQLite database to store the user's registration. It also uses push notifications. Right now I am using a development push notification certificate.
My client now wants a "Lite" version to be built, and I am not sure how to go about it. I have read several articles on Stack Overflow and elsewhere. I am confused by all the versions I have read online.
Can anybody suggest to me what to do, specific to my situation? I don't want to lose the registration data in the database while updating from Lite to Paid version.
One more question: when someone downloads a paid version of an app, will it install as a different app or will it overwrite the existing Lite version? I am guessing it depends whether you are using a separate app ID or the same one, but I am not sure.
Please help.
Thanks.
To your first question, what I do is just create a second target in my Xcode project. One for the Lite version and one for the paid version. Then I create a preprocessor macro for the Lite version in the Xcode build settings for the Lite target. Usually I just do LITE=1. Then in the code when I want to do something different for the Lite version, you can just do
#ifdef LITE
//lite version
#else
//paid version
#endif
And for your second question, the paid version will not overwrite the Lite version. It will be installed as a different app.
EDIT: You should consider having just one free version and providing the "paid" features via an In-App purchase. This would allow the user's preferences to migrate over from the Lite to paid version since it would actually be the same app.
I managed to finish upload my first iPhone app to Apple's App Store couple of days ago. My app is based on Core Data so it contains users' data to their devices.
What I want to know is that what happens when I upgrade the app with or without altering Core Data? (altering means add new entity or property, etc)
From my experience, I downloaded my own app from Apple's App Store and saved some data and then I install the same app from my computer using XCode with slight change to interface that has nothing to do with Core Data. When I turned on the app, the data is all there.
Is it safe to upload an upgraded version of iPhone's app to Apple's App Store assuming that as long as we don't touch Core Data, user's data would not be influenced?
If you change Core Data model, it may need to migrate/update its scheme. Apple has the appropriate documentation. The work necessary to perform a migration depends on what you change.
I am developing an application and i want to distribute it via over the air (which is introduced in iOS4 for enterprise apps).
I am able to send my app via OTA successfully, but i am facing a problem while upgrading the app.
I am using the same bundle identifier for the app upgradation and i am just changing the version of the app before building the application.
But, if I install the updated app on the device using OTA, it is upgrading the application but it is not retaining the data. [my app contains some downloaded pdf files which i am storing in NSCachedDirectory]. I am able to see the archived data in upgaraded app but the files which i have written to NSCachedDirectory i am not able to see.
I have tried using NSDocumentsDirectory as well, but i am getting the same result.
can anyone please help me in this.
Why don't you use the amazing www.testflightapp.com to help you?
It works pretty well, keeps data for upgrades, and you can use it together with iVersion, so you don't need to send emails to update your users.
I am near the end stages of developing an iPhone application and will be releasing it as both a 'lite' (ad-supported) version and a 'pro' (ad-free, likely with additional functionality at some point) version.
I've followed suggestions here and elsewhere about creating multiple targets, etc. and am able to build these without any problems.
But this does bring to mind a question: What is the best, most user-friendly, accepted way in which to handle transitioning from a lite version of an app to a pro version?
As I see it - and please correct me if any of my assumptions are wrong - there are potentially two ways to do this:
Give each application its own Bundle identifier (ie. com.companyname.fooapplite and com.companyname.fooapppro). This will result in both being treated as being completely separate entities. Data is not automatically migrated should a user move from one to the other and both could very well have both installed on the same iPhone at the same time.
Give each application the same Bundle identifier (ie. com.companyname.fooapp), so that they are treated as essentially the same application. The lite version of the application will be overwritten by the pro version if they download and install it. Data from the lite version is maintained in the pro version.
The latter seems ideal to me - I can't imagine someone wanting to keep a lite version after they've just purchased a pro version - but this brings up a few questions:
Does Apple even allow option #2?
Will using option #2 result in any goofiness I should be aware of, ie. the two versions stepping on eachother in some way.
If it's not allowed, is there a suggested practice in place to migrate data from what are basically two completely different applications? I'm aware of StoreKit, but it isn't supported on free applications.
As it is, this current app doesn't really generate data of huge value and the worst thing that will happen is users will have to re-enter some authentication credentials upon upgrading to pro. But down the road, if I were to develop a similar app that stores valuable data locally, I'd like to know how to best transition users and their data in a seamless manner.
Thanks,
Jeff
One more option is to exchange data from the Lite to the Full version via a URL. Register a myFullApp URL with the full version and have the Lite app present an upgrade option that calls that URL with the various data you want to exchanged encoded in it.
That does require the user fire up your Lite version and hit a button, but it's fairly simple too.
I have not tried this myself, but a third option to exchange small amounts of data is to use the Keychain API. Apps that share an identifier stub -- com.companyname.foo as a parent to com.companyname.foo.fooapp and com.companyname.foo.fooapplite -- can supposedly write to the keychain from one app and read from the other. Haven't seen this done, but a lot of people claim it's possible. And in any case, the keychain is probably a good place to be storing things like authentication credentials.
Option four would be to have the lite app store some user data on a server you operate, and have the full app retrieve it from there, but there are all kinds of problems with that approach.