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.
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.
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.
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.
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.
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?
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).
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.
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.
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.
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.
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
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!
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.
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.
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...
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.)
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?".
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?
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.
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 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.
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.