Apple’s Explanation for Removing Old Apps

Does Apple plan to refund the $99 membership to the Developers whose apps are being removed?

- You have to pay $99 for your app to be on Apple's App Stores.
- You have to continue paying $99 each year for your app not be removed/suspended.

=> It seems logical that if Apple removes an app, it should refund the $99.

Hypothetical: Apple removes an app from the App Store. For example, the RSS app I use is likely in danger of removal. A user sometime later runs into an issue or situation for which they go to restore a device from an iCloud backup. For example, a friend had to restore a device recently because a Carrier Settings update failed.

Presumably, an app removed from the App Store would not get restored from an iCloud backup as apps are not included the backups. The solution that comes to mind is including apps on a device but not in the App Store with iCloud backups, akin to how Apple Music uploads songs from a user's library if the songs aren't also in the Apple Music catalog.

@NaOH In that situation, it sounds like your data would effectively be gone because you can only access it from within the app that you can’t restore.

Right. An app and its data are gone. Likewise, a user with an old device repurposed for children would likely be unable to install apps for the device/children because they're not available, having been removed from the store. The point here being it's not just developers taking a hit from this culling of apps, but a segment of users takes a hit as well. I'm not certain what Apple gains from this.

Isn't all this just so that Apple can pretend to run a curated store?

It is arguably a form of curation, just a rather haphazard and capricious one.

A better solution would be for the app not to be available in newer versions of macOS until it had been validated and/or updated by the developer for newer OS. But that would be reasonable and being reasonable is not something Apple is good at when it comes to App Store policies. Their preference is for vague policies that get reinterpreted with every single submission -- putting massive burden on developers to play Apple's game where the rules are constantly changing.

And what about that absurd 30 day (now 90 day) deadline. Really? Can Apple be any more arrogant to think a smaller developer (of which I assume is the target of most of these) can just drop everything to devote the next 1-3 months on getting said app(s) updated to satisfy whatever cryptic criteria Apple demands. Apple clearly knows which apps are on the chopping block and could alert the developer 1 year, 6 months, then 3 months before it is ultimately removed. Again, that would be another attempt to be reasonable.

A better solution would be for the app not to be available in newer versions of macOS until it had been validated and/or updated by the developer for newer OS.

Really? Let's say I have 2 apps I need for work. One now requires the latest OS, but the other doesn't work at all. Who is screwed? Well that would be me.

A better solution would be for Apple to stop breaking things. Each API is a promise of functionality. If one makes a promise, one should keep it.

In the olden days, where RAM and storage was limited, one could understand breaking things. Only so much fits in an 8Kb ROM. Today? I'm not even sure that it is reasonable to break things across major releases (from 10.x to 11.x), let alone across minor releases (from 10.x.y to 10.x.y+1). Perhaps some old library would need to be downloaded, like Rosetta is, when older software is encountered, but that's about it.

Yes, maintaining older libraries is a cost. Guess what, it's a cost you're supposed to sign up for if you write an OS. The only point of an OS is to run software, so if an OS stops running software, it's less valuable than it was, not more valuable. Forcing this cost onto OS makers also has a good side-effect: the OS developer is forced to think its API through to get it right, rather than shipping it "on internet time" and deprecating half of it in the next release.

Apple's solution is instead to pass the cost on to third party developers by claiming they are at fault for not "updating their software to the latest standards" and creating FUD about "security", when in fact it is Apple which is breaking promises. This reversal of reality is quite extraordinary, but I expect it will work out badly for them in the long term.

As a developer, today one is much better off developing web-apps. One gets to upgrade one's backend OS when one wants. Usually the OS is Linux which is quite stable. One doesn't need to worry about piracy: no pay, no play. Software only needs to run on Linux/Chrome & perhaps in Safari, not MacOS, and Windows, and Linux, and iOS, and Android and... One can even sell one's users' data, or force them to watch adverts. Who loses in this scenario? Users. The day the company dies, that app is gone. The day the company raises prices, you either agree or lose your access. When these are apps on which your livelihood depends, you really don't have much of a choice.

Therefore a user friendly solution would be for Apple to ensure software just keeps working. Apple says it respects its users, but if you look at its actions, there's a lot of evidence that that is just so much hot air.

I don't even know if this _is_ about legacy support / deprecating old APIs.

> Yes, maintaining older libraries is a cost. Guess what, it's a cost you're supposed to sign up for if you write an OS. The only point of an OS is to run software, so if an OS stops running software, it's less valuable than it was, not more valuable.

Yeah, but it's not that simple. Microsoft is famously very conservative about supporting legacy software. As a seasoned Windows developer, I assure you that's not all rosy. Instead, they're so busy squaring the circle of supporting old stuff while also doing new stuff that they end up doing neither particularly well. Win32/WinForms looks like it comes straight out 1998; WPF looks like the abandoned it just before release in Vista; UWP never gained much foothold and now there's _yet another_ UI framework in Windows App SDK. None of those four are actually used by many of their first-party apps (such as, y'know, Word), and dogfooding problems aside, the end result is that fresh C# devs ask almost daily "what the heck UI framework _am_ I supposed to use?"; the answer increasingly being: don't bother with anything from MS; just write a web app. Contrast Apple who aggressively deprecate and kill off APIs. Not great if you're a dev, but OTOH: the APIs that haven't been killed off are 1) actually used by Apple themselves (a big exception being the Apple Watch) and 2) more or less kept up-to-date.

"Just keep supporting old things" is only automatically the right choice when you actually pay staff (and motivated staff, at that; see https://mjtsai.com/blog/2022/05/11/problems-with-promotion-oriented-cultures/) to _maintain_ those old things, which can be very unsexy and thankless.

@Sören

Having written Win32 software two decades ago for a very specialized niche, I can assure you the fact it still works is rather useful. Rewriting it would not have been economically feasible for my then employer, even though it is a Fortune 100 company, but the fact it still runs means it can still be used. Whether or not it looks like it came out of 1998 is irrelevant since it dates to... 1997.

As to Apple... well I had the misfortune of looking at Apple's iOS examples recently. I could understand the apps that used good old fashioned Cocoa Touch, but the "SwiftUI" examples were horrible, even in terms of the resulting UI on the phone, putting aside how they didn't actually work in XCode's live preview or how the code was a horrible mess. Honestly, even Haskell UI stuff seemed better to me. I have no idea why they think this is an improvement. And what with Catalyst, SwiftUI, Cocoa, Carbon, I can't say Apple's "UI story" is particularly clear either. So I think this might be a case of "the grass is greener on the other side of the fence".

It's a shame. One reason I moved from Unix to MacOS was that I found Cocoa to be remarkably well engineered, and I liked Objective-C.

As to promotion cultures, you are of course right, and I've been lucky to have avoided such situations. I don't, however, see why maintaining Win32 should be particularly difficult. Give me a 2D buffer to draw on, and draw on it, doesn't really change very much, particularly if you avoid changing styling every couple of years...

> Having written Win32 software two decades ago for a very specialized niche, I can assure you the fact it still works is rather useful.

Absolutely! It's a double-edged sword, is what I'm saying.

On the one hand, I have a client whom I wrote a WinForms app for starting in 2007, with virtually no changes since the early 2010s. They occasionally still have support questions, but by and large just keep using it. Neat.

But OTOH, if I wanted to modernize that app, there's no clear path. With Apple, if you made an AppKit app in 2007, there was always a clear path that you read the Cocoa release notes with every macOS release, and things will not only continue to work, but you keep getting some additions and visual changes for almost-free (for example, Sierra? added tabbed windows). Catalyst and SwiftUI complicate this somewhat as it's no longer clear how motivated Apple is to keep iterating AppKit, but so far, it's had a pretty good run. With Microsoft, it's a very mixed bag. Yes, you can migrate that app to .NET Core, except when you can't (such as because you depend on third-party component vendors who haven't migrated). Yes, you can mix some WPF in using ElementHost to make it more modern, except there's an awful lot of asterisks to that, and virtually zero support, and also, it's entirely unclear what future *that* holds. Yes, you can use "XAML Islands" to mix something even more modern, but now you're inundated with even more asterisks.

> Whether or not it looks like it came out of 1998 is irrelevant since it dates to... 1997.

It's not irrelevant if you want an answer to increasing customer complaints that it "looks dated". To which, yeah, you could rewrite it from scratch, but good luck getting the budget for that, and explaining why the project just got delayed by an entire year.

>I could understand the apps that used good old fashioned Cocoa Touch, but the "SwiftUI" examples were horrible, even in terms of the resulting UI on the phone, putting aside how they didn't actually work in XCode's live preview or how the code was a horrible mess.

I briefly played with SwiftUI a while ago. I have quibbles with having too much of a mix of view and model in the same code file, but beyond that, I thought the tutorial was good, and the Xcode developer experience, performance aside (hard to judge since this Mac is eight years old), was actually quite good. Having multiple different live previews to contrast Light Mode and Dark Mode or a list with zero items vs. a few items vs. so many items you have to scroll, e.g., is a great paradigm that's hard to replicate in WinForms or WPF.

> I have no idea why they think this is an improvement.

It's where the industry is going. Jetpack Compose (Android), Flutter, MAUI's MVU style are all similar. Arguably even React, etc.

> And what with Catalyst, SwiftUI, Cocoa, Carbon, I can't say Apple's "UI story" is particularly clear either.

I think it's clear_er_. There was a period where Carbon seemed to be an additional choice for new apps, but that period was frankly just a handful of years.

>So I think this might be a case of "the grass is greener on the other side of the fence".

Well, some folks in my team do mobile development, and they're hardly happy with Xcode or the App Store. So, I'm certainly not saying Apple's DX is flawless.

>As to promotion cultures, you are of course right, and I've been lucky to have avoided such situations. I don't, however, see why maintaining Win32 should be particularly difficult. Give me a 2D buffer to draw on, and draw on it, doesn't really change very much

Well, to pick up that example, here's one reason: high-dpi. The past ~10 years of Microsoft trying to retrofit adequate high-dpi support for Win32/WinForms (I'm lumping the two together because, really, WinForms is just a thin wrapper) have been painful, and to this day, you can easily find major glitches (including cases where a dialog is outright unusable in >100% because its controls are clipped) in some of Microsoft's own apps.

To be fair to SwiftUI, I wasn't looking at the SwiftUI examples, but at some of the LIDAR examples which (annoyingly to me) used SwiftUI.

However, just because "the industry is going that way" doesn't mean that's the right way to go... "The industry" makes all sorts of weird decisions that aren't particularly based on sound engineering principles.

So what I'd like to know is what exactly are the benefits that SwiftUI provides, and what are the trade-offs it makes, versus AppKit?

For instance, AppKit's separation of code from UI design/layout seems sound (separating concerns). SwiftUI reverses that decision. Using a GUI tool (Interface Builder) to do GUI things seems a good idea too. So perhaps diffing 2 code-bases is better with SwiftUI, but millions of developers having to learn a whole new UI framework, with its own bugs and gotchas, seems like a definitive negative.

If all we care about is better diffs, we could have upgraded Interface Builder to output a GUI tree that looks like SwiftUI. But doing that could have been done without the churn of inventing a completely new incompatible way of doing things.

Imagine someone decided one day to move every car's steering wheel to the other side. Americans would drive on the left side of the road, and Brits on the right. A reasonable question to ask would be "why?" I'm not seeing that question asked or answered with respect to SwiftUI, which makes me think it might also be the result of a promotion culture... Swift also makes me wonder the same thing. Sure it's a little nicer, but is it so much nicer that it was worth the costs of replacing Objective-C... I'm unconvinced. For anything requiring speed (video processing) I had to drop down to C.

> However, just because "the industry is going that way" doesn't mean that's the right way to go... "The industry" makes all sorts of weird decisions that aren't particularly based on sound engineering principles.

Certainly.

I don't think "sound engineering principles" are really a thing for software development, though. We're all still throwing things at the wall and figuring them out. There is no "right way" to do a UI. I would generally argue that MV*-style paradigms are better than "RAD" a.k.a. put everything in one file and hope it's no issue, but even that can be argued against when a quick prototype is called for.

>So what I'd like to know is what exactly are the benefits that SwiftUI provides, and what are the trade-offs it makes, versus AppKit?

As a rule of thumb, I'd say AppKit is the better choice for big, mature apps. However, since you can mix and match, doing certain layouts in SwiftUI instead can be of use. As an added bonus, it makes sharing code with mobile platforms easier.

> For instance, AppKit's separation of code from UI design/layout seems sound (separating concerns). SwiftUI reverses that decision.

Yeah, that's one of my concerns.

> millions of developers having to learn a whole new UI framework, with its own bugs and gotchas, seems like a definitive negative

With Swift, there came a point where telling aspiring iOS developers "our language is Objective-C" was no longer tenable, because it was too different from C#, Java, Kotlin, C++, and others.

With SwiftUI, I'm guessing part of the point is that the same holds true here. For example, it's nice that Apple came up with an ASCII-based autolayout language, but I've never heard of anyone who loves the way pre-autolayout (springs and struts) or autolayout work. In contrast, Swift's layout abilities are similar to WPF, CSS flex layout, etc.

>If all we care about is better diffs, we could have upgraded Interface Builder to output a GUI tree that looks like SwiftUI.

Yep.

But look at web development, for example. WYSIWYG editors were a big thing in the 90s (Claris HomePage, Microsoft FrontPage, Adobe PageMill, GoLive, whathaveyou). Then they disappeared or rather decided to appeal only to those filling a CMS. "Real" web development instead isn't WYSIWYG at all any more; it has live previews, but you type code.

It's simply easier to parse explicitly-written code and preview that than to generate code (or, in IB's case, serialize an object tree) and infer what the developer wanted. Sounds simple enough until you get to things like coordinates.

>But doing that could have been done without the churn of inventing a completely new incompatible way of doing things.

But AppKit is three and a half decades old, really (IB is from '88). And UIKit was more of a refresh of that. It's not like Apple is reinventing things over and over; instead, they're creating a high-level framework that may one day become the new premier framework, and they're doing it much, much later.

> Imagine someone decided one day to move every car's steering wheel to the other side. Americans would drive on the left side of the road, and Brits on the right. A reasonable question to ask would be "why?" I'm not seeing that question asked or answered with respect to SwiftUI

I don't think that's the case here.

> which makes me think it might also be the result of a promotion culture

Maybe.

But I disagree. I think Apple is facing a serious threat that developers are increasingly disinclined to bother with their frameworks at all, and if they do something that's more comparable to competitors, that'll make it more likely you can convince a boss to do a platform-specific app.

> Swift also makes me wonder the same thing. Sure it's a little nicer, but is it so much nicer that it was worth the costs of replacing Objective-C.

I think Swift is sometimes a case of programming language CS alumni being too much in love with their functional language theories. I also worry that Apple has tried too hard to cater both to the low (frameworks) and high levels (GUI apps). We've also lost some of ObjC's dynamism. But overall, I think it's the better forward-thinking choice.

>For anything requiring speed (video processing) I had to drop down to C.

I think that'll increasingly be unnecessary.