catlanSep 24
Steve Troughton-Smith
How has there not been outrage at Apple removing the ability to see the documentation diffs on the developer site? This has made developing for the platforms so much worse over the past year, but I haven't seen anybody even mention it. They cut off the feature when they redesigned the docs site a while back, and now it's impossible to keep track of new APIs added throughout the year. It's especially detrimental to Swift-only APIs, whose changes cant be picked up by diffing the framework headers
Sep 24 at 3:07pmIvory for Mac
Show threadOle BegemannSep 24

@stroughtonsmith Swift’s equivalent to headers are the .swiftinterface files in the SDK. It should be possible to diff them just like header files (possibly with SwiftSyntax for an AST-based diff), but I don’t know if someone has already done the work (and yes, Apple should do this for us).

Example: [Xcode.app]/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/arm64e-apple-ios.swiftinterface

Show threadI Can't Believe It's Not Zero!Sep 24
@ole @stroughtonsmith The loss of hand-written and organized headers is really the only thing I miss from C, tbh.
Show threadI Can't Believe It's Not Zero!Sep 24

@ole @stroughtonsmith (formatted documentation pages are great, but they force everything into a "sort of OK" one-size-fits-all format. _Most_ headers were a mess, but every now and then you came across a project with really great headers that told the whole story of the API in a way that autogenerated documentation pages can not)

And generated docs have a _really_ hard time wrangling with complex conditionals (if you're on this system with this version, you use the API like this because of these considerations, on this other system this doesn't work at all, here's how you should work around it. On these newer systems, you can use this other API instead...) Well-written headers were great for this stuff.

Show threadSteve Troughton-SmithSep 24

@steve @ole what if there were a mode for Swift that required header-style 'specs' or something? Something that could be a design pattern, that a framework provider could adopt…

(Also, you get most of this if you just use @-objcimplementation with objc headers, but it doesn't have a way to describe every kind of Swift type)

Show threadBenRiceMSep 24
@stroughtonsmith I thought I was just failing to find it 🤦🏻
Show threadGiorgio RomanoSep 24
@stroughtonsmith yeah, it's awefull
Show threadMiguel de Icaza ᯅ🍉Sep 24
@stroughtonsmith it is heart brekaong, it was such a useful resource
Show threadRaphael Sebbe 🇪🇺Sep 24
@stroughtonsmith we were discussing that here with the team this week. Was helpful for new/updated API discovery. We definitely need something for that, as not everything is covered in WWDC and it is hard to parse (manual .h text search for "26" in tens of frameworks).
Show threadAlexandra JusinoSep 25
@rsebbe @stroughtonsmith this! I even asked last week how do I find a list of new API’s? 🦗 🦗 I found nothing.
Show threadNicolás AlvarezSep 29
@rsebbe @stroughtonsmith Right after WWDC, 25-50% of the new frameworks said "since iOS 19.0".
Show threadKhaos TianSep 24
@stroughtonsmith I was annoyed when they got rid of the API diffs (the one page version). The documentation diff was always pretty broken so it's not missing much I feel.
Show threadJosh HrachSep 24
@stroughtonsmith I wonder if Swift support for back deployment made it hard to do proper diffing. If a newer SDK version adds a method that is available back to an older SDK version, how do you display that properly?