If I submit a newstand app that does not use push notifications, but instead queries my server for new content each time the user launches the app will apple reject my app?
I.e. Do users expect push on all newsstand apps?
Thanks
No, Apple's guidelines do not mandate the use of push notifications, and your app should not be rejected for not using them. However it may provide a better experience for your users if you implement push notifications. Otherwise the only way for a user to know that updates are available is to manually run your app and check.
Note that the official review guidelines for a Newsstand app are exactly the same as the review guidelines for any other app.
Aroth has answered the question correctly but I want to add few important points to keep in mind for Newsstand apps based on my personal experience.
Apple will reject any Newsstand app without subscription in it.
In case all your content is free still you have to create a Free
subscription.
The content must be a magazine/newspaper/newsletter.No catalog etc
in Newsstand.
The new content must come with frequency of at most a quater.
To answer this question
Do users expect push on all newsstand apps?
YES they will, because it is one of the most important functionality of NS apps and is assumed by default. Every single NS app in App Store has it.
While the technical answer is "no", there is a very good point to implement push notifications. The end user is expecting to see fresh content "magically appearing" in the newsstand applications without actual interaction. For this feature to work, you need to implement background downloading on new issues, data, whatever, which is possible when you have an APNS server informing (and waking up) your application on new content.
I can confirm that a newsstand app with a method for in app purchase of a Free subscription but without automatic content pushing will not be rejected.
Apple just approved an app I've been working on that only has a Dummy "functionality" for subscribing to Free subscription.
User touches "Subscribe now for free", goes through in app purchase and that's it - nothing changes.
Sole purpose of that button is to get the app approved.
Btw. I've implemented that button only 'cause of this thread.
Thanks!
Related
We have a mobile site for our existing website. We have just created an iOS application with back and forward buttons along with an activity indicator. Will it be rejected by Apple? If yes, what else we can include to get the app approved for the App Store?
It will be rejected
The App Store submission guidelines say:
2.12
Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected
I've also heard many stories about people who have made 'apps' for their website that might even have features like automatically logging in the user, that Apple still rejected.
I need to move an app from my current individual developer account to a corporation account. I realize this cannot be done automatically, and that I just have to remove the app from sale in one account, then submit it in the other.
My question is, what is the prefered method of doing this to make it as seamless a possible for current users? Should I alert them through a push notification? Submit an app update that tells users they will have to redownload the app?
Any other tips on this transition?
This is a University app that is free and ranking doesn't matter as much as a paid app.
We're having some trouble with the App Store Review Guidelines, specifically these two points in section 11 - Purchasing and currencies:
11.1
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
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
We're making an app for iOS, Android and Blackberry. We wish to provide in-app purchases for iOS and SMS for all three alongside. We can't quite depict from the guidelines whether we can have text underneath an in-app purchase button saying "or SMS XXX to XXXXX" and have them enter the password received back to their phone.
Yes we're using another system to the IAP, but we're offering that at the same time. Could SMS be counted as a different "mechanism"?
Any help on this would be much appreciated. I don't fancy the idea of submitting our app for approval after setting this all up just to have it rejected and have things delayed for weeks.
Thanks in advance :)
Sending an unlock code via SMS will almost certainly be considered a "mechanism other than the App Store" (11.1), and be used as a cause for rejection.
No you can't do that. Apple will reject your app. They don't want any other IAP methods, because they won't earn any money from it! StoreKit is just the easiest and best (and the only :P) API for IAP. Either you just use regular IAP or you will have to stick with Cydia. You can make your app free in Cydia and then manage your own IAP using SMS or how ever you want it to be.
Does anyone know if you can send a user to an app's update in the appstore?
We want to do this from within the app and/or when getting a Push Notification.
Thanks!
Yes, it is possible as long as you have the URL that links to your app.
I'm not 100% sure, but I seem to remember seeing something in the apple rules that means you may not be able to send a push notification advertising new apps. But an update may be ok.
Remember as well that a user may have already updated the app because they had the badge on the AppStore icon and then you push a notification out to all users. Could be annoying.
We intend to launch a free iPhone/iPad app on the AppStore.
The content will actually be accessible thanks to a subscription model (login/pwd authentication in iPhone app).
The subscription (about 100$ a month) is handled via a dedicated web server.
If used without subscription, this app will provide minimum value.
Does anyone know if this kind of subscription model can be rejected by Apple ?
I know some apps follow this model, but I'd like to have your thought on this before starting in this direction.
Thanks for your answer.
This is fine AFAIK - As long your app is free and you put in the description that it requires a subscription to whichever service. When you submit the app, you'll need to hand over details to a test account to Apple so that they can test it, but other than that it's no hassle at all.
I know of an app which works just like that on the app store right now - Spotify for iPhone. It's a music playing app which streams music from the web - but you need a Spotify premium account. When you first open the app, you have to sign in, and if you don't have a premium account it just tells you that you're not allowed in!
Javawag
There are plenty of apps which only work if I have an account somewhere, and some for which I have to pay for that account so, without knowing the specifics, there is nothing which immediately rules out your subscription model. There are even Apple apps, iDisk for example, which are useless if you don't have a $100 mobile me subscription.
If there are issues you can look at selling your subscription as an in app purchase (apple will take their 30% which should make them happy) or look at making the app more functional without the subscription.
Either way, when submitting for approval make sure to set up a sample account with a full subscription that the apple testers can use (there is space in the submission for including logins for this kind of thing).
Our app, previously approved, update was just rejected because we sell subscriptions through our website. (We have been doing this for 15 years, without giving Apple 30% of our money.) They are requiring that all subscriptions for iphone/ipad content go through in-app purchasing. I guess we will be looking at building a browser based app instead.
Cheers,
Gerry