Monthly Archives: September 2026

google, linux, Mac, microsoft, mobile, open source, tech, windows

Googlebook and Googlebook OS arrive – want one?

Google has released Googlebook OS, a replacement for ChromeOS based on Android and previewed in May this year, with the announcement accompanied by new devices from Acer, Asus, Dell HP and Lenovo.

Unlike the Chromebook, Googlebook is not a budget device, with prices starting at $899. The key features are integration with an Android phone, NPUs (neural processing units) for on-device AI, and a hypervisor which provides an isolated Linux environment so that if your Linux OS is compromised or corrupted it will not impact the parent OS.

Although Google states that “you can safely run any Linux developer tools, pull code repositories, or execute autonomous agents,” the reality is not so simple. For example, if you give an agent write access to a GitHub repository and then suffer from a prompt injection attack which infects that repository, the fact that your local Linux environment is isolated will not help you.

Android integration includes “Continue On” which lets you start something on the phone and continue on the laptop. It is not a new idea; Microsoft has a similar Resume feature in Windows though it is not well supported, and Apple has Continuity which works with iPhone and Mac. I’ve used Continuity and it is somewhat useful but I do not often start something on a phone and then continue it on a Mac or PC. The little things are the most useful; having Apple Messages on the Mac is great, as is linking WhatsApp to the desktop.

The difficulty with ChromeOS and now Googlebook is that most Android apps are not ideal for a laptop. One can live in the web browser of course (the original ChromeOS concept), but for me ChromeOS only became attractive when Linux support was introduced.

Unfortunately Google is mainly focused on Linux as a terminal environment. Questions about GUI Linux apps are not fully answered on this Reddit thread, despite the presence of official Google community engagement manager Mishaal Rahman, though a user comments that “GUI apps are supported via the Weston compositor on the latest Android 17 QPR2 Beta.” It is also noted that on ChromeOS, Google backtracked on GPU acceleration for Linux, introducing it but then making it unsupported.

Rahman states that “our vision is to have an open, thriving platform where your apps, files, and workflows flow seamlessly between your phone, external monitors, and dedicated laptops.” In the context, “apps” means Android apps, not Linux apps. That fits with Google’s priorities but it is not so good for the user.

A Googlebook is more secure than a Windows laptop but also locked down other than in the Linux environment. That, and the priority given to Android apps, makes it of little interest for me, though it could be a good choice for someone who needs the large screen of a laptop with the security of a mobile device.

Another used asked “is the Googlebook OS open source?” No official reply as yet; but the answer is likely to be no or not really; Google has notably retreated from open source on Android and even if some variant of Googlebook OS is published, key Android pieces will remain proprietary.

development, professional, software development, tech

Shopify migrates from React Native to native Android and iOS development, citing AI as enabler

Cross-platform development fascinates because of its many nuances. Is it more important than an app works the same on each platform, or that it is optimized for the best experience? Is it more important to share code for better maintainability, or to have separate code bases to avoid compromising? And if one does go the for a cross-platform framework, what is the best choice?

Back in 2020, Shopify decided on React Native as its solution; now it is changed its mind. The company has several mobile apps, including one called Shopify aimed at vendors using its service, and another called Shop aimed at consumers. Shop has a five-star rating and is the 7th most popular shopping app in the iOS App Store.

When it adopted React Native after “years of native mobile development”, the company cited three reasons: acquisition of another company with deep React Native skills (Tictail); harmony with its use of React in its web applications; and the improving performance of the React Native framework. Shopify said that an early rewrite of Shop (formerly called Arrive) had less crashes on iOS than the native version, and shared 95% of code with the Android version.

Now, Shopify engineers say that “advances in coding agents changed the tradeoffs behind maintaining a shared mobile codebase.” The native port of Shop, now using Swift on iOS and Kotlin on Android, has a faster start-up (23% improvement on iOS, 50% on Android), improved stability, and on Android, 37% smaller release build size.

React Native has a new architecture with many improvements; however migration to this has challenges and avoiding this work for its Shop app was another factor in Shopify’s decision – though it had already migrated two other apps. This also means that Shopify’s comparisons are with the old React Native architecture; one might speculate that migrating to the new architecture would also have brought benefits. That said, its report on migrating the other apps (Shopify Mobile and Shopify Point of Sale) was mixed; start-up time slightly improved, but the team discovered performance and stability issues which required work. “These were not to blame on the New Architecture itself. It just revealed cracks in some component designs that were previously invisible,” said Shopify at the time.

The key point of interest is not so much the change of mind but the role of AI coding in the decision. The company said that “Native still means building and maintaining software on two platforms, that cost has not disappeared. What changed is that agents can now do enough of the implementation, translation, testing, and review work that it’s no longer the deciding factor it was in 2020.”

What works for Shopify may not work so well elsewhere. Personally I am nervous about AI coding for several reasons, including cost, security and subtle bugs. As an individual developer, the notion of paying continually for software development is unattractive; that does not apply to a larger company which asks only whether the benefits exceed the costs.

.net, development, Notes from the field, tech

Why does a MAUI app store data under “User Name” on Windows?

I am experimenting with Microsoft’s MAUI (multi-platform app UI) and have encountered various little problems. MAUI apps run on Android, iOS, Windows (WinUI 3) and Mac (Mac Catalyst), though in my case I am mainly interested in Windows and Mac.

The application needs local storage and follows the mobile app principle of isolating this into a directory largely buried from the user’s view. On the Mac this location is:

/Users/[username]/Library/Containers/[ApplicationId]/

where the [username] is my username on the Mac, and the [ApplicationId] is the App Identifier set in the .csproj project configuration file. All this makes sense to me.

On Windows though I was surprised to see that the local storage was at:

c:\Users\[username]\AppData\Local\User Name

Note that “User Name” is the actual name of the directory, not a placeholder for my username.

I thought this must be a bug and even looked at the MAUI source on GitHub. It turns out that it is not a bug; it is the default value for PublisherDisplayName in the platform-specific file Package.appxmanifest. I replaced this with something more suitable and this then became the name of the directory.

The application data is in a subfolder, the name of which is determined by the DisplayName of the application. For a packaged application installed from the Microsoft Store, publishers register this name with Microsoft to avoid conflict with another publisher.