The Battle for Privacy Continues

Dave Mark writing for The Loop:

The way I read it, this would require device manufacturers (like Apple) to build in some mechanism to allow them to (as the result of a warrant) break encryption. This is no small thing. This would break Apple’s privacy foundation.

I think framing this around Apple kind of belittles the impact here: this is fundamentally breaking the idea of encrypted, private communication full stop.

Two years ago, the Republican-endorsed leadership at the FCC tore down net neutrality, and now the same party is coming after your right to have any private communication. I can understand the perspective that law enforcement would greatly benefit from this information in extreme cases, but it's not just a matter of officials getting this data, it's the fact that a back door is a fundamental security flaw in encryption and those flaws tend to get compromised.

“Android had it First.” “Well iOS had This First!” And Around and Around we Go

I was going to write a long article about each new thing in iOS 14 and whether each feature has been in Android already, but then I trashed the doc. I was getting bored writing it myself, so I can’t imagine how bored you would have been reading it.

Features like home screen widgets, cycling navigation in Maps, and picture-in-picture on your phone may seem like familiar features to Android users, but here’s the thing…

Here are some new features in Android 11 coming this fall:

  • Screen video recording
  • Uniform media controls in quick settings
  • New smart home controls
  • Airplane mode doesn’t turn off bluetooth
  • Pixel 4 face unlock can require eyes open
  • Better voice control
  • Allow location access just once
  • Auto-set dark mode based on a schedule
  • Scrolling screenshots (maybe)

There’s some other stuff there, but that’s a good chunk of the new features, and iOS users will probably already know where I’m going with this…all of this has been on iOS for years.

My point is that iOS and Android are mature operating systems and it is unreasonable to expect each platform to add new features that are totally unique. At this point, we can expect some new features, but a lot of the work is on filling holes (aka doing things the other guys have done for years) and refining the experience as a whole. Snarky tweets about “heh, heh, Android/iOS has had this for years 🤓” get likes and retweets, but they’re not particularly insightful commentary. If you just want to be snarky, that’s cool, enjoy! Let’s just not pretend that this commentary is anything more than fanboy bait.

I think the new widgets in iOS 14 look better than anything I’ve seen in Android widgets in 13 years and it’s stupid easy to make them look good on your home screen, but they’re also less capable and less flexible than what Android can do. The same goes for picture-in-picture, which Android has had for a little while, but iOS is adding a new ability to hide the video off screen and bring it back on demand. They caught up and then took the lead in this feature.

“Android had it first” and “iOS had it first” are mildly interesting data points now, that’s it.

Hey: Feature Requests and Improvements I’d Love to See

I’m also sending a version of this to their support team directly, but I'd love to hear if this lines up with what other people are thinking about the hot new controversial email service, Hey.

  1. The iPad app needs to get keyboard shortcuts to gain parity with the web app (ironically, the iPad app appears to use some web components, so sometimes you’ll see the shortcut letters appear on buttons, but you can’t use them).
  2. The iPhone and Android apps need gestures to move between the Imbox, Feed, and Paper Trail. At the very least, they may want to consider a navigation bar at the bottom. I know they want to make the Imbox the primary location you spend time, but it’s two taps to get anywhere else, which seems unnecessary.
  3. Also, moving a single email to another location (like a receipt to your Paper Trail) means hitting “More”, then “Move”, and then “Paper Trail” buttons.
  4. The Feed needs to do a better job of telling me when there's something new in it. I may not want to see this stuff in my inbox, but I would like to know when I should look at it at all.
  5. The Feed also needs to somehow differentiate messages I've seen before and those that are new. Right now I don't walkways know how much I've seen before so I'm scrolling by some messages a few times. I'm seeing these emails more than I would have if I saw them once and archived them, which is not the goal of this feed.
  6. I buy things from some stores regularly, which means I get receipts and marketing emails from them. I’d like to have their near-daily messages go the The Feed, but the receipts would be better in one of the other areas. I’d like it if Feed items that looked like receipts were automatically thrown in my Imbox instead so I could make sure I see them.
  7. Finally on The Feed, is like to have anything I've seen and is more than 24 hours old disappear from the feed by default. Let me expand to see more if I want, but this would help trim this page down.
  8. The Paper Trail is cool, but I would love to see them do more to make this more powerful than a label like you'd add in Gmail. I'd love to see this page to have a dollar amount added to it, either by automatically crawling the messages to find the total, or allowing the user to manually enter the amount. Turning this into more of a transaction history than a list of emails would be awesome.
  9. Also on the Paper Trail, while I may not want to see those right next to my inboxed emails, I would like to more obviously see when a new one comes in. Maybe this is an indicator on the Imbox page or something, but this should be easier to see without a dedicated visit to the Paper Trail page.

That’s it for now, although I’m sure there will be more things that come up as I keep using it. Frankly, I’m coming around on the service the more I use it. It definitely feels like it has a lot of room to grow, but that’s good: Basecamp seems committed to making this thing work, and I know their product people care about making great software, so I hope to see at least some of these features added in time.

Update: Sent via official channels 😁

The Costs and Benefits of Taking Payments Outside the App Store

I don’t talk about this too much on the site (separation of work and hobby), but I happen to work in the payments industry and the has proven to be both helpful and a cause of madness this past week.

It’s been helpful because I not only know a lot about payments, subscription management, and merchant behavior and desires, but I freaking design the tools merchants use to do these things. I work on tools that allow everyone from big box retailers to airlines to one-person shops collect payment data safely and easily. These tools are used billions of times per year to enable merchants to run their business.

Today I wanted to take that knowledge and consider one element of the current conversation about In-App Purchases in the App Store: fees. What is the cost, both in terms of cash and business requirements, to selling though Apple’s IAP or through your own payments.

Payment Fees

I can’t get into specific fees since those are going to vary a bit from merchant to merchant, and even transaction to transaction , but we can talk about generalities here. Let’s use Hey (Basecamp) as an example.

Basecamp is charging $99 per year for their service, Hey. Currently they have you sign up on their site and pay them directly. I’m not sure what payments provider they’re using, so I’ll talk generalities for this bit.

In general, merchants will pay a flat fee per transaction, as well as a percentage of each transaction to the payment platform. Again, not knowing Basecamp’s provider, it would not be unreasonable to estimate they pay 10¢ per transaction, plus 3%. That might be a little high or low, but it’s likely in the ballpark for them.

That means on every $99 sale they make, $3.07 would go to fees for that transaction. If they added the App Store’s IAP, then they would be paying $29.70 in fees per transaction. You can see why Basecamp would be unhappy to make that trade.

Other Costs

Of course, this savings has a cost of its own in that Basecamp needs to maintain these subscriptions and make sure billing runs correctly and they need to invest in a good customer onboarding. But even with that, they are still coming out way ahead.

It’s possible Hey is making a decent margin on each customer and they could eat those costs and still turn a profit, but that’s certainly not going to be the case for all companies. Those companies will either need to eat the costs and offer IAP as well, which is bad for the mechant, or they raise their cost to customer by 30% to make sure they still turn a profit, which is bad for the customer.


There are benefits to handling payments for yourself too. Refunds, something that are notoriously difficult on the App Store (aka the developer can’t give you one, Apple needs to do it) are simple if you control the payments flow. Let your support team issue them, give them to customers technically ineligible because you think it’s the right thing to do, offer your refunded customers get a coupon in case they ever decide to come back after you’ve refunded them. These are good for both the merchant and the customer.

Handling payments also gives you a closer relationship with your customers. You can manage them in your existing CRM and reporting. You can more easily track churn and understand your business better.

It’s also worth saying that most iPhone users are not all in on Apple. The average iPhone user uses a Windows PC. While this conversation on Twitter is happening mostly between people with Apple everything, the fact is that we’re a smaller slice of the pie. What if I signed up for Hey on Windows and then got the iPhone app? Or what if I use Android today, signed up for some services, and then switched to the iPhone? As a customer, I’d be incensed if I needed to close my accounts and recreate them in Apple’s system. I would reasonably expect to be able to just sign into that account on my new shiny iPhone. I can do this today, but the suggestion by some that IAP should be used for everything would make this impossible.

Alternatively, what if a customer wants to trade in their iPhone for a Galaxy phone? Now they need to cancel all their subscriptions in the App Store and recreate them on their new device. Why should I need to cancel my email account for a third party company in the App Store if I want to use that on a new platform? Correct me if I'm wrong here, but as far as I can tell, there is no way to manage my IAP subscriptions to third parties without an iOS device. That's a bad user experience, and while it makes you more likely to stick with Apple because no one wants to deal with that, it's not the right way to retain customers.

Finally, there is the possibility for a merchant to be even better than Apple at working with their customers. They may give more helpful subscription renewal notices. They may give incentives to lower customer fees in some cases. They may have a better onboarding on more platforms than Apple has created (although Apple’s is pretty solid). They can innovate in ways that Apple hasn’t even thought of yet!


This isn't an argument for or against Apple changing its policy on in-app purchases, nor does this address anything with monopolies or anti-trust regulations. This is just an attempt to give some more context to the conversation and help people understand why some merchants would prefer to use their own system for payments. I hope to have another article out soon that explains the modern methods of accepting credit card information and how it's both more secure and easier to implement than you might expect if you haven't been paying close attention in recent years.

Can My Headline Just be 🤦‍♂️

Matthew Panzarino talking to Phil Schiller

“You download the app and it doesn’t work, that’s not what we want on the store,” says Schiller. This, he says, is why Apple requires in-app purchases to offer the same purchasing functionality as they would have elsewhere.

I feel like this is recursive logic. The app does this becuse they had to bend over backwards to not tell the user how to sign up. They did that because of existing App Store rules that force them to not help the user here.

One way that Hey could have gone, Schiller says, is to offer a free or paid version of the app with basic email reading features on the App Store then separately offered an upgraded email service that worked with the Hey app on iOS on its own website.

I don't blame Schiller here, but this doesn't make sense for Hey at all; something that's made very clear after using the service for just a few minutes. Hey is more of a service unto itself built on the email SMTP standard. Looking at the app right now, I don't even know how they would let you use this as a front end to Gmail or any other IMAP email service. This sounds to me like asking Zendesk to have a free version that just acts as a front end to Gmail. That's really not what the tool does, even if it handles email at its core.

Donate to Good Causes, Get Good Stickers

Indie Sticker Pack

We've worked with hundreds of developers from across the indie developer community to share with you a pack of stickers full of icons you'll recognize — and perhaps some that are new to you. We hope in turn you'll enjoy sharing them with friends and family.


All proceeds will be split 50/50 between the World Health Organization's COVID-19 Solidarity Response Fund and the Equal Justice Initiative for combatting racial and economic injustice.

This is a really nice little project that is giving to good causes. I’ve got mine on order.

You Can’t Set Up a Bodega in Walmart

I've seen some defenses of Apple's now-modified-enforcement of App Store guidelines that go a little something like this:

If you think apps should be able to freeload on Apple's App Store distribution, but then not give Apple a cut of their revenue, then you must also think that it would be perfectly fair for a merchant to set up a bodega in their local Walmart and sell their wares to Walmart customers without giving Walmart a cut of the revenue.

This argument may work as a quick mental exercise, and it may win you a few retweets on Twitter for this single argument, but I don't think this is a good comparison.

First, big box retailers and an app stores are different things. There are many differences between Walmart and the App Store, so I don't think it's wise to suggest app developers need to follow the same rules as merchants selling at Walmart.

Second, if we follow that merchants taking payments for products downloaded from the App Store is like setting up a bodega in Walmart and not giving Walmart a cut, then is the suggestion that services that let you subscribe/pay in the App Store or outside of it (Netflix, Spotify, Disney+, Hulu, HBO, and basically every single SASS out there) should be forced to not let people use the App Store apps unless they are also paying through the App Store? After all, the monthly fee I pay to Netflix through Netflix directly means Apple isn't getting a penny.

Third, if I'm a merchant selling socks and I don't want to deal with Walmart's rules, I can choose to sell at Target, shoe stores, or just go straight to the consumer. Sure, being at Walmart has benefits, but if I choose not to go that route, I still have options. If you can't be on the App Store, you may as well not exist on iOS, which is not the same thing.

As I'll reitterate every time I talk about this, I don't think that Apple is legally required to allow everything on their store. I think they have the right to set rules and enforce them, and even though they're huge, I don't think they should be considered a monopoly. I have this position because I think it's better for consumers, better for developers, and frankly, consistent with how many other apps on the App Store already work.

Hey’s App Store Drama

Apple rejects App Store updates, mandating in-app subscription - The Verge launched yesterday. The new email service offers an alternative to Gmail for $99 per year. To continue using the app on iOS, you have to sign up through the company’s website. Apple initially approved the app on Friday, according to Heinemeier Hansson, but upon review of a bug fix update on Monday, Hey was rejected for not including an option to sign up within the app itself. A second version was rejected on Tuesday.


While Apple told The Verge that apps must offer an in-app subscription option, the company does make exceptions for a variety of apps. Those exceptions include music, video, and magazine apps, among a few others, but email apps are not one of the approved exceptions. Despite this, some subscription email apps, such as Newton, are available in the App Store and don’t offer their service via in-app purchase.

This is a perfect example of why side-loading should be an option on iOS. Sure, make them notarize the app like they would do on the Mac and block them from using Apple Pay for signing up in the side-loaded app or something, but this restriction is kind of nuts.

The App Store is wonderful in many ways, and it helps make sure that people’s devices are safer than they would be if anything at all was allowed, but I think there should be a workaround for apps that can’t comply with every App Store guideline.

Also, the fact that some apps can do what Hey is doing and some can not, even apps that offer the same type of service, is what makes this standard impossible to comply with.

Finally, because I know it’s coming, I’m not implying Apple should be legally compelled to allow side-loading. I’m simply saying I think they should loosen their grip a little on what business models should be allowed to function on their platform. Maybe they do that by letting us install appr safely outside the App Store, or it's by allowing merchants to do the customer acquisition themselves, process payments themselves, and then make their app follow all non-business model rules to be safely distributed on the App Store.

Newsletter Update

Newsletter Update

I wanted to share two quick updates about my newsletter, Birch Bark.

First, I've disabled all tracking in the emails that get sent out. I had this on at first since I wanted to be able to see what items people found the most interesting and got the most engagement. After doing this for 17 issues, I've learned that this is not particularly useful to me and has had zero impact on what I choose to share in the newsletter. So as of this Friday's newsletter, it's all gone. My life won't change at all since I wasn't using the data in the first place, and yours will either stay the same or get better since sometimes ad blockers would block the tracking links.

Second, and this is an experiment, I've added a sign up form inline on this site. I know, I know, I'm not a huge fan either, but I want to try it for a few days at least and see if it drives any additional subscribers. The newsletter has been growing slowly, but the churn is really low and I think the people who are subscribed like it (this is mostly based on anecdotal feedback, although a glance at the analytics I just turned off back this up) and I think more people would too, they just don't know it's a thing. You should be able to dismiss it once and never see it again, but let me know if it's constantly pestering you and I'll either tweak it or remove it.

If you've made it this far, you have probably already seen the form, so I hope you filled it out, but you can also head on over here to signed up today.

Making Operator

Making Operator

This is a really great video from Hoefler & Co. on the making of Operator, their newest font, available in monospaced and what they call "monspace-inspired" versions. I use Hoefler fonts on this site (Quarto, Gotham, and Decimal) and I love them.

So with designers, developers, and most of all readers in mind, we decided to design it both ways. Operator Mono is our new family of fixed-width typefaces, with a broader range of weights than a typical typewriter face, and an italic that positively shines in code. Its more editorial companion is the natural-width Operator family, which offers the voice of typewriting but none of the compromises.