Soured

Once again surprised at how Craig Federighi never comes up in all this. Is he not ultimately in charge of all software? Are not almost all of Apple's problems (aside from legal ones, and even some of those) software related?

Why does he just get to pop up in a pre-recorded video once a year, do something silly, announce some features which may or may not exist yet, and then just fast cut off into the sunset? Well, he then usually does a couple puff piece interviews with the same friendly journalists who ask the same softball, pre-approved questions.

If Tim isn't going to address it, shouldn't it fall to him?

"And, recently, they’ve made it worse by announcing stuff that they know won’t ship in the 0.0 release. This is spun as clever planning to deliver new delights throughout the year. But it seems more like a cope for squeezing more into the major release than they should."

We used to call this vaporware back in the days.

@Bart agree that Craig does not get blamed for a lot of these issues, but I think as I wrote in the linked piece, that it goes further than a single exec.

The annual release cadence is almost entirely driven by the annual iPhone release cadence. Apple believes they need a new iOS with each new iPhone cycle in order to market the newness. Now with services, this inevitably ties all of their other device OS's together, including macOS, on the same release cycle to retain compatibility.

If we want to play blame the execs, from my little knowledge, I don't think Craig would be the main culprit in the deterioration of developer experience.

Every indication is that Phil Schiller is the main culprit behind the App Store's mafia style tactics, obviously supported and backed by Tim Cook. This is in order to continue to keep absolute software control, as well as to extract as much revenue as possible, in order to support their only growing revenue stream, which is 'services'.

They are also doing a very clever magic trick each time they talk about their services. In financial calls and other PR pieces they always talk about services as if it is Apple Music, Apple TV+, iCloud etc. When in fact the reality is that an overwhelming majority of their services income and revenue is actually due to taxing 15-30% from developers on the App Store and getting $20+ billion per/annum by selling their users privacy to Google via the Google Search deal.

All the other Apple One services they like to talk about are all second-tier – when looking at it from a competitive marketshare standpoint – and bring in relatively little revenue or profit in comparison to App Store tax and the Google Search deal.

@Matthew And I wonder if the App Store revenue is still mostly from games.

@Michael if these stats are correct:

https://www.statista.com/statistics/1485088/app-revenue-distribution-by-category-worldwide/

As at mid-2024, Games made up 55% of app revenue worldwide, with Entertainment at 14% and Photo and video at 8%.

This is total app revenue, not just the Apple App Store app revenue, so it's probably not 100% correct but in the ballpark of accuracy.

Maybe developers, instead of complaining and continuing to develop for Apple hardware, should stop work on Apple kit, and devote themselves to porting their products to Linux. KDE Plasma / Qt. Gnome, these are all workable setups.

As long as developers have users who rely on their software, and they're Mac / iOS only, they're part of the problem preventing Apple's bad software from having any consequence.

@Bart Yes, Federighi has been a disaster of greater proportion than when Jonny Ive was operating without Steve Jobs. But damn, he has nice hair, so I guess no consequences.

Scott Forstall should be back into the company he greatly helped to become successful. And begin tiding up.

>porting their products to Linux

One nice thing about using open source is that you can fix bugs that bother you. In my experience, maintainers are always super grateful if you do.

And if you can't code, you can still set bounties.

Last week I filled a bug report for retracting a WWDC talk (Efficiency awaits: Background tasks in SwiftUI) that presents APIs that are either unfinished or not implemented at all even almost 3 years later.

https://x.com/tomaskafka/status/1907003833546657803

I wasted at least a day on this, finding forum and StackOverflow posts of many others who got burned as well.

And in the end, @eskimo told me to file a bug against the talk: https://developer.apple.com/forums/thread/726443?answerId=823711022&page=1#832295022

I don’t expect anything to happen, but man, the comment section on PHP documentation was a godsend for centralizing these kinds of corrections and real world implementation experiences.

There is no reason to have Macs on a 12-month release schedule or keep it in lock step with iOS because of services. If the backend processes for services are that embedded into the OS THAT is a problem. They could rework the relevant bit to accommodate the new iOS and incorporate that without jacking up the entire codebase. With every iteration Apple makes it tougher to troubleshoot and manage the Mac by locking stuff down in the name of "security". Nuts. I left Windows behind more than 20 years ago because of the black hole that was the registry. Now I need to tweak system bits and deal with the death of kernel extensions, Mail extensions and Safari extensions because dog forbid that anyone might want to do something Apple has decided isn't in their best interests.

@Bart Americans love hair. They can't disrespect a guy with loads of hair. It really is as simple as that.

"If you’re an indie Apple developer, you’re on a treadmill that never slows down.

Apple’s annual OS updates mean a constant stream of changes, and unlike Apple — where teams of engineers handle updates — you’re expected to keep up with everything solo. The annual OS release cycle forces developers to scramble to update their apps, even if nothing is broken.

Apple’s constant API changes and deprecations create an ongoing headache for developers. Swift and SwiftUI continue to evolve so quickly that learning them feels like chasing a moving target, with major shifts that often require rewriting large portions of code.

StoreKit changes made in-app purchases a moving target as well, forcing developers to adapt to new implementations. StoreKit 2 completely changed the API structure, forcing rewrites to systems that had been working for years.

Other examples abound: UIKit and AppKit developers had to rethink entire UI structures when Apple pushed SwiftUI as the future. Core Data, long a staple for managing persistence, has been overshadowed by SwiftData, requiring yet another major shift. The introduction of new concurrency models — first Grand Central Dispatch, then Combine, and now async/await — may mean rewriting asynchronous code multiple times over in just a few years.

For Apple, these changes represent progress. For developers, they represent an endless cycle of busy maintenance work that doesn’t always improve their apps, but is necessary just to keep them running."

Being expected to reimplement entire codebases constantly for a "new API" is absurd. Usually the new API isn't an enhancement at all and just makes things worse and often results in us actually losing API features rather than gaining. "I didn't implement this someone else did years, let's rewrite it in Swift" seems more like Apple's attitude/goal. Throwaway years of polish just to chase a new language is a mistake. Sucks to read that someone with a popular app now recommends against developing on Apple platforms. Apple is doing a great job fucking up dev relations.

Seems like Matthew's feelings on SwiftUI may have changed a bit since last July? https://mjtsai.com/blog/2024/07/29/magic-lasso-redesigned/

Swift / SwiftUI has been a disaster for all parties. AppKit/UIKit still work just fine. I recommend devs not move to SwiftUI. Developer pushback can help Apple realize (faster) that SwiftUI was a mistake. I think some people at Apple already know this but can't say it...

I've recently been working on developing for old 68k Macs. It's been loads of fun! Even with things being so much more archaic than what we're used to today, there's a magic there that's absolutely lost in modern Apple. Modern Apple is nothing like the Apple from 80s and 90s. Modern Apple is basically another Microsoft.

So what I wonder is... how can we get that magic back again? Is there any chance at all for having a computer that's fun, creative and productive like classic Macs were? Or like Macs circa 2010, when Snow Leopard was the latest and greatest, and everything "just worked"?

It feels like the only possible option is jumping to Linux, and while there's certainly freedom to be had there, I've never found it to be that magical. At least in my experience so far, it's lacking vision, coherence, and the human touch. Everything is patchwork, designed in haste by programmers who are only technically minded and not trying to make things that are actually pleasant to interact with. There's tons of bickering about the right way to do things, so nothing ever gets streamlined. It's not like classic Mac OS or Mac OS X at all. At least, not in any of the distros I've tried.

Is our only hope something like an eccentric billionaire deciding to fund a new operating system with these explicit goals, and not caring at all about commercial success?

@ObjC4Life re:

> Seems like Matthew's feelings on SwiftUI may have changed a bit since last July?

I wouldn't say those feelings for that particular technology has changed. What I said back then it still my position:

> Personally I prefer working in SwiftUI now – probably because I no longer need to implement two similar UIs in both UIKit and AppKit.

So in my particular situation, for my particular app, I feel SwiftUI is a good approach. My expertise in AppKit and UIKit wasn't the best, so I did always feel that using those technologies, especially with Storyboards, was incredibly fragile and prone to breakage.

Despite its' problems, I don't feel that way with using SwiftUI. Though I do keep my usage of SwiftUI to some of the less high-level components, which I find are the least polished. I also need to support earlier versions of iOS and macOS so cannot use some of the newer SwiftUI apis for backwards compatibility reasons.

Though saying all of that, both SwiftUI and Swift, are still part of the constant maintenance treadmill that I wrote about.

The Swift 6 language mode is another one of those technical debt items that eventually everyone will have to work through which will bring little real benefit, but lots of extra work, to most normal app developers.

The rumoured OS-wide redesign slated for iOS and macOS, is another dreaded item that will likely have to be supported in one way or another. When these things come around, I do look jealously at cross platform electron apps (that have eschewed native platform conventions completely) and can simply ignore Apple's increasingly erratic UI and language changes.

Thanks for your blog post. You were spot on talking about how Swift/SwiftUI is like chasing a moving target. I've decided not to do it. You talked about how devs are basically in an abusive relationship and I agree.

Apple's hard push on new APIs often has developers scrambling (myself included). People who work inside Apple have their own interests/agendas that don't always align with ours.

Ideally an approaching WWDC should be an exiting time for developers. I *should* get the feeling that Apple is going to introduce all these new features that can integrate into my app that is going to make my life EASIER and better. But instead I get a feeling of dread. What APIs that are important to me are they going to deprecate? What's going to break? What new half-implemented features are they going to try to push on me?

Everyone feels they *need* to move to SwiftUI or else ( Sonos, Overcast etc.)...but that isn't the approach I'm taking. Apple's messaging has a lot to do with these feelings but they so often mislead us.

You talked about GCD vs Combine vs Async Await. Combine came out like 5 years ago (maybe?). But GCD is not deprecated and still works. There was no developer penalty for using GCD and skipping Combine entirely (other than FOMO).

When/if SwiftUI becomes a requirement, I'm moving to a third party cross platform framework.

--

Also thanks for mentioning your issues with DTS.

"First, you’ll be lucky to get a response. Second, if you do get a response, it will probably take multiple back and forths before the responder acknowledges what you can prove is occurring. Then they’ll likely state this is expected behaviour, note that you should have known this – despite their being no known public human record of this ‘known’ behaviour on the internet – and close the ticket as completed."

In the past DTS was very helpful to me but recently I've been treated this way. The last couple tickets I filed were ignored completely and I was told to make a post on the developer forums instead. My post was ignored. Do they even do DTS anymore?

@ObjC4Life I am still getting prompt and helpful responses from DTS, but most of the issues end up being bugs or known limitations with no workaround.