We currently have an iphone app in the app store. We release version updates periodically, about once every other month or so, sometimes more often. Most of the times, the updates are not large, just added bits of functionality, bug fixes, etc. Sometimes however, there may be major changes (so far it had happened once, about a year ago and it's about to happen again).
When major changes do happen, ideally, I'd like to get the users to update to the latest version. I know that there's no way to automatically install the update. As the app communicates with a web service to receive its data, I can use that service to check for the latest version and, if it's not the latest one, I can alert the user that a newer version is available and prompt to update. If the user chooses not to update, I have to options: (1) let them continue running the older version, or (2) effectively force the user to update by blocking the app functionality if it's not the latest version.
As the app requires back-end web-service, usually for major app updates the back-end needs changing. Sometimes these changes render the back-end incompatible with the previous version of the app. The previous time this happened, I had to set up a separate back-end for the new version (I now have to two web apps running on the server: for v.1 of the app and for v.2). While theoretically I can continue doing the same - setting up v.3 and so on, I would much rather prefer not to and force the update on the user.
Now, technically it's quite easy to set up. However what is Apple's view on such behaviour? Could they reject an update because of this? Any experience on this front? Thanks in advance.
It depends on the time frame of your transitions. We have a customer who exactly required the behavior you describe. We can send the client application two signals: should-update and must-update. When the client receives must-update, it will no longer allow the user to run. We have transition periods and tag the breaking changes, so maybe the active backends right now are e.g. V6, V7 & V8. We give users enough time to transition.
The Chase bank app forces you to update when an update is available (or else you can't log in). I think it's pretty annoying from the user's perspective, but Apple has certainly approved updates that do exactly what you're describing.
Related
I would like to restrict online gaming features inside an application, ONLY when there is an update available which impacts the online game code/engine. I know I can disable the online gaming features if the string in [[NSBundle mainBundle] objectForInfoDictionaryKey:#"CFBundleShortVersionString"] (referenced from question here) is not equal to the most recent version in the app store. But if I release an update that does not impact the online gaming experience I do not want to disable the online features.
Does anybody have a creative way to "tag" a release so that I can detect whether the update has an impact to online gaming? Would adding a subversion be the best way? I.E. updates with online features change subversion level 2 (1.2.1) and non-online updates change subversion level 3 (1.1.2)?
As a note, I disable the online gaming features when updates are available in case the update has changes to how a packet is sent or a fix to the scoring engine etc.. so I don't encounter a scenario where an old version is playing a new version and the messages don't match up. (I have also considered using Game Center Groups to make sure you are playing a player from the same app version, but ultimately decided that getting users to upgrade is a better plan)
I would go about this by having a list of valid versions on the server in the form of a whitelist. When checking if the user can be online (for example, when they hit the Multiplayer button), just ping your server including the user's bundle version and have the server return a simple response which denotes whether the user can play based on the version number that they submitted.
I do something relatively similar on an application of mine to push actual code updates to a client based on the version of the application that they are running.
I'm facing this problem while designing my iOS app. Suppose that a user purchases an app and downloads it to the iPhone. I would like to provide him with a default consumable item the first time he runs the app to use whenever he wants , however I would also like to track if the user has already consumed the item. This way if he decides to reinstall the app we can restore the transactions (if he used the item) or we can avoid possible intents to download different kind of content by reinstalling app and consuming default items each time. (Guess NSUserDefaults is not an option here).
One approach that came to my mind was using UDID(or any iOS 6 alternatives) to keep a record on server of the user's device the moment he uses the default item. But this will limit items just to the device from which they consumed content.
It would be great to support all the user's devices (like inAppPurchases), but I can't figure out a way to implement this.
Any suggestions or help would be great.
Thanks a lot.
In order to tie information to a user (not just a device she used at one time), you'll need to ask the user to identify herself and save it someplace other than the device. In other words, a backend that implements registration and login.
From scratch, this can be a lot of effort that an iOS developer didn't count on. Fortunately, there are several services in the world that provide a substantial head start. Here's a nice round-up. I've had direct experience only with Parse.com, and think it's excellent.
How often I can update mobile application on App Store? Can I update every 2-3 days?
Thank you.
Highly unlikely.
Apple's review time for a completely acceptable app update varies from less than 2 days to over 2 weeks, and a developer has no control over that length of time. That will limit the rate of updating any app to Apple's pace. Trying to update more often than this will put your update back at the end of the queue and slow down your approvals, and thus App store releases even more.
Somewhere, maybe a developer's talk, they may have recommended non-critical (for bugs) updates no more often than once per month.
For more frequent updates of content, see Apple's WWDC 2010 video on data driven app design, and consider having the app update certain content from your web site.
Not really.
It usually takes Apple 7 days to review an app and if you upload a new update before the old one has been reviewed you go to the back of the queue. If you need to update your app more frequently than every ~7 days you should look into setting up a web-based update mechanism. Obviously, you won't be able to update any code this way, but you can update content as much as you like.
No you cannot change it every 2-3 days, because there can be only one version in review of a given application. If a binary is submitted for review and you upload a new version, the old binary is thrown away and the review process starts over with the new version.
So you loose your position in the review queue each time you submit a new binary while the old one is already submitted but not accepted yet.
If you want to, yes. But take into consideration, that it will take some time for your applications to be reviewed by Apple.
I've been developing an application for our client and they are requesting that we add in compulsory updates for their application. The app allows sales-team members to showcase their product and they are worried that if a product gets re-called then the sales-team must reflect this in the app immediately or else there could be legal implications for the company. How feasible is this to implement? Are there any examples of this in use?
Cheers for the help guys,
Dan
The way you could do this is to get the app to call the server and ask for the latest version number. If it's different then stop the app and tell the user to upgrade. However, this won't work if they start the app without a network connection :)
I also don't know if this will be allowed by Apple?
A better way to do it is for the app to download a list of products each time it runs (cahcing it incse it starts with no connection of course!) so that the products in the app are always up to date and the users never need to upgrade at all.
I need to implement trail period in my app. How to do it? Store day count in NSDefault? or some other?
You could store a counter in the preferences as you mention, although that counter would disappear if the user reset their phone.
However, I think it's all slightly besides the point. In general, Apple frowns upon apps that have this kind of functionality, so don't be surprised if your app gets rejected. Consider launching two different versions of your app instead, a "Lite" app and a "Full" app. The Lite app should have a reduced feature set, but it should never stop working.
Apple is against the idea of you disabling features to prompt people to pay money for something. Your app needs to be fully functional and a 'lite' version and a paid version seems to be how things work at the moment.
That being said - if you implemented it properly you could add in app purchase items to enhance your app. Your original 'lite' app could be $0 and additional features can be added for a fee.
The most bullet-proof method would be to send and maintain a copy of the iPhone's UUID in a database.
Then if the App is not "unlocked" it requires a "key" form the database every time it launches. You can then implement the trial period on the server side.
However, if you decide to use some type of encryption to store or transmit keys etc you will need a licence to distribute the App.
You make a light version of your app. There is no official way to have a trial version at this time. Hopefully Apple will eventually address the need, but I can't say I would hold my breath...