This question is for those familiar with implementing the iphone in-app store functionality.
The app I'm building has only built-in features that are unlocked when features are purchased. Further, any modifications or additions to store items will require an app update. Also, it is only in English so has no localized languages for the items.
If we take those assumptions, is it feasible to skip the step of retrieving the product info with SKProductsRequest and simply use hardcoded data within the app? While I may want to extend my app to greater complexity in the future, I'd like to know if this step to keep it simple would introduce some serious issues.
One issue might be, for instance, if we have to expect a few of the items to occasionally be unavailable due to issues on Apple's side and simply trying to purchase it and letting it fail would not be a permissible or workable option in that case (especially if it is uncommon).
Thanks.
I suspect that Apple would object if you used hard-coded prices in your app, although I can't say for certain that they'd reject you.
Bear in mind, however, that localization isn't just about languages. It also gives you localized prices. Currency values fluctuate, so we can reasonably expect the localized prices associated with a given tier to change from time to time. The possibility of getting money from users in Canada, UK, and other territories beyond the USA seems like ample justification for using SKProductsRequest, whether it's technically and contractually required or not.
Related
I made a game that I would like to publish on the paid PlayStore.
I was wondering how I can protect the characters I created from
being used by other people in their games.
The word "Verification status" appears on Google API Developer,
should I fill in the fields that I am leaving empty (See photo)? If yes, can you explain in detail what and how to do it?
Could I publish the game anyway?
I thank you in advance for your availability.
To my knowledge there is no reliable approach that would protect your game resources - that being graphical assets or your source code. You can probably make it a little bit harder to read by some obfuscation mechanism or some sort of encoding that will require a special key, but overall it's not worth the time. Just take a look at big titles being cracked and pirated in spite of the fact that the companies that are producing them have millions of dollars to their disposal.
Besides remember that all resources you create belong to you. You're the owner and creator and it is yours intellectual property. Using them without your consent would equal breaking the law and you could always seek for compensation on the legal route.
It all depends if you're using those oAuth etc features in your game
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.
I was just wondering about the pros and cons of submitting metadata and changing the UI buttons for people who don't speak English.
According to this study there isn't a huge percentage of users who go to stores that aren't in English (all the smaller countries have stores in UK English).
That said, I was wondering if maybe there is some advantage to this? For example, if I submit to the French store I would assume there are less apps with metadata in French and so therefore you might have a better chance of getting featured.
Keep in mind my app is super simple with no network activity and only a couple of buttons I would need to translate.
PS please forgive me if this is not an appropriate question for this site. And feel free to vote to migrate.
There is no disadvantage of providing localised versions of your application. It's probably more a question of knowing your target audience.
Generally one should assume that in a country, which official language is not English, people don't speak English. Of course there are exceptions like Germany were a lot of people do speak English. But usually they still feel more comfortable using their native language. Following your example, French traditionally have a very strong opinion when it comes to languages and will appreciate a French localisation.
Besides users by country you should also take into account the area or business segment you're targeting. Just to give an example: an British pub guide obviously is targeting English speaking people. If you're creating something around renewable energy it could be worth exploring a German version besides an international English one, too since it's really popular in Germany and also supported by government subsidies.
If you can reach your potential users in English a localisation might not be necessary. But the lack of localisations will make it definitely harder to advertise your application. I can't think of an non-localised app have been featured on the German App Store. This might be just bad memory but Apple points out the importance of localisations many times in the documentation.
Since you mentioned your application doesn't actually have that many localisable elements it might be worth the effort anyway. Even if you decide not to do so for the initial release it's worth building your application with future localisation in mind to add localisations in later updates. See that post for more.
There is a disadvantage, and it is that once you add a language, you will be expected to continue supporting it in future releases. It's not nice for someone who uses your app in say Chinese to install an update and find that the app has reverted to English or that some new features are not translated. But in order to continue supporting a language in future releases, you'll have to get new/changed content translated which will cost you (assuming you are paying a translator) and delay your release a little. You'll also have a bigger testing burden.
That said, localization is a great way to attract more users.
I am planning to create a stock based app for iphone. It's going to be a paid app. So I wanted to know what options do I have for getting the data from API.
I have heard of Yahoo finance api, but think it is not free for commecrial use.
What does Apple use for their native app. Could you please provide me with other options.
Thank you.
Getting fast reliable tick data is going to be very expensive, especially if you want every tick. If you want any kind of order book depth, it's even more expensive.
You might want to investigate LMAX who offer a free API. I think they are the same company that do Betfair in the UK. I'm not sure what markets they offer, whether you can use it outside the UK, and whether the prices on show are actual exchange traded prices, or from their own user generated markets, but it might be of interest...
For historical data (historical stock quotes, historical financial statements, historical dividends, etc), you can use the APIs at http://www.mergent.com/servius
(EDIT: The API can deliver historical ratio information such as P/E ratios, but that feature is still undocumented - will be documented soon).
(EDIT: There's also http://www.zacksdata.com/zacks-data-api . By the way, as a disclosure, both APIs are managed by my company).
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.