How negative app reviews from iOS beta users could be prevented(sparsebundle.net)
sparsebundle.net
How negative app reviews from iOS beta users could be prevented
http://www.sparsebundle.net/posts/ios-beta-app-reviews
12 comments
There really is no reason for Apple to allow reviews from beta versions of their OS. It doesn't bring the developers any useful insight, it's a time-waster at best and a commercial nightmare at worst. I too am left wondering why this is possible in the first place… especially since I assume Apple is fully aware of the "grey" iOS beta market.
I'm all for Apple doing this.
But it seems a pretty good reason might simply be that this would require another conditional be built into the software. And if you talk to my programmer, he doesn't like adding weird exceptions to the code. Even if it makes things "easier" for product people. :)
But it seems a pretty good reason might simply be that this would require another conditional be built into the software. And if you talk to my programmer, he doesn't like adding weird exceptions to the code. Even if it makes things "easier" for product people. :)
If Apple added a delay to prevent pressing caps lock too fast in an apple keyboard, then they can disable reviews from beta versions of iOS.
PS. Not joking about the keyboard delay, it sucks :/ http://support.apple.com/kb/TS1578
PS. Not joking about the keyboard delay, it sucks :/ http://support.apple.com/kb/TS1578
On the other hand, is there any reason to prevent them? If anything, this is driving developers hard to get onto the new version, or at least compatible with it. Apple doesn't seem to have any incentive to prevent these reviews, and they have a big change in their platform coming up with a need to get developers on board.
> There really is no reason for Apple to allow reviews from beta versions of their OS.
Even more so as developers are not allowed to push release for beta OS compatibility (though some sneak in and it's also possible to sneak in fixes without mentioning the OS I believe. Risky though)
Even more so as developers are not allowed to push release for beta OS compatibility (though some sneak in and it's also possible to sneak in fixes without mentioning the OS I believe. Risky though)
I've had no problem submitting iOS 7 compatibility fixes with it specifically mentioned in the releases notes and downloaded other updates that have as well (e.g., 1Password if I remember right). As far as I know you're only restricted from apps built with Xcode 5 and built against the iOS 7 SDK rather than with Xcode 4 and weak-linked to iOS 7 parts.
Even more so that the bug may actually be in iOS 7 and not in the developers app, so they are powerless to fix it.
You're allowed make a fix for iOS 7 and label it as such in the release notes, provided that it's done using the 6.x SDK.
I really wish the title of the article was more along the lines "Apple should prevent negative app reviews when using iOS beta".
I felt a little mislead and thought that a developer had somehow figured out how to do the current title of the submission (news) vs. what it was really about (opinion, that I agree with, but not news).
I felt a little mislead and thought that a developer had somehow figured out how to do the current title of the submission (news) vs. what it was really about (opinion, that I agree with, but not news).
Agreed, it's absolutely ridiculous to allow reviews from a beta iOS. Especially since you can't submit apps built with the new beta SDK!
Although that won't prevent you from making the review from a non-beta iOS (or desktop iTunes) about an iOS beta.
They should flag the apple ID used to purchase the app as "beta user", or at least the purchase itself, so that even iTunes cannot be used to post a review for that given purchase.
The real problem lays in the default trained behavior of the user - leave a review if _anything_.
Both app developers and Apple have wrongly been pushing users to voice opinions publicly in app reviews, leaving app developers exposed with no way to communicate with those users.
The real solution is to start pushing users to communicate their suggestions and issues privately, in the app, where you can better manage conversations, keep users engaged, and establish relationships that can turn upset users into long-term evangelists.
1) Do not bury support or email buttons multiple taps deep. Surface a contact button so that it's easier for users to contact you.
2) Do not ask users to fill out more than a single field to send you their thoughts. Automatically capture user ID, device, platform, OS version, app version, etc. by passing a unique session or user ID.
3) Keep them in your app, engaged, and talking. Think of this more like "user relations", not "user support". You need them engaged and sharing their thoughts more than they need you and your app.
In terms of what can be done now for helping to avoid iOS 7 app reviews, here are a few suggestions:
1) Add an alert for iOS 7 users that your app is not yet compatible: http://mobile.tutsplus.com/tutorials/iphone/uialertview/
2) Here's an example:
[[UIAlertView alloc] initWithTitle:@"Unsupported iOS Version" message: @"This version of the app is untested on this version of iOS, please check for an update in the app store." delegate: self cancelButtonTitle:@"Skip" otherButtonTitles:@"App Store",nil];
2) If you have an email list of your users, send them an email with when they can expect the OS update. Users will expect a great, new experience with iOS 7 and will be deleting apps that don't meet their expectations. You can't expect users to keep using your app when there is so much new "eye candy" on the App Store.
P.S. Stuart from Appbot actually covered this with a scary screenshot of iOS7 reviews only one week into Beta1: http://stuartkhall.com/posts/stop-allowing-app-reviews-from-...
Both app developers and Apple have wrongly been pushing users to voice opinions publicly in app reviews, leaving app developers exposed with no way to communicate with those users.
The real solution is to start pushing users to communicate their suggestions and issues privately, in the app, where you can better manage conversations, keep users engaged, and establish relationships that can turn upset users into long-term evangelists.
1) Do not bury support or email buttons multiple taps deep. Surface a contact button so that it's easier for users to contact you.
2) Do not ask users to fill out more than a single field to send you their thoughts. Automatically capture user ID, device, platform, OS version, app version, etc. by passing a unique session or user ID.
3) Keep them in your app, engaged, and talking. Think of this more like "user relations", not "user support". You need them engaged and sharing their thoughts more than they need you and your app.
In terms of what can be done now for helping to avoid iOS 7 app reviews, here are a few suggestions:
1) Add an alert for iOS 7 users that your app is not yet compatible: http://mobile.tutsplus.com/tutorials/iphone/uialertview/
2) Here's an example:
[[UIAlertView alloc] initWithTitle:@"Unsupported iOS Version" message: @"This version of the app is untested on this version of iOS, please check for an update in the app store." delegate: self cancelButtonTitle:@"Skip" otherButtonTitles:@"App Store",nil];
2) If you have an email list of your users, send them an email with when they can expect the OS update. Users will expect a great, new experience with iOS 7 and will be deleting apps that don't meet their expectations. You can't expect users to keep using your app when there is so much new "eye candy" on the App Store.
P.S. Stuart from Appbot actually covered this with a scary screenshot of iOS7 reviews only one week into Beta1: http://stuartkhall.com/posts/stop-allowing-app-reviews-from-...
> If I see a review that contains the word "iTouch" I don't just report it to Apple, I report it to the proper authorities.
Eh?
Eh?
Also offer a way for users to contact you and let you know about the issues other than through the reviews. I've found a number of apps that don't work with iOS 7 and I contacted at least one developer through email or there website to let the know. With another (a large company) I couldn't find any way to contact them on their website so I gave them a medium review not for incompatibility with iOS 7 but for being uncontactable.
I believe that lack of communication channel is not a problem here. If someone like you wants to let the developer know about this, he will find a way to contact him.
Most of these reviews are from the non-developer crowd who somehow ended up with beta software on their phone and they don't understand that developers can do little about this for the moment, nor they understand that their negative review has a bad impact on the developer himself.
Most of these reviews are from the non-developer crowd who somehow ended up with beta software on their phone and they don't understand that developers can do little about this for the moment, nor they understand that their negative review has a bad impact on the developer himself.
Exactly. Most major (and minor apps) are already retooled for iOS 7 (or are in progress) -- so something not working on iOS7 is often obvious to the developer, but he/she can't release an iOS 7 update until iOS7 is released. So bug feedback is pointless from beta iOS7 because those bugs might already be completely fixed and ready for release.
Apple should change how they distribute beta OSes so that it is more difficult for non-developers who just want the 'latest' to get it.
Based on this article, it sounds like you already have to be a developer (which costs a $99 fee) in order to get the beta. I don't think Apple can reasonably set a bar higher then paying $99 dollars to join the Developers program.
I think an easier solution would be to just hide reviews that are submitted from a device that's running a beta version of the OS.
That way (legit) customers can still submit feedback, but it doesn't affect the app on the appstore.
That way (legit) customers can still submit feedback, but it doesn't affect the app on the appstore.
Or group reviews by class.
That way someone who is saying it's crap on an iPhone5 running iOS7 won't influence the vote of someone who is on an iPhone4 running 6. Same way someone on a 3S won't be able to post "It's too slow" to put off 5 users.
That way someone who is saying it's crap on an iPhone5 running iOS7 won't influence the vote of someone who is on an iPhone4 running 6. Same way someone on a 3S won't be able to post "It's too slow" to put off 5 users.
The reviews, taken as feedback and then sent directly to the developers could be useful.
But to have the reviews/feedback actually show up in the iTunes store reflects bad for Apple and the developers of the app.
Apple should be restricting this, not us. But of course they aren't very good at things that aren't in the following categories: hardware.
Everyone has wanted this for years now. I wouldn't hold my breath.
I'm not sure how "Doesn't work on iOS 7" qualifies as a negative review exactly. He's not saying the app is a pile of crap. He's saying it doesn't work on iOS 7, which appears to be a factual statement.
App reviews are not a guaranteed advertising venue. They are there for the reader, not the developer. The fact that an app doesn't work on iOS 7 is relevant to anyone using iOS 7, whether or not it's an official release yet. As the article says, the iOS 7 beta is pretty widespread at this point. I don't think you can have it both ways; if the beta is in that many hands, then the feedback is useful for potential buyers.
Unfortunately, I'm guessing many of these reviews rate the app poorly as well. That's a much more legitimate complaint, and I assume what the author really wants to curtail. I think restricting reviews is the wrong way to go though. If you really can't be bothered to fix the issue until launch, then stick something in the description telling people that the iOS 7 version will be live on launch day. If enough people are complaining about it in the meantime to make a significant difference in your app's rating, then I'd take that as a pretty clear sign that you should consider fixing the problem. No one is forcing you to rewrite from scratch, and the vast majority of apps are going to update existing codebases just fine instead.
App reviews are not a guaranteed advertising venue. They are there for the reader, not the developer. The fact that an app doesn't work on iOS 7 is relevant to anyone using iOS 7, whether or not it's an official release yet. As the article says, the iOS 7 beta is pretty widespread at this point. I don't think you can have it both ways; if the beta is in that many hands, then the feedback is useful for potential buyers.
Unfortunately, I'm guessing many of these reviews rate the app poorly as well. That's a much more legitimate complaint, and I assume what the author really wants to curtail. I think restricting reviews is the wrong way to go though. If you really can't be bothered to fix the issue until launch, then stick something in the description telling people that the iOS 7 version will be live on launch day. If enough people are complaining about it in the meantime to make a significant difference in your app's rating, then I'd take that as a pretty clear sign that you should consider fixing the problem. No one is forcing you to rewrite from scratch, and the vast majority of apps are going to update existing codebases just fine instead.
It qualifies as a negative review because it's almost always accompanied with 1 star. 1 star reviews matter in the AppStore.
That's what I was talking about in the last paragraph. It's definitely unfortunate, but I stand by my statement. If it's one or two people, then it doesn't affect you that much and certainly isn't worth Apple limiting users ability to comment. If the number is large enough to be significant, then you should fix the bug that is causing a large fraction of your user-base to feel the need to rate you poorly.
I'm sure there are bugs in the beta or bugs in your code that really need the new SDK to fix, but I suspect that the vast majority could be fixed or worked around without too much trouble. Maybe your grand iOS 7 redesign is going to be the greatest thing since sliced bread, but you can likely bodge a fix together in the meantime.
I'm sure there are bugs in the beta or bugs in your code that really need the new SDK to fix, but I suspect that the vast majority could be fixed or worked around without too much trouble. Maybe your grand iOS 7 redesign is going to be the greatest thing since sliced bread, but you can likely bodge a fix together in the meantime.
>Maybe your grand iOS 7 redesign is going to be the greatest thing since sliced bread, but you can likely bodge a fix together in the meantime.
A large part of the point of Apple releasing betas early to developers is to give them a buffer time to get their apps ready. It's unreasonable to demand developers "bodge a fix together" for immediate use as soon as a beta lands, it defeats a large part of the purpose of having these betas.
A large part of the point of Apple releasing betas early to developers is to give them a buffer time to get their apps ready. It's unreasonable to demand developers "bodge a fix together" for immediate use as soon as a beta lands, it defeats a large part of the purpose of having these betas.
You think all developers should have already updated their apps to work with the latest iOS beta release, quite literally the day they (and all the non-tech-savvy people who have been conditioned by Gmail et al. to think of "Beta" as "Latest and greatest") get their hands on that version of the OS for the first time?
No, but nor do I think that people are getting slammed with one-star reviews the day that the first beta goes out.
I can think of a few niche reasons why you would wait until iOS 7 is released before you release a fixed version of your app, but for the vast majority of people, I think they ought to be working on getting a version that runs within a few weeks of seeing a beta OS version that crashes their app.
I can think of a few niche reasons why you would wait until iOS 7 is released before you release a fixed version of your app, but for the vast majority of people, I think they ought to be working on getting a version that runs within a few weeks of seeing a beta OS version that crashes their app.
The beta OS has many bugs that exist in the OS itself. Considering that OS goes through multiple betas before release and numerous bugs are fixed each time, it's short-sighted to try to fix your app to work perfectly on every beta release.
Just imagine if we had all fixed our apps for iOS 7 beta 1 - oh the fun!
Also, while adding a catchall preventing beta OSes from reviewing is good, I have seen other posts advocating mentioning the iOS 7 is no compatible in the description of the app. This is worst advice ever. Those who are not developers who are using the beta cannot be reasoned with and it is their own fault for having an unstable OS. Mentioning iOS 7 will further annoy them [that the app doesn't work on iOS 7] and confuse legitimate users about the availability of iOS 7.
Also, while adding a catchall preventing beta OSes from reviewing is good, I have seen other posts advocating mentioning the iOS 7 is no compatible in the description of the app. This is worst advice ever. Those who are not developers who are using the beta cannot be reasoned with and it is their own fault for having an unstable OS. Mentioning iOS 7 will further annoy them [that the app doesn't work on iOS 7] and confuse legitimate users about the availability of iOS 7.
Yes, but it's not like every new beta release crashes your app in 25 completely new ways. Most apps run just fine in the beta as is. The more likely case is that it's a very small number of issues that you can work around or fix once and be done with.
I still think that the bigger issue is this: if so many of your users are doing this that it's a problem, then fix the problem. If you want to complain about "lusers" in the bar later in the evening, you have my sympathy. But if this is a real problem for you, then it's an even bigger problem for your users, and just calling them unreasonable doesn't help either of you. It might be their fault, but they're still your customers and they still can't run your app. The 1-star reviews are not your biggest problem at that point.
I still think that the bigger issue is this: if so many of your users are doing this that it's a problem, then fix the problem. If you want to complain about "lusers" in the bar later in the evening, you have my sympathy. But if this is a real problem for you, then it's an even bigger problem for your users, and just calling them unreasonable doesn't help either of you. It might be their fault, but they're still your customers and they still can't run your app. The 1-star reviews are not your biggest problem at that point.
The problem with that approach (the immediate update) is that you're chasing a moving target. Fixing an app for a beta OS is actually kind of dumb from a cost-benefit analysis. Because what might be "fixed" in beta 1 might be broken again in beta 5 as the OS itself is necessarily changing. My strategy is to fix obvious issues early (for example UI components) and then revisit in later betas and making final fixes at gold master. I don't care if some beta users have issues because everyone has issues on a beta. Even some of Apple's own apps are still having issues (for example, the iBooks dictionary,) so it's pointless to chase bugs in a beta until the OS itself is closer to final stability.
I have no problem with that approach, but the cost-benefit analysis needs to take into account the likelihood that some huge percentage of your user-base can't run the app.
If 50% of my users get a crash at start-up, I'm going to try to make that go away. If no one is really having the problem, then it's silly to ask for Apple to block potentially legitimate feedback. If loads of people are having the problem, then the cost-benefit analysis ought to look very different.
If 50% of my users get a crash at start-up, I'm going to try to make that go away. If no one is really having the problem, then it's silly to ask for Apple to block potentially legitimate feedback. If loads of people are having the problem, then the cost-benefit analysis ought to look very different.
You can't release iOS7 fixes "in the meantime" because the SDK won't allow you to submit. So it becomes very difficult to chase and fix bugs or test the failures, even if you can test the failure on the 7 SDK and go back to the 6 SDK to test and submit -- you can see the problems that could arise from that. It would almost be like developing for Android! (only joking..)
Beta software is exactly that -- beta. Users should expect failures and problems, so giving any sort of review based on iOS7 beta software is absolutely ridiculous. The funny part is that the only people who should have the beta, should know better. But obviously they don't. I wish there was a way to lock down access to the beta program to legitimate developers, but that's impossible because it wouldn't necessarily be a fair system. Although it could be possible to restrict beta access to developers who actually have a released app in the store. New devs could still use the existing SDK and tools and submit, but they wouldn't necessarily have access to the betas. I don't know what problem that would solve, however. It doesn't seem to be a significant issue, except in app store reviews, so the simple solution is to restrict reviews to non-beta people and instead of reviews, iOS7 users can submit private bug reports. This way devs are aware of problems they might not know about but it doesn't give the negative publicity that affects their sales. Several one-star reviews can kill a newer app before it even gets off the ground.
One potentially cool alternative is to allow devs to release iOS7 beta versions that are only accessibly to iOS7 beta users through the app store. However just as promo-code apps can't be reviewed, the same logic should apply to iOS 7 beta users.
Beta software is exactly that -- beta. Users should expect failures and problems, so giving any sort of review based on iOS7 beta software is absolutely ridiculous. The funny part is that the only people who should have the beta, should know better. But obviously they don't. I wish there was a way to lock down access to the beta program to legitimate developers, but that's impossible because it wouldn't necessarily be a fair system. Although it could be possible to restrict beta access to developers who actually have a released app in the store. New devs could still use the existing SDK and tools and submit, but they wouldn't necessarily have access to the betas. I don't know what problem that would solve, however. It doesn't seem to be a significant issue, except in app store reviews, so the simple solution is to restrict reviews to non-beta people and instead of reviews, iOS7 users can submit private bug reports. This way devs are aware of problems they might not know about but it doesn't give the negative publicity that affects their sales. Several one-star reviews can kill a newer app before it even gets off the ground.
One potentially cool alternative is to allow devs to release iOS7 beta versions that are only accessibly to iOS7 beta users through the app store. However just as promo-code apps can't be reviewed, the same logic should apply to iOS 7 beta users.
You can submit fixes for iOS 7 if you check at runtime for the presence of the methods, which is the standard pattern for supporting multiple iOS versions. You just won't necessarily have the constants and such that are new to the SDK since you're not building against that SDK and may have to work around that.
You can submit compatibility fixes. You just can't use new APIs (as they're not present in the non-beta SDK you have to build with).
The problem isn't so much that people are complaining it doesn't work with iOS 7, it's that those reviews are usually accompanied by a low star rating or, in some cases, harsh criticism based upon the user's ignorance. I don't mean ignorant in a harsh or derogatory way, I mean it literally - the user doesn't know why and assumes that because the app is the thing that is crashing, it must be the app.
I would expect that sort of user to (a) probably not be running an iOS beta, and (b) less likely to think to report it as not working on iOS 7 specifically. I'm sure in both cases there are exceptions, but it's surely not the majority.
Agreed, the 1-star reviews are unfortunate. That's exactly what I was talking about as well. I just don't think it's a big enough problem to justify removing the ability for people to post useful information regarding compatibility with an OS version that exists in the field in significant numbers.
Agreed, the 1-star reviews are unfortunate. That's exactly what I was talking about as well. I just don't think it's a big enough problem to justify removing the ability for people to post useful information regarding compatibility with an OS version that exists in the field in significant numbers.
For your first expectation, (a), ignorant users are EXACTLY the type of users who are running the iOS beta and (b) more likely the rate the app 1 star considering that they had the ask a developer friend to download the beta for them or get a cracked beta. This is definitely the majority in the case of these 1 star reviews.
Although yes, I do not see these reviews causing a huge impact as of yet.
Although yes, I do not see these reviews causing a huge impact as of yet.