I'm considering including some large movies in my app, but I don't want users to have to re-download the movies each time they get an update. When a user downloads an update from the app store, do they end up re-downloading the entire bundle? Or only parts of the app that have changed relative to their version (i.e. do updates only ship some sort of binary patch)?
The whole app. iTunes actually stores multiple versions of all your apps, and they are submitted to Apple as zipped app bundles.
The whole bundle, as submitted to, tested, approved and codesigned by Apple.
iTunes will delete any previous versions of your app.
If you have very large content that you don't want installed on every update, you might want to consider allowing users to download it from a website for offline use, and have the app store it in the app's sandboxed Documents directory, which should survive app updates (baring weird update bugs).
My experience is that large apps take a while to update. There are many ways Apple could theoretically implement a diff (and it's probably advantageous for them to offer a diff between the two latest versions, since it reduces their bandwidth bill), but as far as I know, they don't.
"Large" apps (>20 MB, currently) can only be downloaded over Wi-Fi. If you make your app big enough, that means users won't download the update until they get connected over Wi-Fi. Also consider that existing users have already paid you — I don't advocate screwing over your users (if only because they'll leave bad reviews), but taking a while to update apps isn't a big deal; that can happen as I sleep.
I'd worry about new users/initial installs:
New users won't be able to download your app unless they're connected over Wi-Fi. I'm not sure what the difference in sales figures is — I can't see it in our graphs (so under 10%?), but it probably depends on the type of app.
A lengthy initial install leaves a bad impression: They've never used your app before. They just found it on the App Store, decided it was worth buying/installing.... and now they have to wait.
If you don't mind running your own servers, then it's definitely worth considering.
Related
I'm making my first iOS app. And I have a question.In my app I want to save the current state of the app: levels completed, score reached, money, in-App purchases, etc. in a Settings.plist. The problem is, how can I place this plist so that if the user updates the app, he/she not to lose these settings. I read about The app sandbox, but I don't understand
how it works, and how can I manage that from Xcode.
You should store these settings in the NSUserDefaults. They are kept when new app versions are installed, so you won't have any problems.
Two points:
a) When you update your app after its in the app store by submitting a new version of the same app the files created by the old version will not be lost. So you can store whatever you like in the app's Document or Library directories and expect it to still be there after an update. The Library/Caches directory will not be backed up or restored by iTunes so don't put anything there that you can't re-create. If you submit a different version of the app (not an update but a new app, so you have two separate apps in the app store, perhaps free and paid) there is no way that I know of for the new version to get to the files that the first version created.
b) It's easy for the user to read, delete, or change whatever files you create in Documents/ or Library/. It can be done with an app on his/her Mac such as iExplorer (downloadable from macroplant.com). So be aware that if the file is human-readable, which a .plist file is, the user can change it to improve his/her score, get more consumables, or whatever. You can prevent that by encrypting the data, or somehow obscuring the meaning, or by some kind of checksum scheme so you can at least detect that it was changed. Any of those measures involve complications of course and may not be worth the trouble.
BTW... if you're developing an app that uses data files iExplorer is a great debugging tool. I have no vested interest in it except that I've learned how to use it and want it to continue to be supported. There are probably other apps that do the same thing but this one works great and is fast and easy to use.
I have to restrict a Free app from being downloaded or installed for a 2nd time on an iOS device, as I would like to user to purchase the paid version of the same. A first time user of the free App can download the Free App and install it on their iOS device, but after using the Free App for certain number of times, the Free App will work with limited functionality as I would like to promote my paid version, so I prompt the user to buy my Paid version of the App. At this time the user can delete my Free App and Re-Install the same from either the iTunes store or the iTunes on their computer or iCloud backup.
Question is how can I restrict the user from re-installing the same Free App on their iOS device a 2nd time ?
Is there any way to tell the iOS on the user's device to stop the 2nd time install of the same Free app ?
Or is there any other way to achieve the same results ?
Thank you.
You're unlikely to reliably get past Apple's review process with these restrictions.
Free/lite apps are supposed to be fully usable apps in their own right. So, using a todo app as an example:
You could limit it to ten TODO items
But you'd get into trouble if it stopped working after ten days
Clearly you can also limit in terms of what functionality you offer. My apps, for example, only allow editing in the paid version; the free one is read-only.
I'm not sure that you can reliably do what you want. (What about if I have to wipe my phone and restore from a backup? Does that count as reinstallation?) But even if you could, it wouldn't necessarily be a good idea.
i think the recommended way is to use in-app purchase. You can enable a full Version to the user when he buys it. So there is no reinstall needed.
I'm not sure why you have the requirements you do, but this does not fit the model of the App Store. You are likely to have your application rejected, even if you were to find a way to do this.
If you (or your stakeholder) are insistent in this approach, maybe the App Store is not for you.
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/
Is it possible to automatically force an update of all installations of an iPhone app without requiring interaction from the users?
According to this thread it is impossible to do so for apps deployed on Apple's public app store, but another more recent thread describes a way to at least inform users of updates, but still forces them to take action manually. With the Enterprise Program becoming available to most companies now (the requirement of 500+ employees has been dropped) can we hope to achieve it with the Enterprise Program?
The reason I'm asking is that automated push-updates of applications are a common demand and indispensable requirement by many businesses that use mobile devices. Blackberries have always won over iPhones in the past, because they had this feature while iPhones did not. Has the situation changed now?
Update: Apparently, there is another problem. Apple has a limit on the size of app downloads of 20MB over GSM which to my understanding also applies to deployment within the Enterprise Program. Unless all users consistently have access to a WiFi connection, this is another limitation that needs to be taken into consideration.
Update 2: I have submitted a feature request to Apple. Maybe it helps to expedite the improvements.
I don't believe you can force an update, though you can:
Remotely disable an existing app, if urgent, and
Design your app such that when it is outdated it alerts the user and provides a one-tap link to download a new version (technically two taps, one to load the web page with the app and one to install the new version).
It's not the ideal system you note would be so helpful, but it's an improvement over the earlier system where users had to sync with iTunes at a desktop/laptop in order to perform the upgrade.
I am developing an iPhone application which I need to distribute to an organization of about approximately 50 people, no. of users can increase or decrease in future.
I checked my iPhone developer account, there I got that I can distribute my application via Adhoc Distribution up to 100 iPhone or iPod touch users. So I think it should be best way to distribute my application to that XYZ organization.
On further searching I found that there is also an - iPhone Developer Enterprise Program, which is available to companies with 500 or more employees and a Dun & Bradstreet number.
So I want to know - which will be the best way for me according to my requirements ?
Also I want to know that say if I choose Adhoc distribution then is there any way for automatic up-gradation in it ie. to install new version of my application on user's iPhone or iPod without deleting the old version.
Thanks,
Miraaj
If you do not have something seriously wrong with your persistence frameworks, than you should be able to upgrade the app on devices, while retaining the data just by providing the users with a new version of the .ipa file.
Ad-hoc seems to match your needs best, but remember, that you will have to get the UUID of all 50 iPhones the app will be installed on. A bit tedious and time-consuming. Enterprise would be better in that respect, but you might not be able to qualify for it. It's also extra expensive.
I am not surer what you mean by deleting the old one. If you want to have multiple versions of the app available on a device, they will not be automatically updatable and data sharing will be very complicated. Ad-hoc might be about your best option.