June 23, 2020

Coding: Apple, Hey and a Small Project

This is a quick story about how David Heinemeier Hansson's and Jason Fried's push back against Apple's ambiguous and arbitrary enforcement of in-app purchase rules turned into me spending a couple hours seeing how small I could get a website on S3.

This week the ridiculously awesome Hey email service launched, followed immediately by a tsunami of controversy as Apple rejected the macOS app and blocked the first iOS app update due to violations of the in-app purchase (IAP) rules. This story has been covered many times this week by far more articulate individuals, several of which are collected here - https://hey.com/apple/

One specific point of ambiguity is Apple's inconsistent usage of the "reader" and "business" app categories, which are used to grant developers exemption from IAP requirements. Several large iOS apps are excused from offering IAPs due to these categorizations. For example, Kindle is a classified as a reader app and SalesForce, a business app. Those both make sense. But right next to them are things like Netflix and the Nintendo Switch, which don't seem to fit either use case, but are void of IAPs.

I tried Googling "reader app definition" and found absolutely nothing useful, no explanation, no clarification. So, following the incredibly witty https://youdownloadtheappanditdoesntwork.com, I decided to spin up the (editor's note: far less witty) www.readerappdefinition.com.

The original intend was to create a single page html site to host a sarcastic description for reader apps. I had wanted to play with the static website hosting feature in Amazon S3 ever since I started spinning up buckets for a Rails project (editor's note: more to come soon) and figured this would be the perfect excuse to give it a try. I purchased my domain and followed this guide. A few minutes later I was serving a simple website from an S3 bucket.

Screen shot from www.readerappdefinition.com

For fun, I ran my URL through Pingdom's Website Speed Test. And this is where the real project began. Pingdom recommended I "compress components with gzip". I only had one component, my lonely little html file. This should be easy enough...

I ran my index.html file through gzip, removed the '.gz' extension and uploaded it to my S3 bucket with the following headers, which I got from this post on deploying Jekyll to S3.
  • Content-Type: text/html
  • Cache-Control: max-age=7200, must-revalidate
  • Content-Encoding: gzip

S3 file headers for gzipped html

Ran the website through Pingdom again and got a perfect score...but I was still serving around 10K of content. We can go smaller...

I spend a few minutes reworking the html to remove any unnecessary bulk - css was cleaned up, div id's were reduced to single characters. When I was done, I ran it through a minifier, zipped it back up and dropped it in the bucket. 1.4K!

Back to Pingdom and this time the page size was down to 6K. Looking at my results, it appears there is a 3K-ish overhead to not having a favicon. We can definitely go smaller...

I played around for a bit compressing png and ico files, but couldn't get a 32x32 image much below 2K. I switched over to Inkscape and created a simple svg then cracked open the xml and stripped out every tag that wasn't needed. Under 1K!

Website file sizes in S3

One more trip through Pingdom and the site was now serving under 4K total!

Pingdom results, under 4K served!

And this is where I stopped for the evening. The html isn't perfect and I'm sure there are a few more bytes to be shaved. Likewise, there are probably a couple more tags that can be removed from the svg file if I knew what I was doing. All in all I'm pretty happy with the results for a couple hours of fiddling and a $7 domain.