[mekkkkkk]

Well the difference is that as a general app developer you barely ever need to interact with Google. As for Apple, you do it a lot. I'd rather take rare and abysmal interactions than constant, annoying ones.

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.

[dep_b]

> Well the difference is that as a general app developer you barely ever need to interact with Google.

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.

[wbl]

Those permissions are rather easily abused so I'm glad Google is protecting my privacy by restricting them.

[dep_b]

Sure but the bureaucracy was shocking

[gogopuppygogo]

Years ago, a family member of mine hired a college student to develop an informational application for their small business. This app offered reference guide type information for a niche. To set expectations, my family member paid sub $10k for the entire app to be developed when mobile apps were new.

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.

[bartvk]

So to recap: party Foo tries to take over the developer account of party Bar, using trademark law. Google makes this not possible.

How is this a problem?

[toast0]

Party Foo allows party Bar to release an app using Foo's trademark. Party Foo wishes to release their own app using their trademark, as they've rescinded the permission of party Bar. Google makes this not possible.

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.

[anonymousiam]

Google is not alone when it comes to poor exception handling. The case you cite (a corporate merger) is something they should absolutely support.

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."

[mekkkkkk]

That certainly sounds less than ideal. I have also had a few interactions of this nature with Google, and unless you have contacts in the company or have some sort of partnership, it's very hard to get any form of manual intervention.

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.

[valuearb]

The fault was thinking you could pay less than $10k and get competent professional development devices for your app. That’s less than a month of a professional developers time. I had to pay half that just to get the interior of my house painted, and it took two people less than a week.

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.

[murkle]

So it's not possible to steal accounts - sounds like a good thing to me

[StavrosK]

Forgive my ignorance, but why would you ship an app with a broken login system (or whatever) in the first place?

[mekkkkkk]

I updated the post. The normal login flow requires swedish digital ID. Reviewers won't have access to that.

[StavrosK]

I see, thanks. I can imagine how frustrating that must be, "I don't have a Swedish ID therefore your app doesn't work".

[Isn0gud]

On a side note; Not having a Swedish ID in Sweden makes a lot of things very cumbersome and some even impossible, having one makes one of the most straightforward and convenient bureaucracy systems I have experienced.

[mekkkkkk]

Yeah. The increasing reliance on BankID in Sweden is a blessing and a curse. For us swedes born into the system it's incredibly convenient.

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.

[m-p-3]

I hope we'll reach a point where we have a better system than a simple Social Insurance Number in Canada, which has no cryptographic protection whatsoever and can be major pain in the butt if leaked from a data breach like with had with the Desjardins Credit Union.

[mekkkkkk]

It's very frustrating indeed! I don't know how many times I've edited and attempted to clarify the instructions, but I'm still getting bounces. I really sympathize with the reviewers who are probably under a lot of pressure. But it doesn't change the fact that a hotfix release of our app on iOS is anxiety inducing.

[nicoburns]

As a practical solution, I wonder if you could provide the reviewers with a fake id that you hardcode into the backend for test accounts. Whcih could allow them to use the same login UI (even if the underlying codepath is different)

[mekkkkkk]

The ID login flow is basically UI-less. The user taps the login button, a separate identification app (that basically all swedes have) is launched, and as soon as the authentication is completed the user is navigated to the logged in view. It's a very seamless experience, and a lot of swedish apps work this way.

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.

[nicoburns]

Ah, the login flow is in a separate app. That does indeed make it tricky!

[tasubotadas]

Why do people deliver software with bugs at all???

[StavrosK]

Agreed, why deliver an app with an egregious bug you know about?

[vunuxodo]

Because the Powers that Be insist on making a particular release date, consequences be damned.

I am currently in this situation.

[jessedhillon]

Is it my imagination, or has people's ability to detect and understand sarcasm just fallen off a cliff over the past 1-2 years?

[protomyth]

It's been longer than that. I would expect this is a sore point with people because few professions allow their practitioners to knowingly ship defective products to meet a deadline.

Alternatively, why understand sarcasm when the lack of understanding provides some folks with an amazing weapon?

[StavrosK]

It would appear so.

[valuearb]

You need to do a better job documenting test logins and instructions for reviewers. Not defending Apple, but don’t half-ass the things you control when you go to review.

[mekkkkkk]

I don't know how you got access to our developer console, but you need to stop.

[howlgarnish]

Why do you have button X if you're not supposed to tap it? Will all your users read, understand and follow your instructions?

[mekkkkkk]

Sorry for being unclear. I updated my post. The service uses swedish digital ID verification. This is not feasible for reviewers.

[ehutch79]

You can't be the only app doing this. Others must have been approved. How did they handle it?

[ksec]

Lots of Apps have special log in system or even Apple Review User account just for the reviewers.

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.

[mekkkkkk]

Don't get me wrong, most of the time they read the instructions and everything works great. No issue.

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.

[valuearb]

You create special ids, and logins for Apple reviewers so you don’t have this problem. Or you decide that’s too much hassle and accept the extra days in review as a different cost.

[toast0]

The same way. Resubmit until a reviwer reads the testing comments.

[ehutch79]

Your users will absolutely tap X. They will find your app is broken.

[gcmrtc]

Well, that is what most of your users would have done anyway. You dealt with a reviewer instead of multiple angry users that couldn't log in, looks like the review process works.

[mekkkkkk]

It's a different login procedure for test accounts (such as the ones made available for reviewers).

[ratww]

Curious: any reason it can't be the same button?

[mekkkkkk]

I updated my post, the user facing login is using Swedish digital ID, which naturally the reviewers do not have access to.