Oh well, that's what you get when decisions are made by a combination of algorithm and sweatshop call center.
I have to admit that software for blind people sounds like a fascinating specialty. I'd love to get into it but being not-blind (came close though) probably gives one false theories on design. I love the angle of making software that requires only a microphone and a speaker, it would be an amazing way to rethink the world.
Both to answer your questions, but more of the first one. Blind users still can tap and use gestures as good as everyone else, they just can't find particular buttons.
People say that about the web, too. "If you write semantic html and use aria tags, it's accessible".
In theory, yes, but in practice it's probably a very bad experience unless actively worked on. For instance, I worked on a "seat chooser" once, that actually was very keyboard friendly and worked with screen readers. But trying to actually use it to select a specific seat for a blind was impossible. A seeing user can just press the seat directly, or tab quickly until the correct one is selected. But with voiceover it had to read out "seat 7B, $5 extra, not occupied, extra leg room, aisle, power outlet".
An actually useful way of selecting a seat would be to specify a seat directly, or some kind of filter for wanted features, a table or whatever. Not just take a visual way of presenting something and slap on some voice data.
> People say that about the web, too. "If you write semantic html and use aria tags, it's accessible".
The two aren’t comparable. It’s not even close. I take it you haven’t actually built an iOS app.
That said, for sure, you can build a custom UI that is inaccessible, but with iOS if you build something that is close to conventional, you’d be surprised by how well it works.
> for sure, you can build a custom UI that is inaccessible
Provide a non custom UI alongside the custom one. Use tabs to offer ‘graphical’ and ‘list’ views.
The comment I replied to said this:
> In theory, yes, but in practice it's probably a very bad experience unless actively worked on
It’s also not even clear that the UI they described was that bad for blind people.
The voiceover information is relevant to making a selection, and the blind person can’t see that data so it needs to be read to them at some point. Of course it’s not as easy to use as if you can see it. They describe a search function, and I propose a plain list, but there isn’t a lot of evidence that either would require less interaction.
> It’s also not even clear that the UI they described was that bad for blind people.
Obviously it's bad. Becoming blind doesn't magically make you infinitely patient. Having to listen to a whole listing of airplane seats one by one with unnecessary details when you just want to book a place would probably make you crazy. Well it's the same for your blind users.
So how does a blind user distinguish between each seat's offerings, then? How might they quickly skim those offerings to get a decent idea of what their options are in a way even remotely similar to the speed and efficacy of, say, icons?
> How might they quickly skim those offerings to get a decent idea of what their options are in a way even remotely similar to the speed and efficacy of, say, icons?
They don’t. Why would you expect them to be able to?
Accessible does not always mean usable. That is the whole rub of the submitted link. The developer has better UX for blind users and the reviewers discard that as a criteria.
But you can't suddenly rate it as spam just because other similar apps exist.
Certain criterias are only valid for the initial release and not for updates.
Totally. But there has to be some middle ground. If you did a 180 then do a manual review. If the app is fundamentally the same with a minor bug fix then why review it?
I’ve only worked with the chrome store which is obviously open source so static analysis doesn’t work here like it does there.
It’s a good question. My hot take is diff the syscalls. Easy enough to do. If you changed a bunch of them then big review. It’s not perfect but in 30 seconds I couldn’t think of anything better. My first hot take was app submit its own test scripts for an emulator but that could easily be gamed.
“If you did a 180 then do a manual review. If the app is fundamentally the same with a minor bug fix then why review it?” would have to be a different thing.
Apply that logic to any service where access is a privilege and see how that works. (i.e. getting away with doing whatever you want once you are inside restaurants, forums, HN, etc.)
That's how Steam works. I think it's a much more dev-friendly policy, because in practice there's really zero reason to review Adobe or Microsoft or OmniGroup app updates since you know they won't turn into scam apps overnight; it's weird to me Apple hasn't done a "Trusted Developer" program to exempt the biggest devs from this headache. There's no reason why the weird clone apps (like the app that shows up 3 results down, when you search for "1Password", that trashily has the exact same blue ring and keyhole but slightly different background) should be treated the same as apps by hardworking, honest, trustworthy developers. People would cry foul for unfairness but there's also no way of letting the hundreds of thousands of App Store devs all submit updates with no review, you'd end up with something like the Chrome Web Store where apps get bought and filled with malware all the time.
This. Reputation based review standards is pretty low hanging fruit.
You literally already have an ongoing relationship with the party in question, which is usually one of the biggest hurdles to reputation systems (new users).
I expect the real reason they haven't moved in this direction is fundamentally App Store review is seen as a tool of ongoing control rather than quality. So the more frequently something has to pass through it, the better.
If Apple can "find an issue" with your app every time you update, that's a very different relationship than an ongoing approval.
PS: Would also require developers to inform Apple of any company sale / dev team replacement to prevent abuse (Didn't mention you sold your company? Ban).
With a reputation system you'd still want to do your due diligence and manually check things. Even the most trustworthy people make honest mistakes sometimes.
The problem with this is that these big trusted tech giants have abused the trust put in them to break compliance rules of the app store because they can (facebook for example).
> in practice there's really zero reason to review Adobe or Microsoft or OmniGroup app updates
I can totally see Facebook pushing a update which uses internal APIs to access private information outside of its sandbox.
Honestly apps need to be verified after every update for much of the same reasons they need to be verified initially. The issue is the verification process itself, which sometimes blocks legitimate developers while also sometimes allowing scam apps.
private api issues are usually caught with automated binary scans. You can obfuscate them to avoid detection but manual review wouldn’t help with that either
Apple security is based on developer goodwill. If you’ve used private API, you did it by mistake. That’s how their security model works. That’s why they’re scanning binaries for unobfuscated calls. They don’t have an answer against malicious developers other than acting post-factum.
Wait, did you just imply that apps by certain big companies dont need a review because you think these special biig companies deserve a bit of extra trust? Fascinating, how did you arrive at this conclusion?
He actually arrived at the exact opposite conclusion: all apps should be reviewed after each update because not even (or especially) big companies can’t be trusted.
This is fair, but I think we can agree that rejecting an update on grounds of its basic features being duplicative, when the feature set has not changed -- which is what happened here -- is pretty absurd.
Well, first off, big developers are known to occasionally ship features that Apple wouldn't like. Facebook used their enterprise cert to ship a spyware VPN, and Epic used a hotfix to ship a direct payments feature in Fortnite. So there's no reason to treat Adobe or Microsoft as more trustworthy based on reputation when you're specifically imposing business requirements on them that they won't like. If you're not looking at what they submit, eventually they are going to try and ship something under Apple's nose.
Second, Apple really hates the idea of special rules for specific developers. When they make an exception for, say, Kindle; they don't just approve Kindle. They change the App Store rules to say "apps that are just viewing content purchased on other devices don't have to use IAP". The closest thing they have to special rules are entitlements; things like Zoom's special camera multitasking entitlement comes to mind. However, even that ultimately wound up being something other developers of video chat apps could ask for, they just didn't say anything about it until they got called out on it.
The 1Password example you cite is plain 'ol trademark infringement. I imagine Apple isn't particularly interested in doing trademark enforcement for third parties, though I'm pretty sure they wrote the rules to allow them to do exactly that. This is definitely something where Apple could be more proactive, but there's a limit to how much they can do before you get people complaining about Apple going overboard.
> Apple really hates the idea of special rules for specific developers.
You mean "really loves" special rules for specific developers. They won't change the public rules, of course, but backroom deals for private APIs or specific entitlements are a thing.
For security/compliance reasons as in don't trust the developer by default. To be honest, i appreciate this concept as it makes the store more secure for the users.
In the emails from the Epic trial, they had a special acronym just for this: UTB (under the bus) that was used in multiple contexts (so probably not a one off joke).
Apple absolutely runs an internal App Store case law. In fact this specific case law has caused issues in the past, when I knew they had case law covering the thing I was submitting and their low-level reviewers didn't, and resolving this obviously took work.
I was going to write a snarky comment about upgrading too early, but:
"Exploring images with VoiceOver: Explore people, objects, text, and tables within images in more detail with VoiceOver. Navigate receipts and nutrition label values intelligently in logical order. And move your finger over a photo to discover a person’s position relative to other objects within images."
"Voice image descriptions in Markup: Markup lets the user add image descriptions that can be read by VoiceOver. Image descriptions persist even when shared and can be read in a range of supported apps on iPhone, iPad, and Mac."
"Per-app settings: Customize display and text size settings on an app-by-app basis. Bold or enlarge text, increase contrast, invert colors, add color filters, and more for only the apps you want."
"Magnifier app: Magnifier finally becomes a default app on iOS, so you can use your iPhone as a magnifying glass to zoom in on objects near you."
Unpredictable enforcement of rules is the biggest problem with the App Store today. As a small time developer you have to be ready to jump through every hoop Apple puts in front of you, what else can you do really? But then in the next update you get a different reviewer who goes "no those hoops you jumped through were wrong" and penalizes you for it. Rinse and repeat.
According to all the apple apologists on hackernews that think having an open app store ecosystem is bad, "apple knows what's best for me" is the response they should be giving right about now
Hi,
I am the developer of the app in question, accessible hangman, as well as the other games I hve made for iOS.
I am a blind developer myself, that is why I thought htat making games for the blind would be the best approach for me. I chose Apple's platform, instead of Android, because of the way that SwiftUI lets me write the UI via code and change visual appearance of buttons, etc just by adding button shapes, icons, etc.
Now, I do understand that every app needs to go through review every time it is updated, of course. But this is verion 2.5 of the app, this is in no way the first or second version.
So yes, Apple seems to find a new issue when someone just finds a little light in their brain clicking into place, the first version had no such issue. But after 4 or 5 versions, oooooh wait, your app does not comply with blah blah blah.
So, yes, I think this is unfair.
Anyway, I have some news regarding this whole hing, the update was pushed through and approved finally so I'm a bit less worried, they still say I should talk to them on the phone so they're going to schedule a call with me.
Let's see how this turns out. Thanks all.
I’ve had this sort of thing happen to me as well. Often different reasons, for example: one reviewer didn’t like my permission text for camera access.
Twice now I’ve had to appeal the review. Each time the appeal worked in my favor and I was able to publish again. Keep in mind, as part of the appeal process they call you, so you will need to be answering unknown calls for a while. But the people I’ve talked to that handled the appeal process were all very nice.
Speaking of accessibility, do you know how insistent they are on calling? I'm not an iOS dev so it's a hypothetical question for me. However, I can't speak on the phone and I'm amazed by how many problems that's still causing me in the age of jetpacks and 3D printers.
Sorry for the tangent, but as a blind user, how do you manage to use HackerNews? I can't get a screenreader to pronounce indentation as the indentation of the comments is done with gif images as spacers. Do you know of a HackerNews app or alternative website that works better form an accessibility poinf-of-view? (I'm using NVDA on Windows).
Like so many things, it only seems awful in retrospect. Perhaps it is time to revisit the indentation implementation Hacker News code and change it to use nested lists for threads. (I wonder how HN is implemented and how the code is updated. It could be anything from a single file lisp program running over a single text file to a whole cluster of more traditional specialized servers. (Is it rude poking around DNS looking for clues about a backend implementation?)
Actually, I think it would be rather straightforward. I'm a bit embarrassed for HN that they're still using tables and spacer gifs and see it as an intentional pushback on "caving" to modern web techniques. Despite CSS being 20 years old at this point.
Maybe you're right. I had a poke through the HTML a while back, and there are actually tables-within-tables for some reason. It was way more complicated than I expected it to be. It does seem kind of weird that it still uses tables for layout, when there are so many easier and better ways to do it.
CSS could match the current appearance exactly. I bet if dang put up the code on GitHub he'd get PRs fixing tons of stuff within a week.
Usually when people say something would be a simple change, they're not aware of the underlying complexity.
This is a different case -- HN genuinely does not have a complicated UI, and it genuinely would not be difficult to make a UI that worked better with screen readers. It would not be difficult to rebuild a HN UI to stop using tables without even making any visual changes to what the site looks like.
There is very little complicated functionality going on in HN pages. They're paginated, they don't have a ton of content, they don't have a lot of complicated UI controls they need to support. They're mostly static pages with some very minor form controls.
In this specific case, there really is no excuse for HN to be screenreader inaccessible. This would not be a complicated conversion for even a single experienced web developer. You wouldn't need to use React, you wouldn't need to use any 3rd-party library or dependency at all. You wouldn't need complicated CSS features, you wouldn't need to redesign the UI.
Honestly in a lot of ways, the current HN table layout is more complicated than it needs to be, the generated HTML could be a lot simpler. Really, there's a difference between being "retro" and using what works instead of chasing modern trends, and having outputted HTML that's broken and hacky, and was broken and hacky even at the time it was released. HN is very solidly in the latter category.
> Like so many things, it only seems awful in retrospect.
No, it seemed awful at the time as well. Table layouts were already long obsolete by the time Hacker News was launched. Here’s a discussion from over a decade ago on the subject:
> If this were anyone other than pg, you'd all be excoriating the developer for living in the 90s.
> The big benefit is to accessibility through screenreaders or other alternate clients.
> Look, do what you want. You want to write bullshit markup, be my guest. But there isn't a single web dev in this community who would code output like this for their own site. They're just too chickenshit to tell you.
And here we are, a decade later: nothing has changed, we’re still having the same discussion about the same flaws, and it’s still causing problems for people with disabilities. It doesn’t “only seem awful in retrospect” – it has been awful all along and people have been pointing it out for over a decade.
Here's a talk by Sina Bahram from five years ago -- at around 6:30 he specifically addresses how inaccessible HN is to a visually impaired user. Nothing that he mentioned has been addressed: https://www.youtube.com/watch?v=G1r55efei5c
I'm not sure I agree that it does. HN ships a bunch of extra DOM content that it really doesn't need to ship. If you're optimizing for page size, the HTML could be lighter.
The site does what pg wants, but he really shouldn't be proud of it for doing what he wants well. It's not that the HTML is super-optimized but that the optimization has tradeoffs. It's more like whoever programmed it is very familiar with tables, and when all you have is a hammer everything starts looking like a nail.
>pg: "Arc embodies a similarly unPC attitude to HTML. The predefined libraries just do everything with tables. Why? Because Arc is tuned for exploratory programming, and the W3C-approved way of doing things represents the opposite spirit.
>(...)
>Tables are the lists of html. The W3C doesn't like you to use tables to do more than display tabular data because then it's unclear what a table cell means. But this sort of ambiguity is not always an error. It might be an accurate reflection of the programmer's state of mind. (...)
... and yes, that decision is baked into the server, web app, HTML and forum code (which to my knowledge have never been changed in the standard Arc distribition,) making it a de facto requirement for all Arc based webapps and a PITA to change.
Yes, a nested list would clearly be the better structure here. Or even a description list (dl) with the comment's metadata in a dt and the comment in dd.
Is there any HTML that can be wrapped around the spacer-indents that would mark them as indented for screenreaders? If I knew more about this I’d propose that as a unified diff, so that they could apply it to their templates and solve this, but I don’t :(
(I know there’s ways to restructure it completely to do this, but I like focused and surgical changes that don’t affect anyone who doesn’t notice them. Opinions vary on that.)
For screen readers, there's the "tree" aria role[0] which lets you mark a specific element as a tree, and mark the elements within it as items at a certain level.
Tree wont' be a good fit for comments because one would want to read content by line/word/etc. while a tree item is presented as a whole thing by the screen reader so it's only good for small textual items.
I built hacker news client HACK for iOS, MacOS and Android which scrapes the HN page HTML and this is how I implemented it - when you collapse a comment, it tells you how many child comments that comment has.
You could try my app to see if it’s user friendly for accessibility (I don’t have much experience with it so I am not sure).
Just wanted to take a moment to thank you for all your hard work. Your app is excellent and has quickly become the dominant way for me to interact with Hacker News. It lets me silo my reading and has been a valuable tool in preventing Hacker News from being a distraction in my work day. In the entire time I’ve been using it I’ve only come across one bug! (On the iPhone, the UI can very very rarely lock up when transitioning from the comment view to the post list view… and I do mean very rarely, it’s so rare I don’t care, it’s still 5 stars in my book. I only mention it because the thought occurred to me that having to force quit the app might interfere with crash diagnostics giving you information about this particular bug)
I had someone else mention that rare bug too but unfortunately I haven’t been able to reproduce it to be able to narrow it down. I will see what I can do to fix it.
I'm on a PC and don't currently use a smartphone, but thanks for the suggestion and I will bear it in mind, and give you some feedback if I do use it. I'm sure others on hear could give you some feedback in the meantime.
The hackerweb.app site seems very good for accessibility. It uses nested lists as others here have suggested.
hn.premii.com is a little more difficult to use (in terms of getting from the list of posts to the comments), but still quite usable. It uses a slightly more complicated layout of divs and lists.
Hi, I'm using the site, what do you need indentaiton here for?
NVDA can beep when it finds a space before the beginning of the line, not sure what you mean with the gifs thing.
IO'm new to this site anwyay I signed up when a friend told me this thing was #2.
Just to avoid any confusion, I'll preface this comment by saying that I'm not blind, but in the last few months have mostly been using a screenreader to avoid the migraines I was getting from even small amounts of screen use. So, in other words, I've used the site visually in the past and am now familiar enough with screenreaders and other sites to know waht an accessible site is like.
Basically, the comments on HackerNews are laid out in a tree form. When you first load the page, the comment tree is expanded. You can collapse them by pressing on the little '-' next to the comment.
With the tree expanded, NVDA just reads the comments as a linear stream. Of course, many forums are structured linearly, but the advantage of a tree layout is that you can have tangents like this one, without interrupting the main flow of the thread. Reddit is very similar in that regard. If NVDA can't read the tree structure, it's hard to know what is going on. From my experience, using the arrow keys ( e.g. CTRL + DownArrow ) will not report the indentation, whereas using the numpad keys ( e.g. Numpad 7 or Numpad 9 ) will report indentation, but will not indicate how deep the indentation is, so that isn't terribly helpful. It may be possible to change settings in NVDA to get this to work, but I doubt it, which leads us to the technical implementation.
As others have pointed out, the comments are in a complicated nested table structure, which NVDA seems completely blind to, not even recognizing it as a table. Then, the visual indentation is created by prepending the comments with gif images, which act as spacers. The width of the spacers is determined by a 'width=' attribute.
Others who are more knowledgeable than me have already pointed out alternative ways that this could be implemented, such as using <ol> or <ul> tags.
It wouldn't be hard to also criticize the lack of headings, but we can leave that for another day; if this indentation issue could be sorted out, the usability of the site would go up by about 300%. I've almost stopped coming on here since using a screnreader, whereas I used to browse on here a lot -- it's one of my favourite sites.
To the other commenters: thanks for the useful suggestions and insights; this had been bugging me for months.
I wish you luck. Thanks for writing accessible software.
I am not (visibly) disabled, myself, but write software for a demographic that has a statistically high number of folks dealing with various challenges. Accessibility is a big deal for me (as is Usability –Accessibility's redheaded stepchild). I do things like provide localizable accessibility labels, as well as support for things like colorblind access, high contrast mode, and reduced transparency mode.
I have also released over 20 apps in the App Store (myself), since 2012, and am the proud recipient of many app rejection notes.
One of the more annoying things, is that the reviewers are required to select from a menu of rejection reasons. They can't just write "You need to add a plist row to ensure the new permission we just added is presented to the user." Instead, they have to send you some generalized "blanket" reason that includes that requirement, among a list of others that don't apply.
It's easy to panic, when we get these.
In my case, I sometimes need to break out a Ouija board, to figure out what they mean.
Fortunately, I have had very good luck in getting folks on the phone. They still tend to "beat around the bush," but you can usually figure out what they want.
As the father of a red headed step child, I just want to jump in and let all red headed stepchildren know how much this father of a red headed stepchild loves his red headed stepson. Carry on...
What would be a non volatile equivalent term? (Not being sarcastic. I don't see it as a good term I just can't think of a neutral term of similar meaning.)
Odd one out? Even difficult child? beyond that I’m not sure as I think it’s meaning can change from person to person. Key takeaway is just don’t use that term.
Got me thinking about that too and doing some googling I didn’t find anything that fits perfectly into what OP wanted to express. I suppose it’s best to rephrase it entirely.
I won’t ask dang to remove it from the post, because that would actually make this conversation seem out of place, but I doubt that I’ll use the term in the future. Won’t be the first anachronistic term I’ve stopped using.
Not a big deal. I can always work to modify awkward habits.
Sorry if I my comment made you you feel uncomfortable. I see no evidence that any red headed stepchildren or their parents have been offended here. I just always feel when I hear this phrase, that as someone with a vested interest I should give the red step children a shout out.
So you can in no way see how the phrase might make someone feel uncomfortable and that it might just be easier to use another phrase, which, OP already said they’d noted and are fine with doing? If it’s not an issue then phrase it differently.
They have a call scheduled with him, and have approved the app now. The App Store review process is a bit confusing - at first, he replied to the e-mail from the Reviewer, who replied saying there's nothing he can do. What he should have done is explained that there's a process by which you can get a different group, the App Review Board, to look at your appeal. That is different than replying in the "Resolution Center" or replying to the initial rejection e-mail.
If Apple was more developer-friendly, which they are absolutely not as a company, you would think that all replies to rejection e-mails should go through this board. But unfortunately, that's not the case - you have to go through a different process to submit an appeal, which is what it sounds like the blog poster has done (to get a call with them scheduled.)
I've tried in the past for other issues. You get on the phone with someone who has no power to help, and that's all you're told. They don't do a good job.
Same here-- had a call with them but they don't really have much power or decision making abilities. Similar to customer service reps. Mostly script based.
I wholeheartedly disagree with this assessment of Apple. As a long time business owner and developer, I've had nothing but pain as a developer working with Apple technologies.
We've created over 100 cross platform experiences, and I'm seriously considering a #FckApple tattoo.
I know that feeling. I was going to write a post about how Apple's review process made us change our how business because we couldn't afford to fight with them even when we are in the right.
Unrelated to your comment, I would love to know more about your dev setup. I am a fellow blind developer and have found XCode to be a mixed bag accessibility wise.
> Anyway, I have some news regarding this whole hing, the update was pushed through and approved finally so I'm a bit less worried, they still say I should talk to them on the phone so they're going to schedule a call with me.
This is the standard corporate playbook at this point.
Screw over lots and lots of people, then opponents will find some sympathetic cases like this one and put them in the news to put pressure on the company to do something.
The company fixes the one specific case that made the front page. Neither the million other instances, nor the systemic problems that led to them, are addressed. But if anyone refers to the case that made the news, the company can say that it turned out alright. "The system works."
It only turns out alright in that case because it made the front page. Things are still broken everywhere else.
Honestly just wanted to give you a round of applause. I can’t imagine the tenacity it takes to get to the point where you can ship an iOS app as a totally blind person.
It used to be very bad until I contacted support about a slew of accessibility problems. can you believe that the little dropdown to create new app/new bundle was inaccessible? So was testflight......
Apple has thousands of reviewers, sometimes some of them make mistakes. The best way forward is usually to just submit again, most likely you’ll have another reviewer then that sees things differently.
I don't really understand that every app needs to go through a review honestly. That is a rule we got with mobile OS and they don't really deliver on security ambitions.
"I chose Apple's platform, instead of Android, because of the way that SwiftUI lets me write the UI via code"
Unless I'm misunderstanding the feature, this is coming to Android as well (well, it already has, though it's fairly recent), in the form of Jetpack Compose.
Apple killed one of the best voiceover enabled single-player poker simulator about 2 years ago. THETAPoker was absolutely great, and the author invested a lot of time and energy to make the game perfectly self-voicing. Until Apple review falsely identified it as a gambling-app which needs to be banned. The author tried to get someone to listen at apple, and was totally ignored. Now, Apple has a similar poker simulator, called hold'em, which is by far not as good regarding VoiceOver support. It feels like a scam to kick someone from the AppStore who did a very good job just to make your own botched copy-cat app more prominent.
That said, Apple VoiceOver is still one of the best shipped-by-default accessibility systems. However, we have to thank Steve Jobs for this. If it were only for Tim Cook, apple wouldn't even know how to spell accessibility.
> Apple VoiceOver is still one of the best shipped-by-default accessibility systems
Which is frightening, because two years ago I had a terrible experience trying to modify a web app to be accessible using VoiceOver (I gave up after over a week of solid effort).
We couldn’t afford[1] to pay a third party to modify our 100% custom HTML framework[2], and VoiceOver seemed the most approachable for me to try and see how far I could progress on making our web app accessible.
VoiceOver just felt so very buggy - although perhaps the issue was the integration of VoiceOver within Mobile Safari (my dev experience is that Mobile Safari is a steaming pile of problems - current example is that iPadOS15 Safari crashes twice on many pages then goes blank so you can’t use it!).
As a dev, there also needs to be some better online training for using VoiceOver, since small teams do not have easy access to a colleague that uses it.
[1] We could pay 100% blind users to give us feedback, but couldn’t afford to pay a skilled team to consult and do the work.
[2] Custom framework because we started our product before reliable frameworks existed. Modern components are often designed to support accessibility out of the box, which is far preferable!
I was wondering if just my MacBook had an issue since Safari just goes to a blank white when opening New Relic, but I guess Safari is having this strange problem a lot more than that.
I have Google Sheets that have a moderate number of cells (~500k, so 10% of the maximum allowed), and I can’t get mobile Safari to load them most of the time. When they do load, it is invariably impossible to switch tabs more than once within the sheet.
Chrome for iOS uses the same safari rendering engine as third party browser engines are not allowed. So very curious if it works in iOS Chrome but not Safari as it’s mostly the same.
Also for your specific use case (I realise you were making a point) would be worth using the app I guess.
Hmm didn’t know they use the same rendering engine, but the success rate is not the same.
The Google Sheets app is a no-go because it kept using stale data for some reason. The sheets are regularly updated via script, and the app would constantly fail to show recent data.
Well, if you lack accessibility experience, and insist that a week of hackery on a custom framework should be enough, that is not VoiceOvers fault. Accessibility is a serious thing, not something you can do as a side project while waiting till the baby wakes up.
I believe accessibility is critical, and I was expecting to invest months of time and a significant amount of our money on the project. I cut my losses after over a week of full time effort because I was not making enough progress. One personal fault of mine is often the opposite, where I don’t quit early enough, and I keep flogging a dead horse.
Also, I think you are making many assumptions about me in your response: perhaps try to be a little more generous towards others.
Unrelated, but if you tweet photos, please take a moment to add alt text. I started doing it a few months ago and it's remarkable how easy it is not to (and how much of an impact it can make when you do).
The asymmetry in power between 'everyone' and Apple, Amazon, FB is a problem begging for regulation.
If companies are making byzantine and ridiculous claims against other participants, it's bad for business.
This is completely outside the issues of Apple's right to manage apps - if it's going to do so, it has to fairly clear policy and way to redress grievances.
Things like: 'business review' and 'technical review' are separate so that bug updates don't trigger a business reviews. If a complaint is raised to level 2 and there are problems, it goes to some kind of level 3 mediation, possibly by an outside party. It also might be reasonable for Apple to require a small fee for new feature release review i.e. $100 to release a new version and have the business review. They could even consider having 3rd parties do the reviewing and only have Apple weigh in if there is a conflict. Etc..
Arbitrary and bad business operations are not good for anyone in the long run.
Watch Apple suspend this developer now for violating their policy (causing more "spam", a term apple loves to use, to be sent to their accessibility inbox).
This is particularly evil in light of the fact that security updates are bound to OS versions. I tried to update my iPhone the other day to iOS 14.8 for the security patches, but it wouldn't let me. It would only let me upgrade to 15.0. So now I have a choice: I can either have the security patches, or I can have this (previously approved) app. I can't have both.
This specific app is not an issue for me (I'm not blind) but there is another app that I do rely on that has also not been upgrade to 15.0 so I'm still faced with the same dilemma. And unfortunately, this particular app (Foreflight) is iOS-only.
I tried both with the same result. Weirdly, my phone is one of four devices that I tried to update at the same time, all of which were running the same version of the OS to start (14.4.1). Three of those devices let me upgrade to 14.8. Only one (my phone) did not. It's weird. My guess is that I got stuck in some sort of A-B test.
I contacted Apple tech support and they have so far escalated through two levels. The ticket is still open.
When you upgrade an iOS version you can only proceed after an Apple signing server approves that version of iOS for your devices unique hardware identifier. When their server stops signing an iOS version everyone is locked out of installing it.
In the jailbreaking world you can save these signatures allowing you to install that iOS version later at your leisure.
That said, Apple appears to still be signing iOS 14.8. You can check the signing status here: https://ipsw.me/iPhone12,3
(But look up your device model in particular. Sometimes there’s inconsistencies)
Because AppStore is a monopoly and if you want to publish apps for iOS users, you have one course: obey to their draconian rules and arbitrary review processes.
Because Epic didn’t launch the lawsuit out of the kindness of their souls, I doubt they even have what passes for a soul. They also put their case into jeopardy by knowingly breaking the rules first and then complaining the rules were bad.
But they have definitely stirred some publicity (including nongeek audience) around all these practices, which is good, maybe someone is going to have a better case riding this wave.
The fact that one reviewer missed a potential policy violation is no good reason to ignore a policy violation when it’s found.
If violations got automatically grandfathered in, you’d get devs pulling tricks like sneaking barely functional violations into the app so it’s unlikely to be spotted then when they got it approved make it fully functional.
In any case, it looks like Apple is already engaged with the dev to sort this out. They’ve made some major changes to review appeals in the last year or two.
Some of the reasons Apple comes up with for rejecting developers’ apps are such bullshit. Like I can understand trying to stop scams, malware etc. but this gatekeeping based on Apple’s subjective evaluation of the quality of your app when you have no other option for shipping on iOS is the reason why I just don’t consider it a serious platform. iPhones and iPads are more like iPods to me at this point; cool toys with overpowered hardware that do a few simple things well.
There’s also a lot of irony in Apple judging whether or not your app is good enough. Like does anyone actually think Apple is cool in 2021? To me they’ve just become another boring, stuffy corporation like Dell and HP. The iPhone 13 is so incredibly uninteresting and inconsequential that I couldn’t even remember what number they were on when I was typing this comment. That whole launch just came and went.
I have developed over a dozen iOS apps so I am sympathetic to the frustration as a developer.
But as a user I fully support Apple for curating the App Store experience. Discoverability is a challenge when you have this many apps and it's simply not fun having to wade through so many low quality, user-hostile apps.
You only need to look at the Windows Store to know that curation is an integral part of making a store work.
I agree that there is a lot of good to be done by curating apps but I don’t think Apple is doing a very good job of it in general or in specific regarding this.
There is plenty of garbage on the app store and while in this case I’m sure there are a ton of hangman games on iOS, at least this one if offering something the others aren’t. So it’s kind of failing to deliver on the stated premise for the rejection. Also this seems like a pretty bad justification to reject and app update. Nobody benefits from this as part of a curation aspect. The app will still be there, so it’s already cluttering things up if that’s the issue for the rejection.
I guess what really bothers me about the App Store review process is that most of the time it feels like the human aspect is ignored despite being enforced (which I think is conceptually good). If you’re going to have people actually review everything, let the people actually act as people instead of rule-detecting machines.
> I fully support Apple for curating the App Store experience.
Except curating is a very strong word. This story looks more like the app reviewers are on minimum wage and just go through a script without trying to understand anything about the app. Probably because they have to review too many submissions per day.
Curation on the app store is a failure. I went searching for an app I read about and it would NOT surface in the app store search. I found someone else that had a direct app store link to it and was able to find it. The amount of duplicate/squatting apps out there is simply astonishing.
We need alternate app stores. Maybe with some actual competition Apple will pay more than just lip service to many of the issues that keep cropping up over and over and over....
Then again they never have given the macOS app store much love; then again it does no where the volume the iOS stores do.
And the review process is not even good at filtering out spams. I keep hearing about shitty apps with sneaky $199/week subscriptions making to top grossing apps in the Apple App store.
Not directly related but another "today" App Store rejection story for rules being incorrectly applied: I had an app get rejected today for referencing MacPaint in the subtitle. It was in the subtitle because one of the major features is that it exports images to MacPaint format. The reviewer cited their rule about not using Apple trademarks in the title or subtitle. Which is fair enough, except that their trademark on MacPaint expired in 2007 (I checked before submitting actually). I ended up changing the subtitle, removing MacPaint, and the app was approved later today. I did call out in the resolution center that the trademark had expired, but of course I got no reply.
Fair enough, I didn't think to look abroad. But just for context, suppose my app subtitle were "PDF to Apple Pages." I think if it's in the context of a file format, as mine was, there should be some sort of leeway. "Photo to MacPaint Converter" is basically what my subtitle was.
Rather than turning every app submission into a legal dispute I suspect it's easier for them just to say "don't use our trademarks without permission".
> Rather than turning every app submission into a legal dispute I suspect it's easier for them just to say "don't use our trademarks without permission".
Sure, it's definitely "easier." But given all of the bad press they've been getting about how they treat developers on the App Store, maybe it's time for them to stop just doing what's easier for them and start sometimes doing what's better for developers. Now this can't come from individual reviewers, so I don't fault the reviewer for enforcing their policy. I fault their policy for having limited nuance.
Why not automatically direct developers to an auto-escalation form when something small like this gets violated.
The form could first strongly discourage the use of trademarks.
But then provide fields for escalating the user of the trademark, based on the developers description of why the trademark is required to describe basic functionality of their app.
Auto-escalation options seem like a good thing for an iron gatekeeper to be providing if they want to reduce frustration with the shadow they are casting over techdom.
At a previous company, when I was developing an iOS app, it was difficult to impress upon the business people that there was a very real risk of Apple simply cutting us off. (When Apple wanted to compete in our space, or they cut a deal with a competitor of ours, or they came up with some new idea about "security" or "experience", or simply Kafkaesque random bureaucratic whim with no appeal.)
I then had to explain why "the market" hadn't already corrected that, and why regulators hadn't.
Separate from my professional career, one of the more personal reasons that the reality of the iron-fisted mad-king Apple iOS app store made me sad is... I had hard-won skills at some tricky iOS things, and it would've been very tempting to moonlight on some creative apps that did something new, while also generating side income. But, for this and other Apple developer-hostile reasons, I'd end up aggravated in my spare time, and always with the risk that at some point Apple will stab me in the back. That's no way to spend one's spare time refreshing from the real job.
> why "the market" hadn't already corrected [Apple's ability to cut people off]
Because there are a lot of money to be made, iOS users spend a lot more than Android users, that's a well known fact. If you don't build an app on iOS, someone else will. There are always developers who don't know enough, or simply don't care and keep building apps for iOS.
> why regulators hadn't.
They're starting to notice the problems. Recent regulations from overseas and the Epic lawsuit will draw attention to it.
Because the market is a duopoly of Apple & Google with very similar rules, pricing & close to no competition, there's nowhere else to go for developers if they are not happy.
For everyone visiting this thread, I’d highly recommend this talk by the previous head of App Store review Phillip Shoemaker: https://youtu.be/tJeEuxn9mug
Unfortunately this sort of thing is pretty much inevitable when a large org like Apple makes itself the single bottleneck for all apps. No org that big can actually serve everyone's needs
(Cue people whose needs it serves coming to tell me all about it)
> To my surprise, I got an email saying that my app is similar to other apps on the app store and that it is considered spam. Literally.
Please tell me this is a joke, this can't be true. So I can't develop an app and upload it if there's one similar already on the app store? What kind of stupid rule is this?
Apple applies their rules entirely arbitrarily. For example- they have rules for app update release notes required to be detailed and rejects small developers apps with generic template update notes. Meanwhile larger developers like fAcebook, Google, uber etc regularly put the same generic update notes.
In principle it's not necessarily that bad; does an app store really gets better with 1,000 hangman apps? Probably not. And let's face it: there's a lot of "app spam".
The problem is that 1) it seems enforced unevenly at best and this doesn't seem like "spam" at all, and 2) it's hard to bypass the Apple-curated app store. Apple can have all the rules in their app store they want – I don't really care – as long as they don't prevent me from running the software I want. It's that part that I find far more objectionable.
I don't agree with all the takes the Debian people have on their Free Software guidelines either, and that's not a problem at all because Debian isn't trying to prevent me from running any software I want! Even the more hard-line Free Software-only distros aren't preventing me from installing non-free software (they may not facilitate it or make it easy, but that's different from actively preventing it).
Or more eloquently: It's my bloody phone and I want to run whatever software I fucking want.
As a developer I have vowed to never develop anything for Apple nor buy any of the products. I know my mutiny is like a drop in the ocean for a trillion dollar company but I strongly agree with GNU stance that Apple's Operating Systems Are Malware(1).
Apple been trying to stifle innovation for profit for a very long time and has been getting away with it. Had it not for the good open-source alternatives I believe computers would just be big dumb bricks with 0 scope of experimentation.
I have an iPhone SE2 for the singular reason that it's the only phone that vaguely approaches a reasonable size (although still too large for my liking) and isn't the most budget of budget phones. I kind of hate it though :-/
I think it's a bit unfortunate that the GNU page mixes some good points with hyperbolic nonsense, and I don't care much for calling them "tyrants" either; seems a bit much...
I think it's slowly shifting. ios is attractive to developers because people pay for apps.
ios is attractive to the masses because, among other reasons, the people who can afford to pay for apps use it.
More increasingly, that seems to be changing, thankfully. I just wish the world had a better alternative than Android. It's hard to protest an overstep of Apple by giving money to Google.
215 comments
[ 3.0 ms ] story [ 223 ms ] threadI have to admit that software for blind people sounds like a fascinating specialty. I'd love to get into it but being not-blind (came close though) probably gives one false theories on design. I love the angle of making software that requires only a microphone and a speaker, it would be an amazing way to rethink the world.
My guess is that ground-up software for the blind would work differently at fundamental levels. Really, what an interesting problem.
In theory, yes, but in practice it's probably a very bad experience unless actively worked on. For instance, I worked on a "seat chooser" once, that actually was very keyboard friendly and worked with screen readers. But trying to actually use it to select a specific seat for a blind was impossible. A seeing user can just press the seat directly, or tab quickly until the correct one is selected. But with voiceover it had to read out "seat 7B, $5 extra, not occupied, extra leg room, aisle, power outlet".
An actually useful way of selecting a seat would be to specify a seat directly, or some kind of filter for wanted features, a table or whatever. Not just take a visual way of presenting something and slap on some voice data.
The two aren’t comparable. It’s not even close. I take it you haven’t actually built an iOS app.
That said, for sure, you can build a custom UI that is inaccessible, but with iOS if you build something that is close to conventional, you’d be surprised by how well it works.
Provide a non custom UI alongside the custom one. Use tabs to offer ‘graphical’ and ‘list’ views.
The comment I replied to said this:
> In theory, yes, but in practice it's probably a very bad experience unless actively worked on
It’s also not even clear that the UI they described was that bad for blind people.
The voiceover information is relevant to making a selection, and the blind person can’t see that data so it needs to be read to them at some point. Of course it’s not as easy to use as if you can see it. They describe a search function, and I propose a plain list, but there isn’t a lot of evidence that either would require less interaction.
Obviously it's bad. Becoming blind doesn't magically make you infinitely patient. Having to listen to a whole listing of airplane seats one by one with unnecessary details when you just want to book a place would probably make you crazy. Well it's the same for your blind users.
They don’t. Why would you expect them to be able to?
“If you did a 180 then do a manual review. If the app is fundamentally the same with a minor bug fix then why review it?” would have to be a different thing.
You literally already have an ongoing relationship with the party in question, which is usually one of the biggest hurdles to reputation systems (new users).
I expect the real reason they haven't moved in this direction is fundamentally App Store review is seen as a tool of ongoing control rather than quality. So the more frequently something has to pass through it, the better.
If Apple can "find an issue" with your app every time you update, that's a very different relationship than an ongoing approval.
PS: Would also require developers to inform Apple of any company sale / dev team replacement to prevent abuse (Didn't mention you sold your company? Ban).
I can totally see Facebook pushing a update which uses internal APIs to access private information outside of its sandbox.
Honestly apps need to be verified after every update for much of the same reasons they need to be verified initially. The issue is the verification process itself, which sometimes blocks legitimate developers while also sometimes allowing scam apps.
See: recent iOS exploits.
And the original poster (the blind game developer) says so too
Isn't this being possible a security issue with iOS?
Second, Apple really hates the idea of special rules for specific developers. When they make an exception for, say, Kindle; they don't just approve Kindle. They change the App Store rules to say "apps that are just viewing content purchased on other devices don't have to use IAP". The closest thing they have to special rules are entitlements; things like Zoom's special camera multitasking entitlement comes to mind. However, even that ultimately wound up being something other developers of video chat apps could ask for, they just didn't say anything about it until they got called out on it.
The 1Password example you cite is plain 'ol trademark infringement. I imagine Apple isn't particularly interested in doing trademark enforcement for third parties, though I'm pretty sure they wrote the rules to allow them to do exactly that. This is definitely something where Apple could be more proactive, but there's a limit to how much they can do before you get people complaining about Apple going overboard.
You mean "really loves" special rules for specific developers. They won't change the public rules, of course, but backroom deals for private APIs or specific entitlements are a thing.
It's not feasible to get in touch with Google to fix/remove these.
It's a hard issue to solve; Apple are erring on the side of user safety.
In fact, trying to cite other approvals in an argument in App Review is usually a good way to get other developers' apps pulled.
Apple hands you willing buyers on a silver platter and you pay for it.
"Exploring images with VoiceOver: Explore people, objects, text, and tables within images in more detail with VoiceOver. Navigate receipts and nutrition label values intelligently in logical order. And move your finger over a photo to discover a person’s position relative to other objects within images."
"Voice image descriptions in Markup: Markup lets the user add image descriptions that can be read by VoiceOver. Image descriptions persist even when shared and can be read in a range of supported apps on iPhone, iPad, and Mac."
"Per-app settings: Customize display and text size settings on an app-by-app basis. Bold or enlarge text, increase contrast, invert colors, add color filters, and more for only the apps you want."
"Magnifier app: Magnifier finally becomes a default app on iOS, so you can use your iPhone as a magnifying glass to zoom in on objects near you."
Now, I do understand that every app needs to go through review every time it is updated, of course. But this is verion 2.5 of the app, this is in no way the first or second version. So yes, Apple seems to find a new issue when someone just finds a little light in their brain clicking into place, the first version had no such issue. But after 4 or 5 versions, oooooh wait, your app does not comply with blah blah blah. So, yes, I think this is unfair. Anyway, I have some news regarding this whole hing, the update was pushed through and approved finally so I'm a bit less worried, they still say I should talk to them on the phone so they're going to schedule a call with me. Let's see how this turns out. Thanks all.
Twice now I’ve had to appeal the review. Each time the appeal worked in my favor and I was able to publish again. Keep in mind, as part of the appeal process they call you, so you will need to be answering unknown calls for a while. But the people I’ve talked to that handled the appeal process were all very nice.
CSS could match the current appearance exactly. I bet if dang put up the code on GitHub he'd get PRs fixing tons of stuff within a week.
This is a different case -- HN genuinely does not have a complicated UI, and it genuinely would not be difficult to make a UI that worked better with screen readers. It would not be difficult to rebuild a HN UI to stop using tables without even making any visual changes to what the site looks like.
There is very little complicated functionality going on in HN pages. They're paginated, they don't have a ton of content, they don't have a lot of complicated UI controls they need to support. They're mostly static pages with some very minor form controls.
In this specific case, there really is no excuse for HN to be screenreader inaccessible. This would not be a complicated conversion for even a single experienced web developer. You wouldn't need to use React, you wouldn't need to use any 3rd-party library or dependency at all. You wouldn't need complicated CSS features, you wouldn't need to redesign the UI.
Honestly in a lot of ways, the current HN table layout is more complicated than it needs to be, the generated HTML could be a lot simpler. Really, there's a difference between being "retro" and using what works instead of chasing modern trends, and having outputted HTML that's broken and hacky, and was broken and hacky even at the time it was released. HN is very solidly in the latter category.
No, it seemed awful at the time as well. Table layouts were already long obsolete by the time Hacker News was launched. Here’s a discussion from over a decade ago on the subject:
https://news.ycombinator.com/item?id=2019950
Quotes:
> If this were anyone other than pg, you'd all be excoriating the developer for living in the 90s.
> The big benefit is to accessibility through screenreaders or other alternate clients.
> Look, do what you want. You want to write bullshit markup, be my guest. But there isn't a single web dev in this community who would code output like this for their own site. They're just too chickenshit to tell you.
And here we are, a decade later: nothing has changed, we’re still having the same discussion about the same flaws, and it’s still causing problems for people with disabilities. It doesn’t “only seem awful in retrospect” – it has been awful all along and people have been pointing it out for over a decade.
pg is very proud of HN's quirky implementation that does what he wants very efficiently.
For visual use, I would agree that the site is great, far better than most of the bloated nonsense that is out there these days.
I'm not sure I agree that it does. HN ships a bunch of extra DOM content that it really doesn't need to ship. If you're optimizing for page size, the HTML could be lighter.
The site does what pg wants, but he really shouldn't be proud of it for doing what he wants well. It's not that the HTML is super-optimized but that the optimization has tradeoffs. It's more like whoever programmed it is very familiar with tables, and when all you have is a hammer everything starts looking like a nail.
[0]http://paulgraham.com/arc0.html
>pg: "Arc embodies a similarly unPC attitude to HTML. The predefined libraries just do everything with tables. Why? Because Arc is tuned for exploratory programming, and the W3C-approved way of doing things represents the opposite spirit.
>(...)
>Tables are the lists of html. The W3C doesn't like you to use tables to do more than display tabular data because then it's unclear what a table cell means. But this sort of ambiguity is not always an error. It might be an accurate reflection of the programmer's state of mind. (...)
... and yes, that decision is baked into the server, web app, HTML and forum code (which to my knowledge have never been changed in the standard Arc distribition,) making it a de facto requirement for all Arc based webapps and a PITA to change.
I suggest dropping a line about this to dang at hn@ycombinator.com. He is extremely nice and helpful.
I've always felt HN should use nested lists for comments.
(I know there’s ways to restructure it completely to do this, but I like focused and surgical changes that don’t affect anyone who doesn’t notice them. Opinions vary on that.)
[0] https://www.w3.org/WAI/GL/wiki/Using_ARIA_trees
I had someone else mention that rare bug too but unfortunately I haven’t been able to reproduce it to be able to narrow it down. I will see what I can do to fix it.
Two that display comments: https://hackerweb.app/ https://hn.premii.com/ I don't know how good they are with screenreaders.
The hackerweb.app site seems very good for accessibility. It uses nested lists as others here have suggested.
hn.premii.com is a little more difficult to use (in terms of getting from the list of posts to the comments), but still quite usable. It uses a slightly more complicated layout of divs and lists.
Basically, the comments on HackerNews are laid out in a tree form. When you first load the page, the comment tree is expanded. You can collapse them by pressing on the little '-' next to the comment.
With the tree expanded, NVDA just reads the comments as a linear stream. Of course, many forums are structured linearly, but the advantage of a tree layout is that you can have tangents like this one, without interrupting the main flow of the thread. Reddit is very similar in that regard. If NVDA can't read the tree structure, it's hard to know what is going on. From my experience, using the arrow keys ( e.g. CTRL + DownArrow ) will not report the indentation, whereas using the numpad keys ( e.g. Numpad 7 or Numpad 9 ) will report indentation, but will not indicate how deep the indentation is, so that isn't terribly helpful. It may be possible to change settings in NVDA to get this to work, but I doubt it, which leads us to the technical implementation.
As others have pointed out, the comments are in a complicated nested table structure, which NVDA seems completely blind to, not even recognizing it as a table. Then, the visual indentation is created by prepending the comments with gif images, which act as spacers. The width of the spacers is determined by a 'width=' attribute.
Others who are more knowledgeable than me have already pointed out alternative ways that this could be implemented, such as using <ol> or <ul> tags.
It wouldn't be hard to also criticize the lack of headings, but we can leave that for another day; if this indentation issue could be sorted out, the usability of the site would go up by about 300%. I've almost stopped coming on here since using a screnreader, whereas I used to browse on here a lot -- it's one of my favourite sites.
To the other commenters: thanks for the useful suggestions and insights; this had been bugging me for months.
Edit: typo
Holy shit I didn't realise this? That's terrible!
I am not (visibly) disabled, myself, but write software for a demographic that has a statistically high number of folks dealing with various challenges. Accessibility is a big deal for me (as is Usability –Accessibility's redheaded stepchild). I do things like provide localizable accessibility labels, as well as support for things like colorblind access, high contrast mode, and reduced transparency mode.
I have also released over 20 apps in the App Store (myself), since 2012, and am the proud recipient of many app rejection notes.
One of the more annoying things, is that the reviewers are required to select from a menu of rejection reasons. They can't just write "You need to add a plist row to ensure the new permission we just added is presented to the user." Instead, they have to send you some generalized "blanket" reason that includes that requirement, among a list of others that don't apply.
It's easy to panic, when we get these.
In my case, I sometimes need to break out a Ouija board, to figure out what they mean.
Fortunately, I have had very good luck in getting folks on the phone. They still tend to "beat around the bush," but you can usually figure out what they want.
Not a big deal. I can always work to modify awkward habits.
Give my regards to your dear Ginger. I'm married to one.
Congratulations on your award.
It's a staple of large corporations struggling scale processes and at the same time properly handle edge cases.
How? He tried talking to them, and they rejected his appeal.
If Apple was more developer-friendly, which they are absolutely not as a company, you would think that all replies to rejection e-mails should go through this board. But unfortunately, that's not the case - you have to go through a different process to submit an appeal, which is what it sounds like the blog poster has done (to get a call with them scheduled.)
We've created over 100 cross platform experiences, and I'm seriously considering a #FckApple tattoo.
This is the standard corporate playbook at this point.
Screw over lots and lots of people, then opponents will find some sympathetic cases like this one and put them in the news to put pressure on the company to do something.
The company fixes the one specific case that made the front page. Neither the million other instances, nor the systemic problems that led to them, are addressed. But if anyone refers to the case that made the news, the company can say that it turned out alright. "The system works."
It only turns out alright in that case because it made the front page. Things are still broken everywhere else.
You might want to look into Google's new UI toolkit, for Android, called Compose.
Could you post on how the conversation went?
Normal procedure of Apple to avoid any written communication.
Unless I'm misunderstanding the feature, this is coming to Android as well (well, it already has, though it's fairly recent), in the form of Jetpack Compose.
That said, Apple VoiceOver is still one of the best shipped-by-default accessibility systems. However, we have to thank Steve Jobs for this. If it were only for Tim Cook, apple wouldn't even know how to spell accessibility.
Which is frightening, because two years ago I had a terrible experience trying to modify a web app to be accessible using VoiceOver (I gave up after over a week of solid effort).
We couldn’t afford[1] to pay a third party to modify our 100% custom HTML framework[2], and VoiceOver seemed the most approachable for me to try and see how far I could progress on making our web app accessible.
VoiceOver just felt so very buggy - although perhaps the issue was the integration of VoiceOver within Mobile Safari (my dev experience is that Mobile Safari is a steaming pile of problems - current example is that iPadOS15 Safari crashes twice on many pages then goes blank so you can’t use it!).
As a dev, there also needs to be some better online training for using VoiceOver, since small teams do not have easy access to a colleague that uses it.
[1] We could pay 100% blind users to give us feedback, but couldn’t afford to pay a skilled team to consult and do the work.
[2] Custom framework because we started our product before reliable frameworks existed. Modern components are often designed to support accessibility out of the box, which is far preferable!
Luckily, Chrome for iOS exists :(
Also for your specific use case (I realise you were making a point) would be worth using the app I guess.
The Google Sheets app is a no-go because it kept using stale data for some reason. The sheets are regularly updated via script, and the app would constantly fail to show recent data.
Also, I think you are making many assumptions about me in your response: perhaps try to be a little more generous towards others.
If companies are making byzantine and ridiculous claims against other participants, it's bad for business.
This is completely outside the issues of Apple's right to manage apps - if it's going to do so, it has to fairly clear policy and way to redress grievances.
Things like: 'business review' and 'technical review' are separate so that bug updates don't trigger a business reviews. If a complaint is raised to level 2 and there are problems, it goes to some kind of level 3 mediation, possibly by an outside party. It also might be reasonable for Apple to require a small fee for new feature release review i.e. $100 to release a new version and have the business review. They could even consider having 3rd parties do the reviewing and only have Apple weigh in if there is a conflict. Etc..
Arbitrary and bad business operations are not good for anyone in the long run.
This specific app is not an issue for me (I'm not blind) but there is another app that I do rely on that has also not been upgrade to 15.0 so I'm still faced with the same dilemma. And unfortunately, this particular app (Foreflight) is iOS-only.
I contacted Apple tech support and they have so far escalated through two levels. The ticket is still open.
In the jailbreaking world you can save these signatures allowing you to install that iOS version later at your leisure.
That said, Apple appears to still be signing iOS 14.8. You can check the signing status here: https://ipsw.me/iPhone12,3
(But look up your device model in particular. Sometimes there’s inconsistencies)
But they have definitely stirred some publicity (including nongeek audience) around all these practices, which is good, maybe someone is going to have a better case riding this wave.
If violations got automatically grandfathered in, you’d get devs pulling tricks like sneaking barely functional violations into the app so it’s unlikely to be spotted then when they got it approved make it fully functional.
In any case, it looks like Apple is already engaged with the dev to sort this out. They’ve made some major changes to review appeals in the last year or two.
There’s also a lot of irony in Apple judging whether or not your app is good enough. Like does anyone actually think Apple is cool in 2021? To me they’ve just become another boring, stuffy corporation like Dell and HP. The iPhone 13 is so incredibly uninteresting and inconsequential that I couldn’t even remember what number they were on when I was typing this comment. That whole launch just came and went.
But as a user I fully support Apple for curating the App Store experience. Discoverability is a challenge when you have this many apps and it's simply not fun having to wade through so many low quality, user-hostile apps.
You only need to look at the Windows Store to know that curation is an integral part of making a store work.
There is plenty of garbage on the app store and while in this case I’m sure there are a ton of hangman games on iOS, at least this one if offering something the others aren’t. So it’s kind of failing to deliver on the stated premise for the rejection. Also this seems like a pretty bad justification to reject and app update. Nobody benefits from this as part of a curation aspect. The app will still be there, so it’s already cluttering things up if that’s the issue for the rejection.
I guess what really bothers me about the App Store review process is that most of the time it feels like the human aspect is ignored despite being enforced (which I think is conceptually good). If you’re going to have people actually review everything, let the people actually act as people instead of rule-detecting machines.
If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
The Mac App Store has about a dozen Chinese Bonzi Buddy clones on it.
Have you ever looked at the App Store? It's already like this…
Except curating is a very strong word. This story looks more like the app reviewers are on minimum wage and just go through a script without trying to understand anything about the app. Probably because they have to review too many submissions per day.
We already have to do this.
https://www.theverge.com/2021/4/21/22385859/apple-app-store-...
We need alternate app stores. Maybe with some actual competition Apple will pay more than just lip service to many of the issues that keep cropping up over and over and over....
Then again they never have given the macOS app store much love; then again it does no where the volume the iOS stores do.
If you're app is for sale in the UK, which almost all are, then Apple is obliged to enforce their trademark.
[1] https://trademarks.ipo.gov.uk/ipo-tmcase/page/Results/1/UK00...
Sure, it's definitely "easier." But given all of the bad press they've been getting about how they treat developers on the App Store, maybe it's time for them to stop just doing what's easier for them and start sometimes doing what's better for developers. Now this can't come from individual reviewers, so I don't fault the reviewer for enforcing their policy. I fault their policy for having limited nuance.
The form could first strongly discourage the use of trademarks.
But then provide fields for escalating the user of the trademark, based on the developers description of why the trademark is required to describe basic functionality of their app.
Auto-escalation options seem like a good thing for an iron gatekeeper to be providing if they want to reduce frustration with the shadow they are casting over techdom.
I then had to explain why "the market" hadn't already corrected that, and why regulators hadn't.
Separate from my professional career, one of the more personal reasons that the reality of the iron-fisted mad-king Apple iOS app store made me sad is... I had hard-won skills at some tricky iOS things, and it would've been very tempting to moonlight on some creative apps that did something new, while also generating side income. But, for this and other Apple developer-hostile reasons, I'd end up aggravated in my spare time, and always with the risk that at some point Apple will stab me in the back. That's no way to spend one's spare time refreshing from the real job.
'... why "the market" hadn't already corrected [Apple's ability to cut people off], and why regulators hadn't.
Because there are a lot of money to be made, iOS users spend a lot more than Android users, that's a well known fact. If you don't build an app on iOS, someone else will. There are always developers who don't know enough, or simply don't care and keep building apps for iOS.
> why regulators hadn't.
They're starting to notice the problems. Recent regulations from overseas and the Epic lawsuit will draw attention to it.
(Cue people whose needs it serves coming to tell me all about it)
Please tell me this is a joke, this can't be true. So I can't develop an app and upload it if there's one similar already on the app store? What kind of stupid rule is this?
The problem is that 1) it seems enforced unevenly at best and this doesn't seem like "spam" at all, and 2) it's hard to bypass the Apple-curated app store. Apple can have all the rules in their app store they want – I don't really care – as long as they don't prevent me from running the software I want. It's that part that I find far more objectionable.
I don't agree with all the takes the Debian people have on their Free Software guidelines either, and that's not a problem at all because Debian isn't trying to prevent me from running any software I want! Even the more hard-line Free Software-only distros aren't preventing me from installing non-free software (they may not facilitate it or make it easy, but that's different from actively preventing it).
Or more eloquently: It's my bloody phone and I want to run whatever software I fucking want.
Apple been trying to stifle innovation for profit for a very long time and has been getting away with it. Had it not for the good open-source alternatives I believe computers would just be big dumb bricks with 0 scope of experimentation.
(1) https://www.gnu.org/proprietary/malware-apple.en.html
I think it's a bit unfortunate that the GNU page mixes some good points with hyperbolic nonsense, and I don't care much for calling them "tyrants" either; seems a bit much...
ios is attractive to the masses because, among other reasons, the people who can afford to pay for apps use it.
More increasingly, that seems to be changing, thankfully. I just wish the world had a better alternative than Android. It's hard to protest an overstep of Apple by giving money to Google.
There are at least forks of Android that are open-source. You don't necessarily__have_ to run the Google version of Android.
Lineage-OS is one of them, but a few others have cropped up over the years that I have forgotten the names of.