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.
They have the equivalent store-brand label for that.
Wow so this isn't even 'new' on the Macbook... I had no idea the gen 2 carbon did this...
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.
(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 hope they release an Apple Silicon MacBook still without Touch Bar.
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.
See here for the whiny text file I've been keeping notes in: https://gist.github.com/Efreak/d0d327517ab806e2abc9f193ad5ea...
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!
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.
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.
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.
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.
Did they learn a lesson, or just you?
There needs to be real competition in the mobile app distribution space because this is absurd.
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.
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."
I don't think anyone can do that sanely at scale.
Which is why nobody should try.
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.
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.
2000 testers isn't unreasonable.
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.
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.
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.
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.
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.
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.
We have the same issue and have never been able to get our macOS app approved (not a big deal but... annoying).
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.
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.
Friends have seen the same problem, with different bogus API violations reported.
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.
Google is doing that right?
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.
It's probably exacerbated by the lack of sideloading and alternate app stores on the platform.
The reply below should be flagged and moderated for completely unacceptable behavior.
This kind of arrogant behavior really makes me mad.
Nothing about Touch Bar is required in the App Store guidelines.
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.
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.
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.
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.
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...
Who are you talking to?
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.
It's too bad that there isn't real competition on iOS app distribution.
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.