alwillis

> I equate it to partnering with AT&T on the first iPhone. Very inconsistent with Apple’s preference of owning the entire stack

They went to Verizon first but were turned down. Apple needed distribution, which meant partnering with an established carrier.

Regarding "owning the entire stack" didn't make any sense in 2007, especially for a company that was new to the cell phone business.

Three years later, the first iPhone with Apple's silicon was the iPhone 4 with the A4 processor.

> but Apple renting its AI from Alphabet (Gemini with Siri) might be a long term risk, since they're building on someone else's platform.

Apple isn't renting; they distilled Gemini to create their own model for "broad world knowledge". Some of this runs on Google's infrastructure because Apple didn't have enough compute.

All of the personal context stuff is Apple's Foundation Models.

> Only Apple can properly replace these screens and pair the parts

Not true. Apple has a self-service repair program for most of its products, including the iPad mini.

All the repair manuals are available online and you can buy official Apple parts. [1] They'll even sell or rent the tools you will need.

[1]: https://selfservicerepair.com/en-US/home

> I suspect they are going to drip feed it through their products as a cheap spec bump (vs adding extra RAM or storage).

The iPhone sells way more units than the iPad, so it makes sense that it's not a feature for the iPad mini yet.

It's a little dated, but you'll get the idea:

https://nerdy.dev/cascading-secret-sauce

> There is very much a situation where people in frontier labs have access to exceptional capabilities that are being kept from the rest of us, and they're using it to strip-mine technical and scientific problems.

If these capabilities were available to the public, someone somewhere would make a biological weapon or create a virus we've never seen before that could kill many millions of people.

Stanford researchers have demonstrated it’s possible [1].

[1]: "AI creates 16 new viruses from scratch, showing promise for drug resistance and drawing warnings about potential for misuse" - https://www.cnn.com/2026/08/06/health/ai-viruses-bacteriopha...

From my experience, passkeys work great in the Apple ecosystem. Adding a passkey for a new site on my Mac results in that passkey syncing automatically on my iPhone and iPad via iCloud.

"But what if I lose all of my Apple devices in a freak boating accident?" people often ask or something like it. Apple has a procedure for this [1].

You can contact your "recovery contact" (a trusted friend or family member) that can help authenticate you to regain access to your account, especially if you're locked out or forgot your password.

On a new device, you login to your Apple account, make sure iCloud Keychain is enabled, and all of your credentials, including your passkeys, sync to your device.

I get it—not everyone wants or uses iCloud. Apparently, you can use 3rd party password managers like 1Password, Bitwarden, etc. to backup and recover your passkeys to use elsewhere.

Here's a video of an export from 1Password to the Passwords app on an iPhone [2].

[1]: https://support.apple.com/guide/iphone/passwords-devices-iph...

[2]: https://youtube.com/shorts/gJ8BzT73JzY?si=zSY8vp_v297IfCro

> But you can’t simply switch to Android without recreating every single passkey. Sounds like vendor lock-in to me

Not so fast. Migrating passkeys from iOS to Android is possible now; migrating from Android to iOS is still being worked on.

Ricky Mondello's team at Apple created the Passwords app which brought passkeys to iOS, macOS, etc.

The entire presentation is worth watching if you’re interested in passkeys; the the clip below starts at 24:00 mark where they talk about migrating between platforms.

    Starting with iOS 26.5, you can choose to move passkeys and passwords
    from Apple Passwords to Google Password Manager. However, Android still
    needed "a future update" to receive them. That same update is meant to
    add transfers from Android back to iPhone [1].

The FIDO Alliance created a specification in 2024 called Credential Exchange Format [2] for moving credentials including passkeys, between passkey managers on the same device and across platforms.

In other words, being able to move passkeys between devices and platforms has always been part of the plan.

[1]: https://youtu.be/yVadD-Lfrfk?t=1454

[2]: https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-2026030...

The iPad version of Affinity is being teased on their downloads page: https://www.affinity.studio/download

> Even the biggest sites like Amazon, for example, still use old-school passwords+2FA.

While that is an option, I've been using passkeys on Amazon since 2023.

WebP is limited to 8 bits per pixel, a total of 16,777,216 colors; adding a ICC profile doesn’t change that.

JPEG XL and the other modern formats can support at least 10-bits per pixel, that's over a billion colors.

AVIF supports 12-bits per pixel; JPEG XL [1] can support up to 32-bits per pixel.

[1]: https://en.wikipedia.org/wiki/Comparison_of_graphics_file_fo...

Actually Google engineers in Switzerland started jxl.

I didn't intend to give the impression that Apple was definitely going to use jxl-rs. You're correct; there's been total radio silence from the Safari/WebKit team regarding anything related to Rust.

But it makes so much sense for Apple, Mozilla, and Google to support jxl-rs. Of course, that doesn't mean it's going to happen.

Keeping quiet and then adding jxl-rs to a dot release like Safari 27.4 or something is also a very Apple thing to do.

> Apple refused to support it because they wanted to patent-laden alternative to thrive.

Where do people get this stuff?

Apple finally supported WebP in 2020, 10 years after it was released by Google. Firefox added WebP support in 2019, a year before Safari. Was Mozilla also part of conspiracy to undermine WebP? Come on now.

Seems to me neither Apple or Mozilla wanted to be forced to support a format they had no say in developing. Usually there's a process for coming to consensus on standards.

WebP is ubiquitous now, not the case in 2010 when it was released.

It had advantages compared to JPEG, but not enough at the time to justify changing workflows, etc. WebP initially had better compression than JPEG, but as encoders/decoders improved (MozJPEG, Jpegli, turbo-libjpeg, Guetzli) the lead WebP had mostly went away regarding compression and visual fidelity.

Going forward, WebP is becoming less relevant by the day; it doesn't support wide gamut color; it only supports RGB. It's max pixel count is quite limited compared to AVIF and JPEG XL. Newer formats have use cases beyond the web; WebP doesn't.

There were obviously some internal politics going on—Google joined the Alliance for Open Media, a consortium of the who's who of the media/tech industry: Apple, Facebook, Microsoft, Amazon, Netflix, Nvidia… the list goes on. They supported AVIF as the next generation image format.

Google apparently wanted to be one of the "cool kids" supporting AVIF. When they removed the JPEG XL code from Chrome, they created the excuse that there was little demand for it, along with some other disingenuous talking points that didn't quite make sense. Ironically the project that ended up becoming JPEG XL was started by Google employees in Switzerland.

Anyway, I’m glad Google is supporting JPEG XL now. I wanted to use JPEG XL files for a project I started a month ago, but it was a non-starter with global usage under 20% at the time.

> Why can't it be shipped as a shared library for the whole system to use?

That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.

> MacOS can take a long time to update with support for new formats.

Apple added JPEG XL support for macOS, iOS, iPadOS, and watchOS in September 2023 [1]; iPhone 17 Pro/Pro Max added support for JPEG XL Lossy and Lossless compression for ProRAW pictures last year [2].

When Apple adopts jxl-rs, Safari, Chrome and Firefox will use the same JPEG XL decoder.

[1]: https://webkit.org/blog/14445/webkit-features-in-safari-17-0...

[2]: "iPhone 17 Pro’s Camera Leap: JPEG‑XL, Cleaner Shots, and Pro Filmmaking Tools" - https://modernengineeringmarvels.com/2025/09/19/iphone-17-pr...

> The M1 MacBook Air did not have a 128 GB storage option.

There was an 128 GB model [1] that was only sold to schools.

[1]: https://everymac.com/systems/apple/macbook-air/specs/macbook...

> Nobody is beating Adobe with "claude create for me a clone of the adobe suite".

They're not trying to "beat Adobe" and they certainly didn't wake up one day and tell Claude to make the entire Adobe suite of products.

However, in the not-too-distant future, it'll be the norm to pay $0 for apps and buy AI tokens when needed. That's what Canva did with Affinity--you pay $0 for Affinity Photo, Designer and Publisher that are just as good and in some cases better than Adobe's apps.

Access to advanced features and AI requires a subscription.

> are you kidding? its all vibe coding

Disagree.

There's a difference between "vibe coding" and incorporating AI into a software development process. Hobbyists vibe code for shits and giggles on the weekends.

These guys incorporated dozens of pre-existing Rust packages into their codebases, made sure the apps ran on macOS, Windows and Linux and in modern web browsers. That’s not vibe coding.

Did they use coding agents to assist them? Of course! No different than teams at Microsoft, Google, Adobe, etc. Re-creating Photoshop, Illustrator, Lightroom, InDesign, etc. from scratch in Rust is a huge undertaking; one that would have been impossible just a couple of years ago.

> These companies are going to start tagging files not made by their software as not being "genuine" and freak out a bunch of IT people, who will then ban these apps.

Yeah, that's not going to happen.

The backlash against Adobe would be intense from users and the industry for attempting to break JPEG's interoperability as an ISO standard.

Let’s not get carried away here; Adobe has competed against hundreds of image editors ever since Photoshop 1.0 was released in 1990 and haven’t messed with the interoperability of their file formats.

Just to be clear, nobody at Adobe is losing sleep over a suite of free apps that are knock-offs of Lightroom, Photoshop, Illustrator, and InDesign, etc. for now.

> Serious publishers don't want a photo editing program in their UI.

That's not how it works; when you're in the Layout Studio, that's your UI and nothing else.

I think the confusion is that some tools appear in the Layout Studio and the Pixel Studio because they make sense in those contexts.

Affinity lets you customize each Studio and the overall UI to your heart's content [1].

[1]: https://www.affinity.studio/help/workspace-about-studios/#cu...

> which was bought by Canva and has already been enshittified

Absolutely not.

Affinity just released an update [1] that delivered features like the Blend Tool that users have wanted for years. Cost: $0.

In addition to MCP support, users can now automate the Affinity suite using JavaScript [2].

[1]: https://www.affinity.studio/help/release-notes/

[2]: https://www.affinity.studio/help/scripting-in-affinity/

> i don't want to have to sign up / log in just to test drive the desktop app?

Nope. I just downloaded and installed PhotoCraft [1] and launched it. No sign-up, dialog boxes, licensing agreement.

The installer for LightCraft [2] isn't ready yet; building it from source took about 5 minutes.

[1]: https://getartcraft.com/apps/photocraft

[2]: https://getartcraft.com/apps/lightcraft

ditto is an option on macOS for copying files and directories [1].

[1]: https://keith.github.io/xcode-man-pages/ditto.1.html

> Darwin is the core Unix-like operating system of macOS

macOS isn't "Unix-like"; it's an Open Group certified UNIX™ [1].

[1]: https://www.opengroup.org/openbrand/register/brand3725.htm