Kirk McElhearn:
Screen Time was also added to macOS Catalina, with the same features. However, it doesn’t seem to work correctly. Rather than showing which apps are frontmost when you work, it shows how long apps are open[…]
I keep a number of apps open all the time: Mail, Messages, Fantastical, Omni Focus, Music, and a few others. So counting them as actual “screen time” makes no sense.
In the above example, all these apps were open all day – obviously, the Finder is always “open” – so the data is essentially useless.
[…]
Screen Time also records “Pickups.” While this makes sense for an iOS device – how many times you picked up your iPhone and woke it up – it really makes little sense on the Mac. A pickup on the Mac is the number of times you woke the device from sleep, or restarted it.
Mac remains a product in our lineup. But good news for all the prior art that remains un-Sherlocked.
Update (2019-10-21): John Gruber (tweet):
I can’t see the point of this feature on the Mac other than as a parental control. It seems like Apple just copied the design of iOS’s Screen Time without considering any of the many ways that the Mac is different from iOS.
John Voorhees:
If my Mac’s screen is unlocked for five hours, that means every one of those apps will log five hours of use, which isn’t very helpful if I was writing for three hours, messaging for 30 minutes, and away from my desk with my Mac awake for an hour and a half. I’d prefer if Screen Time on the Mac recorded only the time spent in the app that has the focus.
[…]
That said, there is still utility in having Screen Time built into Catalina. The app works as it does on iOS. Parents can set up limits from a Mac or iOS device, and because the feature works across OSes now, limits can be set for combined usage across all devices.
Bug Mac macOS 10.15 Catalina Parental Controls Screen Time Time Tracking
Howard Oakley:
If you have macOS or other Apple installers, chances are that they’ll be signed, or use as an intermediate certificate authority, by a certificate which expires very shortly. If you were to try installing that package, macOS will report that it’s damaged, and can’t be used. The installers affected can be very recent: I’ve checked an Installer package for the Mojave 10.14.6 Supplemental Update 2, which shipped on 23 September, just a month from the date of expiration, and both its intermediate and user certificates expire on 24 October 2019.
[…]
This is unfortunate timing, as it’s when those migrating to Catalina are likely to be downloading Mojave installers to give them a safe way back if necessary, or to use in a VM provided by Parallels Desktop or VMWare, for instance. In a week or two you could discover that those installers can no longer run because of this expiration. The only real solution is to wait until after 24 October, then download all important Apple installers, which should have new certificates.
Previously:
Update (2019-10-31): Howard Oakley:
As usual, Apple isn’t saying anything, not to users or developers. Its most meaningful communication about this inexcusable failure of support were the 404 errors from download pages. There’s no explanation, no apology, no timescale, no support. Yet again, it seems to hope that if it pretends nothing has happened, we’ll all forget about it. Just like Apple clearly did until someone’s Calendar notified them that crucial certificates expired in a few days time.
Rich Trouton:
As a follow-up to last week’s expiration of the certificate used to sign previously-released macOS installers, Apple has released re-signed macOS installers with the new certificate which is good until April 2029.
Update (2019-11-01): There are reports that this same issue is responsible for HomePods getting bricked.
Update (2019-11-05): Felix Schwarz:
Following issues with expired #macOS installers, Apple now provides direct download (!) copies of updated installers for macOS 10.10 - 10.12. For macOS 10.13 - 10.15, Apple provides App Store links.
See also: TidBITS.
HomePod Installer Mac macOS 10.15 Catalina
Mattt Thompson:
It’s become a truism among iOS and macOS developers that Apple’s documentation is often incomplete or missing altogether.
But to what extent is this actually the case? With a bit of web scraping, I was able to come up with some numbers:
nooverviewavailable.com
It’s the new “Description forthcoming.”
You have to look beyond the colors, and even the numbers. For example, HealthKit gets 100% for documenting 7/7 symbols. But if you click through this seems to be just a bunch of error symbols. There are actually 55 header files for HealthKit, each containing many symbols. In other words, the denominator is the number of symbols that are admitted to be undocumented, rather than the actual number of symbols.
But that doesn’t mean there’s no documentation for them. Many of the symbols have good doc comments in the headers. Yet despite Apple releasing HeaderDoc 19 years ago, it doesn’t seem to have an automated way to get those comments into the published documentation.
Previously:
Update (2019-10-21): Mattt Thompson:
Source code for NoOverviewAvailable.com is now available on GitHub[…]
Update (2019-10-25): Mike Zornek:
During the multiple discussions it has been suggested that this documentation issue is an easier problem for Apple fix than others since documentation can be produced in parallel, money can buy more writers and Apple has plenty of money.
This is mostly true, but a major factor that is not brought up is Apple’s reluctance to hire remote documentation writers.
[…]
There is a fixed, limited pool of candidates who live or is willing to relocate to the Cupertino area. It gets even more difficult when you consider a technical writer will probably make less (Glassdoor listing) than a developer and yet the cost of living out there is crazy for both professions.
See also: Accidental Tech Podcast.
Update (2019-11-01): Chris Krycho (via Hacker News, Slashdot):
The number of parts of this ecosystem which are entirely undocumented is frankly shocking to me.
[…]
The current state of Apple’s software documentation is the worst I’ve ever seen for any framework anywhere.
[…]
Given what I know of Apple’s approach to this, the problem is not individual engineers (who are not responsible for writing docs) or even the members of dedicated documentation teams (who are responsible for writing docs). But that does not make it any less a failure of Apple’s engineering organization. The job of an API engineering organization is to support those who will consume that API. I don’t doubt that many of Apples API engineers would love for all of these things to be documented. I likewise do not doubt that the documentation team is understaffed for the work they have to do. (If I’m wrong, if I should doubt that, because Apple’s engineering culture doesn’t value this, then that’s even worse an indictment of the engineering culture.) This kind of thing has to change at the level of the entire engineering organization.
Damien Petrilli:
Apple not documenting and providing unstable tools will push people to use cross platform and hybrid technology.
Why use native when the other tools are taking the heat for you and provide documentation?
I’ve even seen people pointing to documentation for Microsoft’s cross-platform stuff as being the authoritative source on how macOS works, because Apple’s own documentation on the topic is absent.
ChrisMarshallNY:
Some time ago, I was contacted by Apple to apply for a job. My code is insanely well-documented. I like to think that a lot of the inspiration for my code docs comes from Apple’s open codebases. Their code is exceptionally well-documented.
[…]
In any case, during the test, I did what I always do when I write code. I stopped to write a header document for the function.
This was clearly not something the tester liked.
Steve Troughton-Smith:
When I was learning Cocoa, Apple’s docs were the best around. These days, it’s all left to rot in the Documentation Archive, and it’s much harder to find anything helpful for newer APIs. If this year’s meme helps Apple realize the damage they’ve done to their documentation, great
What happened to Apple’s docs? I think the biggest reason is Swift: Apple’s adoption of Swift as the language they want devs to think about instantly invalidated decades of great documentation and sample code. All new docs are Swift, all WWDC material is Swift, all focus on Swift.
Dimitri Bouniol:
This makes me so sad, because I felt like Apple had some of the best documentation and programming guides around before the ubiquity of iOS and stack overflow. If there was a hole, there was usually a good article on the topic as well.
Now, there are a ton of “beginner” resources, but almost no guidance on the more obscure APIs and frameworks
I feel like they could easily hire remote developers to document existing APIs without feature of leaks, just to flesh out undocumented things, and any new APIs right after WWDC starts and during the beta period.
Brent Simmons:
There has been some discussion about Apple’s developer documentation being less-than-complete, and people have made remarks about the issue of moving to the Cupertino area as a drawback for potential authors.
But note: Apple is actually hiring in Seattle.
FlexMonkey:
Whoa! The Accelerate page has been updated: every article and piece of sample code is available in one place.
Russell Ivanovic:
Forget “No overview available” Apple’s code documentation has far worse sharp edges. This property is marked as iOS 11.0+. Guess what happens when you use it on iOS 11? It crashes because it doesn’t recognise it
Documentation HeaderDoc Hiring iOS iOS 13 Mac macOS 10.15 Catalina Open Source Programming Working
Craig Federighi:
When we released the first set of apps using Catalyst [in Mojave], some of the concerns that were voiced placed a certain amount of focus on the technology, but that was really design decisions we made. There were pure design decisions that were different design teams pushing the bounds of what is the future of media oriented design. I think we’re finding our balance there, pulling back in some areas. And the underlying technology has improved.
Dieter Bohn:
iOS apps on the Mac [in the Catalina developer beta] are starting to feel like a pretty sweet solution.
I wanted Apple to go hard and show developers the right way to do these. This is not that.
Jason Hiner:
“Wait for the public beta. We’re still tuning everything up. That’s where it gets really good,” Federighi said.
Well, the public beta came in July, and Catalina shipped in October, but nothing seems to have changed. The state of Apple’s Catalyst apps, as well as the APIs and documentation available to developers, is just sad. We still have weird panels within windows, spinny date pickers, and buttons that don’t look like buttons. There are no APIs for making standard pop-up menus or table views. Developers who care about making their apps more Mac-like are having to reimplement AppKit controls and resort to private API. The Human Interface Guidelines have been updated to include iOS-style switches, which the News app goes on to use in the opposite of the prescribed way.
Steve Troughton-Smith:
Here we are, couple weeks from release, and it seems clear once again Apple can’t walk & chew gum at the same time. SwiftUI was announced a year too early to sabotage Catalyst on the Mac, and now neither are reliable. Catalyst completely undocumented and starved of dev resources
William Gallagher:
“Their quality varies,” says Andrew Madsen, Mac and iOS developer, “but none of them could be called a great Mac app. Apple has made some public commentary to assuage concerns around these apps, going so far as to say that they’d be majorly improved in the first public beta of Catalina.”
“Despite that public pronouncement,” he continues, “the apps have not seen major changes since the first Catalina beta, and seem on track to ship in a less-than-excellent state for another year. If Apple can’t make really great Mac apps using Catalyst, what hope do third-party developers have?”
Peter Steinberger:
Worked all day to implement “Open Recent” which you’d get for free on AppKit. Result: feature doesn’t work, two new radars filed[…]
Steve Troughton-Smith:
It’s more than a little frustrating that to access the full range of NSToolbar functionality in Catalyst you have to resort to using an AppKit plugin.
Steve Troughton-Smith:
Recreating AppKit controls in UIKit for fun and profit — vertically-resizable split views are an easy one.
[…]
It doesn’t take much to style UISegmentedControl more like a Mac app. Little tweaks like this make it far less obvious that you’re looking at UIKit on the desktop.
Konrad Kołakowski:
I don’t really understand why Apple won’t do it themselves, to style UIKit apps more like macOS apps.
Or at least share some code do allow it easily, without having to reinvent the wheel by every Catalyst dev
Peter Steinberger:
With the help of some Apple folks, I finally managed to get security scoped bookmarks working under Mac Catalyst!! You need to redefine some unavailable enum values (🙀) but hey, nothing’s perfect ;)
Colin Cornaby:
The guess that Catalyst was going to be a big driving force behind Apple Arcade? So far the games I’ve looked at all seem to be AppKit native builds from a game engine like Unity. Game engines make the build environment kind of irrelevant.
Steve Troughton-Smith:
I don’t expect a single game in Apple Arcade on macOS to use Catalyst in any form, but if you come across one do let me know!
Steve Troughton-Smith:
Catalyst can’t support any game on Apple Arcade, nor is there a path towards it doing so. It’s an incredibly bad fit for immersive game experiences right now
Steve Troughton-Smith:
I have a feeling Catalyst is gonna be the sole focus of my radars for a while… 😂
Jason Snell:
Mac Catalyst can be simultaneously
1- A source of a bunch of interesting new Mac apps
2- Limited and frustrating for developers
3- In a strange limbo state where it’s unclear how much more work Apple will put into developing it
Michael Love:
3) is the worst for my purposes because it’s hard to come up with a long term product strategy on desktops without knowing whether or not Apple is serious about this thing.
Apple:
For iPad developers, macOS Catalina makes it easier than ever to bring your apps to the Mac: The process starts by checking a single box in Xcode.
[…]
Whether you want to edit photos, learn a language, balance your budget, or play a cutting-edge game, these awesome apps offer the great Mac experience you’ve come to expect, while taking full advantage of the larger screen and powerful hardware.
Jeff Johnson:
They’re seriously advertising this.
Manton Reece:
Trying to resist judging Catalyst by the initial apps out with Catalina today. Most developers were surprised by Catalina shipping so soon, and porting apps is more difficult than “checking a single box in Xcode”. In 6 months we’ll have a better idea.
Mark Gurman:
So far, the reality has fallen short for some developers and is even leaving consumers paying twice for apps.
[…]
On day one of Apple’s new technology debut, the Mac App Store showed only about 20 compatible iPad apps, out of a possible library of more than a million iPad-optimized applications.
[…]
Many of the issues originate from Apple’s initial promise of checkbox simplicity. It is indeed that easy, but the resulting ported app still carries over vestiges of its iPad optimizations that don’t work as well on Mac computers.
James Thomson (Upgrade):
The “single check box” Catalyst version of PCalc is a single resizable window, with many tables and popovers that seem to me to be out-of-place on the Mac.
[…]
It became pretty clear to me that I would need to rewrite a lot of the user interface, to find a happy middle ground between the iPad and the Mac. Which would probably benefit both in the long run, to be fair. But with everything else that was going on this summer, I couldn’t justify that work, with no guarantees at the end of the day that I would have something I was happy to ship.
[…]
From the business side, there is also no way for somebody to get the Catalyst version of the app for free when they buy the iOS version. And no great way to share in-app purchases either if you have a free app. That generally means that somebody will have to pay a second time to get a copy. There is definitely an argument that building a Catalyst version is actual work, work that should be paid for, but I can equally see the side of consumers that have been told it’s just a simple check box. Apple said a shared store will come in two years, but that’s still a way off.
John Gruber (tweet):
I don’t buy the “ran out of time” excuse. Catalyst has had this particular problem — touch-based spinners in place of pop-up menus — since 10.14 Mojave last year. It’s madness. Has there ever been a GUI toolkit for any mouse-pointer-based platform that didn’t offer pop-up menus as a standard control? Mac, Windows, Motif, Amiga, all the various toolkits for Unix X11 systems — they all had pop-up menus.
John Gruber:
But Catalyst is a developer technology. Users have no idea what it is and shouldn’t need to. “You have to pay for iPad and Mac versions separately” doesn’t seem like a big deal to me because it’s been that way all along, regardless of Catalyst.
[…]
At WWDC in early June — four months ago — Apple showcased the catalyzed Asphalt 9 port on stage, with the following quote from Gameloft: “We had Asphalt 9: Legends for Mac running on the first day. It looks stunning and runs super fast using Metal on powerful Mac hardware.”
But it’s now been “slightly delayed.”
Steve Troughton-Smith:
Netflix won’t be making a Catalyst app ☹️ Also didn’t realize Apple had pulled their marketing for the only game they were promoting as a Catalyst app
Colin Cornaby:
I continue to be impressed at the whiplash of Catalyst is the future of Mac apps but it doesn’t work very well but it helps you write your apps without learning AppKit but you need to learn AppKit to make a good Catalyst app but the Mac UI is dead but make it more Mac like
Paul Haddad:
I got some test code running on Catalyst and the thing I found most glaring is how unatural it felt with a mouse. Trackpad was fine, but good luck if you don’t have one.
Steve Troughton-Smith:
Catalyst developers! What are you missing right now? What would you really like Apple to provide as soon as possible?
I’ll go first:
• a roadmap
• the ability to choose to use shared App Store records
• TestFlight
James Thomson:
Equivalent AppKit controls, like popup buttons and checkboxes, and the ability to switch off the scaling.
Peter Steinberger:
NSUIKitHostingView in AppKit. Then let me write my app in AppKit + load stuff as needed.
And performance + bug fixes.
Daniel Jalkut:
Hm, well obviously “native-feeling” isn’t an agreed, objective standard. But FWIW I’ve yet to see a Catalyst app that meets all my expectations of “native feeling” on the Mac.
Colin Cornaby:
Just to be clear on my position on Catalyst:
It’s something that seems reasonable for smaller, more contained applications that have heavy dependencies on UIKit.
That’s very different than building it up to be the replacement for AppKit or the environment for all Mac software.
Steve Troughton-Smith:
I think text editing in Catalyst apps is gonna be a huge point of contention for a while; there’s certainly a disconnect between the iOS editor and what it bridges to on the AppKit side that makes everything feel like it barely works in every app
Steve Troughton-Smith:
I expect the Twitter Mac team have had an incredibly stressful summer getting a Catalyst app of this complexity out the door. There are plenty of UI areas that are going to need another pass, for sure. The double-toolbar just isn’t a good fit for the Mac
Jane Manchun Wong (via John Gruber):
On Twitter for Mac, it’s easy to fix the small fonts issue
Colin Cornaby:
I think it’s also interesting how Apple is adjusting their user facing language on these applications in their marketing copy. They’re now usually calling them iPad Apps on the Mac, and not Mac apps. Which is a pretty accurate description and expectation for Twitter.
[…]
Sometimes I think Catalyst suffers from the hype of it’s own advocates. If you view Twitter as the iPad app on a Mac, it’s pretty decent. If you try and look at it as a full Mac app, then it’s kind of problematic.
Michael Love:
Obviously they’d keep some sensitive new hardware-related stuff secret, but with Catalyst/SwiftUI this year e.g. I can totally understand the argument for announcing them both at WWDC but there was no reason they had to actually ship this fall.
Ben Sandofsky:
I can spot flaws in Catalyst apps because I’m a Mac nerd. For normal people, Catalyst 1.0 apps are already better than web apps, and infinitely better than Electron.
Vidit Bhargava:
I’m sharing this design document to highlight some of the design considerations I made for bringing LookUp’s iOS App to macOS. And while I did use fall backs to AppKit in certain situations (Even though i had no prior knowledge to AppKit, the APIs were relatively easy to get to), I still feel that a lot of apps can design a good experience without having to use them.
Jason Snell:
Unfortunately, a few apps haven’t really improved much—the four apps sourced from iOS last year as a part of the Mojave update, via what we now call Mac Catalyst. They’re all still pretty rudimentary, and while it’s better to have them than not, they could be much better than they are. The Home app has added support for home automation shortcuts (but it’s so buggy as to be unusable), and setting time-based automations still requires you to spin an iOS-style date picker. That date-picker design should not ever appear on macOS, period—it’s a touchscreen interface that doesn’t work with a mouse or trackpad. I can’t believe Apple has left it untouched.
Steve Troughton-Smith:
Going searching for Catalyst documentation is fun. Doesn’t seem like any of the iPad Apps for Mac WWDC sessions have sample projects either
Steve Troughton-Smith:
Here's a fun one: Lotto Machine for macOS gets a blanket App Store rejection
[…]
To bring your iOS app to the Mac you battle your way through Catalyst without documentation, you lose months of progress with macOS SceneKit bugs, and then when you finally go to ship, Apple tells you they don’t think the app should be on the platform at all
Adam Overholtzer:
There’s a difference between “can” and “can but with a ton of work and lots of hacks”. Catalyst is buggy, undocumented, and requires AppKit hacks to get some of the most basic Mac features working. If a developer doesn’t have time for all that, it doesn’t mean they’re lazy.
Marvis App:
Sadly not, while Catalyst focuses on having common UI for Mac and iOS with some common frameworks, MediaPlayer framework that’s on iOS doesn’t work on Mac in my tests, that means the whole backend of the app wouldn’t work. So, I’m sorry to say, no plans. 😔
John Voorhees:
Less successful is Catalyst. I’ve had high hopes for Catalyst since it was previewed at WWDC in 2018. The realization over this summer that Apple wasn’t going to update its original four Catalyst apps was a big disappointment, as was the lack of documentation and sample code and the inability of developers to bundle Mac apps with iOS and iPadOS apps. Together with the workload imposed on developers by changes to iOS and iPadOS 13, many I’ve spoken to put their Catalyst plans on hold, which is understandable. That’s not encouraging because, in the short-term, it means we’re unlikely to see many of the sort of new ideas and competition that the Mac app ecosystem needs to be sustainable long-term.
Nick Heer:
Catalyst is a frustrating bridge between the entirely-discrete AppKit and UIKit worlds, and the ostensibly cross-platform SwiftUI model. It’s “frustrating” because apps built with it don’t feel like Mac apps, and it’s probably too early to start building with SwiftUI since it will likely change dramatically for developers over the next few years. It’s an awkward middle ground that isn’t as good as either. Apple’s promotion of it as “just a checkbox” in Xcode — and, weirdly, using that as part of its pitch to users — is overly optimistic.
That’s not to say that there are no good Catalyst apps. John Voorhees reviewed Lire for MacOS and was fairly impressed with its platform-specific customizations. But it’s a harder process than Apple promotes to developers, and I’m still not confident we’ll see truly great apps built with Catalyst.
John Voorhees:
So far, the most common path to releasing a Mac Catalyst app on the Mac App Store has been to adapt and release an existing iPadOS app as a first-time Mac app. However, that’s not the only route to the Mac App Store. Apple allows developers to use Mac Catalyst in a variety of ways, as Steve Troughton-Smith has demonstrated with HCC Solitaire, a Mac-only game built using Mac Catalyst. He and Brian Mueller, the creator of CARROT Weather, have also used Mac Catalyst to release new versions of Mac apps that were previously built with AppKit.
Corbin Dunn:
News.app on the mac is such a second class citizen. It is pretty easy to crash with keystrokes, and focus navigation is horrific. (Yeah, “Log a bug”)
Steve Troughton-Smith:
There is some new complex sample code (as of this week?) for creating menu commands and contextual menus in Catalyst apps, including spawning dropdown menus at will without needing to right-click, something I wasn’t aware was possible at all.
As of yet there’s no complex sample code for: using a Mac toolbar, using the Touch Bar, managing multiple titled windows & tabbing behavior, customizing your settings bundle to make a reasonable-looking Mac preferences window, or any further integration with AppKit
Maximilian M:
Catalyst has been quite the journey so far. Bringing over
@instapdf
for Mac to UIKit from AppKit has been difficult. I’ve started creating some OS code to bridge missing functionality[…]
Previously:
Update (2019-10-21): AppStories:
This week, Federico and John interview James Thomson, the creator of PCalc and Dice, for a developer’s perspective on Mac Catalyst[…]
Peter Steinberger:
We finally figured out how to get the system accent color on Mac Catalyst. UIButton gets it, so we use one to set it on the UIWindow subclass…
Update (2019-10-25): Alison DeNisco Rayome (MacRumors):
Apple is taking developer feedback into account when it comes to improving Catalyst, Benjamin said. “For many of the early Mac Catalyst developers, it was their first time ever developing an app for the Mac, and it’s amazing what they’ve been able to achieve in such a short time,” he added. “We’re learning a ton from these early adopters, and are planning additional resources and support to help them create amazing Mac experiences with Mac Catalyst.”
Juli Clover:
Several developers have taken advantage of the new capabilities in Catalina to create Mac Catalyst apps for the Mac App Store, and we thought we’d round up the most useful of these for those who are wondering how Mac Catalyst apps work and how they compare to their iPad app counterparts.
Corbin Dunn:
News.app on macOS suffers from so many UI issues due to the poor UIKit port. When focusing, the sidebar and titlebar don’t appear as the key-window color simultaneously, making it blink in a few frames later.
Update (2019-11-27): Adam Demasi:
the best and worst thing about Catalyst is that apps don’t get killed for high CPU/RAM resource usage.
best - because some apps really do need those resources
worst - because some apps could have bugs that were never fixed because iOS’s Jetsam kills the app after a few seconds
these existing bugs will be fixed over time, and likely new ones will be caught in development since all new code written will be tested on both iOS and Mac. unfortunately this does imply that users of the current set of Catalyst apps are acting as beta testers…
App Store Rejection Apple Arcade Apple News Catalyst (Marzipan) Cocoa Craig Federighi Documentation Mac App Mac App Store macOS 10.15 Catalina Netflix Podcasts Private API Programming
