LateNite Films:
Transfer Toolbox allows you to convert Final Cut Pro (for Mac) Libraries into Final Cut Pro (for iPad) Projects!
LateNite Films:
Apple approved Transfer Toolbox v1.0.0 on 26th May 2023 at 08:57, but then claimed “Developer Removed from Sale” at 10:06 (which we didn’t).
[…]
As far as we can determine, Transfer Toolbox doesn’t actually break this guideline.
We took advantage of the App Review Board, and their Unfair Treatment appeal option, however, it was determined that we’re still breaking Guideline 2.5.1.
[…]
The rejection of Transfer Toolbox appears to hinge on potential issues that Final Cut Pro for iPad users might encounter when importing libraries from the Mac version of the software. However, if such a situation arises, it would likely be an issue with Final Cut Pro for iPad rather than a fault of Transfer Toolbox. Our app is a simple tool that performs no more than what a user can manually do themselves. It merely moves a folder into another folder, using only public APIs and without any use of undocumented or private APIs.
The guidelines don’t matter if Apple doesn’t want your app to exist.
Previously:
Update (2023-06-27): Anders Borum:
They do this on iOS as well where it is much worse because there is no alternative to being in the iOS App Store.
App Store Rejection Final Cut Pro X Mac Mac App Mac App Store macOS 13 Ventura Transfer Toolbox
Keaton Brandt (Reddit):
To the old-school Mac community, installing some shitty cross-platform Java app on their pristine Macbook was an admission of defeat. Even web apps were avoided whenever possible. They saw the use of such software as a tacit acknowledgement that the PC and its “ugly but effective” mindset had won. The point of paying double the price of a PC was to buy an elevated computing experience, and that had to extend to every third-party app on the system.
[…]
Many of the great Mac apps are forgotten or abandoned now. MacHeist is a grotesquely reanimated corpse. The golden age is over. The question isn’t whether Sketch will succeed because it’s a beautiful Mac app, but rather whether it can succeed in spite of that.
[…]
We’ve moved on from the era of beautiful Mac software to the era of web-based apps, for better and for worse. There’s no one simple reason for this evolution, but it’s interesting to think through some of the factors.
[…]
As of 2023 Mac sales are reaching all-time highs, but Apple’s interest in the Mac as a platform is lackluster at best. This year’s macOS Sonoma release adds some cool new features, but also continues the larger trend of making macOS more like iOS and iPadOS. Apple’s big new ideas for Mac software: iOS widgets and progressive web apps.
Apple is still very interested in selling Macs — precision-milled aluminum computers with custom-designed chips and “XDR” screens. But they no longer care much about The Mac: The operating system, the software platform, its design sensibilities, its unique features, its vibes.
It seems like Apple’s greatest passion with the Mac for the last decade-plus has been security and privacy. If the first decade of Mac OS X was about expanding capabilities and designs, with Apple as a cheerleader for all apps, the second was about which features and business models you’re not allowed to use and trying to minimize the regressions and friction that the system imposes in the name of protecting users.
Via Steve Harris:
Closer to home, I also agree that these days Apple’s bundled apps are going places previously only third-party devs would dare tread, and that worries me a little. Indeed, apps like Reminders and Notes in particular are very capable now, and if you’re an indie starting out, wanting to do something in that area, those apps will set the baseline, which is a lot. Additional to that, it’s not easy getting things out of those apps (particularly Notes, with all its new features), and so users will remain locked in.
However, the biggest pain point for any developer is making an app cross-platform, potentially on macOS, Windows, iOS, and Android, with perhaps some kind of web version too. It takes a lot of time and effort to make native apps, sometimes an equal amount for each platform, because savings on the things they share tends to get devoured by gnarly platform-specific considerations.
Apple’s answers to that are Apple-only solutions that won’t serve Android or Windows — porting iPad apps with Mac Catalyst, or adopting SwiftUI — and neither are anywhere close to zero effort to deploy across platforms, and nor do they provide a truly first-class experience on Mac right now. These technologies would be perfect for indie developers that only want to target Apple’s platforms, except that I know my existing apps’ users wouldn’t accept either, because the apps would turn out less integrated and therefore less powerful.
Core Intuition:
How do we prioritize native platform development while maximizing the ability to deploy to all of Apple’s platforms? They talk about investing time into new platforms and frameworks when the investment will pay off, vs. when the work will be wasted on short-term workaround.
Previously:
Update (2023-06-27): Colin Devroe:
I hate that this resonates so clearly. I’ve heard others mention that “there is no one left inside Apple that knows what a good Mac app is” and I tend to agree. While Notes and Reminders are good apps, the OS they run on (and, subsequently, the design guidelines they must live within) are just not as good as earlier versions of macOS.
I do think things can turn for the better: higher contrast, easier to detect focus, leave behind the aversion to texture and shading, stop hiding UI.
Jeff Johnson:
A good article that I largely agree with.
Steve Harris’s article is also very good and brings up crucial points about how the Mac App Store harmed the platform. I’d also mention how the Mac App Store brought the iOS race to the bottom to some extent.
One more thing: the relentless yearly OS release cycle takes away a lot of time from Mac devs, as well as frequently taking away features, adding new restrictions, changing the whole Mac UI design, and adding new bugs.
1Password Catalyst (Marzipan) Delicious Library Design Figma GarageBand History iMovie Mac Mac App Store macOS 13 Ventura Notes Pixelmator Reminders Sandboxing Sketch SwiftUI
macOS 13 Release Notes (2022):
ATS and ATSUI APIs are fully deprecated. Code using these APIs will fail to compile and link when the deployment target is set to 13. Code targeting earlier versions of macOS will continue to compile, link, and run. macOS 13 is the last release where code depending on ATS or ATSUI will run. All runtime functionality will be removed in next major release of macOS.
Mr. Macintosh:
From the public Sonoma Beta 2 developer documentation👇
Whenever the OS detects the usage of deprecated APIs, the user will be presented a dialog stating that the app needs to be updated. When the dialog is dismissed the app will exit.
[…]
Many will say “oh this is beta” and we won’t see this in the public release
Take a look at AltTab’s dev response to this situation👇
I’m just trying to show how most 3rd party app devs may respond.
Apple has been clear that developers need to stop using ATS for a long time, but the alerts themselves are unclear, leaving some developers unsure of what they are referring to. The alert text also implies that the API has not actually been removed yet, which makes it seem like the app is being terminated unnecessarily.
Robert McGovern:
Apparently not all Apple apps have migrated. Someone got that error dialog with Finder
Previously:
Update (2023-06-30): Howard Oakley:
For developers, the vagueness of deprecation makes preparation difficult. I’ve recently spent many days revising my apps that access extended attributes because they relied on deprecated code. While I now feel that’s been worthwhile, my fear that they would stop working in macOS 14 seems to have been completely unfounded, and in retrospect I could have spent that time better. For those using NAS with their Macs, switching from AFP to SMB has brought many problems that those who hung back longer haven’t had to deal with. Was all that time and effort well spent, or will those latecomers profit?
What we all need most is a clear statement of the target date for a feature’s removal, not Apple’s expression of disapproval and vague hand-waving for the future.
[…]
This coincidentally spells out the meaning of full deprecation as a euphemism for removal of support.
[…]
While ATS/ATSUI has surely done this right, it looks like others have jumped on the bandwagon. This is concerning, as Apple needs to be very careful about information that’s displayed to users. It must be specific, and not anticipate removal. Deprecation should normally be a matter between Apple and the developer, not a way of applying pressure to the developer.
Update (2023-07-07): Craig Hockenberry:
Apple needs to go back to the drawing board with these alerts in Sonoma. They are scary, frequent, and not actionable.
It’s like an engine check light going on, taking the car to the mechanic, and having them say “I have no fucking idea what’s wrong”.
What’s worse, is that they only appear once with no apparent way to reset. That makes it impossible for a developer to verify that they fixed the deprecated API usage.
It’s also not a good look that these are happening in System frameworks.
Update (2023-07-10): Craig Hockenberry:
Supposedly, this alert should only appear with the use of ATS or ATSUI (per the release notes), but I find it hard to believe that modern system framework components shown above are using Apple Type Services that were replaced 13 years ago.
[…]
If Apple wants developers to repair these deprecations they need to make major changes:
- Document the behavior, including all of the APIs that trigger it.
- Tell developers if this is something that will only appear in the beta or if it will be a part of the final release.
- Give the customer something to work with when communicating with the developer. A diagnostic code at a minimum.
- Log information about what caused the issue: remember that it may not be the developer’s own code triggering the alert. Plugins, embedded libraries, and external frameworks should be a part of the log. These logs should be available to customers so they can provide them to developers.
- Give developers a way to reset the alerts. Make fixes testable.
Without these changes a Mac user’s future is one with a lot of crashes caused by deprecated code.
Update (2023-07-13): Quentin Carnicelli:
There is no improving this, short of its complete removal.
Since the very first computer platform was created, there has been a power struggle between platform owners and developers. As developers, we wish for a stable platform. It’s understood that it must evolve, but it should do so slowly and predictably. Platform owners, on the other hand, wish to cut out cruft and move forward rapidly. This tension is the normal state of affairs. When managed well, it keeps both parties in check.
This poorly-written alert, instructing users to contact developers for new software, is an unacceptable disturbing of that balance. The last thing users should ever have to worry about is “deprecated APIs”.
Apple already has a powerful method for dealing with deprecated APIs. First, they announce the pending removal of the API to developers. Then, some time later, they remove the APIs. That’s more than enough. It is our fervent hope that Apple simply drops this alert entirely before Sonoma officially ships in the fall.
Guilherme Rambo:
I’m investigating the root cause of this alert. Haven’t gotten to the bottom of it yet, but found a way to reset the alert.
The daemon that’s showing this alert is replayd, it stores a boolean flag for each bundle ID that it’s displayed the alert for in its com.apple.replayd preferences domain, so running defaults delete com.apple.replayd <app_bundle_id> will make the alert pop up again.
Update (2023-07-17): Craig Hockenberry:
And here’s the thing: a crash report from an API that has been removed has A LOT more information than the dumb alert box we’re seeing now.
James Griffin:
This whole thing smells like an effort to chase reducing crash reports as an OKR metric. It can’t crash if you never let it launch!
Rosyna Keller:
With the removal of ATS/ATSUI in macOS 14, I believe all the QuickDraw GX-created things are gone from macOS?
Keeping up that system simultaneously and in sync with CoreText/<thing>, which uses a different model, was resource Intensive.
Core Text Esoteric Preferences Finder Mac macOS 14 Sonoma Programming
