Category Archives: General

Skipping the iPhone XS

I’ve had an unopened iPhone XS on my desk since last Monday. I ordered it through the iPhone Upgrade Program, and I’m trying to decide if I’m going to keep it.

After owning the original iPhone for three years, and an iPhone 4 and iPhone5 for two years each, I switched to buying a new phone every year. I calculated that the depreciation on the iPhones 6, 6S and 7 was about $300 in the first year, and $200 in the second year1, so it was costing me an extra $100 (plus tax) in the odd years to buy a new phone instead of holding on. That worked out to less than an extra $50/year (plus tax) to own the newest phone every year, compared to holding on to a phone for two years.

$50 each year seemed like a great deal for the latest technology, but that value proposition has changed. The costs I’ll incur if I upgrade this year include:

  • Sales Tax: $84.25
  • AT&T Upgrade Fee (plus tax): $31.88
  • The last payment on my iPhone X (since it’s only been out 11 months): $49.91
  • The residual value of a two-year old iPhone X, if I were to keep it another year and own it outright. This is tough to estimate, but resellers are offering $225 - $350 for a two-year iPhone 7+ right now; let’s go with the low-end to make the medicine easier to swallow: $225.00

The total cost of $391.04 is the amount I’ll save if I wait and buy next year’s iPhone, instead of buying the iPhone XS and upgrading again next year. Spreading that premium out over two years is roughly $200/year (including tax); that’s a massive increase over the prior situation.

Part of that increase is that the iPhone Upgrade Program includes AppleCare+, which I’ve never purchased before. Part is that the iPhone X and XS are more fundamentally more expensive than previous generations. Part is the cost associated with just handing the phone back to Apple, instead of dealing with the hassle of a private sale. But I’m not sure if the cost is justified, for me, this year.

The improvements aren’t as numerous, either:

Maybe the strongest indication that I should pass on the iPhone XS is that I haven’t caved in to the temptation to open it yet.

I think I’ll be skipping this one.


  1. Assuming a private resale. 

  2. While this has been true in the past, it wasn’t true with the iPhone X. And while I’d like the flexibility, I’m not sure I’d make use of it during the next year. 

Radiohead

I caught Radiohead at TD Garden last night; they played a really great set:

  1. Daydreaming
  2. Desert Island Disk
  3. Ful Stop
  4. 2 + 2 = 5
  5. Myxomatosis
  6. All I Need
  7. Videotape
  8. No Surprises
  9. Everything in Its Right Place
  10. Bloom
  11. Separator
  12. Reckoner
  13. The National Anthem
  14. How to Disappear Completely
  15. You and Whose Army?
  16. There There
  17. Street Spirit (Fade Out)
  18. Optimistic
  19. Nude
  20. The Numbers
  21. Lotus Flower
  22. Fake Plastic Trees
  23. Idioteque
  24. Exit Music (for a Film)
  25. Karma Police

iOS FLAC Playback

With the release of the iPhone 8 and iPhone X, Apple added support for FLAC playback. Kirk McElhearn wrote:

But I looked at the iPhone 7 tech specs, and it also says that it supports FLAC, so maybe Apple just means that the files can be read by third-party apps. If FLAC were natively supported on last year’s phone, a lot of people would have heard about it. I think that this has something to do with iOS 11. Because I looked on an older version of the iPhone 7 tech specs page (via the Wayback Machine), and FLAC support is not mentioned.

I maintain an app that plays back local files, and as of the initial release of iOS 11, I couldn’t find an API for facilitating playback of FLAC files. I asked on Stack Overflow; the question received a fair amount of traffic, but no clues.

The other day, I realized that my app is able to playback FLAC files with no changes to my code. It appears that, as of iOS 11.2, the isPlayable property of AVAsset returns true when backed by a FLAC file.

It’s nice to see that Apple has made this functionality available to third-party apps with no extra complexity.

homebridge-camera-rpi

With the recently released homebridge-nest-cam plugin, my old Dropcam has new life in HomeKit. This, combined with Steve Troughton-Smith’s tweets about the Pi Zero W, has sparked a desire to setup additional HomeKit cameras.

I ordered a Pi Zero W Camera Pack, and set about following Wojtek Pietrusiewicz’s instructions for configuring it with homebridge-camera-rpi.

It was easy to get the Pi connected to the network, but I ran into trouble when I needed to install ffmpeg. I couldn’t get it working, and based on some comments, I think it may be fairly difficult to install. I’m speculating that something changed between the Rasbian Stretch image of November 2017 and the image of March 2018.

Instead, I used the pre-built image of homebridge-camera-rpi. After using Etcher to flash the image onto my microSD card, the only modifications I made were to the /wpa_supplicant/wpa_supplicant-wlan0.conf file to add my network SSID and passkey, and to tweak the settings of the plugin in /homebridge-camera-rpi.conf.json.

With that, I was able to see the Pi on the network (via Lanscan), and add it in the Home app.

Home App Screenshot

Transporter Desktop on High Sierra

If anyone out there is still using the File Transporter system, there’s a compatibility issue with High Sierra. The last version available via the official update channel is 4.2.12, but there’s a patch for version 4.2.18 available from their support site. This restores access to the Transporter Library.

This issue reminded me that support for this system ended in September, 2017, so I’m on borrowed time. I just upgraded to the 2TB storage plan on iCloud, so I may test migrating the data I have on the File Transporter into iCloud… but that seems risky.

Python 2.7 via Homebrew

I missed the memo, but back in January Homebrew announced that as of version 1.5, python would be upgraded to use Python 3.x. This change went live on March 1, and I noticed it over the weekend while tinkering with Homebridge.

While I was rebuilding Homebridge with the latest version of Node.js, I kept banging into node-gyp errors having to do with using Python 3.x. I’m not alone, though there is already a pull request to fix this issue.

For the time being, I’ve made two changes to please node-gyp:

  1. Forced a link of the new python@2 keg1:

    brew link python@2 -f
    
  2. Added the following to my ~/.bash_profile, so that python will point at python2:

    export PATH="/usr/local/opt/python@2/libexec/bin:$PATH"
    

I think I’ll revert the second change once the node-gyp issue is resolved, to begin forcing myself to use Python 3.x.


EditorConfig

Yesterday, I lamented the limitations of BBEdit’s Dropbox sync:

I wish there was a way to sync language-specific settings for BBEdit via Dropbox.

Specifically, I wanted to sync my soft-wrap settings for Markdown files. My main need for this is in editing the text files that drive this blog1. Yes, this is a trivial problem; it’s one checkbox in BBEdit’s Preferences Pane. It would be easy to recreate on both of my computers. It would be easier still if the preference would sync.

@daiwei replied on Micro.blog with an interesting idea:

If you know where the settings you want to synchronise are stored, simply copy that file(s) to where you want them on Dropbox, and symlink it/them?

I haven’t tried this, and I’m afraid of what might happen if I were to have BBEdit open on both computers at the same time. Maybe I’d just end up with conflicted copy files from Dropbox, but BBEdit’s release notes specifically call this out as unsupported:

The system does not support relocation of the core preferences data file (~/Library/Preferences/com.barebones.bbedit.plist), so you won’t be able to synchronize preference settings.

The BBEdit support team replied to me on Twitter, and offered a solution I was completely unfamiliar with:

Apparently, BBEdit natively supports EditorConfig files. EditorConfig files are used to enforce consistent configurations across editors for a given project, and they’re fairly widely supported. While soft-wrap settings aren’t part of the core properties, BBEdit has defined BBEdit-specific keys, including x-soft-wrap-text, x-soft-wrap-mode, and x-soft-wrap-limit.

Based on this, I created an .editorconfig file in the root directory of the files for this blog, that only contains one key:

# EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

# Soft-wrap every markdown file (in BBEdit only)
[*.md]
x-soft-wrap-text: 1

Now, if I ever forget to enable soft-wrap as a language-specific setting in BBEdit on a new machine, this file will override the global setting and enable soft-wrapping. I’ll still have to deal with this for files in other directories, but this will cover 90% of my use cases.


  1. I’m still publishing this site using Dr. Drang’s WP-MD tools.