We've reviewed XXX and determined that we cannot post this version of your iPhone application to the App Store because it provides to the user potentially inaccurate diagnostic functionality for iPhone OS devices. There is currently no publicly available infrastructure to support diagnostic analysis. This may result in your app reporting potentially inaccurate information which could lead to user confusion.
Has anyone encountered this rejection reason? Can I just add the disclaimer in the app in order to get approved? Has anyone tried this? Or any other trick?
Given that it is impossible for an app to actually test for dead pixels, I'm going to say Apple is on solid ground here. Any such test would rely on a human actively observing the pixels so it wouldn't be an actual measurable diagnostic.
The situation with the App Store isn't like the situation with software that isn't sold through Apple. Given that Apple test and approves apps for basic functionality before allowing them in the App Store, letting through an App that claims to provide diagnostic information about hardware is tantamount to Apple stating that app does provide hardware diagnostic information. However, the API does not provide such information and Apple is not going to hinge their warranty payouts on some, for example, 16 year old kid's idea of what makes an accurate diagnostic tool.
Apple is imagining this conversation:
"Hello Apple? I have dead pixels on
my device. How do I know? I ran an app
that says I do. Hey! You approved the
app for the App Store so that's just
like saying it does detect dead
pixels! If it didn't you shouldn't
have accepted it!"
... and Apple's lawyer gets a new Porsch.
I ran into issues with 3rd party diagnostic software back when I was at Apple. One of the big headaches is that the 3rd party diagnostics offered no protection against false positives. Customers and Apple would spend a lot of money chasing false positives and the diagnostic provider would just shrug. It wasn't their problem and it didn't cost them any money.
Official diagnostic software has to be rigorously tested as false positives cost everyone a lot of time and money. Apple is not going to make a 3rd party tool quasi-official by adding it to the App Store.
You can easily add a "dead pixel" remedy. I remember the old PSPs used to have a quick color flash that fixed pixels well. Red, yellow, etc. Seizure status.
The probability of SEEING a dead pixel on the retina display is probably going to be very difficult if not impossible by the naked eye.
Related
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 am a member of a gliding club with 150 members, and we want to have our own iPhone app. Requiring a member login, the app would be usable only by members of the club, and it would be used by an estimated 20-30 people.
Is it even possible to disribute such an app to non-jailbroken iPhones? According to my research:
It wouldn't be accepted on the App Store due to "limited audience".
Even if we were able and willing to pay $300 for the enterprise distribution model, Apple would likely not accept us as a company.
Ad hoc distribution would be fine for us except for the expiration time associated with apps distributed in the manner.
Are we at a dead end?
Thanks.
Edit: In case anyone is wondering why I didn't just ask Apple directly: I did, and their answer was, "We are unable to advise you with respect to the Apple Developer Program that best fits your needs."
I'm not 100% on your question.
But depending on your requirement, pretty much everything you need can be achieved as a web app, with the correct coding behind it i.e. CACHE MANIFEST you could make the app function similar to the a native app, available offline and can be saved to any iOS device through the browser.
Give me a shout if you need more information.
Hope it helps
Gary
You could always try to make the app a little more "global"? Perhaps offer some free stuff for Joe Bloggs to use, but tucked away you have your real motive... that way you can get it released legitimately.
I've seen some real disasters in the app store that shouldn't have made it, and I'm sure Apples screening isn't as intense as we might think. (example: that flash light application, when pressing a sequence of buttons it would enable free tethering).
Best of luck!
Yup. You seem to have all the options laid out pretty clearly, and there's no other way to do it. Except developing for android, and just distributing the application freely and without arbitrary restrictions.
Sorry.
Ad-hoc distribution would give you about 90 days expiration time, i think, whereas enterprise would give you a year. Though gaining enterprise status in the eyes of apple is easier said than done.
Even if we were able and willing to pay $300 for the enterprise distribution model, Apple would likely not accept us as a company.
You don't have to be a company to apply for the enterprise account, you just need to be an organisation with a DUNS number.
Some of our application is already in AppStore...
But suddenly one thing comes into my mind, that I want to clear before submitting my next application.
The thing is : As a programmer's point of view, should we require to handle if iPhone Device is jailbreaked ? If yes, then how we can tackle with this ?
Thanks in advance....
On a general note, jail-breaking the device is an issue between the user, Apple and potentially the carrier. You are not a side in this relationship, and the user has no contractual obligations to you with regards to their device.
You could choose to attempt detecting jail-broken devices in an attempt to prevent piracy of your app. However:
If the device is jail-broken, there's nothing you can do to reliably verify it's not jail-broken, since none of the OS APIs (including networking) is guaranteed to function as you expect. Your code could be running in a non-jail-broken simulation on top of jail-broken device.
Of course, you could check by attempting to do one of the things you currently know Apple actively prevents apps from doing. However, there's no guarantee that Apple is not going to allow that particular action in future. And, there's the chance that your app might get rejected because you are attempting to do something prohibited by Apple.
There is no official criteria from Apple on what constitutes a jail-broken device and what does not. And even if there was, you are not guaranteed to be notified in a timely manner (or at all) by Apple if they decide to change any such criteria. But even assuming you do get notified somehow, you can't update your app quick enough to avoid falsely detected jail-broken devices, thus potentially denying access to your app to legitimate users.
If you would like to cut off a large group of users, then sure, go ahead and require it.
Unless your application specifically requires it, there should be no reason to force users to have a jailbroken iPhone or a non-jailbroken iPhone.
If you program is legitimate (no private API calls etc), then you should not concern yourself with JB. You don't need to handle anything differently if the users phone has been JB'd. If it has, and your software doesn't run (say memory issues because they are using backgrounder to run 2 other things) then that's their problem not yours. Make your code well behaved, not leak memory, dump cache's etc with memory warnings, and you should be fine.
As you asked for the "programmer's point of view", I'd say: make sure your app runs on as many devices as possible.
Meaning: as long as you app is safe to run on an iPhone whether it's JB or not, I wouldn't care.
One thing I have found, at least early on (not seen it for a while) is that most reports I got of strange behaviour with my app (vConqr) turned out to be from people with jailbroken phones.
That's not to say I think that's good reason to block them. But if you do any sort of custom crash reporting, or other diagnostics it could be useful to log the fact to save time on troubleshooting.
Do a search on the Internet. You'll find several articles that shows some ways you can detect a pirated app. I make no claim on their effectiveness, but I do use some of these in my own apps. These techniques do not try to detect if a phone is jailbroken; they focus on detecting if your app has been tampered with.
We're days away from submitting our first app to the appstore and
last night I was horrified to hear that it does not work on
jailbroken devices. I got a few seconds with the device and saw the OS version, and free memory available (36MB, I guess that's low).
Should I care?
Presumably jailbreak users can buy the app and write scathing reviews.
If so and jailbroken iPhones are common, then the iPhoneJB becomes a de facto shadow-platform that I'm obliged to support.
EDIT
I got some ball park figures, sounds like I should care about the new de facto shadow platform. So either I can try reducing memory requirements and cross my fingers, or get out the credit card and go get me another iPhone to jailbreak.
With around 2.3 million jailbroken iPhones, it is a significant portion of the market. I have a jailbroken iPhone, but most of my apps are from the App Store. I vote yes.
This is a similar issue to what many web developers run into: should they support Internet Explorer 6? While as of this writing 14.9% of the market still uses IE6, many web developers choose not to support it because it is difficult and takes too much time. My own experience was that supporting IE6 caused 50% of my work; that's obviously not a good trade-off.
As Jergason mentioned, there are 2.3 million jailbroken iPhones. Obviously that's a large market. But compare that with the 30 million iPhones total sold as of March 2009. You could probably find better numbers to compare, but assuming those numbers are roughly accurate, less than 10% of the market is jailbroken. Look at how much work, money, etc. it's going to take to support jailbroken phones. I don't know how much work it would take, but when it comes to money, my guess is that simply the cost of getting a jailbroken iPhone to test on will be more than 10% of your revenue (iPhone dev tends to be a small-scale operation, but I don't know the nature of your product so I could be way off-base here).
So my vote is neither yes nor no: do the research and get more detailed stats than I've provided here. When you have your information, don't spend a larger percentage of your revenue supporting a segment of the market than that segment is as a percentage of the whole.
Of course you don't have to support anyone you don't want to! Ultimately, as others have noted, it's a business decision.
In my experience, you'll spend a disproportionate amount of time supporting users with jailbroken handsets. I spent more than twenty hours tracking down one problem that only affected jailbroken phones and even then only found the solution entirely by accident.
Having said that, some of my most enthusiastic (or at least vocal!) users have jailbroken handsets.
At the time of writing, about 25% of users of my free version have a jailbroken handset and 10% for the paid version.
In the end I try to support all users but I do put a higher priority on users with vanilla handsets. I'd draw the line at users of cracked versions, but I have no reason to suspect that's the case.
Incidenally, technically you'd be in breach of your iPhone Developer Program agreement if you used a jailbroken handset. And 36Mb sounds like a lot of available memory for anything other than a 3GS.
The accepted answer to this question seems fine, but I thought I'd add one more (technical) issue to consider.
If you don't at least test your app on jailbroken devices, you may not be aware of some security vulnerabilities. If your app contains any kind of sensitive information, you might want to make sure it can't be easily accessed on a jailbroken device. This might include protecting users' data, or protecting the corporate data on the back end.
Jailbroken phones allow a user to ssh into the phone, and browse any file on the filesystem. The sandbox is nullified (App Store apps will still be limited to their own sandboxes, but non App Store apps will be able to read and write the sandboxes of other apps, including App Store apps).
NSUserDefaults used to store sensitive information, for example, are easily exploited on a jailbroken device.
Even the keychain can be subverted on jailbroken phones.
It would be nice if you didn't have to worry about this, but at least through iOS 6, you really do need to worry about it. So far, Apple has not been able to (or maybe doesn't want to) completely prevent jailbreaking, so it's a real-world vulnerability. Ignoring it is probably not doing your clients or users any favors.
Do your market research. Do you expect to sell to alot of users with jail broken iPhones? Then you need to decide how important that revenue is to you...
What does it mean that I have to "apply"? Can day say: "No, we don't like your nose. Do something else!"? Did they do that in the past?
I've been investing now two full months worth about 20.000 USD on learning for iPhone programming, and I didn't apply yet...
I've never heard of them rejecting an application for developer license. But I've heard plenty of stories of them rejecting code. That's the much larger risk with Apple's stranglehold on the iPhone marketplace.
There is no reason for them not to accept you as a iPhone developer. There is no situation that I know of where they have denied the application provisioning for testing out on the iPhone. They can and will deny your app submission to the app store in some cases. Usually those cases include:
Using copyrighted assets which you do not have a license for
Competing with one of their apps (mail client was the only one I know of)
No value added (yet another "flashlight" app - pretty rare)
Opening the iPhone to scripting attack through download.
Does not conform to their UI guides
The last of these is the trickiest. A friend of mine had his app rejected because he used a UI widget in an unexpected way. This is pretty subjective IMO but they did tell him exactly why they denied it and accepted it when he fixed the issue.
Also about the 20,000, I can't agree here. In addition to learning and bettering yourself as a programmer, you are assuming that you would be paid for every off hour you spend learning - not very realistic.
Apple has a right to not accept your app at their wish, so you have to take a risk.
Yes they could. That's the risk behind developing for any tightly locked down environment.
Of course in practice they are unlikely to reject you for no reason.
And you're already taking a gigantic risk by investing $20k into iPhone development. I can't help wondering if this is a saturated market, although there have been a few well publicised success stories, everybody and his dog are now working on a bejeweled clone, and lets face it, even people who buy iphones are going to be looking a reduction in spending on pointless trivia soon with the market the way it is