Apple Design

Posted on 2023-09-23 08:10 +0100 in Tech • Tagged with Apple, iOS, iPhone, design • 2 min read

As someone who started out in the Android ecosystem when it came to smart phones -- starting out with a HTC Magic and going through a few different phones before settling on Pixels (until I finally jumped ship to iOS in 2020) -- I have to admit that there's always been something nice about the design of iPhones. iOS, less so... My first exposure to iOS was back in 2015 when I got an iPod, and I wasn't terribly impressed. It looked okay, but it felt so far behind Android in terms of functionality.

Much has changed and improved since then. These days, 3 years into being totally consumed by the Apple ecosystem (one day I should write a post about how comprehensively I've moved over), I'm won over and I like how iOS works now.

Except this...

Bad design

That thing where, when you're in one app, it will show the most useless link "back" to another app, and in doing so bump the time up and out of the way a little. Like, seriously, compare it to when the app link thing isn't there:

Good design

Once you see it, you can't unsee it.

Toggle of the two images

After all this time you'd think they would have found a less janky way of doing this; perhaps even simply removed it (I can't remember the last time I needed or wanted the ability to go "back" an app like this, especially not with the bottom-of-screen swipe gesture being a thing). If nothing else you'd think that, by now, they'd have found a way of doing it that doesn't look so terrible.

The "eh, let's just shove it here" approach that seems to be on display here almost reminds me of the "time wiggle" that used to mildly annoy me back on my iMac.


The HomePod fixed itself

Posted on 2023-08-12 07:46 +0100 in Tech • Tagged with Apple • 2 min read

A couple of weeks back I mentioned home my main HomePod had got stuck installing 16.6 of the software that runs it. This situation persisted for days after writing that post and I kept promising myself that I was going to see if I could unstick it by removing it from the Home, doing a factory reset and adding it back again.

Of course, during the week that followed, I never got round to that. You can imagine what it's like: no time in the morning, and by the time I get home in the evening I want to watch TV and use the HomePod as the speaker for the Apple TV, I don't want to be doing tech support shit.

The following weekend... yeah, I kinda forgot.

So, here I am, a couple of Saturdays on, it's early morning, I've had breakfast and I'm having coffee and I think it's the perfect time to do this. I hope the Home app my on iPad and... it's sorted!

HomePod all good again

So, yeah, it looks like it somehow managed to unstick itself in the end. A quick test of some of the issues I was seeing suggested there was still an issue, for example asking for the temperature in the bedroom would still result in a "working on it" reply followed by it telling me it wasn't responding. A quick reset seems to have fixed that.

I guess it's good to know: if it happens again, it'll keep on working as the speaker for my Apple TV, and it'll eventually sort itself out even if I don't muck about with a hard reset.


I turned it off and on again

Posted on 2023-08-10 18:17 +0100 in Tech • Tagged with Obsidian, Apple, iCloud, iPhone, Mac • 1 min read

Following on from the previous entry, where I outlined a weird problem I'd started having with syncing Obsidian via iCloud, I finally decided to sit down and try and work out the exact flow of the problem. Today, for example, I'd created an entry in two different vaults on my phone while on the bus into work, and when I got to my desk the vault I use on my work machine had updated.

However, when I got home this evening, the vault for my personal stuff hadn't updated on my home Mac Mini. I tried a few edits, in both vaults, on the iPhone, and nothing came through to the Mac.

So... before I started really diving into things I decided to "turn it off and on again" -- the iPhone that is -- and when it came back I ran up Obsidian, which told me it wasn't allowed to access my iCloud drive!

I took a moment to go into the settings to try and figure it out, didn't find what I wanted right away, then got to thinking that perhaps some of the phone's services were still spinning up, so I ran Obsidian up again (after killing it).

Sure enough, this time, it saw my vaults. With both vaults open on my Mac I made edits to open entries and the edits started to flow.

So, yup, looks like it was a simple case of "turn it off and on again".

Apple: #ItJustWorks.


Strange Obsidian sync issue

Posted on 2023-08-08 20:55 +0100 in Tech • Tagged with Obsidian, Apple, iCloud, iPhone, Mac • 2 min read

Since October last year I've been getting into using Obsidian. Not that heavily, not to the extent some people do, but just as a way to keep a daily journal of work-related things. Each day at Textual HQ we finish off with a chat about how our day has gone, stuff we're wondering about, etc, etc... So I don't lose tack of what I've been up to I keep notes and Obsidian is how I do that.

One of the things I really like about it is how I can have iPhone, iPad and macOS versions on the go and have it all sync via iCloud. It generally works well.

But in the last couple of days I've noted the oddest problem, and I've yet to pin down the exact flow. But it seems to be this:

  • If I create or edit a note on my iPhone, it doesn't turn up on my Mac.
  • If I create or edit a note on my Mac, it turns up on my iPhone.

I think I might have seen variations on that theme but I've not made careful note -- normally I'm made aware of it when I'm trying to get something done.

What's super weird is this: on the iPhone, if I create a note, and then go into the Files app and look at the iCloud folders for Obsidian, the file isn't there! It's there in Obsidian itself, I can move it about, edit it, etc, etc... but it's not in the "vault" as seen from the Files app.

It's the last part that has be really puzzled.

If I get to the bottom of this I'll try and remember to write up what I find. I suspect I'm going to need some proper clear time, without other distractions, and experiment with all the edit and sync options and see what works and what fails.


HomePod Stuck Installing Update

Posted on 2023-07-29 07:56 +0100 in Tech • Tagged with Apple • 2 min read

I have three HomePods. I have a Mini in the kitchen and one in the bedroom. I then have one of the newer-gen "big" HomePods in the living room, which amongst other things is the speaker for my Apple TV device (yeah, I'm kinda Apple all over the place these days).

This week there was an update to the software, updating to 16.6. The two Minis updated just fine. The big one, however, days later...

HomePod stuck installing the update

It's been like this all the time since the update turned up. I've tried a reboot from the Home app. I've tried pulling the plug and plugging it in again. Nope. It just keeps sitting there like this.

Meanwhile... it's working (more or less) fine. It's still playing music. It's still being the speaker for the Apple TV. It still answers most questions and performs most commands (most of the commands I give it are to add stuff to my Reminders).

On occasion if I ask it questions about other devices in the apartment ("hey siri, what's the temperature in the bedroom?") it'll do the "working on it" thing and then give up saying the thing wasn't responding. That seems to be about the worst of it.

Having checked this online it looks like, annoyingly, the one option I have left is to do a full reset, removing it from my Home, doing a factory reset, and then setting it up again. I'm sure it's something that'll take 10 minutes or so; but it's an annoyance.

Apple: #ItJustWorks.


Cmd-Tab switcher on all screens

Posted on 2023-07-14 07:56 +0100 in TIL • Tagged with Apple, Mac, macOS, Work • 2 min read

This week, on Monday gone in fact, we moved office. We've now got a bigger space and, as part of that, bigger desks. Somewhat (but not entirely) coincidentally the work desk will also convert into a standing desk1. Also also... I inherited a second screen for the desk too. Ever since the days of CRTs and video cards that supported it, I've been a fan of having at least a couple of screens in front of me, and now at my work desk I've got 3 (two external displays and the display of the MacBook Pro itself).

This caused a slight problem though: horizontally there's quite the spread of things to look at. This is fine, mostly I'm looking at the screen that's in front of me; the MacBook is to the left and the "second" screen is to the right, both with "other" stuff on them. In front of me is Emacs and my browser, which I flip between lots.

The problem is this: the MacBook needs to go to the left (because of physical layout), which means that despite me setting the screen in front of me as the "main" screen, the Cmd-Tab display (you know the thing: when you hit Cmd-Tab you see the icons of all your active applications) appears on the left-most display, which is the MacBook.

Not great. If I'm looking at the right-most display, and want to switch using the keyboard, I've got to look over to the left, as a worst case. That makes for a lot of unnecessary head-swivelling.

One quick Google later and Today I Learnt that the following pretty much solves the problem:

$ defaults write com.apple.Dock appswitcher-all-displays -bool true
$ killall Dock

As the name of the setting would suggest: once done, the switcher appears on all displays.

That's perfect.


  1. Although the work one is manual hand-cranked, not electronic button-push goodness like my new one at home


Catching up

Posted on 2023-07-02 08:00 +0100 in Meta • Tagged with Mac, Apple • 2 min read

So... erm... yeah... I did it again. I looked away for a moment and somehow almost 7 months passed without a post! It's so easily done too isn't it? While, when I revived this blog last year, I didn't make a point of intending to write lots and often, I had hope that I'd manage something at least once a week; perhaps at least once a month.

Ahh well.

There's been two main reasons why it's been quiet around here. The first is that my (now not so) new job keeps me busy (in a good way). It involves a reasonable amount of trekking into town and back (which I don't mind on the whole), and once I'm home in the evening I'm generally (but not always) done with the keyboard and desk.

The second reason, which is probably the dafter one, is that a bit earlier this year I finally upgraded my desktop setup from the 2019 Intel MacBook Pro I was using to a recently-released M2Pro Mac Mini (and what an upgrade!). How this plays into blogging being even more quiet is... I needed to set up jekyll again, and I'd forgotten how I got it running in the first place, so I kept putting off getting it going, and...

Well, this morning, I sat down with coffee, grepped the history on my previous machine, and got it running in like 5 minutes (of course).

So, here I am, back adding another blog post. I'm writing this as much to test that the setup works as anything else.

But also, this time, I'm going to try and make a promise to myself: I'm going to try and write more. I can and should write about anything. I can and should write short things as well as long things. I can and should remember that it's not about writing things that are going to be super important or anything like that, it's about just getting stuff down and creating and recording.

Note of course I said "try" and make a promise.

We'll see. ;-)


Swift TIL 12

Posted on 2020-07-18 10:16 +0100 in TIL • Tagged with Swift, Apple • 3 min read

First a small aside: To be honest, the T part of TIL is getting to be less and less true with this series of posts, but the posts themselves serve a useful purpose for me. As I've been reading the book I'm working through, I've also been making notes on my iPad in the Apple Notes application. I'm not really convinced that that's the best final location for such notes, so early on I made an extra step in keeping track of what I'm doing and trying to reinforce what I'm learning: transfer the notes into Org-Mode documents in my notebook repository.

This repository contains lots of Org-Mode files, broken down into subject directories, that hang on to longer-form information I want to keep track of regarding software development and general operating system use. I'm sure you know the sort of thing, the things where you know you know them but you can't always retain all the detail -- so having the detail where you know you'll find it is useful.

So I've made that part of the process: read book, find thing worth noting, note in Apple Notes, a wee while later re-read and test out by writing sample code and transfer to the Org-Mode notebook. During that latter step I sometimes also write up something that I really liked or found interesting here to further reinforce the learning process.

The "TIL" I wanted to note quickly today is how happy I was to see that Swift has something that's a reasonably recent addition to Emacs Lisp: conditional binding. Skipping off into Emacs Lisp for a moment, it would be very common for me to find myself writing something like this (this actually happens in all languages really):

(let ((foo (get-something-from-elsewhere)))
  (when foo
    (do-something-with foo)))

Quite simply: I'd get a value from elsewhere, that value could possibly be nil to mark that there was a failure to get a value, but that failure wasn't in any way fatal or even a problem worthy of note: I just needed to skip along. But that binding followed by the test was always a little jarring. And then, back in 25.1, if-let and when-let got added (of course, this being Lisp, it would have been very simple to add them anyway), and it was easier to write the code so it looked just a little nicer:

(when-let ((foo (get-something-from-elsewhere)))
  (do-something-with foo))

It's a small difference, but I find it a pleasing one.

So of course I was pleased to find that Swift has something similar with if and Optional values, where you can write something like:

if let foo = getSomethingFromElsewhere() {
    // Do something with foo but only if it's not nil
}

Which means you can do things like this (not that I'd really do things like this, but it was a handy test on the command line):

func oddRand() -> Int? {

    let n = Int.random( in: 0...99 )

    if n % 2 == 0 {
        return nil
    }

    return n
}

for _ in 0...10 {
    if let n = oddRand() {
        print( n )
    } else {
        print( "Nope" )
    }
}

As usual... of course that's horrible code, it was just thrown together to test/experience the language feature on the command line.

I like it though. I figure all the best languages have conditional binding. ;-)


Swift TIL 11

Posted on 2020-07-11 21:34 +0100 in TIL • Tagged with Swift, Apple • 2 min read

This is one of those things, especially this little play to help appreciate the feature, that I'm filing under "kinda cool, but I am never doing this in production".

So Swift has operator overriding, and then some. Moreover, operators are, in effect, functions, just with some extra syntax support. None of this is new to me, I've worked in and with other languages that have this ability, expect... I don't ever recall working in a language that, at the time I did, supported creating brand new operators (okay, fine, Lisp is a bit of an outlier here and there's all sorts of fun conversations to be had there -- but still, let's stick with more "conventional" syntax here). Support always seemed to be about extending the ability of an existing operator.

Swift though... yeah, you get to pick from a huge character space when it comes to creating operators.

Which got me thinking... How cool would it be to have a prefix operator that turns a floating point number into a currency-friendly number (you know, the sort of number type that can be used for currency-friendly calculations).

Swift has the decimal type which, at first glance anyway, looks to be a sensible candidate; even if it isn't (and, really, how to actually sensibly handle currency is a whole series of blog posts in their own right, that I have no wish to write myself because such things are a previous working life for me, and other people have doubtless done a very comprehensive job elsewhere over the years) it will serve as a good stand-in for the little bit of horror I'm going to write next.

So... Let's say we want to use £ as a prefix operator to say "see this number? make it a decimal", we could do something as simple as this:

import Foundation

prefix operator £
prefix func £( n : Decimal ) -> Decimal { n }

print( £1.20 + £0.75 + £0.01 )

Horrifically and delightfully, it works:

$ swift run
[3/3] Linking opover
1.96

I know, I know, I feel bad for even trying. But it's also kinda cool that the language has this.

It gets better though...

While reading up on what characters can and can't be used as operators, one thing that stood out was the fact that, more or less, any character that isn't a valid identifier can be used as an operator. So... hang on, we can use "emoji" as identifiers?

Like this?

import Foundation

prefix operator £
prefix func £( n : Decimal ) -> Decimal { n }

let 💵 = £1.20 + £0.75 + £0.01

print( 💵 )

Why yes. Yes we can. 😈


Swift TIL 10

Posted on 2020-07-05 15:27 +0100 in TIL • Tagged with Swift, Apple • 2 min read

My leisurely journey into getting to know Swift by reading and then making notes to myself in my blog continues, and this weekend I encountered defer. As I was reading about Swift I did keep wondering when something like try (it has try), catch (it has catch) and finally (it doesn't have finally, but...) might crop up. This weekend I hit the part of the book that covered this sort of thing.

Given Swift's apparent general reliance on not throwing errors but instead using Optional and nil to signify issues, it sort of came as no surprise that its approach to implementing something like try...finally is actually divorced from try. I'm not sure how I feel about it yet, but defer makes sense.

Here's an utterly useless bit of code that demonstrates how it works:

func add( _ n1 : Int, _ n2 : Int ) -> Int {

    defer {
        print( "Huh! We did some adding!" )
    }

    print( "About to do the add and then return" )
    return n1 + n2
}

print( add( 2, 2 ) )

When run, the output is this:

$ swift run
[3/3] Linking try-defer
About to do the add and then return
Huh! We did some adding!
4

A defer (and there can be multiple) is tied to the block that it's declared in, and is executed when the block exits. This is, of course, going to be really handy for things like resource-management where you don't want to be leaking something, although I can imagine a few other uses too (none of which are really going to be novel for someone who's coded in other languages with similar constructs).

What I find interesting about this is that one or more defer blocks can be declared at various locations within a block of code; this obviously makes sense in that you might not want to be handling the tidy-up of something you've not got around to creating yet. But there's also part of me feels uneasy about the "exit" code being declared further up the body of code, rather than down towards the end. On the other hand I think I do appreciate the idea of, up front, writing "look, any time there's a GTFO in the code that follows, this will happen" -- you're made aware pretty quickly of what to expect.

Anyway, it's good to know Swift has something similar to a finally.