iOS Family Sharing users cannot mix authentication schemes

Apple supports two styles of two-factor authentication, that they call (and distinguish as) “two-step” vs “two-factor”.  “Two-step” is their older method, though functionally they’re basically equivalent.

If you have multiple accounts on a Family Sharing arrangement, and some use “two-factor” while others use “two-step”, you’re in for a bag of hurt.

For example, any time you change the password on any of the non-master accounts, you’ll have to reauthorise all devices on that account with the master purchaser.  You’ll be prompted, when trying to download apps or purchase anything etc, with a dialog saying “Your Family Organizer, [foo], must enter the security code for their payment method”, asking for some kind of input.  There is literally nothing you can enter there that will make it work.  Not the password for any of the relevant Apple IDs, not any security codes for any credit cards, nada.

The problem is that it’s asking for a verification code that you can only create on a device which has “two-factor” authentication enabled.  Compare for example what you see with “two-factor” authentication enabled on your iDevice:

Screenshot of two-factor authentication enabled in iOS account settings

Versus what you see with “two-step”:

Screenshot of two-step authentication enabled in iOS account settings

That “Get Verification Code” “button” is what you’re looking for.  As you can see, it simply doesn’t exist with “two-step” authentication enabled.

The only solution – to allow your family members to download apps, purchase music / videos / books / etc, or pretty much do anything else on their iDevices – is to force the master account over to “two-factor” authentication.

To do this, you have to go to https://appleid.apple.com/ and turn off “two-step” authentication (which will require you to complete some stupid ‘security’ questions).  You cannot turn off “two-step” authentication from any of your actual iDevices’ Settings apps.

Then, stupidly, you can’t actually enable “two-factor” authentication from that same website.  That can only be done in the Settings app on one of your iDevices – by (in iOS 10.3 or later) going into Settings ➜ <your name at the top of the list> ➜ Password & Security.

There’s no way to enable “two-step” authentication anymore.  And not having any form of two-factor authentication enabled is a very bad idea.  So if any of your family’s accounts have “two-factor” authentication enabled, you basically have to switch to “two-factor” on all of them.

Which would be broadly fine, if Apple hadn’t made it so needlessly complicated, and the two systems so incompatible that their own software can’t figure out what’s going on.

Rotated Windows

I’d forgotten about this until I stumbled across a reference to it again recently.

This was a little hack I worked on back in 2004, with Mac OS X Tiger (10.4).  Yes, kids, macOS was called Mac OS X back in ye Olden Times.

Rotated Windows example screenshot

Wow, Slashdot looked even uglier than I remember, back then.  Though amusingly my daily reading list hasn’t changed substantially – it still features Slashdot and MacSurfer’s Headline News.

Also… 1024 x 768.  That’s just over 5% of the resolution of my current display (27″ Retina iMac).  It’s nearly as big as my iPhone 6s’s screen.

Man, do I not miss those shitty old monitors.

I don’t recall what the exact impetus was for the project.  I do recall that I was spurred on by Claus Atzenbeck, who was doing some kind of academic work into graphical user interfaces and, IIRC, wanted a way to explore window rotation and general manipulation in a real OS.

Claus’s personal website still exists, all these years later, though alas the link to his relevant research is now broken.

What reminded me of this was finding an attribution to me in a header file that was associated with the project – CoreGraphicsServices.h.  This was something I generated (presumably with the help of class-dump or similar) from the CoreGraphicsServices framework, and then partially reverse-engineered (in the sense of figuring out parameter types, function prerequisites, etc).  It’s what was necessary to find & use the private APIs for doing window geometry manipulation.

And the only reason my name is on it is because I splatted a 3-clause BSD license into the header file I made, which in hindsight seems highly dubious since the APIs themselves are owned by Apple (insofar as one can ‘own’ APIs, I guess…).

A quick web search reveals a few more mentions:

The source & other paraphernalia were originally posted on my La Trobe University student web hosting account, though of course that’s long gone.  Here’s the original StuffIt archive, if you’re interested.  I don’t actually know if it’s the very latest version – I do still have the project in full – but it’s the latest version I ever published, AFAIR.

I leave it as an exercise to the reader on how to decompress StuffIt files in this day and age. 🙂

Undocumented Swift conditional compilation macros

swift/lib/Basic/LangOptions.cpp has most of the conditional compilation macros (called “Language Options” in the compiler internally).  Notably the swift() version macro is absent, and doesn’t seem to be defined anywhere…

At time of writing the two undocumented additions, to the os(), arch(), and swift() set, are _endian() and _runtime().

I have no idea if they’re useful or not – does anyone have to care about CPU endianness these days, really? – but there they are.