Can someone explain to me what is required for Auto-Renewable subscriptions on iOS?
I'm confused as to whether it requires a server-side component (built by myself)? Or can everything be handled within the app?
For the most basic setup, the answer is no, you don't need your own back end. Apple takes care of the money, and you can get the transaction status from apple in the app and unlock or lock whatever the user is paying for based on that information.
Actually, this issue is fully covered in apple docs even with pictures and schemas
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html
Briefly:
1) You will need server-side if you want to make your subscriptions more flexible
(ex: to add more sub-ns while app is in appstore) In this case your app gets list of subscriptions from server
2) You will be able to check the correctness of a transaction using your server by sending the received receipt to Apple-server, and give users the content if only the receipt is valid.
Related
I'm submitting my first app through iTunes Connect. It is a social networking community so I have to provide a demo account for the submission. My app already has a live database of users as there is currently an active web version.
I'm new to this and confused as to how I should handle this. Should I be creating a demo account that will not show up in any other live user's search results? Are the testers going to be attempting to interact with other live users? I am assuming I will need to show the various functions of the app, like messaging and events. In that case should I be creating a few "demo" users for the testers to interact with?
Alternatively, should I be linking them to the development version and development database? If that's the case, then the build that I send them would only be a development build then?
I am confused on how this is supposed to work and can't seem to find any information to help?
In my experience, you'll need to give them the production version that will go into the store. So not the development build.
When we submit an app for approval, it seems to get installed and activated on a couple of devices, but nothing much ever happens. They barely use it, as far as we can tell. We can tell that it's installed and run. We have previously been rejected when the network connectivity wasn't working right, so we know that they do look at the app after it's installed.
I'd suggest you make them an account that looks relatively anonymous (or even "Test Account" which you real users are hardly likely to try to interact with). You could create another account and say "If you want to send a message, send it to account xxxx". We've never had them interact with our app enough to utilise the suggestions we've made.
If you have an active / inactive flag, you could think about making these accounts inactive once the app is approved, then re-activating it when you next want to submit your app.
I have made an android application that enables advertisers to count the posts each one of their followers/followings have liked. this way they'll be able to understand which one of them is more active and which one is not, I also have added another feature for sending like requests to the followers/followings by leaving a like on their most recent post and leaving a comment that tells them "I liked your posts come and like my posts".
I registered a submission and explained everything as they wanted, but they declined my submission :(
Now my question is How should I explain it for them or WHAT CHANGES should I apply to my application so they approve it.
This is their answer:
General issues:
Invalid Use Case: The use case described in your submission notes,
screencast and website is not a valid use case. If you are trying to
build analytics for personal use or one-off projects, note that we do
not support one-off and single use projects. We recommend that you use
a third-party platform that powers this use case. If you are building
a platform for this use case, we will only approve one client ID for
all your integrations. For more information, please see:
https://www.instagram.com/developer/review/ Policy Violation ("Like",
"Follow", "Comment" Exchange Program): Your app shouldn't participate,
enable or promote any “like”, “share”, “comment” or “follower”
exchange programs. In working to build a high quality platform
experience, we ask that you comply with our Platform Policy
(http://wwww.instagram.com/about/legal/terms/api/).
I have to say my application is not a ONE-OFF application, as the number of liked posts vary from time to time, so the user will check this application almost every day.
I also have added another feature for sending like requests to the
followers/followings by leaving a like on their most recent post and
leaving a comment that tells them "I liked your posts come and like my
posts".
This is against the API policy:
Your app shouldn't participate, enable or promote any “like”, “share”,
“comment” or “follower” exchange programs.
I've seen different documentation on various forums and site on different ways of using Paypal api, here is a pretty useful link: https://cms.paypal.com/us/cgi-bin?cmd=_render-content&content_ID=developer/e_howto_api_ECOnMobileDevices&bn_r=o/, My question is a little different i do not want to use any of the Paypal libraries offered to us in my app, this is the link to libraries:https://www.x.com/developers/paypal/documentation-tools/sdk , I also do not want to gather any personal information, I want Paypal to take care of everything. So in other words I want to be able to open up a UIWebview to the Paypal's mobile site if possible (or if not the regular site will work) have to user log in with his credential or he can use the express checkout option and get back the transaction ID, or receipt what ever is available. I'm a little new to iOS and any help is appreciated.
If you don't want to use any libraries or API's, Express Checkout won't work for you.
Which does make it somewhat easier, as you can just use PayPal Website Payments Standard in a UIWebView instead.
For example; just open https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=your#email.tld&amount=1.99¤cy_code=GBP
This will start a 1.99 GBP payment to email#here.tld via PayPal, and automatically use a mobile layout.
If you subsequently want to receive transaction information; set up PayPal IPN on your account and use that to receive transaction-related events. This can be handled outside your app, and thus take away precious processing power to the server.
For an overview on getting started with PayPal IPN, have a look at https://www.paypal.com/ipn/
I would strongly suggest against trying to do transactions through paypal. If you look at the App Store Review Guidelines it states that
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
This is a problem that every developer will face when building their apps: how to contact the reviewer of your app to notify them of an update, new release, help topics, etc?
Some things I am thinking:
Include an RSS feed in your app which you can update to notify the users of the app.
Include a twitter feed regarding your app. How to go about this?
Include a way for the users to subscribe to a mailing list. This way, I can send a mass-email to the users who opted-in? Any suggestions here?
Any other ways that you think this can/should be done? Any existing solutions you can point me to will be great. Thanks in advance.
One way, for contacting a specific user who created a review of an application is to go to Zune Social (at http://social.zune.net/home) and create a new message. You can then enter the Zune Tag of the user who created a review.
Personally, I'd try to do all three - have a web page/site, with an RSS feed, and a subscription link (so they can subscribe to the RSS feed via email) and then post any updates to your twitter account as well.
You can't really force a user to do any of these, but having the options available, and linked from inside your app on the about page is probably good practise.
You could also include some kind of "Update Available" feature inside the application. Try to make this as unobtrusive as possible obviously. Obviously if they've still got the app installed they'll get an update notification from the marketplace anyway.
Sam
Besides the suggestions made by samjudson, I'll also recommend having a support-page with a direct option to send a email to you. Here's a example of a support-page from one of my applications. I've received lot of emails with suggestions for improvements, or complains about bugs. And since it's by email, it gives you the option to respond directly to people.
Another thing about reviews. Don't take them to serious. Most people only rate negatively (since humans like to complain), and by such a lot of reviews are often misinformed, outdated, or the users just been plain ignorant.
I heard that there are applications that allow people to do transactions by just touching there iPhones to each other. How is that archive via code in Objective C?
I beleive each phone has to detect the "bump" (using UIAccelermeter) and send an immediate notification of the event ot a server (perhaps with a timestamp and some geolocation info too?). Then the server matches up events that occur at the same moment, to determine the two devices involved. Then the server facilitates the transaction by sending each phone's info to the other.
take a look at the Bump API http://bu.mp/api.html as used in the Bump iPhone application. I haven't used it myself so I cannot say how easy it is to integrate but they claim it only requires you to add ten lines of code.
The way I would do it would be to have each device send the other their UID over bluetooth and then have them both send a message containing the other devices UID and their own UID to the server with a timestamp, then have the server handle the transaction.