We have an existing game app that is now defunct and is just sitting there doing nothing. We are considering if the new game app that we are releasing can be released as an update to the old one. The old one has nothing in relation to this new one at all.
I am personally against doing this, but do any of you see any potential problems that could be caused by releasing the new game app as an update for the old one?
Thank you!!
I'm going to leave the moral or business take (and the app store guidelines issues) on the sideline here, and just talk technically.
There really isn't much glue that handles app updates. All you need to do is use the same bundle identifier com.mydomain.myapp for the new one, and use a higher version number than the last release, and upload to the same "app" on the portal, and it should just work. The new version, that is totally different, should just replace the old one.
One case it may not work is if you have a lot of documents or local databases, or settings stored ont he phone, the new app will have to take into account some of that data if it uses the same keys or filenames. But if it's totally different app, that's probably not a big deal.
iPhone app store updates have very little magic. One packaged binary simply replaces the old one. The update could be a minor bug fix, or a complete codebase rewrite that performs a similar function, or a whole new app. There is no technical restriction.
Even app meta data like name, keywords, description, icons, can all be changed along with an update. Whether completely changing one app into another is cool with Apple though, I can't claim to guess.
Related
In my game, I'm planning to add IAPs for different level packs that the player will be able to buy and play in the game. But after reading documentations on IAPs, there's still one question I'm wondering : Is it better to download the new content from Apple's server, or unlock it in the game with NSUserDefaults?
The problem is that if I chose option 2, the content will be easily hackable, and the app will need an update for each DLC I'm adding.
And the problem with option 1 is that the new content will be downloaded in the Documents folder, but my app search the list of levels in the resource folders (I know it's not hard to implement, but I'm just saying the pros and cons)
Anyone can tell me which one is the best practice, and why?
Thanks in advance!
Well, I think both options are good. Whats the size of these packs? If you have numerous iaps all consisting of new levels, id recommend to have them downloadable, imagine shipping the app without the extra levels, quite a network-loadoff.
As you are stating, option nr 1 gives you the ability to add levels dynamically. This is convenient since apple are quite slow when it comes to uploading of new builds. Come to think of it, they are not super fast when it comes to revising your DLC either.
Due to the hacking risk and initial reduction of app-filesize, I would definately go with option one but if possible, i'd provide the actual content from a private FTP server. That way, the new content is available directly.
I'm developing an app with the option of in-app purchasing of audio packs, probably around 30 MB per pack, around 500 files. I want to start with say 10 packs available, and add new packs over time, maybe 4-5 per month. A given user is expected to have no more than 10 packs in use at any time. Here are a few considerations I would greatly appreciate advice / suggestions on:
Can I set the app up so that it downloads the audio files for a
pack only once the pack has been purchased? Or do they need to be included in the main bundle, with an 'unlock' feature being the way to get access to them?
Can I give the user the option of deleting the audio files contained in a pack which has been 'finished', of course with the option of re-downloading it later - it has been paid for, after all.
Can I set up the app, so that the list of packs available is updated without having to re-submit through the app store every time?
If I need to replace a single file in one of the packs - how do I push this update out to the end user who has already installed the pack?
If I go with the option of including all the words in the main bundle - and I want to add more packs later, can the iPhone retain the original content so users with the original version only need to download the new content?
Thankyou.
To answer your questions:
You can set it up so that content is downloadable from your own servers.
Yes, but you will have to keep track of which users have downloaded what. I believe there are API's the can assist you with this, such as MKStoreKit which you can find on git.
If the content is on your own servers, then you can just update that without having to resubmit the app. But you will have set this up intelligently so you can dynamically update the UI of the app based on info pinged from your server.
Not sure, but there probably is a way.
Not sure, but that does not seem like a logical approach, especially since you will be storing data on your own servers.
iOS5 Programming Pushing The Limits by Napier and Kumar provide a pretty good high level explanation on how this all works. You probably do need to do a bit of reading on it.
I hope this gets you on your way.
I am developing an app that has an sqlite file embedded inside.
That sqlite file is being copied to the /documents folder of the app, and contains the data of a specific version of a book (it's an advanced search app for a specific book).
I've also implemented an subscription service (via inapp payments) for that app, for updating the content. for Registered users only. Basically the app update will occur once a large number of update entries is fulfilled or a bug fix, so that the newer user would have to download a lesser number of updates.
The problem is that the old users have paid for a specific book. New users could pay for the extra book, at the same price (consider it an updated version). Is there any way to "forbid" the old users from having access to that book resources since they have not paid a subscription or the app at a latter time?
There are different types of inapp purchases: non-replenishable, replenishable, subscriptions, and auto-renewing subscriptions.
The user will always get what's embedded, though, if you don't track user status yourself (which probably is not worth it) - and then you have to deal with the problem of giving him that exact version.
The main question remains though: Do you really want to penalize your early buyers? Their money came to you first (so it is more worth than the current buy), and now they are left behind with less.
If there is really new content frequently, you might want to go the subscription route. Personally, losing my purchased data like a book just because you bring an update would leave you with one frustrated customer less.
A different route is to limit the support for that app to a specific date and then get your users to buy a new (different) App, maybe with making the first app cheaper during its final stages, and then removing it altogether.
You should aim to make your users buy as soon as possible. But with your business model, it is actually better to buy as late as possible, and often late equals never in practice.
Yeah I know there are couple of questions which are related to syncing with iPhone and Web DB but none of them helped me.
I also did a lot googling but I rarely found informations about two-way-syncing. Maybe I just used the wrong keywords.
I'm building an App right now and I came up with the idea to add a two-sync to my App and my Web service.
My first thought were that it would be ridiculously easy but it turns out to be not that easy at all.
I found couple of problems and some solutions to my problems but I would like to hear from you guys if these soultions would create other problems or if these solutions are good or bad.
The idea of my App is helping me sync my notes which I will take on the go with my iPhone and at work or at home with a Web App.
Those two ends should always sync'd cause I don't know on any time which device (iPhone or Computer) I will use to take, edit or just read my notes.
What I have on both sides:
For my Web service (and web app) I will use rails and I think mysql on the DB side.
On the iPhone I will use a SQLite DB with a Objective-C wrapper (FMDB).
Both will exchange data via JSON (using a JSON framwork on iPhone side).
My ideas so far:
Primary key has to be unique on both sides
As a primary key I will use a UUID. I think it's a unique solution on both sides and it won't make any duplicates (at least I hope).
Revisions for changes of data
Each change will be saved as revision with a SHA1 key, which I will create from date + note data.
The revision object is also including information like:
date
which note object belongs to this revision
changes are made on which device?
what chaged? (atually I'm not sure about including this information)
My "solution" so far is I will track every modification (create, update, delete) on a histroy-table with revisions on both sides.
On the iPhone side I will first update my history-table from Web DB and then commit my changes to the Web DB.
This should work, right?
That sounds not that bad to me but my question here is how can I handle conflicts? I don't want to bother the user with messages how to handle the conflicts.
Roundup of my questions:
Is my "solution" good or bad? What should I change to make it better?
How can I handle change conflicts so the user don't notice them?
Do you have any resources I could read about two-way-sycing?
EDIT:
Thank you all for your answers. I know now that I'm not alone with this "problem" and there is no simple and all fitting solution for all Apps. I assume that I'm doing good with my ideas or solutions so far and I will try to come up with syncing rules.
My idea so far is: I will develop it simple as possible and will use it for my own needs. Solve problems I discovered while using and syncing. After that I will invite my friends to test and solve problems they have.
I think this way I can came up with real world rules for syncing my data with Web cause I see what people are actually doing and where problems are.
What you think?
"It depends."
Everyone loves that line in their answers.
Two way sync boils down fundamentally to conflict resolution. And only you as the application designer can come up with the rules for conflict resolution.
Without conflict, syncing is easy.
One way syncing is "easy" because it's just like two way sync, save that the rules for conflict always favor one party. "Make this look like that." Simple rule.
Fine grained two way syncing isn't that hard, you just need to record the specific changes that are made and when they are done, then when you sync, you take that log of changes from each party, combine them in to a single log, and then apply that log to each party starting with the last time they were in sync.
By specific changes I don't mean "record changed", as it's too coarse. Rather you want to know that "lastName" of record changed. It changed at 01/01/2011 12:23:45.
When party A says lastName changed to "Johnson" at 01/01/2011 12:22:45 and party B says lastName changed to "Smith" at 01/01/2011 12:22:46, then "Smith" is the right answer, since it's the latest.
But wait, did you see what happened there? I just pulled a rule out of thin air. "Latest wins". Maybe that doesn't work for you, maybe you have different rules. "It Depends".
So, really, it all comes down to the rules. You can make it as fine grained as you want. There will ALWAYS be conflicts. That's what the rules are for.
So you need to decide what those are for you application.
actually i consider that the only problem in any kind of two way syncing only happens when there are conflicts. Really. Take for example any version control system (svn, cvs, git, etc.). They solve this conflict more granularly because they split the file itself, and they are checking for line conflicts, so changes in two different parts of the file are not treated as conflicts.
However i suppose this solution would not be really feasible because it's a pain to implement it :) ...
If you decide to handle the conflicts at the level of notes, and not it's lines, then probably at the end of the day you need to come up with some business rule that defines what happens when there are changes that result in conflict.
Possibilities:
Use the last change. Override the older. This is easy.
A solution what Dropbox uses i've seen it a couple of times when we were changing the same document on multiple machines is, that it creates multiple files appending a suffix to let users know about the changes on the multiple machines. Something like this you could do easily with notes as well.
I'm not sure i've helped though ...
Moszi
I'm scratching my head over this.
I have a moderately successful app which has a free "LITE" version in addition to the full one. This is a utility app, not a game with levels, and I'm having trouble figuring out what Apple will accept for the lite version. The reason this is now an issue is that I've brought both code bases together with different targets and my new improved lite version will be iPad compatible as well.
There are two fundamental differences in the versions. In the lite version, the data displayed is only displayed for the current day, whereas the full version allows users to choose any date. Additionally, one of the data screens shows 3 data points in detail, whereas the full version shows much more. The lite version is perfectly functional in its own right and has no greyed out features.
What I would like to do is use the spare space on the lite version data screen to explain that more data is available in the full version and offer a button to upgrade, however I can't figure out if Apple will classify this as "upselling" (well how else am I going to mention the full version?) and from reading the new app store review guidelines, I was disappointed to note that absolutely no further clarity seems forthcoming from Cupertino in this regard. All the examples I find from Apple are games with additional levels and this simply doesn't match a "utility" application.
Is there any recent advice on what is and what is not allowed? I'm aware of not having greyed out functionality and nagging the user - but does having an upgrade button on one of the tabs (in the case of the iPad in a popover) count as nagging? Am I allowed to mention the additional features in the premium version or does that count as upselling? If not, what can I actually say?
Clues welcomed!
Frankly speaking, there is no way to be 100% sure without submitting the app. There might be someone who have already tried this and get rejected. It's not very easy to be sure. But as a user personally I won't be happy to see the upgrade button in every page. Rather I would like to get the summery of full version in a different page. This might not be a better design to have an upgrade button in every page, though this is my personal opinion. Apple gives importance to be consistent with the convention, and the convention is to have different upgrade page, I think.
You can download a number of lite apps and check whether any one has done this kind of thing. The policy should be same for both game and utility. If after checking many you don't find a single one, then you should reconsider this. But yes, you can't be 100% sure.
The rules appear to be inconsistently applied.
I think it boils down to the perceived difference between "Ha! You don't get $feature unless you pay us!" and "By the way, we also offer $more_expensive_app with more features." The two are effectively the same thing, but they leave a different impression. Yes, it's a big grey area — I've seen apps across the spectrum (I don't recall any persistent nagging/mentions, but certainly "buy $full_app to get more levels").
"Other apps by $company" might be a good way to go, perhaps in an "about" tab or similar.
Reviewers are also far from consistent. Before Apple did any "private API" checks (they didn't seem to until mid-2009; apparently not even the frameworks you linked to which is dead easy), private API usage was determined by whether your app did anything in $list_of_suspicious_behaviour, which seemed to be applied inconsistently by different reviewers.
I've also used "$full_app" because that's the impression I got; I think part of the guidelines is that you're not supposed to give the impression that your app is not "full". I also hate crippleware (artificially limiting a feature, e.g. a navigation app limited to 8 waypoints and telling you to buy the full version if you want more, as opposed to simply not including a feature), but Apple doesn't seem to mind.
Apple allows ads in apps if they are presented in a reasonable manner.
Developers can choose which ad network to run, even from competitors such as admob.
There's nothing to say you can't be your own ad network.
Just make sure your ad for your products (which occasionally just so happens to be an ad for the full version of the same app) follows the same presentation rules as the ads for admob, iAd, etc. follow. Your own ad network may or may not be the campaign you choose to run during the review period.