WWDC 2018

WWDC is tomorrow! For the first time in
a while, the rumor mill is pretty quiet. However, it has led to even more
wishful thinking and speculation.

The general theme and expectation is Apple will focus on reliability. Bug fixes
will be prioritized which would be great. Another possible theme may be
“Digital Health”, which can mean information about how you use your phone to
better notification and Do Not Disturb management. After spending some time
with health and meditation apps, I think it would be helpful to have features
that make more efficient usage of your device and make you acknowledge that
it is your responsibility to monitor and manage your time.

watchOS needs more independence from iOS whether that be apps that can
operate more independently (when there’s Wi-Fi, use it instead of the
Bluetooth connection) to more capabilities (e.g. able to streaming podcasts)
for third party apps. There needs to be some justification for investing
energy into watchOS apps considering most developers are abandoning the
platform.

It would be wonderful if tvOS gained user profiles and some sort of
acknowledgement that it is not meant for just a single user’s preferences.
For instance, you can only log into one Game Center profile (even though
Game Center might as well not exist itself). More intriguingly, I think it
would be useful to detect the presence of multiple people (say some people
had their iPhones or Apple Watches near the Apple TV), and then tvOS would
give recommendations tailored to those people. It seems far-fetched at this
point given Apple’s direction, but it would be interesting conceptually.

macOS stability and feature parity is a sore spot. There are many capabilities
that are just not present (e.g. HomeKit, iMessage apps, TV app). If feature
parity is not on the table, then slowly breaking apart iTunes must be on
Apple’s priority list hopefully.

Perhaps the most important area of focus is Apple’s services. Siri is the poster
child of an Apple service needing improvement. The speech recognition and
feedback seem to be fine but actually interpreting the commands seems to be
difficult with its open ended nature. Compared to Google Assistant and Amazon
Echo, Siri might work slightly subpar but the constant embarrassing screenshots
of incidents where Siri makes wild interpretations of questions is alarming.

Personally, I would prefer if Apple makes a few acknowledgements in their
process more than anything. A public announcement that they will deliver
iOS 12 over the course of a few months instead of a 12.0 release with everything
in it. Whether intentional or not, iOS 11 just got the last of its announced
features a week before WWDC 2018 (Messages in the Cloud and AirPlay 2). It would
be even better if all of their services like Siri were continuously publicly
improved every week/month/quarter so that customers feel things are getting
better constantly at a sustainable pace.

The other major change I would like to see happen is a “service” mentality for
every one of their introduced features. Instead of features being tied to
an OS, the APIs should be made available on as many platforms as possible with
the ability for apps to integrate with the service. iMessage, Photos, HomeKit,
Siri, Apple Music and in general iCloud should become independent platforms
themselves without needing to build apps to use OS APIs to integrate with them.
Building ecosystems for these systems without requiring an iOS device would be a
huge change in strategy but if Apple is focusing on service revenue, building
great independent services would drive them forward. Instead of catching up
to WeChat, Dropbox, Amazon Echo, Spotify, Apple could independently move forward
without being tied to iOS.

Terraform and Let's Encrypt on Google Cloud Platform

Let’s Encrypt is a service that offers free TLS
(aka SSL) certificates. The certificates are recognized by all modern browsers.
The only “disadvantage” of using Let’s Encrypt is that the certificates have to
be renewed every few months but the process can be automated.

Depending on your environment, there are various ways to get initially setup with
their certificates. You can get specific domain (e.g.
www.example.com or staging.example.com) or wildcard (*.example.com)
certificates. Visit the Let’s Encrypt website to understand all of your options.

The above config sets up the Google Cloud provider with a domain name, project,
region, and zone via variables to be set later. It creates a DNS managed zone on
Google Cloud. You may want to rename some of the resource names like
example_com to your specific setup.

Note that for the dns_name, the value will need a trailing . (so the final
value will be like example.com.).

The above config also creates a service account with a custom role which
allows the service account to modify DNS records. Once the account is
created, it will store the credentials in a local letsencrypt-credentials.json.base64
file.

Variable Config

Create a terraform.tfvars file to fill in the variables with your specific
config.

Plan and Apply

You may want to inspect the output of terraform plan to understand
what resources are being created.

Run the following when ready to create the resources:

terraform apply terraform.plan

Setup DNS Nameserver

You will need to have your domain registar use the Google Cloud DNS nameservers.
After applying the Terraform config, you can go to the
Google Cloud Console
under Networks services > Cloud DNS. Find your domain name and get the DNS
nameservers. Go to your domain registar and use all of the DNS nameservers
(under the NS record like ns-cloud-b1.googledomains.com.).

You may have to wait a few minutes to a day for the nameserver change to
propagate.

After running the command and answering a few questions, the certbot will use
the service account to create a DNS entry to verify domain ownership. Then it
will issue a wildcard certificate for your domain. The certificate files and
credentials will be stored in your certs/config directory.

You can then re-run the certbot when it is time to renew the certificates.
Be sure to keep (and backup) a copy of the certs/* directories to
re-use them later.