Earlier this week, users of Legacy Update started reporting errors when checking for updates on Windows 7.

The most common variant of this is error 80728015 when checking for updates. That error code is documented with the message:

An operation did not complete because the registration of the service has expired.

Interesting - “registration” of “services” usually relates to Microsoft Update, which extends Windows Update (the naming is terrible, I know) with the ability to receive updates beyond just Windows itself, including updates for Microsoft Office, Visual Studio, and SQL Server, as well as free software offers such as Windows Search, Microsoft Security Essentials, and Microsoft Edge.

Rather than an error code, some users instead got a very misleading error dialog:

Windows Update cannot currently check for updates, because the service is not running. You may need to restart your computer.

However, the service is in fact running, and a system restart has no effect.

As spotted by Douglas Reno, who works alongside me on the Legacy Update project, when we peek at the “authorization” XML file used to specify how Microsoft Update should be configured, it lists an expiry date of 2025-07-01, at midnight UTC.

Here is the file, reformatted for brevity:

<ProviderAuthorizationInfo>
	<ServiceID>7971f918-a847-4430-9279-4a52d1efe18d</ServiceID>
	<CabVersion>8110</CabVersion>
	<IssuedDate>2017-12-01T00:00:00.0000000-00:00</IssuedDate>
	<ExpiryDate>2025-07-01T00:00:00.0000000-00:00</ExpiryDate>
	<RedirectUrl>http://ds.download.windowsupdate.com/v11/2/microsoftupdate/redir/v6-muredir.cab</RedirectUrl>
	<RedirectUrl>http://fe2.update.microsoft.com/v11/2/microsoftupdate/redir/v6-muredir.cab</RedirectUrl>
	<OffersWindowsPatches>true</OffersWindowsPatches>
	<UIPluginCLSID>3809920F-B9D4-42DA-92E0-E26265E0FB89</UIPluginCLSID>
	<IsManaged>false</IsManaged>
	<CanRegisterWithAU>true</CanRegisterWithAU>
	<ServiceUrl>https://fe2.update.microsoft.com/v6/</ServiceUrl>
	<SetupPrefix>mu</SetupPrefix>
	<LocalizedProperties>
		<Language>en</Language>
		<Name>Microsoft Update</Name>
	</LocalizedProperties>
</ProviderAuthorizationInfo>

This XML file is found inside a cabinet file named v6-muauth.cab. The cabinet is used to attach a digital signature to the file, preventing a man-in-the-middle attack where the XML is modified to hijack users’ devices to use a malicious Microsoft Update server, while still allowing businesses and ISPs to run an HTTP mirror of download.windowsupdate.com to increase download speeds and save on bandwidth.

As you can see from <ExpiryDate>, it definitely stopped working because the expiry date lapsed. As seems to happen too often in our industry, apparently nobody set a reminder to make sure it would be updated in advance of the date.

You might notice that it has an <IssuedDate> of 2017-12-01. That’s fairly recent! After digging further, we learned that this already happened once! On the 4th of that month, Bleeping Computer covered an error Windows 7 users were receiving when checking for updates. That error is 80248015 - pretty familiar, right? Microsoft allowed this file to expire, not on the 1st but rather on the 4th (more specifically, 35 seconds before midnight in US Pacific time, or 8:00 PM UTC), and did not manage to upload a new file until the 6th at 10:02 AM Pacific (6:02 PM UTC). This left Microsoft Update broken for 3 days.

	<IssuedDate>2013-12-03T11:59:25.5067616-08:00</IssuedDate>
	<ExpiryDate>2017-12-03T11:59:25.5067616-08:00</ExpiryDate>

The fix

…is to just bump the expiry date again. Indeed, yesterday at 7:32 PM Pacific (2:32 AM UTC), 2 days late, that’s exactly what Microsoft did. The file now looks like this:

	<IssuedDate>2025-07-01T15:00:08.7715059-07:00</IssuedDate>
	<ExpiryDate>2033-07-01T15:00:08.7715059-07:00</ExpiryDate>

Curiously, the timestamps are once again in Pacific time, as a precise number down to the microsecond. This matches how the 2013 version of the file is written.

The 2013 version of muauth.cab lasted 4 years. The 2017 version lasted 7 years and 7 months. The 2025 version will last 8 years. Interestingly, prior versions of the file I can find were issued on 2007-05-02, and are set to expire on 2027-05-02. (These do not appear to still be in use.)

Why does this file expire?

It’s not clear to me why this file needs to expire. In fact, Microsoft agrees. In Windows 8.1, the way Microsoft Update is registered changed, introducing a new component named SLS, which we believe means Service Locator Service. It allows Microsoft to provide different versions of the configuration depending on the Windows version, build number, architecture (x86 vs x64 vs ARM, etc.), language, Windows Update agent version, and other details that can be particularly relevant to your device. By contrast, the same v6-muauth.cab file is shared by all versions from Windows 2000 to Windows 8, which could be running wildly different versions of the Windows Update agent.

Here is how the SLS manifest for Microsoft Update looks for Windows 8.1:

<!-- PRODUCTION MU v6 LIVE -->
<ServiceEnvironment
	ServiceID="7971f918-a847-4430-9279-4a52d1efe18d"
	ID="MUv6LiveProduction"
	Revision="1">
	<WUClientData>
		<Protocol
			clientServerUrl="https://fe2.update.microsoft.com/v6/"
			clientServerUrlCR="https://fe2cr.update.microsoft.com/v6/"
			reportingServerUrl="http://statsfe2.update.microsoft.com/"
			elementVersion="1" />
		<SelfUpdate
			selfUpdateUrl="https://fe2.update.microsoft.com/v10/3/microsoftupdate"
			elementVersion="1" />
		<ServiceID>7971f918-a847-4430-9279-4a52d1efe18d</ServiceID>
		<OffersWindowsPatches>true</OffersWindowsPatches>
		<UIPluginCLSID>3809920F-B9D4-42DA-92E0-E26265E0FB89</UIPluginCLSID>
		<IsManaged>false</IsManaged>
		<CanRegisterWithAU>true</CanRegisterWithAU>
		<ServiceUrl>https://fe2.update.microsoft.com/v6/</ServiceUrl>
		<SetupPrefix>mu</SetupPrefix>
		<LocalizedProperties>
			<Language>en</Language>
			<Name>Microsoft Update</Name>
		</LocalizedProperties>
	</WUClientData>
	<StoreClientData />
</ServiceEnvironment>

There are no dates in this file! It appears it never expires. In fact, the cabinet is signed by two certificates that expired in 2019, so there is no concern that it might use expiry dates from the certificate chain (we’ll leave that type of behavior up to Apple…).

The exact path this cabinet file can be found at is much more complicated. I split it across multiple lines for clarity:

https://sls.update.microsoft.com
	/SLS
	/{7971F918-A847-4430-9279-4A52D1EFE18D}
	/x64
	/6.3.9600.0
	/0
	?CH=424
	&L=en-US
	&P=
	&PT=0x59
	&WUA=7.9.9600.17092

As you might have gathered by now, {7971f918-a847-4430-9279-4a52d1efe18d} is the unique identifier for the Microsoft Update service. Microsoft loves to use GUIDs for everything.

What to do if you’re affected by this

This section is no longer necessary, but I already wrote it and took nice screenshots, so…

To avoid this for now, disable Microsoft Update.

You can do so by going to Start → Control Panel → Windows Update → Change settings, and unticking “Give me updates for Microsoft products and check for new optional Microsoft software when I update Windows” (Windows 7) or “Give me updates for other Microsoft products when I update Windows” (Windows 8).

If you use Legacy Update, we detect the error and display a useful explanation of the issue, and offer to disable Microsoft Update for you.

If you already disabled Microsoft Update to work around this issue, you can install Legacy Update again to re-enable it.

As I’ve now learned that SLS was introduced in Windows 8.1, not Windows 8 as I previously assumed,¹ we’ve tweaked the upcoming Legacy Update 1.11.1 release to offer a checkbox to enable Microsoft Update on Windows 8 and 8.1, in addition to Windows 7 as we already did. It doesn’t hurt to have the option anyway - the method of registering for Microsoft Update is the same on every version of Windows from 2000 SP3, to 11 25H2.

Post-mortem

When the issue first showed up, we brainstormed a number of ways to work around this issue, in case Microsoft decided to forego fixing this. Fortunately, we didn’t need to use any of those options.

Windows 7 and later, at least for now, continue to be fully supported by the official fe2.update.microsoft.com service (ignoring bugs that prevent Windows 7 and 8 from completing update checks out-of-box). Legacy Update hosts a proxy service to connect to this server, which we use on Windows 2000, XP, and Vista. Due to the way Microsoft Update is designed, configuring a custom server in the registry also inherently allows it to receive Microsoft Update updates. It also means the expiry doesn’t apply, because the authorization file is no longer relevant. This is the workaround we most likely would have used.

By the time we reach July 2033, I expect that standards of secure TLS versions and ciphers will have already increased, locking Windows 7 out from Windows Update. This would require Legacy Update to configure its proxy server to fix Windows Update access on Windows 7 devices. We’ll just need to wait and see what the next 8 years are like.

Just wanted to write up some thoughts about Microsoft’s recent announcement that old drivers will be removed from Windows Update.

The short version of it is that “legacy drivers that have newer replacements” will soon be hidden from Windows Update, and in 6 months’ time, depending how the industry responds to this, they may be fully deleted. As you might imagine, that “legacy” keyword has brought some curious questions my way.

There is some real ambiguity to what Microsoft is trying to do here. Here is how I understand the timeline of what will be happening with drivers. This is only my interpretation, and I can be wrong about any or all of this.

1. At some point in the near future, Microsoft will perform a soft deprecation of all versions other than the latest of each driver, such that they are no longer offered in WSUS as an option to deploy to devices. The drivers will likely still be accessible by manually finding and downloading them on the Microsoft Update Catalog.
2. Hardware manufacturers will then have a 6 month window to raise concerns with Microsoft. A manufacturer can suggest that Microsoft reinstate old versions of a driver, but they should be prepared to give a really good reason for it.
3. After 6 months, any remaining drivers that did not get reinstated will be removed forever. It’s not clear whether this means they will only cease to be offered by WSUS, or if they will also disappear from the Microsoft Update Catalog, or if the files will also be deleted.
4. At some later time, a policy will be instated that old drivers will expire on a continuous basis, the exact details not discussed yet. They may also consider removing drivers that are not considered “legacy drivers that have newer replacements already on Windows Update”.

I don’t have any reason to believe this will affect old devices. You should still be able to automatically receive drivers for something like an Nvidia 700 series GPU, or a Wi-Fi PCMCIA card - including from Legacy Update, which relies on the public Windows Update service.

But why is this being done? As I posted in a quick first reaction, I think two things are true here:

First, what Microsoft is actually saying: that this is an initiative to improve security. This is valid, because of “bring your own vulnerable driver” attacks. This is a malware tactic that takes advantage of an outdated driver that is already installed, or is easy to trick the victim into installing, to gain full unrestricted kernel privileges. If you don’t know operating system design: malware finding its way into the kernel is game over. It has access to everything the infected system has access to, and can take measures to hide itself to hang around as long as possible. In the past few years, Microsoft has been stepping up defences against BYOVD attacks, particularly through the Vulnerable Driver Blocklist. Vulnerable drivers Microsoft has blocked include ones for Realtek audio, VirtualBox, Nvidia NVFlash, and something from Asus. They also recently took the unpopular major step of blocking WinRing0, a fundamentally flawed and vulnerable driver, yet still widely used to access hardware such as RGB and fan controllers.

While Windows Update itself will only ever install the latest version of a driver (sometimes even against your wishes), businesses can choose which updates they roll out to their devices. This tends to be done with Windows Server Update Services (WSUS), or one of Microsoft’s numerous replacements of it. Sometimes you just need an old version of a driver or update. The new version breaks something, or your business requires the utmost software stability, or is legally obligated to audit all software running on systems exposed to sensitive data. As far as I’m aware, since Windows Update v4 (2001), Microsoft has never deleted old drivers or updates, except where they needed to stop the rollout of a seriously broken update. Despite potential security concerns, an old release could be better for your needs, and it is assumed that your IT department has made the risk assessment decision. With this change, if you require an outdated driver, it must be deployed through some means other than Windows Update.

Second, what Microsoft isn’t saying, or rather, what they were saying up until a few months ago. Let’s go back to WSUS. The current generation of it started off as version 3.0, which released not long after Windows Vista in 2007. A lot has changed, but a lot has also stayed the same. If you’ve reinstalled Windows 7 sometime since 2015, you might know that its Windows Update servicing system is straight up broken in its out-of-box state, and requires a manual update - that, even then, doesn’t properly solve the problem, just makes it more tolerable. Windows Update has a pretty cool system of describing whether an update is necessary to be installed on the current system, or if it is already installed. It also builds a relationship graph between updates, to indicate when they have been replaced by a newer update that includes all changes from the previous update. That system is also its downfall, causing the Windows Update service to be incredibly slow in checking for updates, possibly never completing the check at all. This issue also applies to WSUS, which despite being based on the very robust SQL Server, struggles with the number of drivers Microsoft hosts on Windows Update. As of April, we know that Windows Update hosts 1,799,339 drivers, and this creates a 138 GB database that requires almost 16 days to synchronise down from the main servers. The WSUS server is brought to its knees, with frequent timeouts while it furiously tries to complete database queries. (The PC used is a Ryzen 5700G with 32 GB of 3600 MHz RAM and 500 GB of NVMe, running Windows Server 2025 and SQL Server 2022.)

The reason we have those numbers is because, in June 2024, Microsoft announced the deprecation of WSUS’s driver synchronisation, then in September 2024 announced the deprecation of WSUS, indicating that it will no longer be supported after Windows Server 2025, then in April 2025, backtracked at the eleventh hour and decided drivers are staying around after all. To preserve the data for use by Legacy Update and the community, I jumped to sync it all down right before it was due to go away. I can respect that Microsoft is trying to move on from software that hasn’t had a major update since forever ago, but this timeline of events is crazy, and comes off mildly tone-deaf that they don’t understand how their customers are using their products. Or, that they perhaps do know, but don’t consider a 34% response to a survey as important enough to register.

Under the announcement, a commenter, ItsADave, made a suggestion that Microsoft should consider sharing the to-be-deleted drivers with Legacy Update or the Internet Archive. First, I’m flattered that our project is in such a respected and trusted position. I never expected it to be mentioned adjacent a Microsoft announcement that’s being linked back to from major tech news outlets. But to be realistic, I don’t expect this to happen, because the drivers are owned by the hardware manufacturers that wrote them, and they likely only license them to Microsoft for redistribution to end-users and IT administrators. Even if the agreements they have with Microsoft are lenient, the lawyers are very likely not comfortable with handing over other companies’ work to a small project, or even drawing any attention to us, which can be seen as an endorsement to continue running old vulnerable software. Unless proven otherwise, this is entirely for us to deal with as a community. As for the Internet Archive, I would mention that this is a considerable amount of data (6.454 TB), and the optics of one of the most valuable companies of all time deferring a problem to a non-profit library that already has enough battles to fight aren’t particularly positive.

As a side note, I’ve found the Microsoft announcements made on their Tech Community website to be kinda weird, because as we just explored, they come off unclear, vague, and often filled with jargon. They tend to read like nobody has proofread them - the announcement we started this post with blatantly refers to “windows update” in all lowercase four times! The announcement about backtracking on WSUS drivers also interchangeably refers to them as being both “deprecated” and “removed”, while correctly reminding the reader that the terms have very different meanings. The reason there has been confusion and concern about changes like this is because, besides poor discussion with the community, it’s just plain missing the extra attention to wording and clarity from someone good with PR.

The high resolution Windows XP icons in the banner image come from the excellent Windows XP High Resolution Icon Pack. Thanks, marchmountain!

If I had a LinkedIn bio, I'd definitely mention that I wrote the Windows Start Menu.

Well, the non-resume version is that I wrote the code that custom-paints the Start menu, draws the sideways text, background gradient, and so on. It had been done with a Bitmap in Windows 95, but for WindowsNT that would mean doing it in N languages for V variants of server, workstation, and so on. That would be a lot of bitmaps with text in them.

I wanted to render it live.

There's probably a way to render text sideways now, but there wasn't at the time. Fortunately, with NT, unlike 9x, you could rotate the device context itself. I'd only been coding for Windows a few months at that point, so it was cool to discover it was even possible. I tried a quick test and it worked!

I used standard GDI calls to render the background gradient, which fades blue-black like the sky on the NT box, then fill anything past that with solid black.

And now you know how the start menu draws :-) pic.twitter.com/QgQqhSFi8w

— Dave W Plummer (@davepl1968) July 14, 2024

Well, that’s interesting! It might seem like nothing these days - of course you can procedurally draw rotated text, why not? But you have to remember Windows NT 4.0’s minimum system requirements are a 486 at 33 MHz, 16 MB of RAM, and just any VGA graphics card that makes pixels appear on the screen. (VGA here refers to the 1987 IBM PC standard of 640×480 with 16 colors, not the “modern” VGA, specified by VESA, that stretches as far as 2048×1536 with 24-bit color.) The Graphics Device Interface (GDI) library’s performance was dramatically improved in NT 4, so it could plausibly make sense that even the lowest-end systems could draw the gradient and text very quickly. After all, Windows 95 with its minimum spec of 4 MB of RAM managed miracles such as drawing your desktop wallpaper - at 16-bit 1024×768, that would require about 1.5 MB, which could already be well in use by other programs.

In Dave’s tweet, and subsequent YouTube video, he mentions that Windows 95 simply had a pre-rendered bitmap of its Start menu banner logo embedded into explorer.exe. Indeed, you can find this bitmap pretty easily using a copy of Windows 95, 98, or Me, and a tool such as Resource Hacker:

And if we go past NT 4, to 2000, XP, Server 2003, and Vista (the classic Start menu was removed in Windows 7), we can also see that the banner is a bitmap:

Ok, that’s a lot of editions (and I didn’t even include all editions of XP). Maybe they decided rendering with GDI at runtime didn’t make sense, so they went back to bitmaps.

The two key claims Dave makes about NT 4.0 are:

• NT 4.0 comes in many editions, so there are already multiple brand names to consider.
• Each language release of NT 4.0 needs its name localised.

Starting with the first claim, we can easily confirm that it appears to be incorrect.

The final release of NT 4.0 (and all service packs) only contains two banners: Workstation, and Server. There are also two later releases of NT 4.0 - Terminal Server and Embedded. Terminal Server simply overwrites the Server resource with the Terminal Server name, and Embedded adds a new resource. Amusingly, “Embedded” seems to have two nearly invisible letters: “Ed”. Maybe it was originally “Embedded Edition”?

Well, this still just doesn’t seem right. There must be some situation where the bitmaps are ignored, and a graphic rendered at runtime is used instead.

I poked at a copy of Windows NT 4.0 Workstation in Italian, and found the exact same bitmaps with English text. Maybe the bitmaps are just there for some compatibility reason?

So I installed this copy, and found the exact same English-language bitmaps.

Nope - the branding stays identical. What about Server in Spanish?

Hm. English and other European languages were part of the initial release of NT 4.0. Chinese, Japanese, and Korean (CJK) were released later. Maybe it was added later to handle those languages. So let’s try Simplified Chinese Server.

Let’s go for broke then - Japanese Enterprise Server.

At this point we’ve confirmed that, in released builds of NT 4.0, the Windows branding doesn’t change with localisation, in fact rarely changes with the specific edition of the operating system, and no procedural rendering is being done.

That leaves one more theory - was the bitmap originally procedurally generated in NT 4.0 betas, and then, later, it became the two Workstation and Server bitmap resources?

Let’s turn back the clock to the development of Windows 95, the first time the Start menu, taskbar, and Explorer (the “shell”) were implemented in a capacity more than just a proof-of-concept. Alongside the MS-DOS-based versions of Windows, Microsoft were simultaneously working on Windows NT. There was some clear excitement for the Windows 95 redesign, and therefore demand for it to make its way to Windows NT. The project porting the Windows 95 shell to NT was named the Shell Update Release (SUR), and it was released as Windows NT 4.0. Microsoft also developed and released the Shell Technology Preview (aka NewShell), allowing an early build of the port to be tested on NT 3.51.

In the earliest leaked build of the Shell Technology Preview, 3.50.854, the banner says “Windows 95” on a grey background, almost identically to the banner found in Windows 95, but in what appears to be a Helvetica-alike font such as Microsoft Sans Serif, rather than the Franklin Gothic font used by the Windows brand between 95 and XP. By the time STP reaches its official preview release (of which two builds were released), the graphic is changed to say “Windows NT Explorer” on a bright blue background.

This NT Explorer graphic also appears in early leaked pre-beta builds of NT 4.0. In Beta 1, the bitmap changes to a grey gradient with a condensed font, also adding the edition of NT, “Workstation” or “Server”. It also has some random color sparkles. The final graphics appear in Beta 2, with a dithered blue to black gradient, and the correct brand font for “Windows NT”.

Finally, leaked source code of presumably RTM or a post-RTM release of NT 4.0 does not appear to contain any code to render the banners with GDI. The only code that has been found simply loads the bitmap resource for Workstation or Server.

Preliminary glance at NT 4 source code seems to confirm pic.twitter.com/dweshpCivD

— Rafael Rivera (@WithinRafael) July 16, 2024

In conclusion: From publicly available evidence, it does not appear that, at any point, Windows NT 4.0 ever used a procedurally rendered graphic.

So was Dave lying, did he just forget how it works, or is there more to the story we don’t know? Well, of course, it’s hard to tell. In one way, the SUR project was at least 29 years ago, with the earliest known Shell Technology Preview build being from November 1994, and I can definitely see memory failing to recall how it was put together all that long ago. In another, I’ve observed Dave to have an interesting way of describing his achievements, where it seems like some of it is truth, and some of it is embellished. This does feel a bit like it could be one of those, but again, all I can do is speculate. He’s had some clear contributions to Windows that, in my opinion, need no embellishment because they’re significant enough that millions of users have interfaced with them, and many still exist in the latest version of Windows 11 today, despite him leaving Microsoft in 2003. And indeed, Dave himself frequently mentions on social media that he is wealthy, published a book literally titled “Secrets of the Autistic Millionaire”, and closes his videos by saying he’s “just in it for the subs and likes”. There is also the possibility that the code never saw the light of day - never released, and never leaked.

I performed this exercise to understand whether, perhaps, something was missing from Dave’s story, or we were unaware of some necessary condition to invoke the procedurally-drawn graphic code path. With all of the above said, please do not harass Dave over this post. Unless he has some evidence we don’t, or that I missed, I don’t think it’s necessary to bug him.

As a quick recap: The eligibility system works with a file on Apple’s servers that tells iOS which conditions must be met for a country-specific feature to be enabled. They can change this file at any time, and all active iOS devices should apply the update within a few days.

You can visit The Apple Wiki article about Eligibility for the most current (and detailed) info, but here’s a summary of what we found:

Unless I specifically call it out, all of these features are iPhone-only, and the country requirement applies to both your physical location, and your Apple ID’s country setting.

App marketplaces

If iOS determines you’re in the European Union, you can install app marketplaces (3rd-party app stores), and install apps offered in them. Or, coming in iOS 17.5, you can install apps directly from the web.

If you leave the EU, or sign into a non-EU Apple ID, you receive updates to these apps for a grace period of up to 30 days. After that, you stop receiving updates, and can’t reinstall either, including if you’re running low on space and iOS automatically offloads it (cloud icon next to the name on the home screen).

Apple confirmed in statements to the media that apps still open after the grace period expires – they just can’t be updated or reinstalled. Apps downloaded from the web do update automatically, by the way, because it’s still all Apple’s App Store infrastructure behind the scenes.

Web browsers

If you’re in the EU, you can install variants of browsers that use their own rendering/JavaScript engines, rather than Safari’s WebKit and JavaScriptCore. The app needs to be a separate app from the worldwide version of the app, which still must use WebKit/JavaScriptCore. (Mozilla has spoken out on why this is problematic.)

Like with app marketplaces, you have a grace period of 30 days after leaving the EU before browsers with their own engine stop updating or reinstalling.

You’ll also be prompted to choose a browser the first time you open Safari.

PWAs (home screen web apps)

Apple caused a stink during the 17.4 betas because web apps added to the home screen (Progressive Web Apps) would display a message stating they now open in your default web browser, instead of running in a full-screen app experience. This meant you lost cookies and other data you stored in the app (I heard of crypto wallet apps as one of the scariest examples – you couldn’t even transfer your data across to Safari!), and lost other features Safari locks to home screen apps to prevent abuse, such as push notifications. Apple swears this was due to them having a time constraint to release 17.4, but the DMA was signed into law in 2022, so they had plenty of time. Delaying to the last minute isn’t a good excuse 🤷‍♀️

Anyway, it seems this either was, or is now after the backlash, controlled by a remote toggle. This is the only one that disables something, rather than enabling. It’s currently set to nothing, so home screen web apps are enabled worldwide. The code for disabling them is probably still there, meaning it can be toggled back on at any time. I doubt they will, but the mechanism is there regardless.

Contactless payments

Moving to the European Economic Area now (the EU plus 🇮🇸 Iceland, 🇱🇮 Liechtenstein, and 🇳🇴 Norway). Users in the EEA have the option to use payment apps that can perform Host Card Emulation (HCE), which means your iPhone can act as a credit card to a payment terminal. In less technical words, apps can exist that compete with Apple Pay for in-person payments. They also have the option to become the default app launched when you double-click the side button, instead of Wallet/Apple Pay.

If you leave the EEA, you immediately revert to Apple Pay, and can’t use 3rd-party payment apps.

External purchase links

Apps can take you to a website to make purchases, rather than using the App Store In-App Purchase (IAP) system, in a number of countries:

• 🇪🇺 EU: Allowed on iPhone only. (Apple documentation)
• 🇮🇸 🇱🇮 🇳🇴 Iceland, Liechtenstein, Norway: Allowed on iPhone and iPad if you’re physically in one of these countries, and your billing address is also set to one of them, or, for some reason, 🇦🇹 Austria.
• 🇺🇸 US: Allowed on iPhone or iPad if your Apple ID billing address is set to the US. (Apple documentation)
• 🇷🇺 Russia: Allowed on iPhone and iPad if your billing address is set to Russia.

This permission remains active for a grace period of 30 days after you no longer meet any of these requirements.

3rd-party billing

In some countries, you can make an IAP purchase through a 3rd-party payment provider, without leaving the app:

• 🇪🇺 EU: Allowed on iPhone only. (Apple documentation)
• 🇰🇷 South Korea: Allowed on iPhone or iPad. (Apple documentation)

South Korean apps must go through one of the following payment providers: KCP, Inicis, Toss, or NICE. Each app that wants to use 3rd-party billing needs to opt into the feature, and release separate versions of their app for South Korean and/or EU users.

This permission also remains active for 30 days after you no longer meet the requirements.

China geopolitics

An Apple system for country-specific features wouldn’t be complete without some curious Chinese geopolitical tweaks. There are already a number of things that differ on iOS if you have an iPhone whose model number ends in “CH” (that’s China in Apple’s model region system, not Switzerland). A new one introduced in iOS 17.4 changes the names of Hong Kong, Macao, and Taiwan across the operating system to include a “(China)” suffix if you have a China-region iPhone.

This one was more interesting to look into, because it was built as a patch to an open-source component, International Components for Unicode (ICU), which is used by basically all modern software on the planet. It handles things like displaying the correct date and time format, currency format, and specific to this case, country/language names translated to every language. What happened here is Apple made a patch that isn’t tied to the Chinese language, but rather whether the device is China-region. The patch code is publicly released in macOS 14.4’s open-source components. The engineer added an amusingly misleading comment explaining that it’s so China displays as “China mainland” when it appears next to Hong Kong, Macao, or Taiwan. Another part of the patch, where the country names are defined in each language, adds the “(China)” suffix when the code forces the “%prc” variant to be used.

#if APPLE_ICU_CHANGES
// rdar://115264744 (Sub-TLF: China geopolitical location display via ICU)
bool useChineseVariant = uaprv_onCalciumDevice();
if (useChineseVariant && uprv_strcmp(region, "CN") == 0) {
    // if the region code is CN, the regular display name is "China mainland" and the "%prc" variant
    // is "China".  On a China-SKU device, we want "China mainland" when CN appears in a list along
    // with TW. HK, and/or MO, and "China" the rest of the time.  We use
    // UDISPCTX_CAPITALIZATION_FOR_UI_LIST_OR_MENU as the mechanism to tell us when to say "China mainland".
    if (capitalizationContext == UDISPCTX_CAPITALIZATION_FOR_UI_LIST_OR_MENU) {
        useChineseVariant = false;
    }
}
#endif // APPLE_ICU_CHANGES

You can see this patch here and here.

That’s all we know for now. There are some eligibility domains that we haven’t figured out yet, but it’s likely because they’re not implemented yet. This is the bulk of it, though.

This post is based on a tweet I originally posted on Twitter.

See also my previous post about how the eligibility system works, and iOS 17.4’s flawed app marketplace installation flow.

In iOS 17.4, Apple introduced a new system called eligibilityd. This works with countryd (which you might have heard about when it first appeared in iOS 16.2) and the Apple ID system to decide where you physically are. The idea is that multiple sources need to agree on where you are, before giving you access to features such as those mandated by the Digital Markets Act.

A plist file downloaded from Apple declares “domains”, which are individual features locked behind a location wall. At the time of writing, there are 24 (although one is missing), and the file was last updated on the 5th of April. We weren’t tracking updates to it before this week, so I don’t know what changed exactly. As a reminder, iOS 17.4 launched on the 5th of March, and was in beta from the 30th of January.

Probably to obscure what they are, these domains are named after the chemical elements corresponding to their numeric value. The only way to determine what feature these correspond to is by disassembling the relevant parts of iOS that check the eligibility system. On The Apple Wiki’s Eligibility article, I’ve documented what I’ve already found.

Most domains are currently configured to only be allowed on iPhone, because the DMA has only declared Apple a gatekeeper with phones, not tablets. So much for all the laptop-class hardware the iPad Pro gets if it doesn’t get laptop-class software features the iPhone does get…

Apple has the ability to push an update to this config file at any time, whether to roll out a feature to more countries, to enable features on iPad, or to withdraw the feature from some or all countries. The update would likely be installed on all active iPhones within a few days.

I’m working through figuring out what each of the domains are. See the Apple Wiki article for the most current table.

So knowing all this, how did I trick iOS into giving me the DMA features? Well, I took my old 12 Pro Max and started tinkering around. I reset the phone, disabled Location Services, inserted an Italian SIM from my holiday many years ago, and made a new Italian Apple ID. No good.

I then set up a pfSense Wi-Fi router, broadcasting itself as having a regulatory country of Italy. (I compared the regulations, there are a bunch of differences for 5 GHz, so I disabled it. Otherwise, the EU’s Wi-Fi regulations are stricter than Australia’s, so it’s safe.) Well, looking at the device’s logs, countryd still knew I was in Australia, even after erasing and setting up the phone again.

The last thing I tried was going downstairs to our basement, where there’s no mobile signal. Reset the phone again, and what do you know, as soon as I open Safari it asks me to choose a browser. I put the phone in airplane mode so I can go back upstairs. As far as I can tell, it still believes I’m in Italy. It’s not just the 30 day grace period Apple provides - in fact, that grace period only applies to four of the 24 domains.

I don’t know how much of what I did was necessary (at minimum, the VPN is likely not needed), but this phone is obviously not practical to use in this state. It needs to stay in airplane mode, and needs a Wi-Fi network configured to present itself as having an EU regulatory country. It’s really only a setup I can use for testing EU features.

Again, I’m still actively researching this. Check the eligibility article to see the most current information I have.

This post is based on a tweet I originally posted on Twitter.

See also my previous post about iOS 17.4’s flawed app marketplace installation flow, and the next post, Features controlled by iOS 17.4’s eligibility system.

App installation has no progress prompts. The app-marketplace:// URL scheme, used by websites to tell iOS to begin installing a marketplace app, displays zero progress. It only has the ability to display error messages, such as telling you you’re not eligible (not located in the EU), or that you need to go to Settings to allow the app to be installed. Naturally, there’s no button that takes you to Settings, nor any explanation of what you do when you’re there.

Let’s follow the process of being in an eligible country (currently being any in the European Union), though.

In both prompts, the “Learn More” button takes you to this Apple Support article.

Once you’re in Settings, a followup button appears below your Apple ID name.

Tapping it displays this full-screen prompt:

Tapping Allow simply dismisses the prompt. There’s no indication of what happens next. The answer is - nothing happens. You need to go back to Safari and initiate the installation again. Then, you get another full-screen prompt, and then an alert prompt to confirm you’re really sure.

The app then starts downloading, but nothing tells you that. Tapping the download button does nothing now. You just eventually think to go to the home screen and find the app.

The only way to understand what is actually going on is to watch the syslog of the device - which it should go without saying is not something intended for users to look at anyway.

Awesome, we finally got there! Uh, almost. Now you found an app you’d like to install from the marketplace, so you do so. You then get another full-screen prompt like the one above.

To AltStore’s credit, I was using a slow VPN into the EU, so I don’t know if the lack of progress indication for the first few seconds is their fault or mine. But eventually it shows a progress bar.

I hit what I hope is a bug in AltStore, where I’ve uninstalled Delta, but it still thinks it’s installed, so I couldn’t get a screenshot of the app installing from the home screen. However, it does indeed display progress there, as confirmed by others who have posted about their experience.

Finally, the app is installed! We got there eventually.

This goes back to me being conflicted about where we’re at with this. I both don’t like AltStore working with Apple as if to show that we’re ok with this solution, but also, it is important to show how bad Apple’s solution really is.

Make no mistake, if a teenager was able to build a jailbreak that puts a Cydia icon on the home screen with a download progress bar back on iOS 4.3 (2011!), Apple can do far better with user experience here. They know what they’re doing. The sloppiness of the whole process is intentional, and AltStore needing to charge €1.50/year is a barrier Apple fully intended to force upon marketplaces.

My bet is that Apple will use the shortcomings to argue to authorities that hey, look, nobody’s using this. Users hate it, the only positive user experience is our App Store. Could you drop the regulations and lawsuits, pretty please?

This post is based on a tweet I originally posted on Twitter. I updated some of this based on information I learned later on, such as that some duplicated confirmation popups were in fact from AltStore, and I would imagine are remnants of its sideloaded version that will be cleaned up soon. This post is a review of iOS 17.4’s app marketplace functionality, not a review of AltStore, so I decided to remove those parts.

I also followed up this post with a look into the feature eligibility system, and a list of features controlled by the system.

As a new solution, you can query UniformTypeIdentifiers, which holds a comprehensive taxonomy of all PowerPC, Intel, and Apple Silicon Macs released up to the point of the running macOS version. The upside is also that you can find tons of other information on the device, such as the visual design, which works great for picking the right SF Symbol.

Here is the result of the below code on my 14″ MacBook Pro with M2 Pro:

Really unfortunately, nothing similar seems to exist on iOS. It would have been great to have this considering we now have three major hardware designs (home bar, home button, dynamic island) to worry about.

I originally wrote about this way back in 2013. What changed since then?

Well, seemingly everything!

In iOS 8.0, FrontBoard was introduced. Many of SpringBoard’s responsibilities were shifted from SpringBoard itself to the FrontBoard framework, allowing Apple to share SpringBoard code with watchOS and tvOS (which use their own Boards), even macOS. One of the responsibilities of FrontBoard is handling shutting down/restarting the device, and relaunching the system app (SpringBoard in this case).

The -[SpringBoard _relaunchSpringBoardNow] method recommended in the 2013 post did still remain for some time, but was finally removed with iOS 9.3.

The code isn’t as fun-looking as the old way, but it does give you a super useful feature – you can have it automatically unlock after the restart and open a URL. This is especially really convenient if you’re adding a respring button to your preference bundle (please don’t require a respring to update settings if you can avoid it, but when you do, use this!).

NSURL *relaunchURL = [NSURL URLWithString:@"prefs:root=MyTweak"]; // use a nil relaunch URL to return to the lock screen
SBSRelaunchAction *restartAction = [SBSRelaunchAction actionWithReason:@"RestartRenderServer" options:SBSRelaunchActionOptionsFadeToBlackTransition targetURL:relaunchURL];
[[FBSSystemService sharedService] sendActions:[NSSet setWithObject:restartAction] withResult:nil];

If you need to support iOS versions between 8.0 – 9.2, you can perform checks and use the previous incarnation of the relaunch action.

NSURL *relaunchURL = [NSURL URLWithString:@"prefs:root=MyTweak"]; // use a nil relaunch URL to return to the lock screen
SBSRelaunchAction *restartAction;

if (%c(SBSRelaunchAction)) { // 9.3+
  restartAction = [%c(SBSRelaunchAction) actionWithReason:@"RestartRenderServer" options:SBSRelaunchActionOptionsFadeToBlackTransition targetURL:relaunchURL];
} else { // 8.0 – 9.3
  restartAction = [%c(SBSRestartRenderServerAction) restartActionWithTargetRelaunchURL:relaunchURL];
}

[[FBSSystemService sharedService] sendActions:[NSSet setWithObject:restartAction] withResult:nil];

This works from any process that isn’t sandboxed against sending inter-process messages to SpringBoard.

You can also use HBRespringController from Cephei that super-simplifies this and provides a fallback to _relaunchSpringBoardNow for pre-FrontBoard iOS versions.

[HBRespringController respring];
// or
[HBRespringController respringAndReturnTo:[NSURL URLWithString:@"prefs:root=MyAwesomeTweak"]];

In a preference bundle, you can subclass from HBListController to get the action method hb_respringAndReturn: for use on a PSLinkCell or PSButtonCell. This handles calling HBRespringController for you with a URL pointing to the current settings page. That means the screen will go blank for a few seconds, before returning straight to the very same Settings app screen that was just open. Pretty neat.

Finally, there is a third option for iOS 11 and newer. The Electra/Chimera and Elucubratus (included with unc0ver) repositories have a package named UIKit Tools – installed by default – containing a command line tool called sbreload, that executes the same logic to restart SpringBoard via FrontBoard. It also handles the case that SpringBoard is frozen and needs to be forcefully killed, so it’s ideal for use in scripts. Be aware that Telesphoreo’s (saurik’s) build of sbreload doesn’t seem to work, so use a different solution when running on iOS 10 or older.

Fixing it for good (or, getting close to it at least)

In the original post, I wrote:

Can there be a “fix” for tweaks that don’t respring the right way?

I’m working on it, not a high priority to get it done though.

The fix I had in mind was to register a signal(3) handler inside SpringBoard for SIGTERM, a graceful termination where the process is given the opportunity to clean up before terminating, and have it call _relaunchSpringBoardNow instead. This would allow you to run killall SpringBoard and retain battery stats. This wasn’t really viable, as a crash (SIGSEGV, SIGABRT, etc.), which was inevitable while developing a SpringBoard tweak, would ruin the stats anyway. Overriding those signals with a signal handler is possible, but would tamper with the crash being caught by the crash reporter. It’d also prevent Cydia Substrate from catching the crash so it can set a flag to launch Safe Mode when SpringBoard starts again.

Finally, there are still some tweaks (and people) who kill SpringBoard using SIGKILL. That usually comes in the form of killall -9 SpringBoard (9 is the numeric value of SIGKILL). It may sound like the same thing as SIGTERM since “kill” and “terminate” are synonyms in the English dictionary, but there’s a very important difference. A terminate signal asks the process to clean up and then exit when it’s ready to do so, while a kill signal instructs the operating system to kill the process, without giving it a chance to run any cleaning-up code. Of course, this means you can’t install a signal(3) handler for SIGKILL as it’ll never be called.

This made a “fix” seem like a poor idea, as there are still so many ways SpringBoard can exit without activating the fix. At that point I wasn’t able to find any explanation of what made _relaunchSpringBoardNow so special and why any other method, like the venerable exit(3), or terminating the main run loop (causing code placed after a -[NSRunLoop run] call to be executed), wouldn’t activate this mythical SpringBoard termination handler that saved these stats.

The better solution was activism about “the right way”, and the original post I made served that role as it showed up when Googling the right keywords. Later I created HBRespringController to take advantage of Cephei’s popularity and make it a no-brainer to call that handy method to respring correctly regardless of the iOS version it’s running on.

One workaround did get released — CySpring by Skylerk99. It makes Cydia respring via a call to FrontBoard, rather than by killing its process as Cydia does by default. However, it was never updated after the API changes were made in iOS 9.3, so it doesn’t work today.

While CoolStar was re-developing the UIKit Tools project inherited from the ageing Telesphoreo ecosystem to be up-to-date with modern developments to iOS, I brought up a consideration that it includes a tool called sbreload that doesn’t work. At this point, sbreload used a fairly complex looking technique of restarting SpringBoard by manually doing some teardown work and then forcing a full unload and restart of its launch daemon, that presumably worked a long time ago on early versions of iOS/iPhone OS, but definitely doesn’t seem to work now. There may have been some good reason it was developed like this – Cydia used to invoke this tool, but later switched to directly killing SpringBoard. sbreload on the Electra/Chimera and unc0ver jailbreaks now restarts SpringBoard via FrontBoard, with a fallback to forcefully restart SpringBoard if it seems to be frozen.

Sileo and Zebra now happily use sbreload to restart SpringBoard, and the fast respring times this brings are thoroughly enjoyed. Hopefully the speed of it encourages tweak developers to find out how it’s done, and leads them to this post. If that’s you, then it looks like I’ve done my job 😊

Update

With iOS 12, while developing the Screen Time feature, Apple rewrote a significant amount of crusty code relating to statistics collection. In the process, the long-standing lost battery usage data bug was fixed! It’s now impossible for an incorrect SpringBoard termination to affect battery statistics. Of course, you should still allow SpringBoard to exit gracefully through the specific APIs designed for this job, especially since this allows for a faster SpringBoard restart.

…but what did come in the initial beta of macOS Mojave were some real, working, iOSMac apps. News, Stocks, Home, and Voice Memos are all iOS apps ported to macOS and included in the initial beta of Mojave.

Some of this has already been covered by people faster than me, but I’m posting research from the way I approached this.

An effective way to get started investigating new frameworks like this is to review a real use case and work our way through the most obvious things. We’ll look at the simplest of the initial four apps — Voice Memos.

Starting with the obvious

otool -L shows a list of frameworks the app links against:

$ otool -L /Applications/VoiceMemos.app/Contents/MacOS/VoiceMemos
VoiceMemos:
	/System/Library/Frameworks/AVFoundation.framework
	/System/Library/Frameworks/CloudKit.framework
	/System/Library/Frameworks/CoreData.framework
	/System/Library/Frameworks/CoreFoundation.framework
	/System/Library/Frameworks/CoreGraphics.framework
	/System/Library/Frameworks/CoreMedia.framework
	/System/Library/Frameworks/CoreSpotlight.framework
	/System/Library/Frameworks/Foundation.framework
	/System/Library/Frameworks/QuartzCore.framework
	/System/Library/PrivateFrameworks/AppSupport.framework
	/System/Library/PrivateFrameworks/FrontBoardServices.framework
	/System/Library/PrivateFrameworks/MediaRemote.framework
	/System/Library/PrivateFrameworks/MediaServices.framework
	/System/iOSSupport/System/Library/Frameworks/UIKit.framework
	/System/iOSSupport/System/Library/PrivateFrameworks/NetAppsUtilitiesUI.framework
	/System/iOSSupport/System/Library/PrivateFrameworks/VoiceMemos.framework
	/usr/lib/libSystem.B.dylib
	/usr/lib/libobjc.A.dylib

(Output shortened so it’s easier to read on smaller screens.)

Interesting! While it’s linked against many of macOS’s core frameworks, there’s also some new iOS-alike frameworks found in /System/iOSSupport, and some of iOS’s core frameworks found in /System/Library/PrivateFrameworks.

Particularly of interest is that it links against FrontBoardServices, the client framework to the FrontBoard system of iOS. With the release of iOS 8, Apple began splitting out parts of SpringBoard — the “system app”, in FrontBoard nomenclature — so that different user interfaces and behaviors can be used for the growing array of iOS-based products such as Apple Watch, Apple TV, MacBook Pro Touch Bar, and HomePod. iOS still uses SpringBoard, watchOS uses Carousel, etc. The frameworks are identical across all of these platforms — particularly they all use the UIKit framework. This includes watchOS, where Apple has decided to keep UIKit private, exposing some of it through a rather limited wrapper framework (WatchKit). To see an iOSMac app linking against FrontBoardServices gives a clear indication that we’re very likely dealing with a one-to-one API-compatible system for iOS on top of macOS, with zero overhead such as running iOS in a separate subsystem from macOS.

Launching the Voice Memos app and checking the task list reveals a few processes running:

• VoiceMemos.app (/Applications/VoiceMemos.app/Contents/MacOS/VoiceMemos)
• voicememod (/System/iOSSupport/System/Library/PrivateFrameworks/VoiceMemos.framework/Support/voicememod)
• UIKitSystem.app (/System/Library/CoreServices/UIKitSystem.app/Contents/MacOS/UIKitSystem system_app_start)
• UIKitHostApp.xpc (/System/Library/PrivateFrameworks/UIKitHostAppServices.framework/Versions/A/XPCServices/UIKitHostApp.xpc/Contents/MacOS/UIKitHostApp)

The first two seem obvious — the app itself, and a daemon that does whatever necessary background work. Comparing to a jailbroken iPhone, we can see the same voicememod running when the Voice Memos app is in use.

The next two are what we’re interested in. We’ve very likely confirmed that there is a FrontBoard system app, named UIKitSystem. We also see the XPC agent UIKitHostApp, which we’ll delve into shortly.

UIKitSystem

$ /System/Library/CoreServices/UIKitSystem.app/Contents/MacOS/UIKitSystem
UIKitSystemApp is the system app for iosmac applications. It cannot be started directly.

Well, that solves that mystery, but that’s no fun. Let’s see what it links against:

$ otool -L /System/Library/CoreServices/UIKitSystem.app/Contents/MacOS/UIKitSystem
UIKitSystem:
	/System/Library/CoreServices/UIKitSystem.app/Contents/Frameworks/UIKitSystemAppCore.framework
	/System/Library/Frameworks/CoreFoundation.framework
	/System/Library/Frameworks/CoreServices.framework
	/System/Library/Frameworks/Foundation.framework
	/System/Library/Frameworks/QuartzCore.framework
	/System/Library/PrivateFrameworks/AssertionServices.framework
	/System/Library/PrivateFrameworks/BackBoardServices.framework
	/System/Library/PrivateFrameworks/BaseBoard.framework
	/System/Library/PrivateFrameworks/FrontBoardServices.framework
	/System/Library/PrivateFrameworks/Swift/libswift….dylib (etc, etc)
	/System/Library/PrivateFrameworks/UIKitSystemAppServices.framework
	/System/iOSSupport/System/Library/Frameworks/UIKit.framework
	/System/iOSSupport/System/Library/PrivateFrameworks/AccessibilityPlatformTranslation.framework
	/System/iOSSupport/System/Library/PrivateFrameworks/FrontBoard.framework
	/System/iOSSupport/System/Library/PrivateFrameworks/UIKitCore.framework
	/System/iOSSupport/System/Library/PrivateFrameworks/UIKitServices.framework
	/usr/lib/libAccessibility.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib
	/usr/lib/libobjc.A.dylib

It links against FrontBoard.framework! We are definitely looking at the system app here. This is a little different, though, because there’s no “home screen” or other UI we can necessarily associate with it. The key feature of iOSMac is that the user never needs to know they’re using an app that’s “different” from traditional Mac apps built with AppKit — much like the early days of Mac OS X with the Carbon framework that provided the ability for classic Mac OS apps to run on the new, completely different OS. One of the roles of the system app on iOS, watchOS, and tvOS is to be the “host” of the window (“context”) of apps. This allows it to do fun things such as displaying live-updating snapshots of apps in the app switcher, support split-screen on iPad and the gesture-based switcher on iPhone X, and so on. (You’ll see why this is relevant shortly.)

It’s also interesting to observe that it links against libswift. Apple has slowly ramped up its usage of Swift internally since iOS 10 and macOS 10.12, and the promise that Swift’s interface will be standardised with Swift 5 is a sure sign that Apple will continue using Swift.

Finally, this is a launch agent, just as SpringBoard is on iOS. You can find its plist at /System/Library/LaunchAgents/com.apple.uikitsystemapp.plist.

<plist>
<dict>
	<key>Label</key>
	<string>com.apple.uikitsystemapp</string>
	<key>MachServices</key>
	<dict>
		<key>PurpleSystemAppPort</key>
		<dict>
			<key>ResetAtClose</key>
			<true/>
		</dict>
		<key>com.apple.frontboard.systemappservices</key>
		<true/>
		<key>com.apple.frontboard.workspace</key>
		<true/>
		<key>com.apple.uikitsystemapp.services</key>
		<true/>
		<key>com.apple.UIKit.KeyboardManagement.hosted</key>
		<true/>
		<key>com.apple.UIKit.statusbarserver</key>
		<true/>
	</dict>
	<key>ProgramArguments</key>
	<array>
		<string>/System/Library/CoreServices/UIKitSystem.app/Contents/MacOS/UIKitSystem</string>
		<string>system_app_start</string>
	</array>
</dict>
</plist>

(Some bits I’m not covering removed for brevity.)

Another correlation we can find here is that each of these except for com.apple.uikitsystemapp.services can be found in the launch daemon plist for SpringBoard. Here is a shortened version of the plist from on iOS 10.3:

<plist>
<dict>
	<key>Label</key>
	<string>com.apple.SpringBoard</string>
	<key>MachServices</key>
	<dict>
		<key>PurpleSystemAppPort</key>
		<dict>
			<key>ResetAtClose</key>
			<true/>
		</dict>
		…
		<key>com.apple.UIKit.KeyboardManagement.hosted</key>
		<true/>
		<key>com.apple.UIKit.statusbarserver</key>
		<true/>
		…
		<key>com.apple.frontboard.systemappservices</key>
		<true/>
		<key>com.apple.frontboard.workspace</key>
		<true/>
		…
	</dict>
	<key>KeepAlive</key>
	<true/>
	<key>RunAtLoad</key>
	<true/>
</dict>
</plist>

One difference we can see is that SpringBoard has RunAtLoad and KeepAlive enabled. While iOS truly needs SpringBoard for your iPhone to be useful at all, UIKitSystem only needs to be launched and stay running for at least the duration of an iOSMac app. Hence, it won’t start till an iOSMac app is launched, and may be terminated in low memory conditions as long as no iOSMac apps have been used for a while.

UIKitHostApp

Since iOSMac apps intend to not seem obviously different from an AppKit app, forcing them to live in a separate “world” with its own home screen and app switching functionality — like the iOS Simulator — would be a dealbreaker. Indeed, at the WWDC keynote the four iOSMac apps were demoed and there was no indication that they were anything other than typical AppKit apps until iOSMac was announced later in the keynote.

How Apple has tackled this is intriguing — displaying of windows in fact seems to not be handled by the app at all, rather being offloaded to UIKitHostApp. In fact, launching an iOSMac app from the command line reveals that the app is actually UIKitHostApp disguising itself as the app you launched:

When launching the app through LaunchServices (Finder, Dock, Launchpad, etc.), it correctly gets named “Voice Memos” in the Dock.

Peeking at UIKitHostApp’s entitlements — a plist embedded in most modern Mach-O binaries, used by Apple to control the use of risky features — gives it away:

$ ldid -e /System/Library/PrivateFrameworks/UIKitHostAppServices.framework/Versions/A/XPCServices/UIKitHostApp.xpc/Contents/MacOS/UIKitHostApp
<plist>
<dict>
	<key>applicationservices.allowedtowrapanotherprocess</key>
	<true/>
	<key>com.apple.authkit.client.private</key>
	<true/>
	<key>com.apple.private.defaults-impersonate</key>
	<true/>
	<key>com.apple.uikitsystemapp.bundlehost</key>
	<true/>
	<key>com.apple.uikitsystemapp.client</key>
	<true/>
</dict>
</plist>

applicationservices.allowedtowrapanotherprocess likely allows UIKitHostApp to take the role of displaying windows on behalf of other apps.

As an interesting test, you can confirm this by sending pause and resume signals to the Voice Memos and UIKitHostApp processes:

When killall -STOP VoiceMemos is executed, the app interface becomes unresponsive. This is expected as events (clicks, typing, etc.) must be delivered to the app — the app is what’s in control of how its interface works. Notice that the title bar reacts to the window coming into focus, and the traffic lights also react, just like normal. Now resume Voice Memos with killall -CONT VoiceMemos, and pause UIKitHostApp with killall -STOP UIKitHostApp. Unfortunately the QuickTime screen recorder doesn’t catch the wait cursor (the beachball), but in this situation the app is instantly unresponsive to all events, including in the title bar area. macOS notices that the app didn’t respond to the “come into focus” event and displays the wait cursor. This subtle difference makes it pretty obvious what’s going on — the UI is rendered by the Voice Memos app, and displayed by UIKitHostApp.

One interesting difference from AppKit apps is that iOSMac apps simply do not display at all when GPU acceleration isn’t present, such as when running macOS in VMware or VirtualBox, as noticed by @zhuowei:

I spent 7 hours setting up a macOS virtual machine to run the new Stocks app. It turns out it won't run in a virtual machine. Sigh.

— Zhuowei Zhang (@zhuowei) June 5, 2018

Ok, but how can I make an iOSMac app?

Early on, the community realised making an iOSMac app of their own isn’t as straightforward as they wished. Looking at the entitlements of the Voice Memos binary, we see a few interesting private entitlements:

$ ldid -e /Applications/VoiceMemos.app/Contents/MacOS/VoiceMemos
<plist>
<dict>
	<key>com.apple.QuartzCore.secure-mode</key>
	<true/>
	<key>com.apple.UIKit.vends-view-services</key>
	<true/>
	<key>com.apple.private.iosmac</key>
	<true/>
	<key>com.apple.private.mobileinstall.xpc-services-enabled</key>
	<true/>
	<key>com.apple.private.security.container-required</key>
	<true/>
	<key>com.apple.private.security.system-application</key>
	<true/>
	<key>com.apple.private.tcc.allow</key>
	<array>
		<string>kTCCServiceMicrophone</string>
	</array>
	<key>platform-application</key>
	<true/>
</dict>
</plist>

(Again, cut down for brevity.)

The one that sticks out is com.apple.private.iosmac. It’s not possible to execute a binary using this entitlement, even using a certificate obtained via a paid Apple developer account, unless the binary is signed by Apple or distributed through the App Store (where Apple carefully scrutinizes app entitlements). The iOSMac system indeed checks for this and won’t let you get by without it:

man, they really don't want to make this easy. i'm trying to find some way to inject code into UIKitHostApp to remove this entitlement check: pic.twitter.com/QXx6zTolFc

— Adam Demasi (@hbkirb) June 5, 2018

@zhuowei, @biscuitehh, @HamzaSood have all found different ways to work around this, each involving some sort of workaround to sidestep the restrictions globally (regardless of the entitlement and regardless of the app being used — so a fair security risk).

By disabling System Integrity Protection, setting the boot argument amfi_get_out_of_my_way=0x1 (AMFI is AppleMobileFileIntegrity), and rebooting the Mac, I was able to get as far as seeing the initial interface of my iOS terminal app NewTerm, unfortunately with an error indicating forking failed due to lack of permission:

using the amfi_get_out_of_my_way=0x1 boot arg got me as far as the initial NewTerm UI!! unfortunately it seems the iosmac entitlement also enables the sandbox, blocking it from forking in order to launch the shell, and (worse!) it causes a window server freeze immediately after pic.twitter.com/x5iqd5lKvO

— Adam Demasi (@hbkirb) June 7, 2018

Fortunately, explicitly setting the “App Sandbox” entitlement to false allowed it to successfully fork and execute my shell:

it works!!!

…well. ok, it hangs the window server. but simply setting the sandbox entitlement to false worked to let me fork and get a working terminal under iOSMac! pic.twitter.com/rwg5dIO7RB

— Adam Demasi (@hbkirb) June 8, 2018

(For comparison, see the NewTerm homepage for how the app looks on iOS.)

I’ve poked around trying different ideas to make NewTerm work, and none have made a difference (in fact I occasionally made it worse, causing a window server crash before the window even shows up…), so I’m going to leave it here for now and see if any of these issues improve in the coming macOS Mojave betas.

You can see my kinda-sorta working demo of NewTerm running under iOSMac at github.com/kirb/iOSMac-Demo.

iOSMac is definitely not ready for primetime — that should have been obvious when Apple indicated this is only “phase one”. It is very possible for an iOSMac app to crash the window server, causing all of your running apps to be terminated and kicking you back to the login window. Sometimes you get even more unlucky and the window server hangs, forcing you to either use another device to SSH into your Mac and killall UIKitSystem, or simply hold down the power button. Such is beta life — I’d be certain this will be heavily improved in the coming betas, because these issues could certainly arise while using Apple’s own iOSMac apps. There are many frameworks missing; it’s rather clear that Apple has only included frameworks used by the four apps, plus a few extras whose API/ABI map one-to-one with macOS frameworks. Still, a great demo for now, fascinating how closely related it is to true iOS, and it’s amazing that its release to developers is only a year from now!

Pete Steinberger did a talk at try! Swift 2018 covering a lot of what I discovered here, along with some updated details as of the Golden Master release of Mojave. Spoiler: He manages to get his PDF Viewer app to work on macOS almost fully. Give it a watch!

macOS’s amazing Time Machine feature can make backups either to a local drive (whether connected externally or internally), or to a network share. Unfortunately, the way Apple has implemented it, not just any network share can be used — the server has to mark it as a Time Machine-capable share.

The Samba project recently merged the support necessary for macOS to “see” an SMB shared folder as capable of being a network Time Machine share. That’s the good news. The bad news is that your favorite Linux distro probably doesn’t have this version (4.8.0) and likely won’t until the distro’s next major release.

Until that time, you’ll need to build Samba from source. Skip past this section if your distro already comes with Samba 4.8.0 or newer. Ubuntu 18.10 and Debian Buster do have 4.8.x.

Start by downloading the latest version of the Samba source.

mkdir ~/build
cd ~/build
wget --content-disposition https://github.com/samba-team/samba/archive/samba-4.9.2.tar.gz
tar -xf samba-samba-*.tar.gz
cd samba-samba-*/

Before we build, install the build dependencies, and (if needed) uninstall the currently installed copy of Samba. This, of course, varies based on the package manager your distro uses. Here is how it would be done with Debian or Ubuntu:

sudo apt remove samba
sudo apt autoremove  # (clear out the now-unused Samba dependencies)
sudo apt install build-essential avahi-daemon tracker libtracker-sparql-1.0-dev
sudo apt build-dep samba

The Samba wiki has instructions for other distros.

Now we can build and install:

DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH)

./configure \
    --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc \
    --localstatedir=/var --libdir=/usr/lib/$DEB_HOST_MULTIARCH \
    --with-privatedir=/var/lib/samba/private \
    --with-smbpasswd-file=/etc/samba/smbpasswd \
    --enable-fhs --enable-spotlight --with-systemd

make -j$(nproc)
sudo make install

sudo cp bin/default/packaging/systemd/*.service /lib/systemd/system
sudo systemctl daemon-reload
sudo systemctl enable {nmb,smb,winbind}.service
sudo systemctl start {nmb,smb,winbind}.service

Again, this is pretty specific to Debian/Ubuntu. $DEB_HOST_MULTIARCH is, for instance, x86_64-linux-gnu on a 64-bit PC, or aarch64-linux-gnu on a Raspberry Pi 3. If you’re not on a systemd-based distro, remove --with-systemd, and replace the last few systemd-related lines with calls to the init scripts:

for i in nmb smb winbind; do sudo /etc/init.d/$i start; done

Newer distros (at least the case with Ubuntu 17.10) may have libtracker-sparql version 2 rather than 1. It doesn’t seem Samba’s Spotlight feature supports version 2 yet, so just remove --enable-spotlight in this case.

Hopefully, you’ll now have your own copy of Samba built and running. Disconnect and reconnect to your shares on your Mac to double-check that it’s working fine.

You’ll need to do some additional work to set up Tracker, the search backend. (I really wish this part were much easier.)

A Time Machine share is for the most part no different from any other share. The five parts required to enable Time Machine support are:

• The fruit module, which provides Apple’s proprietary extensions to SMB,
• The catia module, which maps the encoding of filenames that macOS expects to a form most native Linux filesystems can support,
• The streams_xattr module, which maps macOS’s extended attributes to a separate AppleDouble file,
• Optionally, the spotlight module, which builds a Spotlight search index on the server to speed up discovery of files in the backup, and
• Avahi, a multicast (aka Bonjour) daemon for Linux, used here to allow Macs on the network to discover the Time Machine share.

Importantly, Avahi support is intentionally disabled in Debian and Ubuntu’s builds of Samba, and Spotlight support is not enabled. These are both features you can live without; you can manually configure Avahi to advertise the services, and a Spotlight index is recommended but entirely optional. Since we’re building from source here, we’ll just pick the easier option of having them both enabled for us.

Edit /etc/samba/smb.conf (this assumes you already have one or understand how to create one), and fill in the details for your Time Machine share:

[timemachine]
    comment = Time Machine
    path = /data/backup/timemachine
    browseable = yes
    writeable = yes
    create mask = 0600
    directory mask = 0700
    spotlight = yes
    vfs objects = catia fruit streams_xattr
    fruit:aapl = yes
    fruit:time machine = yes

What this does:

• Defines a share called timemachine,
• Sets its location on the server to /data/backup/timemachine (you should change this to suit your setup),
• Enables authorised users to read and write to it,
• Sets tight file and directory permissions so only the original owner can access their own files,
• Enables Spotlight indexing on the share,
• Enables the VFS modules that were discussed above, and
• Enables the Apple extensions, and instructs fruit to set the Time Machine flag on the share.

Save this, and create the directory you specified. After restarting smbd as per usual (sudo systemctl smb restart or sudo /etc/init.d/smb restart), open Finder on a Mac. As long as no firewall is blocking it, in the Shared section of the sidebar, you’ll see your server’s hostname.

This is one part of the Avahi functionality — any device that supports multicast discovery (mostly Macs, but other devices can too) will now discover the server while performing a search for SMB services on the network. The second part is the ability for the Time Machine preferences pane to list it as an available destination for backing up to.

In the Time Machine pane of System Preferences, click “Select Disk…”. The share will appear. Select it, enter your password, and it’ll instantly begin making an initial backup to it.

Perfect!

If the share doesn’t appear due to a firewall blocking multicast packets, or because the server is external to your network, you can force it to be used anyway by running the following in Terminal on the Mac:

tmutil setdestination 'smb://kirb:mypassw0rd@myserver/timemachine'

This will force Time Machine to connect to the specified server hostname or IP, using the specified username (kirb) and password (mypassw0rd), and back up to the specified share. The share still needs to have the Apple extensions enabled.

Using this method, you could store your Time Machine backup offsite on a server located in a datacenter or colocation service. (Personally, I prefer this job to be handled by Backblaze¹, alongside Time Machine for local backup.)

I’ve been running this for a few days and so far the only trouble I’ve had is that Time Machine will compare the size of the backup to the available space reported by the server, but as you can see in the above screenshot, ZFS indicates far less than the actual capacity I have available (4 TB). The only workaround I’ve found is to make a first backup with some larger directories excluded, which will make ZFS eventually indicate more space is available. Then, remove those exclusions, and on the next backup it will work fine.

To make the most of your available space, you might consider enabling compression at the filesystem level. ZFS supports this. I created my backup volume like so:

sudo zfs create meteor/backup -o mountpoint=/data/backup -o compression=on -o quota=2T

This mounts the volume at /data/backup, enables compression, and ensures this volume can’t grow larger than 2 TB (so that the other 2 TB remains available for my own storage). This, of course, expects your server to have a reasonably fast CPU with a reasonable number of cores so your backups and restores don’t become extremely slow while the server produces large amounts of heat. Any Core i3/i5/i7 server is probably perfectly fine, but decide for yourself what you’re comfortable with.

By the way, if you have a Mac running macOS High Sierra or newer that you use as a server, you can now create a Time Machine share directly from the Sharing preferences pane, rather than having to buy and install macOS Server:

ProTip®: you can make any mac a time machine server without buying macOS server. create a backups share, then right click → advanced options pic.twitter.com/W2SKcjKQrt

— Adam Demasi (@hbkirb) October 26, 2017