Hacker News Reader

Comment by Liquid_Fire | Hacker News Reader

Maybe I am missing some context here as I have never developed for an Apple platform, but what is the point this blog post is trying to make? That the tooling used to be very complicated?

View on HN

Actually the opposite, likely. The tooling was preinstalled and ready to go, and you could largely click your way through building interactive experiences.

Compare this GUI-driven, mostly-discoverable flow with the incantations you need to know to set up a React interface, for example. It's night and day.

Xcode/dev tools were not preinstalled, but just cost a registration on their site to download and install.

When OS X was still distributed on optical discs, it came with a dev tools disc for the first several releases. That how I personally stumbled upon Project Builder, Cocoa, etc. I may have never found it if I had to seek it out and download it.

What does macOS / iOS / iPadOS development look like today? Do you not have XCode with a GUI-driven workflow anymore? I only poked around iOS development during the iPhone 1/3G days, but I thought tooling has been constantly improving since then.

Disclaimer, I'm only a wannabe Apple platform developer, but the GUI-driven workflow is still the predominate way to develop for Apple platforms. The most radical change is the introduction of SwiftUI, which has you writing interfaces entirely with code, rather than using drag-n-drop components with Storyboards.

There’s quite a few iOS devs who ditched storyboards and XIBs years ago in favor of full code. I did several years ago, largely because Interface Builder became so much worse after it was merged into Xcode. That, and XIBs and storyboards suck to have to deal with merge conflicts on.

I still use XIBs when doing personal Mac Cocoa development though, because the experience there is still decent (though not as good as it was). Won’t touch storyboards with a ten foot pole though, they slow down IB too much and generally aren’t a good fit for desktop UI paradigms.

Most iOS teams I worked on did UI in code since Storyboards are a nightmare with more than one developer and version control.

The main difference is that now most development is actually not based on the platform but carried out with web tech. Which, compared to desktop tools, is light-years behind in usability.

honestly if you are doing native development and using the iOS/macOS tooling directly it is not that different than this. You basically have options, xibs and nibs like in this blog now have a new friend Storyboards that encompasses multiple screens and transitions but development is still GUI based and uses outlets like in the blog. A lot of programmers just refuse to use this stuff and just do everything programmatically. new kid on the block is SwiftUI which is a much saner not XML based declarative way of defining UI components like React but is still rough around edges and will likely be for a couple years.

This!

I usually praise Apple's UI for often being intuitive and elegant. But it looks like, in this specific case, there is a problem only outsiders can see clearly: ctrl+clicking an icon to an UI gadget is neither discoverable nor intuitive!

When I improved the Anjuta-Glade integration, I made some effort to do something simpler:

  - Open the .ui then the corresponding (by marker comments that are automatically created when the project is created) .c and .h files... boom! They are automatically associated.

  - Add an ID to a widget you want to access programmatically, double-click it on the inspector... boom! Code for accessing it as a member of the "private" struct is automatically created.

  - Add an onClicked signal to a button (which already has an ID), double click it... boom! Code for the callback is automatically created.

It is a shame Anjuta+Glade never became as popular as they could.

Didn’t Delphi/Visual Studio do this as well when using corn designer / property inspector?

Yes - Delphi and C++Builder's Object Inspector still does this. Double-click a control, and the default event handler (OnClick) will be created. There's a link auto-set between the button instance's event handler (method pointer) and the method, which is auto-created in the form the button belongs to.

Last time I tried, Delphi had no concept of "outlet", every widget is accessible by the form class that contains it. On the Anjuta+Glade integration, you double click the widget on the inspector to add it to "private" struct, so you can access it on the callbacks.

I know that because I implemented it: https://gitlab.gnome.org/GNOME/anjuta/-/commit/5abe8fd3a97d8...

I came to the comments, looking for the same answer. Was it that.. there was no documentation or tutorials whatsoever?

I was absolutely expecting a comparison with how hard it's to get started and develop software on modern MacOS and XCode today (is it? I haven't used it).

It would be a much better post if a comparison with the current state of the art was made

Alternate take: if you want developing for OS X [sic] to be this easy, don't even think of trying to use anything other than the tools we give you (after you ask for them).

It’s the same logic that drives how they handle OS licensing.

It's funny that you got two opposite answers.

"GUI-driven, mostly-discoverable" vs "neither discoverable nor intuitive"

Reply on news.ycombinator.com