Hacker News new | past | comments | ask | show | jobs | submit login
Apple, Hey, and the Path Forward (hey.com)
107 points by braythwayt on June 22, 2020 | hide | past | favorite | 111 comments



I may be cynical to this whole thing, but to me this conclusion reads as Hey acquiescing to Apple’s policies, and now the whole thing feels like a PR stunt, particularly shaded by DHH’s documented “pick a fight” stance [1]. It feels like we got played. It’s remarked as a compromise, but it doesn’t feel that way to me.

1. https://m.signalvnoise.com/pick-a-fight-on-twitter/


Im not sure if they planned it, but I feel like they definitely played their hand around using it as a marketing / publicity stunt


Agreed. You cant "plan" an App Store rejection when they did show they make all the effort to comply with the App Store policy.

Again, Hey was really hyped, 70,000 on waiting list alone. They dont even need any of these marketing to get customers. Name me an SaaS product that had these kind of traction baring FAANG.

But this letter, the initial tone from DHH, and no further complains about App Store really leaves a bad taste in my mouth.


I know this will be unpopular on HN, but I actually appreciate Apple’s stance here as a user.

I don’t want to give developers my billing info. I even have to use a special throwaway number at Home Depot. There’s no way I’d trust hundreds of developers with that info when I don’t even trust a F500 company.

I don’t want to download apps that literally do nothing except kick me out to a website for a billing transaction, especially a recurring one with no way in app to cancel that subscription. If I delete the app, I want to get promoted to cancel the subscription.

Apple has some major issues with the App Store (search, discovery, business models, % cut, just as a few), but in this case I actually agree with their principles.


I think they should just go with the Twitch (Amazon) strategy. Allow for IAP for subscriptions, but just factor in the cost of Apples % cut. Still offer the option of paying you directly on your website or whatever for the $99/year, but for people that really want to subscribe through the app they can pay $150/year and have the subscription cancel when they delete the app or whatever


Apple doesn't allow that. Your in-app prices have to match your out-of-app prices. Which would be fine if the cut was like 1-2%. But 30% is a lot.


I dont that is the case any more. At least we have multiple reports that Apple allows that. ( Likely due to legal requirement )


If they allow it now, it's either fairly recent (past couple of years), or they are inconsistent about it.



But then the rule could be "one of the payment options needs to be Apple Pay, we take 3% cut".


or let the developer say "Sign up with Apple Pay for 30% more, or go sign up at our website for standard pricing."


43% more if Apple wants a 30% cut.


I call this the paradox of Apple: they're the least open platform and perhaps as a result are the best for privacy, security, and user trust.

Android is much more open and is a spyware free for all.

The Internet is like a failed state. Apple is like a walled and privately patrolled compound where the wealthy have taken shelter. Outside the compound everything is spying on you and if you get something from a random site there's a decent chance it contains malware.

Tech-savvy users think nothing is wrong and wonder why everyone shelters in the compound, but they're like the street kids who grew up with hard-earned street smarts. They know how to avoid trouble and know how to fight. People like that can live on the street but it's no place to raise a family.

Taking this analogy way too far, I guess you could compare a web browser with its armored sandbox JavaScript VM to an armored vehicle with bullet proof glass that you can use to drive around. Just make sure you've got plenty of gas and never open the door.


Tech savvy? Mate you can pry my iPhone from my dead nerd hands


> I don’t want to give developers my billing info. […] I don’t want to download apps that literally do nothing except kick me out to a website for a billing transaction

I agree. But I'm not ready to pay $142/year instead of $99 for that convenience.


And it should be chosen by the user, not enforced by the gatekeeper


Exactly. Which is why I think it's fine to force apps to propose an IAP, but they should be able to inform the user that there's another option (for another price eventually).


I agree with you. There is much place for improvement but the verion you donwload now on AppStore is new user hostile, especially when you figure out that they have a waiting list...


But what you're describing, is not actually Apple's stance. Apple is fine with apps providing their own payment solutions, as long as what those apps are selling is not digital goods. There are plenty of apps for buying clothes, groceries, (physical) books etc. that do not use Apple pay, and do not give Apple a 30% cut of each purchase.


In this particular case In-App subscription option was not added, though.


No problem, nobody forces you to do it. They could inform you whether the app offers paying through Apple on the store page.


Apple would still be able to optimize around your experience even if they allowed other marketplaces to be installed. Apple and developers would be under more pressure to provide you a good experience if you could install open source utilities from F-Droid as easily as $500/year subscription utilities.


If you're at the size and visibility of Hey, you can strike these kinds of compromises. This isn't particularly surprising. The real issue is the smaller guys, who are forced with a "take it or leave it" roadblock from app stores.

You'd hope the bigger players - particularly ones who have hit these roadblocks - to become advocates for developers. Perhaps working in some sort of ongoing developer agency/evangelist fashion would be good for all involved.


Lots of people want the walled garden abolished, but it would be HUGE if Apple simply created a set of guidelines—no matter how draconian—and then applied them equally and transparently to everyone, big or small.

If the guidelines are transparent and fairly applied, it's up to you as a developer whether to play their game. But it is ridiculous that small developers are literally spinning the Wheel of Fortune every time they submit an app that does exactly what Google, Netflix, Amazon, &c. are doing.

And speaking as a user, I bought a mail app called Spark. It's great. But now I have to worry, what if Apple decides that the next release breaks their rules? What if they pull the app entirely?

Capricious and unjust application of the rules is bad for users as well as developers.


Couldn't you demand your money back? You or the app provider sue Apple? Is all of this prevented in the ToS? Would that really be enforcable?

If the answer is "no" or yes for the last one, that'd go pretty far against my sense of justice. But of course we're talking about american laws.


Do you really need an app on iPhone to mail?


what can you use besides an app to get your mail on iPhone?


A web browser? Aside for a few apps that provide significant advantages over the web version (or those that force you to use the app even in "requst desktop version" mode), I use a browser for everything. Hell, even though the YouTube app was preinstalled on my phone, I still used the mobile site because I just found the experience better.


a browser is an app... but I try to do like you and avoid random and single-purpose apps because they are riskier.


Exactly, I consciously check email when I want/need. So I don't even need push notification.


There are more than 2 million ios developers worldwide.

There is literally no evidence at all that developers are spinning the wheel of fortune or that Apple is capricious or unjust.

Given that number of developers, hundreds of mistakes every year would be an amazing track record for Apple.


There is literally no evidence at all that developers are spinning the wheel of fortune or that Apple is capricious or unjust.

Okay then. That settles the matter. It's a mass delusion!


I’m clearly not saying that.

What I’m saying is that in order to make these claims you’d need to be able to show that it’s more than just a normal rate of error.

If you just take a few reports (or indeed even a few hundred) and ignore the size of the sample, then the conclusion is likely to be flawed.

Do you actually know what the rate of ‘capricious’ rejections is? I have seen a few 10s of cases reported, and many of them aren’t actually capricious, although a few clearly are.

My guess is that the chances of a capricious rejection of an App Store submission is less than 1 in 1,000,000.

I’d say that is neither unjust, nor capricious, and simply a reflection of scale.


I agree that when they make a mistake in the form of applying the rules inequitably, get called out, and fix it, that's a mistake.

But I claim that when they make a mistake in the form of applying the rules inequitably, get called out, and double down on applying the rules inequitably, that is not a mistake, that is capricious.

There may only be a small number of times they have been capricious, but they are not "making a mistake." They are applying the rules capriciously.

And while nobody is getting killed, the principle of justice is the same here as in our society. Injustice anywhere is a threat to justice everywhere.

One person imprisoned for a crime they didn't commit and the police knew they didn't commit taints the entire justice system. It removes confidence for everyone.

It's the same principle here. Mistakes, fine. But applying the rules inequitably and doubling down on that even once taints the system for everyone.

TL;DR I agree that the system usually works. But for a mistake to be a mistake, Apple has to be prepared to fix the mistake, not double down on continuing to have different rules for different developers.


Ok - but then the issue is - what actually constitutes a mistake?

In the Hey case it does seem like Apple was simply applying it’s rules, and DHH didn’t quite understand them.

As for the justice system - all justice systems are radically tainted in this way.

No system has ever been created which does not have this problem, in all of human history.

If you are expecting Apple to achieve perfect justice, that is fair enough, but it’s also fair to acknowledge that it’s an unsolved problem.

It’s also simply not reasonable for developers to be ‘in fear of capricious rejections’.

It’s fairly predictable, or easily resolved in most cases.


In the Hey case it does seem like Apple was simply applying it’s rules, and DHH didn’t quite understand them.

I was far from simply applying the rules. The only documented rule they were applying was the one, which states that you must use Apple's in-app purchase if you offer sign-up within the app. There are many high profile apps (Netflix, Kindle, Fastmail etc) that require paid memberships but which don't offer sign-up within the app (not to mention several apps that Basecamp already offer in the app store), and Apple has apparently been fine with those for a long time. For that reason, Basecamp had every reason to think that they were in compliance with both the letter of the guideline as well as Apple's interpretation of it.

The distinction between what Apple calls reader apps and whatever they deem an email app to be, as well as the consumer/business distinction that an Apple spokesperson also offered as an explanation to one publication, are not mentioned in the app store review guidelines, and Apple has not talked about them before, so how on earth can DHH be blamed for not understanding that these distinctions mattered?


Just as with YouTube, or Facebook, or just anywhere else whenever there's a big player involved: things get resolved if you have enough clout and you make a big enough of a stink-up.

I'd sincerely hope for a genuine change of heart at Apple and that Hey's resolution was just not the exception to the rule, but I seriously doubt so.


There was no change of heart at Apple. Hey changed their app to conform to the rules that all other developers have done.


Smaller guys aren’t forced to take it or leave it. Even the no name companies like ACloudGuru that have “view only” functionality force you to subscribe outside of the App Store.


I'm glad Hey now has a future on the App Store – it's better than not existing at all, but the whole episode has been absurd.

This new version introduces a new free option for the iOS app. Now users can sign up directly in-app for a free, temporary, randomized @hey.com email address that works for 14 days. Think of it like a temporary SIM card you buy when traveling. Or for when you don’t want to give out your real email address, like a short term “for sale” listing, like Craigslist does it.

This, in particular, is just ridiculous. A whole new feature, designed and developed in haste over a weekend, simply to satisfy Apple. But then we've had to do that ourselves in our own apps, and no doubt thousands of other devs have their own stories.


Why is it ridiculous? Who wants an app that you can’t do anything with when you download it?

Even Office for iOS lets you view documents without paying and then you need a subscription to edit them.

Name one retailer that lets you hock your product in their store without paying anything?


> Name one retailer that lets you hock your product in their store without paying anything?

I realize that Apple brands it as a store, but analogies to other "stores" don't really make sense. 90% of apps are free[1], so you could similarly ask "name one retailer who gives away 90% of their products for free".

To me, the App "Store" is part of the product you get when you buy an iPhone. When free apps are distributed through it, they aren't getting "free" placement, you (the iPhone customer) are getting the service you paid for when you bought the phone.

[1] https://www.businessofapps.com/data/app-statistics/


> 90% of apps are free

Is that free free or free up front with recurring revenue because your engagement is profitable for them via advertising or in-app purchases or both? Because those are not the same.


Is this an argument against the rules? Apple in that case is more lenient than most other retailers.


> Name one retailer lets you hock your product in their store without paying anything?

Apple. Google. Microsoft. Samsung.

> Who wants an app that you can’t do anything with when you download it?

People who want a client for their email service?

Hell, fastmail is even an email app, that has no in app purchases, and doesn't work without an account. (and is in the app store)


FastMail is adding IAP to their app. They stated that Apple has asked them to, and that it was on their long-term roadmap.

https://twitter.com/Fastmail/status/1273800222989324288?s=20


If you make money. They want to make money. Can I use all of BaseCamp features for free?


I don't think you can use any of basecamp features for free. [1]

They make money, that is not up for debate.

(and yes, I know, their platform, their rules, etc etc, but nothing about that says people cannot fight it, and make it politically difficult to let them bleed money from people for a very basic service.)

1 - I have never used basecamp, or looked into it, so YMMV


You can use any app that integrates with Basecamp without paying a cent to Basecamp for the integration itself. You can even browse a list of integrations hosted by Basecamp. https://basecamp.com/extras

Basecamp isn't free, but neither is an actual IPhone. In the case of the tools that are enabled on their platform, Basecamp's library doesn't require paying basecamp, and Apple's does.


And neither is my computer or internet connection. But that doesn’t mean I expect BaseCamp to be free. Can I distribute my games on any of the console manufacturers system for free?

And before someone responds that you can buy physical games for consoles, they still have to pay the console manufacturer for each physical game sold and the console manufacturers have to approve it.

Can I use BaseCamp’s APIs for free and create my own app? In fact, BaseCamp just announced that they will not allow third parties to integrate with their software that use their platform to track employees.


Netflix's app (among plenty of others) doesn't work unless you're already subscribed


And they also are “reader apps”. They offer view only functionality for content. That exception applies to all sorts of apps no one ever heard of that force you to subscribe outside of the App Store.


As mentioned elsewhere, you could take FastMail if you want an email specific example


Apparently FastMail has to pay IAP fees "as of June 19, 2020", according to https://youdownloadtheappanditdoesntwork.com/.


It’s rumored that Fastmail’s next update won’t be approved. That’s when they usually throw down the hammer.


FastMail had an update 2 days ago


And they also have to start charging IAP.

https://youdownloadtheappanditdoesntwork.com/


The reason the app didn't work when you downloaded it is because of Apple's own policies.

Also: https://youdownloadtheappanditdoesntwork.com


And BaseCamp was free to offer in app purchases at a 43% markup to make up for the 30% cut. BaseCamp is not a non profit anymore than Apple is.


Can you?

I am pretty sure that the rules about IAP make it very clear you have to charge the same price on and off the app store.


No it doesn’t. In fact, when Spotify was still allowing in app purchases, they did exactly this.

https://www.theverge.com/2015/7/8/8913105/spotify-apple-app-...


That was Apple's initial attempt, but the pushback was fast and furious. Spotify, especially, led the charge that this was ridiculous and Apple relented pretty quickly, IIRC. Now you can charge more to cover their 30%.


OK, that's probably what I remember then


>Who wants an app that you can’t do anything with when you download it?

Apple has accepted plenty of those into the App Store before. Maybe you can't expect every application on the App Store to work after downloading. I don't own a Tesla, so why should I expect the Tesla app to do anything for me?


There has always been a distinction in the App Store between an app that is used to purchase physical goods or ties in with physical goods than those that are used exclusively for digital goods. You can use the Amazon app to buy goods within Amazon’s store. But you can’t use it to buy Kindle books.


> Name one retailer that lets you hock your product in their store without paying anything?

This is a bad take. Hey is a subscription service. If you buy a magazine from a newsagent and then sign up to a subscription from it, the newsagent doesn't get to claim 30% of the subscription fee.


You do however pay the retailer something. Also, the physical retailer doesn’t provide you in further infrastructure - automatic updates, notification support, a printing press to help you create your magazine (ie developer tools), etc.


The analogy falls down because stores generally don't benefit a great deal from having products in their store except insofar as the money they make for the store, or occasionally the money they'll make by consumers buying other products in the store (in the case of loss leaders).

The iOS app store could be 100% free apps, or even 100% apps that Apple doesn't get a cent of, and Apple still benefits from those apps existing.


So now Apple should operate the App Store as a loss leader? The console makers also benefit from games because it makes their consoles more valuable. Roku benefits from apps being available. Are any of those free?


It’s not “simply to satisfy Apple”. The rule is so that Apps people download provide functionality you can at the very least try out.

This is about providing a consistent user experience, and a consistent user experience is why people trust the store and actually download things from it.


It should be about both: Following your distributor's rules and providing the good user experience of an app that doesn't immediately demand a login when you launch it.

Back when I was working at an iOS developer, our leadership brain trust decided that the next version of our app should require the user to log in, or sign up for an account, and not let the user move forward unless they did so. I advised against this because, 1. Apple generally forbids the practice, 2. It's an unnecessary roadblock to getting into the app (having an account provided optional benefits), and 3. The engineering effort, plus the effort to rework later once Apple rejects it, was not worth it. I was unconvincing, so we did the work, submitted to the App Store, and lo and behold, it was rejected, and we had to scramble to re-work a "skip the login" function (in 6 point gray-on-black text) link into the flow. sigh

This was almost a decade ago. I guess my point is that this whole episode, fair or not, was totally predictable and avoidable. I bet that Hey had engineers internally shouting for the hills to not do this, who were being ignored. Maybe the company's leadership just wanted to pick a fight with Apple. Who would want to start such a fight, I don't know? If you're not a behemoth then there are only two possible ways that fight ends: 1. tears and engineering re-work, or 2. App Store banishment. It's just not worth it. Or maybe it is worth it if you're an exec and it's not your time being wasted but some poor engineer working over the weekend to scramble for a fix.


Which is a better user experience: the new implementation, or the original?


TFA says, "A win for Apple, a win for us, and a win for our customers."

Basecamp appears be saying that the new implementation offers a better user experience.


The win for them is that they get to update their app instead of being booted from the app store.


I suppose if you've been sitting on the sidelines since 1971 to see if this whole "e-mail thing" was a fad or not, and currently don't have an email address, a 14 day trial with some rando address might be just what you're looking for. Now if only you had some one to email...


I may just be under-knowledgable of App Store practices but -- how much of this could charitably have to do with how can Apple confirm / accept apps that they can't test? With onboard payments they could fake charges and get into the app functionality, but without it and without any free content how can they do that? Or if you're Hey, are you able to specify credentials for Apple testing?


Well, when I worked for an enterprise health app that required an outside contract with employers, Apple required a valid login for testing. So, we gave them one. Surely, Hey did the same.


For apps like Hey, you must provide credentials for approval.


On the first read this seemed like a conclusion of the story, but on a second read it sounds like this is another chess move. 1.0.2 was approved (to Hey's surprise, and likely just to ease some PR/legal pressure), but 1.0.3 is still pending. Hey's approach here seems a bit like lawyering the rules to me -- I could see how temporary email addresses can be useful, but the feature seems to mainly exist to appease Apple rather than users. I hope it works for them, but I'm not holding my breath.


I agree it's a chess move. But it's also a way for both sides claim victory.

Apple doesn't want to change its rules; Hey doesn't want to change how users sign up.

I guess I'm saying I'm more optimistic this will settle the dispute. But I agree, the feature is more aimed at Apple than users.


If someone sends me a PowerPoint slide in an email and then I go to the App Store to download PowerPoint to view it, it would be a horrible user experience if I couldn’t do anything with the app before paying for it.

On the other hand, I can still view the slides without paying MS, but I have to have a subscription to edit it. I can’t pay for the subscription within the app. I think that’s a decent compromise.


Looks like 1.0.3 has been updated to "In Review" status.

https://mobile.twitter.com/dhh/status/1275085027613609984


The cynic in me thinks this whole thing was a publicity stunt. I find it hard to believe that they hadn't thought of offering an in-app free trial. I wouldn't be surprised if they had it implemented all along in a separate branch and just waited a few days to create a storm.


That could have been the case if the app had been rejected. It was approved, and Apple says it was a mistake that it was approved. And that point, they can't know that bug fix updates would be rejected.


Considering DHH’s choice of words on Twitter, I’d be inclined to believe the same too.


I think Apple is overreaching on this whole thing, but it feels somewhat disingenuous to argue that they did what Apple/Phil asked for.

He asked for a basic version that people can use without their service, and instead they implemented a variation on a 14 day demo.

Then they're posting publicly saying "We did what Apple asked for", without clearing this new solution (which isn't really what Apple asked for).

To be clear, I think Apple shouldn't be demanding a 30% cut here at all! But this article feels like they're presenting their solution publicly in order to try to leverage Apple into accepting it.


> He asked for a basic version that people can use without their service

To be clear, Apple asked them to do something that they surely must know isn't possible. Hey specifically doesn't offer IMAP/POP access because they layer enough features on top of email that IMAP and POP simply can't support.

For the same reasons they don't offer IMAP/POP access, they couldn't "just" add the "bring your own server" feature that Apple asked for. The Hey iOS app isn't an IMAP/POP client with fancy chrome; it's designed specifically to work with Hey's servers and nothing else.

Even if they shoe-horned an IMAP/POP client into the app to try and satisfy Apple, I think the user experience would end up far worse than what they've just implemented this weekend; and likely would violate other provisions of the App store.


I'm glad they found a solution that was satisfactory for Apple, but this random email thing seems forced and useless.

If you end up signing up on HEY will the random address keep working?

Otherwise why use an address that will disappear no matter what. Obviously you can't use it to sign up on anything, or tell people to contact you at that address. It would only work for sending test emails between HEY and your other email addresses. I mean, who's going to do that? Is this really better for the end user?


Interesting outcome for both Apple and Hey. However, the threat still exists when Apple can potentially announce a similar service to hey.com somewhere in the future, which will be a kick in the teeth to everyone. Would that be considered as a win? I don't ever underestimate Apple's strategic plans to maintain control of the ecosystem and compete with your own apps.

Seriously. Apple 'really' is not your friend.


Since the whole issue boiled down to "providing some functionality to users who saw the app in the App Store and downloaded" and completely moved on from the initial IAP discussion, I believe a good compromise for all parties would be to allow developers to submit such applications but simply unlist them, making them only discoverable via search or deep links.


Just downloaded the app and there’s no sign of a free tier whatsoever. I can’t do anything with it, absolute shite if I didn’t know that it’s still in closed preview.


They just submitted version 1.0.3 this morning, they needed the weekend to implement it. It'll probably be released sometime today.


I think having a free trial is a good idea regardless of in app versus out of app purchases. That it had to be done so hastily is unfortunate, though.


Quick Wins have never helped anyone in the long run but they fool you into thinking you can go on with it forever.

When the entire debacle started I was suddenly an optimist on:

- Mobile vs Web debate forcing gate keepers on giving equally competent choices for users & makers alike.

- Apple relooking and rethinking their 70-30% strategy

- Small & Indie Developers openly talking about the problems being at the mercy of Apple and Google's stores.


"And Phil, we set aside an amazing @hey.com address for you. Free for life, our gift to you. Lemme know."

hmmm. Anyone guess what that could be?


chick-phil@hey.com?


So Android users have to continue to clamour for the invite? If they had done the same for Android it would have been reasonable.


So, in the end... is there a link or something, in the app, about upgrading to the paid option?


No, that's against the guidelines.


So the experience of someone who doesn't know anything about HEY, i.e. what Schiller cares about, is:

- download the app

- use the free service for 14 days

- see their emails disappear on day 14

Doesn't seem like a great xp. Wouldn't it be better to be told straight away "you need an account for this"?

Also, Schiller has now instigated a wonderful tool for trolling and harassment.


I'm sure Hey will .... email you wink a link to sign up for a paid account. If they link to the pricing page in the app, that's a no-no, but if they EMAIL it to you, and you just so happen to be using an email client that can display that link, then that's okay.


In Italy that's called fatta la legge, trovato l'inganno - as soon as the law is created, the loophole is found.

Apple should just do the decent thing.


Still not clear if this is a special deal for hey or for all developers as well.


There is nothing special about this deal. I can name of list of a dozen of apps that are “reader apps” - view only that force you to subscribe out of the store. Even the major apps from Adobe and MS offer some type of functionality without subscribing.


Small developers wouldn't even get Schiller's ears in the first place...


This is great news Apple and Hey managed to find a way to go foward, but I wonder would Hey get this far if it was not backed up by Jason and DHH


What are you talking about? They complied with the guidelines.


Having a bad day?

I am referring to communication with "Apple’s Senior Vice President of Worldwide Marketing" after which Hey did an implementation of a functionality which clearly is not a "basic functionality", but a 14 day demo. After that the app is approved.

Would some random developer really get such treatment from Apple?


Probably not an SVP, however I have had Apple engineers proactively call me to discuss ways to make non-compliant apps fit their guidelines, and that’s without me complaining at all - they initiated it following the rejection.


I don't have a horse in the race, but watched this closely. The whole situation put Apple in a bad light, and Basecamp got free publicity. I hesitate to say it was planned, as DHH likes to mention he's not THAT smart. Regardless of the drama, HEY the actual product, looks like it does a lot of things right.


I agree on the free publicity part. Don’t think I would’ve given this product this much of my attention if it weren’t for this whole debacle. The free publicity in this case is likely to turn out to be a net positive for Basecamp.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: