Hacker News Reader

Comment by deong | Hacker News Reader

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.

View on HN

>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.

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.

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.

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.

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.

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.

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).

Reply on news.ycombinator.com