I've had numerous app rejections because of reviewers simply incapable of reading instructions, and it's immensely frustrating. Especially when important hotfixes etc. is put on hold for days for no reason whatsoever.
Instruction: Do NOT tap button X to log in, instead use method Z.
Rejection: Tapped button X, could not log in. Your app is broken.
Welp, time to resubmit and wait for a couple of days to possibly get the same rejection again.
EDIT: To clarify, the login procedure is different and simplified for test accounts, such as the ones reviewers are using. Real users need to identify with real ID for (valid) reasons.
They will have the same hurdle. And resubmit again and again and possibly; again. That is why many developers are so frustrated. It isn't some one -off problems. It has been going on for years.
Just like the Butterfly Keyboard, it wasn't until a journalist wrote about it and mainstream media pick it up causing Apple PR damage before Apple acted on it. Just the same with App Store review. This time with DHH.
But the uncalled-for rejections happens enough that we can never feel confident. As I say, it's a major nuisance, but it isn't unworkable.
I am currently in this situation.
Alternatively, why understand sarcasm when the lack of understanding provides some folks with an amazing weapon?
On the flip side I've heard my fair share of horror stories from expats that get locked out of necessary services only because they don't have a social security number and bank account (yet). And that process can take a while.
On the other hand it means that it's impossible to determine which user is logging in until the proper auth is complete. And thus you cannot have "special accounts" using this flow.
Those days are over. Want to access text messages because you have 2 factor logins? Want to access phone logs because your apps measures how much time you spent on the phone with each of your clients?:
Be prepared for a lot of bureaucracy.
Of course you can't even access texts or calls on an iOS device, but then again when that's the case none of your customers can ever force you to build a feature around it.
After a few years it had attracted a few thousand users but needed updating and the developer was non-responsive. The family member of mine was non-technical and had allowed the developer to publish the app under their own developer account.
A saga begins that I won't bore everyone with the details but basically this family member didn't want to lose the thousands of users. They tried to get the developer to send them the app to maintain but the developer was non responsive. They tried to enforce their trademark on the app but Google would only delist it.
Now they had no listing at all for their company so they tried to start over. They tried to create a new app with the same name but Google's review process wouldn't let them because another app had already existed with that name. Armed with a trademark and people we knew who worked at Google we got exactly zero steps further after three months of trying to work with Google on the issue.
Eventually, we tracked down the mother of the developer who had ghosted on us and paid them to give us their developer account. Where we showed the trademark, had the app re-activated, and moved it to another Google account we controlled.
Basically, Google couldn't help us at all. It was a mess. Eventually we got things sorted but we had to go around Google.
Was this Google's fault? Heck no. The family member got unprofessional help from a student developer who ghosted on them but Google didn't make it easy to fix the issue. They made it impossible.
That being said, Apple is also known for being incredibly draconian when it comes to account management. I don't think you would have been in a better position on iOS.
I think understaffed, off-shored and with a lack of permissions is just the baseline when it comes to this sort of tech support.
How is this a problem?
How is that not a problem? Yes, parties Foo and Bar probably used the wrong procedure when releasing the app, but can't fix that.
Google has no exception handling ability, and it's awful. You can't merge G suite organizations when there's a corporate merger. Clearly, you should have known five years ago, that you were going to be purchased by X. Same story, no exception handling.
I recently had a problem with Dell/VMWare when we wanted to change the domain name associated with a VxRail cluster. After working with their support teams for months, they eventually threw up their arms and said; "It cannot be done unless you reset and do a fresh install."
And without a maintenance agreement the developer isn’t going to help you, they have their own life to live. You think they are going to take vacation days from their next job to figure out that old code? As usual the problem is the client.
Full disclosure: I write this as a contract developer who had to take over an active app on the store when the client fired the previous developers, and tried to update it themselves. I have to update 140,000 lines of code with zero comments or documentation, and the previous devs aren’t accessible. In my case the clients screwed themselves, but got lucky cause I’m very very good.
With Apple, you may have to convince them of your opinion, but you can very quickly talk to a human who will reply with an actual, thoughtful response.
With Google, if you manage to get a human on the other side of the line, you’re probably weeks or months later, several automated forms and replies deep, and completely confused.
I like that apple only allows apps of a certain quality. But some guidelines are multi-interpretable.. Causing issues when submitting app updates.
So if you want happy customers then a native app is a necessity.
PWAs can be a great experience, and they already are on android and desktop when they're well done.
I say this as someone who deleted the Facebook app and only uses web because of tracking.
So, we're not likely to see video editing software on the web surpass native any time soon.
The web is a powerful platform for a lot of reasons but I don't agree that it's easy to develop for, iOS is a much less hostile and predicatble environment to run client side code in. I also don't believe that CSS/HTML are particularly well suited to rich mobile applications in comparison to UIKit or SwiftUI. I still write PWAs and native apps and don't see why they can't coexist. Proponents of the PWA approach seem to really want PWAs to replace native development.
There is a lot of functionality and APIs that native apps have access to on both platforms, I'm not sure I see the point in browser developers implementing every single one of them when a subset can cover 70% of JSON-viewer type app needs, the remaining niche can be written as native apps.
However I appreciate it’s a big process and given the amount of complaints online on how bad the process is, I put a lot of extra care to make sure everything goes through very smoothly. I use TestFlight a lot to test a lot and I look at the App Store process as akin to sending my software to a publisher and writing to CDs - I go to full efforts to make sure it is as perfect as possible by the point I’m submitting.
Also might have to do with number of users you have. Now I have quite a few downloads on my main app, so I may be getting a bit better treatment on priority fixes.