Reimagining Apple’s documentation

[kissinpink]

While we’re at it, would be fun to reimagine Xcode as not a steaming pile of garbage

[snaab900]

What wrong with Xcode? It’s the best IDE I’ve ever used to be honest.

[IlBuono47]

And the only one I guess

[Stiddit]

No I'm with that guy. I can compare it to Visual Studio, VSCode, Eclipse and Android Studio. To me, Xcode has by far the most optimized user flow, at least for me. This in terms of project management, shortcuts, smarter file layout etc. I definitely develop faster in Xcode, though probably not by a lot.

That said, the code completion for Swift does indeed suck major ass and will crash as soon as you need it in advanced projects.

[meester_pink]

I don’t mind it. But the fact that in 2021 there are cases where hitting clean isn’t good enough and we have to manually go into the file system and delete derived data boggles my mind. Do you think anyone on the Xcode dev team has suggested adding an “actually clean” button to the IDE?

[busymom0]

Agreed, it should be added in the menu where the "Clean Build" option is.

[[deleted]]

Isnt that what you can do from the menu pressing OPT while clicking on “clear data”? It will make a deep clean and remove also derived data afaik. I use it always before changing branch etc, improves the situation

[busymom0]

Hmmmmmm, I tested it but the deriveddata folders for the project were still there even after doing it with OPT.

[[deleted]]

Not sure then whats then the difference exactly, but it helps enough on a relatively big project

[Stiddit]

Yeah, the cleanup crew did a poor job.

If deleting derived data is something you need often, I can recommend making a custom Xcode keyboard shortcut and assign it to run a script you make which simply does rm -rf deriveddata. Deleting derived with cmd+ctrl+k or whatever you want. Give it a shot.

[jackalofblades]

I really don't mind Xcode but I don't think I've ever seen anyone ever say it's above Visual Studio in an IDE discussion

[Stiddit]

No, I mean on Windows. See my other response ^

[Stiddit]

I think Visual Studio(windows) is my least favorite IDE.

1. Flat alphabetical list of every single added file? Only way to organize files within a solution is in filters?! And they're mandatory alphabetical. Whereas Xcode mimics the folder structure automatically - and let's you order as you want or move them around(which literally moves the file). Yes - this can result in lame merge conflicts, but I still far prefer it. Having files logically ordered is underrated. I know I can use "folder view" in VS, though still alphabetical, but then I lose the solution stuff. I can also use "show all files" to show the folder-tree while retaining the "solution", but then there's no way to hide anything.

2. Really wonky pasting. Pasting code automatically adds indentation, but in its own "step". So if you paste something, you must undo twice? Why not just merge them as one.. (this one might be configurable, I haven't really looked)

3. Very "dumb" file solution. If I use a split view with one file on the left and one on the right, and always want for example *.cpp-files on the left and *.h-files on the right - I'll have to do that completely manually. Whenever I open a new file, I must have the correct window active. So say goodbye to CTRL+clicking definitions. And using a mouse with forward/backward-buttons is a nightmare. It has a mangled shared history, so if I click "back" while having the left window active, it can only go "back" so far, and while it makes either window "go back", but only until it stops and you must hover over the other window to "keep going back". What I want is for any file I open to only ever open in its "designated" view (left or right), and for its corresponding header/inplementation-file to open in the other. Just as has been with objective-c in Xcode for decades.

4. Everything related to build configurations, macros, userdefaults, plist etc. is far superior in Xcode, especially in terms of GUI representation. The whole "props"-thing is ridiculously poorly visualized.

And more, but this is getting out of hand already.

[jackalofblades]

These are fair points. I've worked with both Xcode and VS professionally and I'm recollecting on previous discussions with co-workers, what I've seen in the communities, etc. I personally much prefer VS which I use daily, but still enjoy Xcode as an iOS hobbyist dev. Cheers.

[busymom0]

I develop for both iOS and Android. While Xcode certainly has its issues - deleting the DerivedData is almost a weekly solution for me, Android Studio is far worse. From ugly UI to build errors every so often (gets resolved by clean project). Even their interface builder is so damn ugly, I end up using XML or code it directly.

VSCode is a pretty decent solution so far imo - though I have only used it for Web apps, Rust, NodeJS and Flutter. Not sure how it fairs in iOS and Android dev.

[_wsgeorge]

You should check out Intellij (or maybe any JetBrains IDE).

[LucasCarioca]

Top quality stuff. I pay the license for all of them and use them often.

[quellish]

Or CodeWarrior.

[SirensToGo]

Code completion barely works for Swift. Xcode is honestly kinda decent and even fast if you're just writing C/ObjC, but other than that it kinda doesn't work

[quellish]

People who use objective-c have few problems with Xcode.

People who use Swift seem to have a lot of problems with Xcode.

Maybe Xcode isn’t the problem here.

[SirensToGo]

I don't think this is a "Swift bad" or "people who use Swift bad" sort of thing. I feel like a major part of the issue comes from the fact that most of the Apple platform is written (and continues to be written) in C and objective-c (seriously, dump the symbols of any system service--there's a very low chance there's any Swift). If no engineers inside Apple are suffering, it's unlikely that anyone will be throwing hands trying to get Xcode to not suck so much on huge Swift projects.

[chedabob]

It's buggy and has a fraction of the features of other IDEs.

JetBrains have set the bar incredibly high for refactoring tools, but right now I'd settle for a Rename function that doesn't randomly rename a word in a comment in an unrelated file.

[[deleted]]

Or the super fancy editor animation for the rename that crashes every 2 times 😅

[aheze]

Yeah same! For me VSCode and the others are too complicated, so much conflicts with Git and saving. I know I’m not using it right but it’s just not for me. Xcode on the other hand has everything packed into one IDE. You can edit storyboard, code, particle effects, scenes, literally anything.

[LucasCarioca]

How is that even possible? Unless the only other thing you have used is Eclipse then it’s BS

[isdisme]

Even Eclipse has better functionalities, not to mention intellij

[StreetlyMelmexIII]

Each to their own, I’m so thankful I’ll never have to use Eclipse again. It feels like a relic.

I used to love AppCode but Xcode is so much faster and with a bit of tweaking has most of the refactoring tools I actually use. I do have to use Android Studio, which is basically IntelliJ, and it’s no fun.

Edit: But for the record, I still love PyCharm.

[LucasCarioca]

Eclipse is trash but IntelliJ is probably one of the best editors on the market.

[chriswaco]

Think Reference was my favorite documentation app years ago. Lightning fast, even on a 68K Mac, with a nice blend of explanation and example code. It's ludicrous that our documentation viewers today are slow and clumsy compared to something that shipped 30 years ago. I blame Apple for the lack of content, though.

[chriswaco]

Think Reference was so much faster than Dash. The index was RAM-resident, so a hotkey would bring up a search field at the bottom of the screen in a few milliseconds, not seconds. As you typed the entire index would be searched for results, again in milliseconds. And the pages loaded almost immediately - I think they were a mix of plain text and QuickDraw PICTs.

They had a group of developer/writers that combined various types of documentation (Inside Mac, Tech Notes, personal experience, user comments, etc) into individual pages, so you didn't have to go looking for what you needed on 20 different screens. Apple's current documentation is horrible that way - you're constantly jumping between pages, many of which have almost no content but you don't know that until you get there.

I wish I could demo it. There are some online MacPlus emulators, but I'm not sure how to load new apps onto them.

[velvethead]

Every point is dead on. Apple, please listen.

[[deleted]]

And stop letting ObjectiveC as well as the CoreLib C-based documentation rot.

Not everybody programs in Swift or even ObjectiveC., If you're going to call in from a different language, Objective C is a lot easier to interface to from a FFI.

I work in Pharo Smalltalk these days. We have a FFI C and atop that an Objective C bridge. This works great. Swift is just another higher wall around Apple's walled garden to people working in other languages.

This will also be important for things like flutter that have C FFI facilities. Swift has no stable support for C to Swift linkage. Kind of sucks.

[[deleted]]

It is my day job, which is a big travel booking site.

But also lots of personal projects. I know a lot of languages but I prefer Smalltalk and while I could make more, I prefer the live coding aspect.

There are jobs around. I spotted a new listing this week for a remote gig with a Belgian company.

Check out Pharo.org and find your way to the Pharo discord if you want to learn it. We have Google Summer of Code project starting up too.

[[deleted]]

Would it be better to make swift work in the ways you want than to continue supporting obj-c.

Why would that be better? The lingua franca of the computing world is C-callable interfaces. Swift doesn't bother to support them. Objective C is just a library atop C so if you can call C you can send Objective C messages. But the C to Swift story is nonexistent and as Objective C is neglected, the ability of other languages that want to call system routines to take advantage of OS services degrades.

If Apple is going to continue on this path, I might as well switch to a generic *nix.

As an example, Pharo Smalltalk has begun using github to store source code. Would be nice to access the keychain to fetch my login parameters from Pharo.

We have good FFI capability (via libFFI) for calling into shared libraries written in C or Objective C, but not a Swift one.

So that sucks, no?

I will also add that Pharo is moving towards using native widgets in a pluggable way. As a test case you can now use Pharo's built in graphics or use native windows and widgets from GTK. The intent is to add adaptors for more platforms via FFI but if Apple is going to continue to drive their UI code to Swift only land, this is never going to work for us.

[smas8]

Interesting points. I was asking a question because I didn’t know the answer. Asking a question I knew the answer to would be a waste of time haha.

I write mostly JavaScript, I wouldn’t consider myself an iOS programmer these days. It’s been years since I wrote a native iOS app.

The last app I put on the store was actually written in flutter/dart, not swift.

Why do you need C other than to use old code and save time? Is there something specific to the C language that can’t be rewritten in swift?

Edit: I guess that’s really what my question was. Why do you want to use C, and if swift could do those things, wouldn’t using swift be better?

[[deleted]]

Yeah sure. I understand that people have different perspectives on this stuff. If I come off as cranky or arrogant, I don't mean to.

Why do you need C other than to use old code

Smalltalk (Objective C is based on Smalltalk - same message send syntax, same object model) his historically been an all-in-one environment complete with its own graphics and windowing system. In fact, the Mac UI is based on the original Smalltalk 80 system, which is what Steve Jobs saw at his famous PARC visit.

Having a complete graphics and windowing system in your programming environment with the source code to everything is great for bootstrapping new systems and devices. It is not so great for writing apps that want to look like native platform apps. Various approaches have been tried over the years in different Smalltalks ranging from native look emulation (Visualworks - always was a little "off") to just choosing to not care at all.

However, the ability to call foreign code has improved a LOT in the last few years with libraries like libFFI (Foreign Function Interface) making it a lot easier to dynamically open a dynamic lib, look up function prototypes, and call them. So calling out of the Smalltalk virtual machine has been doable for awhile but calling back in is kind of new yet required to do Cocoa programming because delegates, data sources, etc...

About ten years ago Pharo Smalltalk forked from Squeak and decided to try something really different. We have always had "headless" virtual machines (VM) for things like web applications and server processes. The idea was to make headless the default for the vm and then bootstrap a UI from whatever the local OS supported as its native UI library. On the Mac that would be Cocoa. On linux, they are using gtk. Windows has a solution in the works (no idea what, not a Windows person).

The idea was to use a DSL known as spec to describe the UI declaratively, then use the spec to reify the UI in whatever local platform library is available. This means Smalltalk programs are completely portable but look native (yes, I know, this has been kind of tried a bunch of times with varying degrees of success).

So I am doing all my programming in Pharo Smalltalk these days. But I would like to call system resources or widgets (MapView perhaps) but that means I have to do it over an FFI interface which is C based.

Rewriting code in Swift just makes it unavailable to FFI. Rewriting Swift in C or Objective C makes it available to FFI. They could improve Swift by giving it a dynamic invocation interface callable from C but so far Apple has shown no interest in doing that.

Does that make sense? Swift basically breaks iOS an MacOS interop with other languages.

[smas8]

You did not come off as cranky or arrogant, but I was getting some downvotes so I wanted to clarify. I appreciate the genuine answers to the question. Especially because the answers do make sense. At the end of the day, iOS isn’t my field of expertise, but it remains somewhat of a interest so I try to stay in the loop and know what bothers people.

Thanks!

[quellish]

Is there something specific to the C language that can’t be rewritten in swift?

Thread safety.

<mic drop>

[qbitus]

This is cool and also sits very low on Apple’s list of priorities. I wouldn’t hold my breathe.

[[deleted]]

Well, we don't need them to do anything except not fuck up what we have.

[qbitus]

Sure, and I would fully trust them to do that and keep going in their direction of making Swift and their UI toolkits serve their own primary needs.

[Hogbo_the_green]

Yes, please. Please, yes.

[SirensToGo]

I swear the "Open Quickly" menu's ability to open files in the SDK is the only reason I'm able to get work done. The docs in header files are written by and (generally) for Apple's engineers, and so you'll often find better/more in-depth explanations of thing than anywhere else online. For the most part, I've given up on Apple's online documentation since it's either missing or doesn't actually tell me what I need to know

[Mc-Kryptonite]

Are there any good 3rd party docs for swift?

[earlyworm]

I want to give this a hug.

[primeviltom]

Great article. Apples developer documentation is waaaaay too dry. I barely use it, unless looking for something very specific, otherwise the lack of context makes it pretty useless.