I have an app in the iTunes Store and sales have slowed so want to convert it to a free app from a paid app. The new app will contain an option to buy, using In App Purchase. I was considering using a flag / pre processor macro to then allow full features for those that buy using the IAP, and limit features for those who have not.
The problem will be if I add this new pre processor macro to the new update, those who have previously paid for the app will not be able to use full features, as they would not have used the IAP to "unlock" the full app.
Does anyone have any suggestions to overcome this problem.
I have a few ideas, but in my mind they are not fool proof.
Thanks for assistance.
Pondering exactly the same issue here. The only thing i found workable (under most use cases) is to look-up gamestate information at when the new_free_iAP version starts.
If there is no iAP state, AND if games exist, AND the playtime counter > 0, i will make the assumption that the user bought this and will preseed his/her iAP configuration information to indicate that this was iPurchased. The only users left out would be buyers who NEVER started the app.
Not fool proof, but better than none. Ugly state to manage, nasty testing for this. And of course, this is a variable geometry solution : if I did not have reliable persisted state in the current version, i would not know where to start.
Related
I work for a company that generates calendars for professionals and we'd like our users to synchronize their calendar on their phone for simplicity's sake. We initially had an ICS file, but we started hitting issues out of our control and we're looking to switch to a full CalDav support.
However, the steps necessary to create a CalDav account can be a bit tedious
( https://www.youtube.com/watch?v=BfPtH8fOLfw ) especially since in our mobile app, we already have an authentified user, we were wondering if there was any way we could do the setup for the user, so he/she doesn't have to switch back and forth to copy/paste the CalDav Account Credentials.
Surprisingly, we've found nothing. No NPM package, no way to simplify this. We did found a way to generate a configuration profile with the data, but we were told to steer clear this idea since some of our customers may be using a company-provided phone and it was possible to prevent any sort of installation through configuration profiles.
Anyone has an idea on how we can make it simple for our users and give them the best UX as possible ?
Thanks :)
I created an application that simply spins a picture of my goose on screen. That's it. Nothing else.
Could that be deployed to the app stores?
Context:
I'm a mobile app engineer for a few different companies (finTech, gigEconomy, social...) and all of our applications have very specific use cases for the end user.
I'm also an artist in my own time, and have built a few different apps that help people make art.
For each of these, the data gathered by the apps must be well documented and explained to the end user to be accepted by the App Store along with the purpose of that collection.
That's got me thinking, would the Apple App Store accept an app that does not collect any user data at all, but also has no true "purpose"? (Google Play Store too, though I expect their review process is so easy you can get just about anything up there anyways...)
I haven't found any relevant answers to this question online and might test it just for fun, but would love some insight by other curious developers if they have tried uploading apps just for fun
You might find the following section from the official App Store Review Guidelines useful:
4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted.
Does this include a purpose or does this mean that an app like you have suggested in your scenario gets rejected? Absolutely not.
After a quick google search, I have found the IsItMyBirthday app which lets you pick a date and it tells you if that date is today. Is this useful or unique? We could just look up the date in the calendar on the phone itself.
However, this could be considered a 'joke' and a joke has a purpose and might be considered as unique. An app that does nothing, could be considered a joke as well. It has a purpose and Apple might agree or disagree.
In my experience it can be very random on why an app gets rejected or accepted. For example one of our apps got rejected in version X for reason Y. We released a new version without changing Y and it was accepted.
I want to change my app from a paid version to a free with ads. However, I don't want the people that originally paid for the app to get the ads.
I was thinking I could include a new update that has extra code that sets up some UserDefaults saying the version doesn't have ads and then do the update to the free version. But that doesn't seem like a very reliable solution.
I think, it depends on minimum OS version, that your program can be run on. For iOS 5.0 and later you can try to use iCloud to store some flag about purchased version. It allows you to set this flag not only for one device, but for the user's account.
Or you can store this info in the keychain to get it later. But in this case your user will not be able to have no ADs on some other device with his(her) account.
Anyway, as far as I know, you need to create an update for your app first to write this flag anywhere. And only in some time make an update with ADs.
I will be glad to see comments if someone has another thoughts about this issue.
It seems there is no reliable method to detect whether someone paid for your app or downloaded it later when the price has been changed to free. For this reason I have decided to create two separate entries in the app store.
I was wondering if anyone has any experience of submitting location-specific apps to the Apple App store.
What I mean by location-specific is an app that only works when you are at a particular location. For example, a GPS tour of a historical battleground might have content that is triggered at particular lat/long coordinates when the user is at the actual physical location.
So my question is: In order to make the app be likely to be accepted on the app store do I..
(1) Not worry about it as there's evidence that the Apple Reviewers have some way of simulating the GPS. I can then supply lat/long coords to the reviewers so they can experience some of the content.
or (I suspect more likely)
(2) I Need to make it work anywhere in order for the reviewer to see at least some of the content (e.g. have a menu or map interface that allows direct access). This could be a 'secret' option explained in the review notes accessed via a special key combination or something.
Has anyone else run into a situation like this?
Regards,
Ben
Edit: Thanks for the responses. My app has now been accepted by Apple. Interestingly I didn't need to make the app work anywhere or add any new methods of using the app at all, they simply asked me for a video of the app in action. I made a YouTube video of the app (unlisted of course) and sent it to the reviewers.. and now it's accepted! I was very surprised that this is how it worked out!
I asked this same question (and answered it myself) a while back. I basically added a "Drop Pin" feature so the testers (and users) could pretend to be somewhere else.
I submitted an app recently that "works anywhere" (and uses GPS) but "works best" in New England when looking for data (on our server) that is near your current location. The app also supports entering a city & state or zip code to perform searches. So, in the submission, you can tell the reviewers how to test it, and we explained the nature of the app and how to test the functionality by using specific New England locations. The app was approved, for what it's worth.
Basically, when you submit an app, there is an opportunity to give the reviewers guidance. So definitely tell them what they need to know to make your app work for them, wherever they might be in the world! :-)
I can't use Chargify, Recurly, Spreedly or any of those apps because I am not based in the US. I am in Jamaica, actually...so many of these companies don't support Jamaica.
But I am trying to roll a custom subscription management solution - but given that this is my first web app - I think it might be too big a task for me to take on.
Are there any gems that can handle this? These are the requirements:
All users registered automatically get on a free plan for X days
Towards the end of X days, they should be prompted to upgrade
If they don't upgrade, at the end of X days their account gets locked/disabled
If their account is disabled, they can upgrade and be taken to a checkout page (powered by 2checkout, because that is who I have to use for now).
Then once they upgrade, and have selected a plan, the system should automatically increase their allocations (# of clients, # of projects, storage space, etc.)
So I don't need the system to actually handle the processing of the credit cards, etc. It's more the logic of the subscription, restrictions on the models, upgrading and downgrading that I need.
The perfect solution would be a well supported Rails gem that I can include in my Gemfile.
If you don't have that, just send any/all possible solutions and I can take it from there.
Thanks.
You can look into Saasy. It's a stand alone Rails app (not a plugin) that you host on a subdomain and communicate with it using SSO/REST protocols. Probably won't fit your need as it is, but you may be able to extend it or get a general idea of how it works.
There is a great solution called Chargify, its one of Heroku available add-ons, you can see it here: https://addons.heroku.com/chargify and http://devcenter.heroku.com/articles/chargify
With a reasonable rate, you can manage all the recurring/subscription billing in your Rails App, I hope this is useful answer.