I have an app that needs to fetch background media from the server even when the app is closed.
I know that ios 5 newsstand does this for once a day.
but i also know that this feature is intended for magazines and not any app.
so what is the limitation of integrating it in my app? will it simply get rejected ? is there a format for the app to be a newsstand?
They're very strict on the requirement that the app's content be a newspaper or magazine.
That is, issue-based, mainly written content. Don't waste your time if your app is none of these.
Newsstand applications can receive Push Notifications with a special payload ("content-available":1) that causes the app to launch in the background so that it can check for content to download. This notification can only be sent once a day (the rest of the time it is ignored).
In order to receive this notification, your app must have a UIBackgroundModes that includes newsstand-content. Apple has suggested that non-newsstand apps with this background mode will be rejected, but I have not seen any evidence one way or another.
According to the App Store Review Guidelines,
Apps that are offered in Newsstand must comply with schedules 1, 2 and
3 of the Developer Program License Agreement or they will be rejected.
The License Agreement requires that
[You] confirm that the content of the Licensed Application is a
periodical (e.g., newspaper or magazine)
You acknowledge and agree
that Apple reserves the right to recategorize or reject your Licensed
Application if it is not appropriate for Newsstand.
(I'm in the same boat - would love to use the NK features to manage downloads, spent half a day reading about it, then found out about this limitation.)
Related
I have created this location tracking app, that uses nstimer in background to fetch location every 4 mins.
I am wondering if there will be any problem in submitting the app in the market place..
If you know something regarding it, can you please let me know.
Thanx.
If it's relevant to what your app is doing I don't think it will be a problem.
This is from Apple's App Store Review Guidelines:
4.1 Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
4.2 Apps that use location-based APIs for automatic or autonomous control of vehicles, aircraft, or other devices will be rejected
4.3 Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected
4.4 Location data can only be used when directly relevant to the features and services provided by the app to the user or to support
approved advertising uses
But pay attention that if you want your app to keep getting location updates even in background, you need to declare this in your plist file, otherwise when the app goes to background you won't be able to get location updates.
Declaring Your App’s Supported Background Tasks
Support for some types of background execution must be declared in
advance by the app that uses them. An app declares support for a
service using its Info.plist file. Add the UIBackgroundModes key to
your Info.plist file and set its value to an array containing one or
location—The app keeps users informed of their location, even while it
is running in the background.
I've gotten one app through. You have to make sure that the user is informed exactly as to what is going on. So dialogs have to be very specific and have a privacy policy in place.
4 minutes is a little bit extreme if that's a permanent state of your app.. I don't think Apple would allow that if they found it during app review. Would it not suffice to just have it updated based on movement? ie. the significant location change api?
The app I did this for used significant location change api for background location tracking and then stepped it up to higher frequency tracking if the app was actually open.
I am building an app for a client that will have 30 days of content for free, thereafter you are required to buy a subscription via in app store purchases.
However, I have read that you will get rejected if you have trials.
Don’t set time limits on any of the functionality of your app, either
for run times or life times. Applications that only run for a set
number of minutes per session, or that expire altogether after some
period of time, don’t recruit customers so much as leave a bad taste
in their mouths.
Finally, they also say "your app will be returned to you by the App Review Team for modification if it is found to have time limits".
This seems odd because I know the Guardian and all major newspaper apps have limited functionality.
The Guardian app is free but you get limited functionality?
The Daily app is free, but you have to pay for daily subscriptions
and has limited functionality for the period of your subscription.
The Times app is free, but is a free trial (of sorts) (plenty of
complaints about it)
There are other examples which seem to differ from Apple's policies.
Lets say you have an app that is free, but then you have to pay for subscriptions to gain access; however according to the rules this is considered limited functionality -- yet there are lots of newspaper apps that do exactly that.
I'm confused.
Can someone clarify the situation? Can apps have trials?
Thanks
It is difficult to clarify the situation because unfortunately the guidelines are not necessarily set in stone. They can and do vary on an app and publisher basis.
In the case of The Times and The Daily, both apps are produced by News Corp. It is perhaps safe to say that News Corp has a good deal more influence with Apple than a one-man development shop producing an iPhone game. Apple would be loath to admit it, but there are clear cases of popular apps on the store that don't conform to the guidelines, where they have tacitly made an exception.
So what I would say to you is this: be sensible. Don't have an app that quits automatically when your trial runs out. Think about what would be acceptable to users. It's very much a case of nothing ventured, nothing gained. Take a risk, submit your app with your limited trial, and see what happens.
With the Guardian app, we had to deliver an app where you always got at least some fresh content if you were using the free version. Subscribing opens up more content to the user.
I think, you are mixing up "content" and "functionality".
You can deliver content items (i.e. an magazine issue) for free or user has to pay for it — so the first n issues, or all issues in a certain timeframe, can be free, while the others need to be paid. But if an user purchased an content item before, you have to re-deliver it for free.
You can sell functionalities (i.e a search in the magazine's archive) as-well. But you cannot give it to the user for free for a certain time and them make him pay.
So the general rule is: What ever the user got from you — you cannot take it back from them and make them purchase it again.
There are plenty of free apps which provide limited functionality. They don't provide time limits though (or at least they shouldn't). I'm guessing it won't be as clear cut as accept or reject for Apple, because I did encounter an app which closes itself after 10 minutes, opening a web page to purchase it (closing an app is also against the Apple Human Interface Guidelines, as an app should never terminate itself).
The guidelines mention this is only allowed for specific types of content:
11.9 Apps containing content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs, music, books)
11.15 Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
I need to implement trail period in my app. How to do it? Store day count in NSDefault? or some other?
You could store a counter in the preferences as you mention, although that counter would disappear if the user reset their phone.
However, I think it's all slightly besides the point. In general, Apple frowns upon apps that have this kind of functionality, so don't be surprised if your app gets rejected. Consider launching two different versions of your app instead, a "Lite" app and a "Full" app. The Lite app should have a reduced feature set, but it should never stop working.
Apple is against the idea of you disabling features to prompt people to pay money for something. Your app needs to be fully functional and a 'lite' version and a paid version seems to be how things work at the moment.
That being said - if you implemented it properly you could add in app purchase items to enhance your app. Your original 'lite' app could be $0 and additional features can be added for a fee.
The most bullet-proof method would be to send and maintain a copy of the iPhone's UUID in a database.
Then if the App is not "unlocked" it requires a "key" form the database every time it launches. You can then implement the trial period on the server side.
However, if you decide to use some type of encryption to store or transmit keys etc you will need a licence to distribute the App.
You make a light version of your app. There is no official way to have a trial version at this time. Hopefully Apple will eventually address the need, but I can't say I would hold my breath...
I finished building an app that allows beaming of photos, contacts and text clips over Wi-Fi
IPhone to IPhone and IPhone to desktop.
I want to decide on the feature set of the lite version of my IPhone app. I also want to come up with a pricing model. So the question is, which of these components should be free, and for which I should be charging for ?
For example, the lite version could have all features except the ability to interact with the desktop version - that is, it would work IPhone to IPhone, but not IPhone to desktop. The paid version would be able to beam to the desktop. In addition, the desktop version would be free, so you could share it with family and friends.
Alternatively, there would be a single free IPhone version and I would charge for the desktop app. The only thing here is that I would have to setup server side code for managing registration codes.
One reason to make your desktop app free and the iPhone app a paid product would be to take advantage of Apple's app store and their payment processing, hosting, etc. While I know 30% seems steep for what Apple provides, it is nice to have that part of the business be handled by someone else. For example, you will never have to deal with credit card processing or have to issue refunds - Apple does all that for you.
I like the mechanism that is more suited to viral distribution and giving people a good taste of all the features, before they are sort of convinced to go for the paid version. The marketing value of an app that can be freely tried out once one user recommends it to another, is invaluable. If someone recommends a product to me and I have to pay for it, then I probably would put off trying it till alter when I have learned more about it. However, if it is free, I can download and try it without feeling like I need to do more research prior. Once I like, and am hooked on it, then I will want locked functionality that I would have to pay to unlock.
I'd stay away from selling, payment processing, and reg code management, if your expertise is in coding - you'd make yourself more money writing more code than writing reg code management utilities...
Good luck.
I'm not sure charging for either is the best idea. If you keep both tools free, you get people trying (and liking) both apps. Viral distribution will ensure a decent user base. Once people use both tools, they're more likely to pay for the next part, which is the connector software.
I like your idea of three parts: a free iPhone app (Let people share photos on their iPhone), free PC app (There are hundreds of photo viewing apps, free... Don't try to charge for them, that way lies pain) and paid connection between 'em.
That way:
You get people using your iPhone app virally (To share with each other's phones & try out the application)
You get people using your PC app virally (Because the cost to try is nearly null)
The connection can be sold through Apple's iStore, so you don't need to do the money handling side
You could even make the connection component a subscription, but as an end user I hate that idea unless I get some additional functionality from it being a subscription (Like free hosting).
If you deploy an application through the iTunes app store, what usage information do you get from Apple? Do you only get the number of downloads/sales, and does this differ for free vs. paid apps? Do you get any information regarding how often it is used, crash logs, demographics info, etc? Is the only way to build hooks to your own server to track this information and would such an app even get approved?
I've seen articles such as this one that includes quotes like:
only about 20 percent of users return to use a free app the day after they first download it and by 30 days out, less than five percent are using the app.
Is that based on surveys, or is it data that comes from Apple? There doesn't appear to be much publicly available data except when Apple shows the top applications, but that is just based downloads or ratings, and nothing deeper.
Most of this information comes from companies like Pinch Media and Admob. They supply libraries you can include in you app which inform their servers of events in your app (specifically launch but also other events decided by you).
They use these events to provide aggregate information on iPhone apps. Several reports have been published recently referencing this data.
You only receive usage information if you somehow program the reporting of such information into your app.
Number of Downloads (Sales if a non-free app) and more recently crash logs are the only information you receive from Apple. you do not even receive personal information about WHO is was that bought your app, only that they did.
You won't get usage statistics from Apple, only download and sales statistics. The reporting is slightly different for free apps(as they won't show up in the financial report), but basically the same information is provided.
You can however track usage information on your own by having your application ping a remote server every time the app is accessed. You can use the unique device id to track a specific user. This will be dependent on internet access for the iPhone/iPod Touch.
Apple does give you how many downloads have occurred as well as what countries they are from. If you want more detailed usage statistics you will have to go to a third party solution, or write it yourself.
Unless Apple is secretly sending usage information when an app is opened, I don't see how anyone can get aggregate statistics about the whole app store. When I upload an app, it is in binary format, and it is probably unlikely that anyone adds in their own code to secretly do this.