Hacker News Reader

Comment by _qulr | Hacker News Reader

My update, which has a new feature but no bug fixes, is currently in limbo because the reviewer is getting mysterious proxy connection errors that no customer of mine has ever reported.

I saw another developer today say their app was "rejected" because the reviewer asked "How does the app utilize Touch Bar and where can we locate these features?"

This kind of crap happens all the time, and I don't see anything in this announcement that will help. App review is just plain incompetent and terrible.

View on HN

I have had an app rejected because it described the ingredients necessary to cast a spell that could cause damage to others.

This was in an app for managing a Dungeons and Dragons campaign.

I made some trivial change and resubmitted without issue. I'm still annoyed by that.

That’s actually pretty funny.

I worked on a dating app that would almost always get rejected because the reviewer would find a profile that had partial nudity or someone in a sexy pose and would just reject the whole binary for that reason. Even for major bug fixes. Even for a feature we had added that would make it easier for users to report inappropriate photos on our app. They were holding back that feature because they found an inappropriate photo in the app. Updates would take on average 4 weeks to get approved. Very infuriating.

Sounds legit to me, it's an extra push for app developers to be extremely vigilant about their content.

We were trying to add tools to make it easier to find lewd profiles; their app review process was stopping us from releasing the tools that would allow us to fix the problem.

Why is it the job of app developers to do this? Also why can’t apps display lewd content? None of this makes sense.

Because it's Apple's phone, Apple's operating system, Apple's app store, not the developers. Does Disney allow lewd content on Disney+ or at Disneyland?

No, it's my phone, that's why I had to pay hundreds of dollars for it. If every video I watched on my computer had to be approved by Disney I'd be just as outraged.

Then go ahead and install YOUR operating system with YOUR rules and YOUR apps. Yes it’s your physical device and it’s exactly like they sold it to you with a license to use Apple’s software (iOS) on it and everything that comes with it. It was YOUR choice to buy an iPhone or something else.

> Does Disney allow lewd content on Disney+ or at Disneyland?

They have the equivalent store-brand label for that.

https://en.wikipedia.org/wiki/Touchstone_Pictures

Touch Bar sucks. I cannot wait until they start offering the option to not have the Touch Bar; it's such a gimmick; I bet I'm not the only one who'd pay more to NOT have Touch Bar, but have the physical function keys instead.

I literally camped out the refurbished macs section until I found the specs I wanted without the Touch Bar. Took like 4 months, but I got it cheaper than new so it was worth it IMO

I'll be special-ordering MacBook Air as my next laptop, because the work only provides MacBook Pro, and MacBook Pro is not available with a professional (physical) keyboard -- only with Touch Bar.

I really hope they release an Apple Silicon MacBook still without Touch Bar.

I'm using MB Air 2020 now because of that, just couldn't stand Touch Bar in my previous MB Pro. It is slower unfortunately, but at least it has normal, usable keyboard.

The only thing you're missing is the F1-F12 keys, is this really so awful for you?

With TouchBar, you cannot change volume quickly without looking at the keyboard, spotlight gets activated all the time as you lay your hands around the keyboard -- yes, it's really that awful for many folk.

A lot of people use MacBook Pros for software development and Terminal access, and F1-F12 keys are often mapped to specific functions, from console software in Terminal, to cross-platform web browsers, to VirtualBox and such. It's not that difficult to remember which Fn key stands for which functions if you're a professional, it's easier to document Fn than the special case of a pictogram that's only available on select hardware, and Fn is 100% backwards-compatible, cross-platform and supported through Terminal OSS applications, plus much faster to use if you're a professional.

If you're a non-professional user who's never used F1-F12? Yes, sure, the TouchBar might be distractingly enjoyable to look at.

As a non-mac user (and also not a professional in your terms), one of my biggest gripes about keyboards is that full 5250-style 122+ key keyboards (with f1-f24, without a fun/modifier key) are either old (massive & won't fit nicely on my desktop) or expensive ($100+). Neither one has analog volume control, which I use frequently, and windows doesn't make it easy to map them, though the new windows powertoys feature might help. The color is also annoying (older are all beige, newer tend to have beige keys, which looks even weirder), but that can be fixed.

See here for the whiny text file I've been keeping notes in: https://gist.github.com/Efreak/d0d327517ab806e2abc9f193ad5ea...

Lenovo tried the Touch Bar approach on the 2nd gen Thinkpad X1, and ended up getting rid of it in the 3rd gen (2015) version. Maybe Apple will follow suit?

https://www.youtube.com/watch?v=QgkB6T6LrhQ

Wow so this isn't even 'new' on the Macbook... I had no idea the gen 2 carbon did this...

And Art Lebedev also introduced an Optimus Maximus keyboard, where each individual key has a tiny display -- yet every key is still a physical key -- back in like 2008 at CES -- 12 years ago -- with smaller prototypes and announcements for several years prior to that (they've even got vapourware awards because production has initially been delayed after a lot of initial attention -- it's finally hit the shelves in 2008).

https://www.youtube.com/watch?v=IJ5rX6WpxTk

https://en.wikipedia.org/wiki/Optimus_Maximus_keyboard

https://www.artlebedev.com/optimus/maximus/

They were pretty expensive, and looks like they've all been sold-out and are no longer manufactured.

Touchbar is the most stupid and user hostile feature on MBP (getting rid of replaceable battery being the most hostile).

What about foregoing all the useful ports on the MacBooks, because USB-C is the future, and yet then 5 years later still not being able to use the same headset on both the MacBook and the iPhone?

(Because your USB-C headset can't be used on an iPhone, and iPhone doesn't have a headphone jack that MacBook still has, either -- so much for sacrificing the regular USB ports so that we can all quickly switch to USB-C!)

P.S. Yes, I can use the same headset on MacBook and Android -- either the headphone jack or USB-C work great on both.

You can make the touch bar surprisingly useful if you can install some third party software and configurations. I use a one call Better Touch Tool and its really good, It's worth a try. Here is a previous HN thread on it: https://news.ycombinator.com/item?id=20229226

It honestly just seems ridiculous that 3rd party software is required to restore 'basic' keyboard/computer functionality to a feature that few people seem to enjoy having in the first place.

If people want the touch bar, fine, have a separate SKU for that, but at least give those of us who want a real keyboard the option to have one.

It feels to me like Apple should have taken an "if it ain't broken, don't fix it" approach. There was, and is, nothing wrong with a traditional keyboard, yet for some reason they decided that changing something so fundamental was a good idea. In fact I would probably be less miffed if their systems came setup with Dvorak, at least it's possible to argue reasons why it was a good decision.

Now in 2020, they actually already offer all keyboard layouts on any laptop in their US store, all at no extra cost -- which is really nice -- you can get a British, Japanese or Russian keyboard directly on any laptop when purchased directly at Apple.com for US delivery on a US credit card -- at no extra charge -- and it's advertised to still come with a correct US-based plug, so, there's nothing to worry about.

I wish Lenovo would follow suit. Currently, Lenovo doesn't even sell separate SKUs for non-en-US keyboard layout even on external keyboards, not to mention keyboards already integrated into the laptops. But in any case, I'd rather have the physical keys than the TouchBar strip, even if accompanied by a laser-etched keyboard layout of my choice.

> You can make the touch bar surprisingly useful if you can install some third party software and configurations.

From your link:

> I'd recommend BetterTouchTool and things like finger swipes for volume up/down and brightness up/down and showing things like Spotify.

That sounds less good than function keys. If that's the best pitch for the touch bar, that is the very definition of damning with faint praise.

You can already change the Touch Bar settings in macOS to put back the default keys as would be on the physical keyboard; the problem is that it's still not a physical keyboard, and you get phantom key presses as you lay your hands around the keyboard to be able to push any key you want without even looking at the keyboard. Not to mention the loss of the haptic feedback.

The fact that Touch Bar is a "premium" feature, yet many folks would pay MORE to NOT have it, shows you that Apple merely doesn't want to admit the defeat, because there'd be plenty of people who'd pay more just to get the newer hardware without giving up the physical keys.

P.S. The same actually goes for the oversized Trackpad on the latest 2019 MacBook Pro 16" as well: I've enabled Tap to click on MBP16 as on all my prior MacBook laptops for years, and I'm getting phantom clicks everywhere all the time now; it's really annoying, and one of the reasons why 16GB Quad-Core 2020 MacBook Air 13" is on the only decent MacBook out there, even if you have an unlimited budget to spend -- I wish they'd at least offer more RAM on it, if that's their only actual professional machine at the end of the day!

Stubbornness may be a pattern from a computer hardware company offering only a single button mouse for decades

I really frigging hate it, but one of the best things I ever did was to put a custom version of the standard buttons with free spaces on both sides: now I can rest my hands on the keyboard without continuously activating the sh*tbar.

Don't devour me… But I really like it. It can do a lot more than F keys and I've never really used those.

Similar experience.

Had an app reviewer when my app first launched, who was complaining that 2FA was failing for them, so they couldn't allow the app to go live.

I was livid. It had worked for EVERY beta tester.

It turns out it was 100% the tester's fault. It "mysteriously" fixed itself. Aka, they realized that the 2FA was via email instead of SMS and finally after 2 weeks of back and forth, passed the app.

I've been having similar issues with one of our apps, the reviewer can't seem to log in and keeps getting network error messages. No customers have had any issues, I've tried logging in to multiple accounts including the apple reviewer account on multiple networks and I have no issues whatsoever. It's really frustrating.

I had the same issue once and was convinced that I must have pointed the reviewer account to the wrong server. I spent 2 days debugging before I finally asked the reviewer to check their network connection, I was approved the next day. They did send a nice response admitting the issue was on their end, lesson learned.

> lesson learned

Did they learn a lesson, or just you?

Just me, spend ~15 minutes sanity checking then just ask them to test again.

Yep, I've been hearing a lot of issues like this for the past week. It's definitely an issue with their internal test servers, and even though hundreds of different apps are having the exact same issue, they keep insisting it's the devs fault...

Apple takes 30% of all sales and yet can't even hire skilled quality assurance workers to run the approval process for their App Store?

There needs to be real competition in the mobile app distribution space because this is absurd.

Apple said they review 100,000 apps per week.

I don't think anyone can do that sanely at scale.

Which is why nobody should try.

1,000 - 2,000 dedicated quality assurances workers could review between 1 to 2.5 app per hour each week. Adding more personnel cuts this number down drastically.

It certainly can be done. Besides, this is a problem Apple has decided it can handle, since it decided that its customers can't benefit from competition between app stores with different approval processes.

> 1,000 - 2,000 dedicated quality assurances workers could review between 1 to 2.5 app per hour each week.

Are those people even out there and available?

I mean, maybe there are right now because of Great Depression II, but were they available from 2008 to 2019?

As a company, Apple is generally against remote work, with only grudging exceptions, so that's another issue in hiring.

> Are those people even out there and available?

There are over 4 million of software engineers in the United States alone, and I'd wager that many of them are capable of doing QA. Apple is a company that is able to pay competitive wages for their talent.

I'm a software engineer, and I would never want this job. It's got to be incredibly boring and tedious.

Most reviews are for minor app updates. "Bug fixes and performance improvements." Ho hum. Twitter and many other companies release app updates every week, just because they can.

I suspect the job of app reviewer has a pretty high turnover.

> I'm a software engineer, and I would never want this job. It's got to be incredibly boring and tedious.

That's cool, but testing roles exist throughout the industry and some people choose QA as a career.

I wouldn't want to be an IT support specialist, it sounds like a boring job to me, but that doesn't mean that there aren't a million career support specialists employed by trillion dollar companies like Apple.

I'm sure people would line up to be paid well to work on Apple's QA even if you wouldn't.

To be fair, software engineers are in the kind of luxurious position where we can actually say something like:

I don’t enjoy doing this job so I won’t do it.

I don’t think that’s true for the majority of people, who just happen to do a specific job because they’ve been trained for it and it pays the bills.

Especially the fact that QA folks don't need to be software engineers or even be paid SWE wages.

Some software engineers are in it for the pay. If you offer them a relatively easy (even if repetitive) job for the same pay, they will jump on it. You can't judge these types of thing based on your personal preferences, you have to take a step back and look back at all the people you knew in college, I think you'll remember some who would be perfectly fine with this line of work.

But, you're a software developer. As a developer testing isn't the exciting part of your work.

I'm also a dev and have had the chance to work with top notch QA testers. A good QA engineer is a blessing. Unfortunately that is not what an apple app reviewer does. Their work is much more boring.

Microsoft used to have far more manual testers than that.

2000 testers isn't unreasonable.

In my opinion, legitimate competition between App Stores would make the iPhone strictly worse for myself and for everyone I know that owns an iOS device. For me, the mandatory app review process is the big differentiator between the iPhone and Android and is the main reason why I have not switched.

As a consumer, I'd rather Apple sometimes do a bad job and sometimes piss off developers than do nothing. I'm certainly not saying that Apple is doing a good job, but for most end users, the alternative is strictly worse.

I don't think the problem here is with the QA workers. This is clearly a bug in the underlying internal test framework, which the QA workers have very little info about. And the likelihood of a given worker seeing enough of these errors for them to realize it's an issue with the system and not the app is fairly low.

The real issue is that the engineering team who maintains the internal app checking system 1. needs to have infrastructure to detect abnormal amount of a given error and 2. need to notify the QA team so the QA team can communicate it with the devs, rather than just blaming the apps.

You'd think people would look at the initial healthcare.gov mess and make some conclusions.

One of which should maybe be "Don't strictly isolate teams, with unowned space between their output and the next team's input, and no method by which post-delivery failure reflects back on them."

Is this for macOS?

We have the same issue and have never been able to get our macOS app approved (not a big deal but... annoying).

iOS, we don't have macOS apps so haven't run into it there but could be a similar problem.

Latency issues? Perhaps the reviewer is on the other side of the globe?

If it can help you, you should know that they test everything over a VPN that doesn’t support UDP. So if your app makes use of UDP you’ll need a fallback method.

What kind VPN doesn't support UDP!?

For example, I've never managed to establish any sort of UDP connection over an AT&T line, neither home nor cellular.

UDP on AT&T and other carriers is just fine, but you need to do NAT hole punching or proxy the UDP packets. See my comment to the grandparent.

What, so iOS can't run UDP-dependant apps at all?!

UDP is fine. We have apps on the App Store that use UDP. This is likely a NAT related issue. That is not going to be an issue just for App Store review, but also for tons of other networks out there. As of lately, carrier-grade NAT deployments are very common.

It's usually impossible to establish a two-way UDP "connection" between two peers that are both behind NAT. This varies depending on the type of NAT. If just one peer is behind NAT you can typically establish the "connection" using NAT hole punching. If both peers are behind NAT you may need to proxy the UDP packets using an intermediary server.

There are protocols for hole punching, such as ICE (https://tools.ietf.org/html/rfc8445), but you can also roll your own - if you control all endpoints.

"Connection" in quotation marks because UDP is a connection-less protocol, but the NAT port mappings that are established are sometimes referred to as a connection.

Firebase auth?

We once got rejected and they sent a screenshot back of an error. The screenshot wasn't even our app.

May I ask: if it was, how was that situation resolved?

It's been a few years since I developed for iOS, but I guess via the "escalate this issue" button in the review dialogue.

So many of our updates were first rejected by a reviewer in the first round for bogus reasons and after escalating them were quickly approved. With both of those steps taking a few days each, this made updates on iOS such an annoyance that we put it on a slower release cycle than Android.

Apple test everything on a VPN. This issue took me 2 weeks to resolve, and they had to whitelist the IP addresses for the provider I used :(

It's the inconsistency that makes me worried every time app review takes longer than a day. And then that dreaded message "New Message from App Store Review Regarding xxx" arrives, for something that has been in the app since 1.0.

I've honestly been successful just retrying, uploading and submitting the same build. Got it through the 3rd time.

Wait, there are actual people reviewing every app update on the app store? Doesn't that require crazy amounts of manpower? Are they code reviewing or testing the app or what?

Yea... Thats what that 30% pays for.

No, that's what the $99 a year pays for. You can create and upload a free app to the App Store and Apple gets nothing.

You realize both things can pay those salaries right? Paying customers subsidizing non-paying customers is rather common. Also you know free apps have in-app purchases right?

Not every free app has in-app purchases. My city, Seattle, has an app called Find-it, Fix-it where I can report potholes or abandoned cars. One Bus Away is an app that shows bus arrival times. I have grocery apps that show me what's on sale and give me digital coupons. None of these apps have in-app purchases.

If no apps had in-app purchases, there's no guarantee that Apple could still pay those salaries.

By Apple's definition, these Apps have not contributed anything to the App Store and Apple.

Mind Sharing the reason for downvote? That is what Apple state in their reply in multiple outlet and emails to developers.

Your app helps Apple sell devices and their margins are large.

Fewer than 1% of the apps in the store will have any effect whatsoever on Apple's hardware sales. Easily 99% of apps are long tail products that don't influence prior decision-making.

AS for margins, once you factor in Apple's high spending on R&D and engineering, their margins are fairly normal. Apple are financially successful because they sell high quantities and don't chase the extreme bottom of any market. Notice for example how they don't (currently) offer any mainstream external displays.

Interesting how I'm being voted down here, but nobody wants to disagree with anything I said. Is what I said even remotely controversial?

No code review since you only upload a build. The reviewer usually runs the app and pokes around a bit. You can provide them with test logins if it is an authenticated app. They have certain things they look for (errors, payments not through Apple, etc.)

I believe they run a bunch of automated test on an internal test server, maybe some parts get flagged and re-tested manually if I had to guess.

They verify that the app preforms what it is supposed to be doing and doesn't negatively impact the device.

A code scanner will be run that examines the system calls and makes sure that it isn't using internal/undocumented APIs that may cause the app to fail when the operating system is updated.

And yes, this is done for every app and every update. Free and paid. Yes, it requires a crazy amount of manpower.

This is also something that introduces a human component to the review process - it is possible to get someone who misinterprets how the app is working or how a particular rule is applied to the review of the app and human mistakes can be made.

The Apple code scanner is buggy. I had an app rejected for an alleged call to an internal API that the app does not actually call. I had to appeal to the app review board, who approved my build, but it delayed a critical bug fix.

Friends have seen the same problem, with different bogus API violations reported.

It's not particularly smart.

> Wait, there are actual people reviewing every app update on the app store?

Apple's made themselves the sole arbiter when it comes what software is allowed to run millions of people's phones, so I'd hope so!

Imagine the bureaucratic nightmare that would erupt from automating that process, and the businesses that will live and die based off of an automated filter deciding whether or not their products can be sold to users who want them.

> Imagine the bureaucratic nightmare that would erupt from automating that process, and the businesses that will live and die based off of an automated filter deciding whether or not their products can be sold to users who want them.

Google is doing that right?

I'd sure hope not. Surely that would draw the ire of the FTC or other regulatory bodies.

Stuff makes me wonder ... what does it take to be an apple app reviewer? Could I do a better job?

I suspect the problem is not primarily one of individual skill. It's one of volume/workload and incentives that don't prioritize fairness to developers.

It's probably exacerbated by the lack of sideloading and alternate app stores on the platform.

Yeah I did some googling and it seemed to indicate the reviewers are actually at Apple... with the scale of work I would expect they were not / be someplace cheaper.

Could sti be hired at Apple directly, but at another city/country with cheap wage costs. No clue though where they have their employees.

What Apple needs is to invest in reviewers that are also good developers who can then spend half their time reviewing apps and the other half developing tools and processes for improving the review process.

I'm no longer engaging with you, because you completely rewrote your comment after I replied to it. That's highly misleading to readers.

The reply below should be flagged and moderated for completely unacceptable behavior.

That's almost a free bug report. That's a good thing. Investigate.

> the reviewer asked "How does the app utilize Touch Bar and where can we locate these features?"

This kind of arrogant behavior really makes me mad.

Why is this arrogant? If they are asking about the Touch Bar, it's most likely because the developer mentioned adding some feature to the Touch Bar in the release notes and it is not apparent what that feature is. You can't advertise something that doesn't exist.

No, the developer did not mention Touch Bar in the release notes, and the app has no specific Touch Bar features.

Nothing about Touch Bar is required in the App Store guidelines.

You either referenced NSTouchBar or included a library that did so. Sometimes it is as simple as a error reporting library or ad network client trying to enumerate the device hardware.

The Human Interface Guidelines explicitly lay out what is allowed and not allowed with the Touch Bar. For example, you can't turn it in to an extended display. https://developer.apple.com/design/human-interface-guideline...

> You either referenced NSTouchBar or included a library that did so.

Who are you talking to?

You were speaking authoritatively about the underlying code of an app that had a review issue related to Touch Bar, and made an incorrect statement that there are no design requirements for that feature. I was giving you guidance on why that item gets flagged for review.

> You were speaking authoritatively about the underlying code of an app

I know the developer, who was talking about the rejection.

> that had a review issue related to Touch Bar,

Several other developers chimed in and said they randomly got the same exact question. It's not a "review issue" per se, although it does prevent the app from getting approved. It may be some weird kind of obnoxious poll Apple is running. (Apple really wants devs to support Touch Bar.)

> and made an incorrect statement that there are no design requirements for that feature. I was giving you guidance on why that item gets flagged for review.

No, this is an incorrect interpretation of what I said. What I meant was that the App Store Review Guidelines don't require you to support the Touch Bar. You can have a Mac App Store app with no Touch Bar customization. None of my apps have any.

Yup, sounds very much on par with our experience. On the first version of our app, we especially mentioned in the review comments (and configured in the release build) that we do not support iPads, as that wasn't a priority for our initial release and would have required additional testing work. Review came back as rejected with a comment along the lines of "Hey, why don't you support iPads?".

False. If you are using touch bar libraries you MUST have touch bar features and the reviewer can ask you where they are.

This really shows why apple needs to be strict with devs. They will include third party code (ad networks etc) without enough care - the networks then try to device fingerprint etc.

And 98% of the touch bar library use with no touch bar feature is abusive.

They should let devs appeal, but if a dev lies and claims no touchbar library use when there is some, ban their account permanently. The reviewer in these cases may want to see the touchbar feature that justifies library use, the app author saying they don't have any touchbar feature means use of library is improper.

So many devs do NO due diligence on the third party libraries they import.

> If you are using touch bar libraries you MUST have touch bar features and the reviewer can ask you where they are.

Ok but there are no touch bar libraries in this case.

> They will include third party code (ad networks etc) without enough care - the networks then try to device fingerprint etc.

Not the case here. Also, if this issue was triggered by code, then it would come up in every update, instead of just occasionally at random.

My point is simply there are guidelines around touchbar - despite your claims. Stop trying to claim that there is no guideline - as I have repeatedly pointed out - if you are using touchbar libs to fingerprint devices for ad networks - that is not allowed as one example.

If this app wasn't doing any of that, then great! The reviewer was wrong. But to claim no rules around touchbar usage and calls is entirely false.

> Stop trying to claim that there is no guideline - as I have repeatedly pointed out

As I have repeatedly pointed out, I was never trying to claim that. You are arguing against a straw man.

You're right. You win. The straw man is defeated.

I have a hard time following you: it's been clarified that the code in question didn't reference the touchbar, neither directly nor indirectly. That's the whole point.

I wonder if that is because of the technical skill required to do app reviews. If you are "too competent" as a coder, obviously you'd go and be developer somewhere else instead so I suppose it is kind of a requirement for people who reviews app submissions to not be as competent as developers as those people submitting the apps?

Then Apple should pay their reviewers enough that they're able to do their job without having to jump ship to another employer. It seems like Apple doesn't care enough to do so, though.

It's too bad that there isn't real competition on iOS app distribution.

That's not what I was implying at all. It's not about money. If a person learns to actually write software on their QA job, why would they not do it for a living? In most cases, it's a more satisfying job to have. The assumption I made was that if a QA person who also reviews code a lot becomes really good at the job, they are very likely to try and become a developer themselves.

I doubt you have to be a full on developer. Probably along the lines of a QA tester. Some overlap for sure with developers but a different skillset mostly. I think it would be interesting to work as one for a while just to see how the sausage is made though.

I agree but there is a thin line. I've seen a lot of really good QA testers slowly start patching issues on their own and grow into proper developers. I think there is a very small window where a QA tester can be the best QA tester he/she can without getting into the developer territory especially if it involves reviewing code.

> I saw another developer today say their app was "rejected" because the reviewer asked "How does the app utilize Touch Bar and where can we locate these features?"

This might not be an Apple policy, as much as a reviewer just holding the app maker hostage until they get their personal feature request approved.

Reply on news.ycombinator.com