Safari extension rejected because developer not “reputable” | Hacker News Reader

Safari extension rejected because developer not “reputable”

twitter.com

203 pointsksec91 comments

As David C. pointed out in the comments,[1] Apple has reversed course.[2]

[1] https://mjtsai.com/blog/2021/07/30/safari-extension-rejected...

[2] https://twitter.com/thomasareed/status/1420831606227488772

Man I wish I could find that post where Apple told developers not to complain about app rejections on social media. When in reality it’s often the only way for developers to successfully appeal. Anyway, I hate the App Store (and by extension all adjacent reviews by Apple) and I hope Apple gets regulated to hell. It will also be completely their own fault. The people that are competent enough to make correct decisions in such cases don’t want to do such menial work. I think the whole approach of manual reviews is doomed to fail.

Well, and only if they can drum up enough support around their social media complaint. I imagine lots of developers don't have any real recourse.

Lo and behold (head of App Store review): https://youtu.be/tJeEuxn9mug?t=1707

The world needs developers to continually push the envelope. Apple is a little closed off on innovaion from Developers, they don't really push the envelope as much as developers want them to... If you have something that's really compelling, and apple keeps rejecting it, don't just go silent into the night - complain. Do an appeal, complain, use whatever means necessary to get your idea out there... Apple responds well to the media; if you go and you put a nice campaign together and you say this app should be approved for these reasons, and you go to the media and talk about it, chances are Apple will eventually approve it.

I used to be a pretty ardent defender of Apple's right to control their platform. Then, recently, I submitted an app to the App Store and experienced the process first hand.

Kafkaesque is an overused term, but I've not been able to think of a better description. One of my rejections had the following text:

> Your app uses a third-party login service, but does not offer Sign in with Apple. Apps that use a third-party login service for account identification need to offer Sign in with Apple... Please see the attached screenshot for details.

This was the screenshot they mentioned: https://i.imgur.com/7QGLE6J.png

Amusingly, almost everyone I've shown this to is like "So Apple's AI is messed up, huh? Were you able to get in touch with a human?"

I have had that issue with Microsoft and when it existed, Blackberry as well. I just resubmit if I don't think the problem is real and half the time it works.

That's what I did, and fortunately it's not come up again—yet. But it was a trip to experience first hand, and on my very first submission ever (!), what I'd been reading on this forum and others for years.

That reason sounds pretty straightforward. Where’s the ambiguity in it?

It's the first button on the screenshot

The screenshot they cite as evidence for the app offering other third party vendors but not apple for sign ins... shows Apple as the first sign in option

that the screenshot features a sign in with apple option

If only the OP had provided a picture of their login screen, so that we could evaluate whether they're missing a "login with Apple" button and Apple is making a reasonable request, or whether such a button already exists and the OP is caught in a byzantine maze of confusing and contradictory instructions that they will only be able to escape through a combination of perseverance and blind luck.

For what it's worth, I must stress that they sent me that screenshot.

> escape through a combination of perseverance and blind luck.

It's funny you say that, because you know what I did finally provide? A bunch of 15-30 second videos demonstrating the salient features (sign in with apple, user safety features, how to get to terms of service and privacy statement, etc) that Apple wants to know about. After that the back-and-forth ended and my app got approved. But that may have just been a coincidence.

Perhaps I woke up in a strange parallel world given the downvotes but isn’t the usual assumption that a button for a feature != the feature actually working correctly?

In other words the button, or sign in pathway, could have had some sort of ‘bug’.

I assume that is why Apple’s system flagged it, otherwise we would have to believe that the folks working on Apple’s app store ‘sign in with AppleID’ review team are bozos and flagged, or had an AI that flagged, a working implementation that followed their guidelines?

If that is the case then I agree since tens of thousands of apps have now implemented ‘sign in with AppleID’ a few months after a splashy introduction with undoubtably lots of behind the scenes attention it’s a pretty bizarre maze to get caught in.

I think we found the Safari Extension reviewer's HN handle!

To be honest, if that’s a well intentioned comment, it’s pretty bizarre, given your profile background. You automatically assumed: visible button = working feature without any bugs

It's a joke, relax =)

And there's a saying: familiarity breeds contempt.

Was it because of the Sign in with Apple button color?

Always make sure that people can instantly identify your custom button as a Sign in with Apple button. If your custom button differs too much from the standard one, people may not feel comfortable using it to set up an account or sign in. App Review evaluates all custom Sign in with Apple buttons.

https://developer.apple.com/design/human-interface-guideline...

I thought that might be the case but it doesn't seem so different from the version on the HIG[0] or the sample project[1]. I ended up replying something like "it's there, please look again. It's the first one." And it hasn't come up since then. But I've only submitted one build. Will see when I submit the next.

[0] https://developer.apple.com/design/human-interface-guideline...

[1] https://developer.apple.com/documentation/authenticationserv...

They usually point that out specifically though. Although maybe they proved their point with their review staff.

So you already had Sign in with Apple implemented yet they told you to add it?

I had a similar experience for my Hacker News client. Apple rejected my app initially because they require developers to use SFSafariViewController instead of WKWebView when displaying third party websites from the app. I replied back to them that my app was already using SFSafariViewController and I didn't even have any WKWebView in the app so I wasn't sure what they were referring to.

Then it got rejected second time with: "- The layout does not take advantage of the full screen - When tapping on some of the content, the right part of the screen populates with a white page with no content."

To this I replied:

> My app did take advantage of the full screen iPad experience. In fact that was one of my selling points that my app supports the iOS UISplitViewController for iPads which lets you view 2 view controllers at the same Time size by side. From the screenshot the reviewer sent, it appears they clicked on "New" (I could tell because the number of points and comments in the screenshot are all zero). Now since they clicked on "New", obviously, it won't show any comments and is what the reviewer saw.

I had to ask the reviewer to try going to the main page and clicking on "Trending" or "Home" or "Best Stories" where they will see the full content? There is plenty of content and this takes advantage of the iOS native SDK for UISplitViewController. When you select a story on the left side, the detail story on the right shows the story discussion, threaded comments, ability to upvote/downvote, favoriting stories and comments (swipe left on a story or comment), view the full article by clicking on the link image on the right of a story, tap the reply button to reply to comments or stories, use the date picker to go to articles from a specific date, view leader boards of the top users, search for stories and comments etc. You can tap on comments to collapse the comment thread (not possible using a website). You can also swipe on a comment or post to upvote (left swipe), favorite (right swipe) which is also not possible using a website as these are only possible on touch screen devices. These are all implemented using native iOS SDK. UISplitViewController isn't even possible using a website.

It almost seems like the review team simply launches an app and rejects things without taking the purpose of the app in context.

Now to be fair to Apple, I develop for android too and good lord, they are even worse if your app happens to get caught by their "Artificial Unintelligence". You end up having to deal with a computer without any human on the other side unless you can make enough noise on social media and get some tech blogs to write about you as it happened recently with Droidscript:

https://news.ycombinator.com/item?id=26956077

Now to be fair to Apple, I develop for android too and good lord, they are even worse if your app happens to get caught by their "Artificial Unintelligence".

With Android, at least you can always just post the APK elsewhere and have your users get it from you directly; no such choice for Apple (unless you count the tiny number of jailbroken users.)

I know someone who works on policy for a major App Store (not my employer, or I wouldn’t be blabbing).

They outsource content testing to an overseas operations team whose metrics are based on numbers of cases reviewed, with no review quality metric. Of course, they get what they incentivize.

> I used to be a pretty ardent defender of Apple's right to control their platform. Then I submitted an app to the App Store and experienced the process first hand. Kafkaesque is an overused term, but I've not been able to think of a better description.

One of the main reasons I use against censorship of "offensive" content and why I have become a free speech absolutist.

In fact, this whole Apple rejection thread applies to free speech too:

https://twitter.com/thomasareed/status/1420831606227488772

> My last experience with a rejection that required appeal didn’t go so nicely. We ended up having to spend a couple months ripping a feature out and replacing it with something lesser… when other apps were already doing the thing we wanted to do. This was a few years ago, tho.

> I feel you. We’ve had similar experiences. Really not fun and definitely not cheap for a small business. The worst thing is that you don’t always get the confidence that “fixing” what annoys apple will secure an approval. Definitely kills you inside.

> Yeah, very true. Sometimes the rejection is very vague on exactly what needs to be fixed. That’s very frustrating. Have to say, though, I’m impressed with the outcome in this case, given how badly it started.

> And the “ptsd” lingers a long time after experiencing that type of rejection from the app review. It’s definitely something tough as a business or even a dev to feel that powerlessness. You tend to self limit yourself which is not good for the product or the users in the end.

The "PTSD" referred to here is what happens with censorship too where people self-censor because they don't want to get caught in the big tech "community guidelines" trap.

It's kind of bullshit too though that you are required to add an apple login.

As a user I love it. More privacy for me.

Agree. It's made me sign up for many services that I never would have otherwise.

Lol, privacy? You think that's what it is?

Apple forces you to use in-app purchases, Apple forces you to stick with their crippled browser ecosystem, it has no compatibility outside of Apple. Their protocols for messaging and device interop are closed-source; they have tech that tracks all your devices + these new beacons, and all your devices are those beacons too.

You are more heavily tracked under Apple than you are in any other system. Did you think your iphone would be a location tracker for another device?

You're mixing up "privacy from Apple" and "privacy from random third-party developers when using 'Login with Apple' specifically".

You could have saved yourself a fair amount of embarrassment with just a little bit of reading. Apple can’t decrypt beacon locations. https://support.apple.com/en-ca/guide/security/sece994d0126/...

No. You can't get an Apple ID without providing a phone number, street address, and email address.

That must be recent, I didn’t provide a street address.

The street address is not verified/authenticated, but the email and phone are.

Sure, but you can have an anonymous email address and phone number in the US.

I recall having to provide this around 2013 or so around the time I got an iPhone 5. But possibly it was part of their credit card verification? That could explain why some have been asked and not others.

As with others, I trust Apple to safeguard this information waaaay more than constantly rolling the dice with shady app publishers every time I sign up to something.

That I can sign up to TikTok with "Sign in with Apple", with an auto-generated Apple Privacy email address and literally no other information, is quite amazing and useful.

Apple surrenders customer data on over 30,000 customers per year to the US government without search warrants or probable cause.

This is disclosed in their own transparency report (FISA).

This isn't optional; Apple has to provide data on any user account the USG demands of them, without a search warrant.

Your trust in them is misplaced.

Most of us are more worried about scummy advertisers than three-letter agencies.

Advertisers can't put you in jail indefinitely without trial because you published something they didn't like.

The USA IC can and will.

Yes, but the odds of that are quite low for the overwhelming majority of us.

All companies operating in the US are going to be subject to the same.

I’m not sure what your point is. This is unavoidable for any company subject to FISA or you know, laws.

I care far more about companies like Google and Facebook taking my information and using it in tracking and advertising, or selling it to whomever wants to pay for it for whatever reason to build a profile about me and using that to take advantage of me.

On that front, I trust Apple far more than any of the other options. They’re using it as a competitive advantage and it’s working.

Did you want Apple to have the power of the Dutch East India Company? How else would Apple resist national governments?

They could not collect the information in the first place, especially for free customers who just want to download free apps.

Or how about this, be able to install free apps without any apple ID!

Where does it say that this information was provided on demand without a warrant? The only exception to a warrant requirement is a FISA letter, and all US persons are required by law to respond to those.

And in terms of NSLs, they only turned over data for under 500 of them so far this year (and it could be a lot fewer since the bucket size is 1-500).

How do you get an Apple ID without a street address? There are still places in the US that don't have street addresses, even after 911 attempts.

This is a serious question since many of our students don't have a street address. Many reservations only have PO Boxes.

A P.O. Box address should be fine.

As a developer it was a pretty exotic experience. Their OAuth service is unlike any other big name provider I'd used. Some day soon I hope to open source my Apple backend integrations in TypeScript, because Apple provides no backend SDKs, at least not for Node/JS/TS.

Lots of people seem to use Sign In With Apple, though. They make it really nice for the user. The email relay thing is pretty neat.

The thing that troubles me with OAuth is that if you don't provide apps with some other way to sign in and you lose access to you OAuth account, you lose access to all your applications.

It was pretty painless to implement in my case, though I was already familiar with communicating with Apple backend services.

It is even worst when your App isn't actually the content owner but a shell or client to existing services.

Which means you cant add Apple Login, and that also means the end of your App.

I don’t fully understand. Have a link to describe the issue?

Imagine a 3rd party HN app - they can't control the login options, and thus can't add apple login.

There are a few APIs I use where the OAuth dance would show users site and Google login options, but not Apple.

It’s only required to use Sign In with Apple if you use other third party logins—which wouldn’t be possible with your scenario anyways since you couldn’t do an oauth dance if you don’t own the private key.

White-label apps never use Google or Facebook authentication and not Apple?

A white-label app would be the content owner. This sounds like describing a GitHub or IRC client or something

I have a Patreon page and a recipe in Zappier that sends new Patreons to Mailchimp. It seems Patreon allows to Login with Apple, because a few of my Patreons used it but never received any newsletter (it's one of the perks). I checked and it was because the email address that Patreon received and tried to send to Mailchimp failed. I lost a few Patreons because of this, because they thought I never sent the newsletter to them.

>I checked and it was because the email address that Patreon received and tried to send to Mailchimp failed. I lost a few Patreons because of this, because they thought I never sent the newsletter to them.

AFAIK apple's private relay only accepts mail signed by the corresponding developer. In other words, no third party can use the private relay address.

edit: https://developer.apple.com/forums/thread/120112

Honestly I don't know, I never developed anything with Apple. But as a content seller that was my experience :(

Seems like that could be a problem for some business models.

Is an app allowed to prompt for a real email address if it uses Sign in with Apple?

> Is an app allowed to prompt for a real email address if it uses Sign in with Apple?

It can ask, but cannot require it.

It's not just bullshit—it's diabolical.

On your iOS device, you are logged in with one Apple ID at a time. This Apple identity is the one that makes In-App Purchases ("IAPs"). So if a user makes a purchase in your app signed in as "bob", and then logs out of your app and signs in as "alice", they still have that IAP. Therefore, the simplest, most correct way to have an app with IAPs and third party auth is to exclusively use Sign In With Apple, because Sign In With Apple is tied to your device's currently signed in Apple ID and all of its IAPs.

https://stackoverflow.com/questions/63272699/how-do-you-hand...

I considered removing my other third party auth methods but have kept them in to see how it goes... :|

Apple account is not the same as login with Apple. IAPs have always been tied to the Apple account. It’s a pain in the ass to handle all the cases. It’s not any easier on Android either.

Right, but Sign In with Apple is tied to your Apple account. I have no way to make an IAP autorenewable subscription and tie it to “bob” in my system. It’s tied to the iOS Apple account.

You can’t tie it to bob. You have to look at the receipt and reward from that. So bob logs in you look at the receipt and bobs your uncle you have the subscriptions.

And then what if, on your service, `bob` signs out and `alice` signs in? Then `alice` not only has `bob`'s subscriptions, but she also can't buy her own.

Apple doesn’t see it that way. Apple ID has the subscription, not the the user account.

Apple has supported switching between multiple user accounts on a device for years, but since you're not a school or a company, you can't have it. Buy four iPads.

It's pretty stupid.

Technically, you still have that capability. After the user is authenticated with their Apple ID, you can present a profile to provide username/password/email.

Yep, but then all username/password/emails that log on using that device share the same subscription IAPs—namely, those that belong to the Apple ID that's sign in to iOS.

Only if you allow login with other 3rd party login services. Honestly this seems pretty reasonable so apps are guaranteed usable even if you don’t have a Facebook or Google account. There are apps that only have social logins what with the “outsource your auth” marketing a few years back.

As a user, no it’s not bullshit or diabolical, it’s a godsend. I’m glad they enforce it, saving me from handing out my email and a ton of other info to every random app I want to try for a while.

Only predatory devs would complain against this rule, and I won’t miss them.

There are so much rules, yet for some reasons apps that are free to download but require a subscription at $30/month to do any action (so, not even a freemium model and arguably qualifiable of scam) are present in the store...

Edit for the downvoters: I'm speaking of apps doing local data manipulation (in my case, I tried few photo collage apps), not something linked to a web service. Those should be one time purchase, not subscription based.

That’s just monopolist behavior masked as some kind of privacy user benefit. These companies are enjoying too much power and we need new modern anti trust regulations that can deal with companies that are operating in a market with more than one competitor but with reduced competitive elements.

That is a bit harsh. I haven't once experienced a virus, or malware, with Apple.

I'm not a fanboy. A human shouid review every app submission though. Maybe they do? The minute Apple lightens up on security, they know they will lose a lot of customers.

If a company can achieve 70% margin (apple services), it's a clear sign that there's a lack of competition, or structurally anti-competitive elements.

Why? Because normally if profit is that high, other players will see that and seek to compete in that market, thus driving down those margins.

Certainly legislation shouldn't be based on a specific margin number, but if a company can achieve these kind of margins over the long run, then it's a clear warning sign.

Where to draw the line for anti-trust is philosophical and up for debate, of course.

In Apple's case, taking a 30% cut on all app store purchases is something that probably will be legislated against in the future. For AWS, charging excessively to egress your data and move to another platform is an anti-competitive tactic that will likely be disallowed.

Current law does not appropriately account for the scale, power, and network effects that are of themselves anti competitive.

> If a company can achieve 70% margin (apple services), it's a clear sign that there's a lack of competition, or structurally anti-competitive elements.

"most SaaS companies should achieve gross margins in the 75%–80% range, depending on the level of professional services required to deploy the solutions." - https://leadedge.com/why-we-like-saas-businesses/

Dropbox:

" GAAP gross margin was 78.6%, as compared to 77.3% in the same period last year. Non-GAAP gross margin was 80.2%, as compared to 78.3% in the same period last year." - https://www.businesswire.com/news/home/20210506006050/en/Dro...

You do realize that most SaaS based software business are targeting 70%+ margin? Are they all structurally anti-competitive?

It's pretty simple. In a highly competitive market, margins will approach 0.

This is self evident, due to how competition works. The only way higher margins are achieved is by being a first mover (fine), or by using stickiness to make it difficult for customers to switch (AWS egress fees).

Thought experiment. Say Apple had to prompt you to choose from top 3 app stores when starting up your new iPhone, and was not allowed to default, or even suggest as default, their own app store. A dev clones the app store 100% in appearance and behavior, but charges a 5% fee to app creators. In this world most likely Apple would lose a huge portion of their app store margins, as customers could make microtransactions at greater discount.

Yes, Apple would likely still carry some premium due to being first party, but not 30% cut.

What we'll likely see, probably many years from now, is a requirement to have open APIs to allow for easy transfer between SaaS services. Yes, this would reduce SaaS margins significantly. It gives the customer a huge amount of leverage to negotiate in their favor.

Customers having leverage is what leads to a competitive and fair market.

Right now SaaS are allowed to operate as a de facto Monopoly through network effect (cost of switching is very high). A walled garden is not a monopoly in the traditional sense, of course, but is a de facto one over the set of people within your walls.

Yes, many years in the future, software is likely to be delivered close to "at cost" which would be a huge win for the customer, and really society at large. Right now that money is going towards paying devs 10x the median salary, which obviously creates a bimodal society, to a certain extent.

Believe me, I'm as capitalist as they come... But capitalism only thrives in a competitive market.

>I haven't once experienced a virus, or malware, with Apple.

https://9to5mac.com/2021/05/07/emails-reveal-128-million-ios...

Malware exists but as you can see Apple will not even let you know if you were affected, some fans will assume that your are not informed because Apple protects you (similarly how Apple protects you from better deals)

This happened to us on an update submission we made. We hadn’t changed anything with the sign in screen and they suddenly rejected us for it.

Turned out they were just being more strict about the actual styling of the Apple sign in button as they want it to look identical in every app essentially.

Turned out they were just being more strict about the actual styling of the Apple sign in button as they want it to look identical in every app essentially.

Then why couldn't they have just said that, instead of an (almost passive-aggressive) "your app doesn't have Sign in with Apple" bullshit reason?

Bureaucracies love boilerplate text

So do software developers, especially with respect to error messages.

@dang, perhaps change the URL to link to source: https://twitter.com/thomasareed/status/1420678663046111232

Ouch. Changed from https://mjtsai.com/blog/2021/07/30/safari-extension-rejected... now. Thanks!

Submitters - please follow the site guidelines: "Please submit the original source. If a post reports on something found on another site, submit the latter." https://news.ycombinator.com/newsguidelines.html

Was it an overzealous reviewer reacting to the name “Malwarebytes”?

I'm reminded of how Digital Research (the CP/M people) was originally Intergalactic Digital Research, but they dropped the Intergalactic out of concerns that it made them look unprofessional (although I think at that time they might still have been operating out of Gary Kildall's kitchen).

My guess: because none of their other apps are in the store (they ship via developer id signed apps outside of the store), the reviewer didn’t find any other app they made and decided that an extension like the one they were making needs to be from a company with a more reputable AppStore account.

They should of course also have checked what Malwarebytes does outside of the store, but they didn’t which might or might not have been actual internal review policy

Url changed from https://mjtsai.com/blog/2021/07/30/safari-extension-rejected..., which points to this.

Reply on news.ycombinator.com