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.
Related
Let's say I have the following app (just a stupid example) https://tenant-eight.vercel.app
In words: A customer can see a business name and the address. He can leave a like, that is stored in a MySQL database. The app will send a email in the background to the business owner.
I want to sell that app to clients (b2b), so that they can collect votes on their own.
Let's say I have 100 clients. I would store the company configuration (database api url, company name, address...) in an .env file. Then I would build 100 apps. I need 100 domains, 100 web spaces, 100 databases and so on.... How can I make my life easier?
What is the best approach to realise that with less scaling issues, update maintenance, and so on? (each customer will always have the same latest code - no customer specific features).
Well, a method is just selling your apps source code and relax. Don't want it to get stolen? Two ways (both are sh#tty in an aspect but.. welcome to selling closed source things :p)
Obfuscate the code, which will make it much slower, but not a single soul will understand it unless they are a real tech-savvy person. Clients may also feel less secure.
Make a licensing system with a private npm project, and give out license codes to activate the website (no source code will be given)
I see that many iOS games nowadays don't hardcode their store, and items, description, price etc. are loaded from an external server.
What would be the easiest way to implement this? I am a game programmer with very little experience in server side programming. (Have done hobby PHP scripts a long time ago)
Please let me know what libraries can ease the effort on server side / client side. I would like something that is easy to manage. How do they announce offers like 50% off on certain items etc. whenever they want? Doesn't every in-app purchase manipulation need to get approval from Apple?
Also I would want to maximize security, and prevent the game store getting hacked as much as possible.
You are correct that this has to go through Apple's IAP. You'll want to read about this at https://developer.apple.com/appstore/in-app-purchase/index.html. You setup the IAP items in iTunesConnect (iTC). Your in-app store lists only items that you've setup in iTC, though you can choose not to list every item in ITC. To make your store dynamic, the easiest way is probably to use a UIWebView and then have your store be a series of webpages. This lets you update it on your server easily.
You might check out http://stackmob.com which makes it relatively easy to do just the store part of your in-game store without having all the server admin aspect of it (and associated security). Also, http://urbanairship.com provides hosting for IAP items.
We are looking at building a b2b application for the iPhone. A major concern is the possible delay in publishing updates to the applications. I would like to believe that all updates will be orderly, but the reality of a newly found bug for a client or an upcoming trade show could mean that updating the application NOW is critical. Even an "expedited" day wait would not be acceptable.
One option I have thought of is having a flag for each page that we send down when the user logs into our server. If the flag is set, then instead of the native screen for a given page, there would be a page with a UIWebView that would get the latest HTML from the web or stored HTML loaded at the time of login.
I would prefer storing the HTML and using it "offline" because a data connection cannot be guaranteed.
The questions are:
1) Does this violate any of Apple's licensing?
2) Is this feasible or is there a hole I am not thinking of?
It doesnt violate Apple's guidelines and as far as I know you are not missing anything here...in fact, we have the exact same problem in my company (which on top of the issue that you have, we have customers that would like to "brand" the app for their users, and thats how we accomplish that) and there are no issues with apple (for now...:)). Obviously, you need to think of user experience implications...hope that helps.
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.
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.