[HN Gopher] Apple's app review prevents developer from submittin...
___________________________________________________________________
Apple's app review prevents developer from submitting fix to game
for the blind
Author : latexr
Score : 318 points
Date : 2021-09-26 18:52 UTC (4 hours ago)
(HTM) web link (www.applevis.com)
(TXT) w3m dump (www.applevis.com)
| adolph wrote:
| It's regretable that so many bigcoes have to outsource their
| customer service exception pathway thru HN.
| DarkmSparks wrote:
| I wish blindness on whoever rejected the update. At the very
| least a couple of weeks with restricted vision to teach them some
| empathy.
| WoodenChair wrote:
| 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.
| threeseed wrote:
| Apple still has an active trademark for MacPaint in UK [1].
|
| 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...
| WoodenChair wrote:
| 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.
| paxys wrote:
| 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.
| supernintendo wrote:
| 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.
| cglace wrote:
| I seem to be able to use my toy for quite a bit.
| threeseed wrote:
| 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.
| PerkinWarwick wrote:
| 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.
| zepto wrote:
| If you follow apple's accessibility guidelines, your iOS app is
| already accessible by the blind.
| JanneVee wrote:
| 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.
| matsemann wrote:
| 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.
| zepto wrote:
| > 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.
| jtsiskin wrote:
| How would iOS fix the seat selection example they gave?
| zepto wrote:
| > 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.
| WastingMyTime89 wrote:
| > 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.
| SSLy wrote:
| I believe quite a few of those blind-accessible apps also use
| touchscreen gestures, accelerator, and buttons for inputs.
| alkz wrote:
| just classic apple hostility towards their users and developers
| gtirloni wrote:
| If you get a permission to publish on the App Store the first
| time, shouldn't that be permanent? Why do developers have to
| justify _every_ new update?
| kmeisthax wrote:
| No. Apple absolutely does not want to have "App Store case
| law". They want the rules to be what the agreement says and no
| more.
|
| In fact, trying to cite other approvals in an argument in App
| Review is usually a good way to get other developers' apps
| pulled.
| kall wrote:
| 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).
| xvector wrote:
| Because it makes being malicious trivial if all you have to do
| is get approved once
| david_allison wrote:
| There are apps on the Play Store which get updated, and now
| sideload malware.
|
| 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.
| oauea wrote:
| I feel very safe knowing blind people aren't allowed to play
| hangman.
| BrightGlow wrote:
| Blind people can also get malware...
| labster wrote:
| You have it backwards. If Apple doesn't review every update,
| how can they justify 30% transaction fees?
| threeseed wrote:
| The same way every digital and retail store does: as a
| "channel to market" cost.
|
| Apple hands you willing buyers on a silver platter and you
| pay for it.
| saagarjha wrote:
| Because apps change.
| croes wrote:
| 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.
| Closi wrote:
| Because developers will just submit a first version which
| follows the rules, and then just put anything non-compliant in
| the update.
| peterburkimsher wrote:
| That would be treachery of Epic proportions ;)
| shreddit wrote:
| In theory, you could do a 180 turn on the content of your app
| with every update. So a permanent green light would do more bad
| than good
| flatiron wrote:
| 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?
| Someone wrote:
| How do you suggest Apple determines whether an update does
| a 180 or just has a minor bug fix? Trust the submitter?
| Razengan wrote:
| 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.)
| concinds wrote:
| 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.
| ethbr0 wrote:
| 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).
| BrightGlow wrote:
| 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.
| siva7 wrote:
| 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).
| armchairhacker wrote:
| > 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.
| kennywinker wrote:
| 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
| meibo wrote:
| They can't even fix private API abuse, how do you expect
| them to scan for it?
|
| See: recent iOS exploits.
| b3morales wrote:
| 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.
| trothamel wrote:
| "which uses internal APIs to access private information
| outside of its sandbox"
|
| Isn't this being possible a security issue with iOS?
| mlang23 wrote:
| 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?
| sunderw wrote:
| 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.
| gumby wrote:
| No, armchairhacker said the opposite: even big famous
| companies need review of every update.
|
| And the original poster (the blind game developer) says
| so too
| catlifeonmars wrote:
| Did you mean to reply to the grandparent poster?
| kmeisthax wrote:
| 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.
| siva7 wrote:
| 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.
| lozenge wrote:
| 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."
| sillysaurusx wrote:
| 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).
| jollybean wrote:
| 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.
| neilv wrote:
| 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.
| friedman23 wrote:
| 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
| ogomez92 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| cwbrandsma wrote:
| 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.
| juancn wrote:
| Talk to them. Apple is a huge company, but they really care
| about user experience (developers or otherwise), even if
| sometimes they fail at it.
|
| It's a staple of large corporations struggling scale processes
| and at the same time properly handle edge cases.
| cortesoft wrote:
| > Talk to them
|
| How? He tried talking to them, and they rejected his appeal.
| kolanos wrote:
| 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.
| bellweather49 wrote:
| 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).
| AlexAndScripts wrote:
| That's awful... Why would it be done like that?
| jraph wrote:
| I've noticed that in terminal browsers as well (as a non-
| blind person).
|
| 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.
| kolanos wrote:
| I use the "[-]" next to comments. Collapsing/uncollapsing
| comment trees lets me know what is nested under what.
| oauea wrote:
| 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).
| judge2020 wrote:
| 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
| mlang23 wrote:
| 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.
| robocat wrote:
| > 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!
| zzt123 wrote:
| 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.
|
| Luckily, Chrome for iOS exists :(
| lathiat wrote:
| 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.
| zzt123 wrote:
| 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.
| stephenhuey wrote:
| 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.
| bangonkeyboard wrote:
| Apple's Texas Hold'em actually dates to 2006.
| lisper wrote:
| 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.
| b3morales wrote:
| Did you try via your Mac or the phone's own Settings? FYI, the
| latter is where you will find the 14.8 update offered.
| lisper wrote:
| 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.
| b3morales wrote:
| That sounds annoying. Good luck!
| oauea wrote:
| Apple always does this for all kinds of apps. It sucks, and I
| don't understand why people keep on happily suffering under their
| abuse.
| Andrew_nenakhov wrote:
| 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.
| VortexDream wrote:
| This is the issue I was hoping the Epic case would solve.
| They all missed the plot though, so we're stuck with this
| bullshit.
| WesolyKubeczek wrote:
| 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.
| simonh wrote:
| 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.
| Jensson wrote:
| Apple should really dogfood their own review system by applying
| it to their own apps. Would probably fix these inconsistent
| things pretty quickly.
| [deleted]
| advael wrote:
| 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)
___________________________________________________________________
(page generated 2021-09-26 23:00 UTC)