Is removed "use storyboard" option when creating new cocoa application project in Xcode 8.3?

yes it is. Hopefully by mistake and not deliberately.

They did it on purpose. Please believe it. They don't care that most mac developers don't like how they implemented storyboards. Hope they atleast fix storyboard zooming.

>> They don't care that most mac developers don't like how they implemented storyboards

Well, sure, sort of. But there's another way of looking at it. Apple doesn't disclose future plans (and I know nothing about them), but sometimes they will … um … emphasize a particular set of API behaviors, knowing that this represents a future direction, and other behaviors are heading in the direction of deprecation. It's usually wise to be guided in the direction that Apple seems to be herding us.

It seems unlikely to me that XIB-based interfaces are going away any time soon, but it's certainly possible that there are some amazingly useful new UI APIs coming in the next year or two that will only be accessible via storyboards, not retrofitted to XIBs.

Again, I have no knowledge of whether this is so in this case. It's happened before, though.

Yeah...that's true. I'm all for the nudging in a certain direction when it increases productivity. But not when it doesn't. This really is that big of a problem for me. I know how to manually configure a project to not use storyboards. The number of times this question has been asked on these forums though I think is indicative of the fact that developers don't really like storyboards on mac.

It's also true that sometimes they introduce something and the technology is not quite right. But because they are the Gods, developers flock to it like sheep, even though if they were thinking logically they porbably shouldn't use it (or hold off on it at least). And then after much self-inflicted pain, Apple admits defeat and deprecates. And developers who listened to their calls, now have a mess to deal with.

I can't see standalone nibs getting deprecated anytime soon either. I prefer to be able to make my own development decisions that work best for *me* though on things like this.

Certain things, like old nasty bugs (*reported bugs*...not unknown issues), they sometimes leave lingering for years. Bugs that are easy to fix, but devs can't because they don't have the source, or can't override a private method and submit the app to the App Store. Those things, they allocate little time for. But they release these teeny tiny API changes that often have little benefit.

>> I think is indicative of the fact that developers don't really like storyboards on mac.

I don't recall seeing anything really dire (link to something if you think so), but rather the constant reappearance of the following fairly manageable problems:

1. Storyboards change the referencing structure between controllers, and there's no really good way of achieving the same thing without complications. (However, since the last time this came up, I discovered there is a fairly simple way of solving this in some cases.)

2. There is virtually no documentation about how to use storyboards on the Mac. We have to figure everything out by analogy with iOS, but it's not quite the same.

3. There have been bugs, performance and usabilities in the gradual evolution of storyboards in IB. It's frustrating to go a long way round when we already know a faster way with XIBs. That doesn't necessarily mean the storyboard way won't be better than XIBs eventually, even if only a new generation of developers will learn to appreciate this.

Not dire. I haven't really seen anybody praise storyboards for mac apps. Storyboards do change the referencing structure a lot, perhaps to encourage more reusable view controllers, entice iOS devs to port there apps to mac. I find storyboards to be too restrictive for mac apps IMO, but will give them another try.

Mac developers get the shaft. iOS devs get the shaft too, but not as much as Mac developers. We have soft deprecated stuff like NSCell that hasn't been fully replaced, but it's deprecated. Old school controls like NSFontPanel and NSBrowser (which is kind of a nightmare to use), and such. NSFriggenClipView had a comment in its header file that it would be deprecated...*years* ago but that ***** is still around.

For all they can do to make the Mac platform better for users and developers, I just find it odd that they decide to make using Storyboards a priority. Not to mention, zoom still doesn't work in Mac storyboards (unless they fixed it in 8.3.2...I haven't updated yet....fingers crossed).

Not really trying to side scroll a gigantic macOS storyboard on my 13 Macbook Pro, so I hope they fixed that.

I do not like storyboards for Mac app. They are great for IOS, but not for Mac IMO.

I Have a Mac App with literally 50 different windows, each with its Nib.

If I have to use storyboards, could this be limited to the initial screen (then it's not a serious problem)or should all the windows be in the storyboard (which would be an incredible mess for me).

You could break up the windows across several diff storyboards. Did the concept of storyboard references make it to the Mac version?

I'd just leave your project alone though until/unless you see some advantage to converting your xibs to storyboards

I can't say I like storyboard either but am attempting to try them out.

One thing this Xcode change does is invalidate prevously printed books which only focus on XIB uage. It makes it much more difficult for someone new to the platform to find useful references and examples to follow; very much frustrates the learning process.

QuinceyMorris, could you elaborate on your comment:

>> 1. Storyboards change the referencing structure between controllers, and there's

>> no really good way of achieving the same thing without complications. (However,

>> since the last time this came up, I discovered there is a fairly simple way of solving this in some cases.)

I've been struggeling a bit with finding good ways for the various controllers wired up with segues to reference one another (mostly up the chain). Mostly I've been resorting to using global variables to capture 'self' for the various controllers so that UI elements can find one another when needed. With XIB, it seemed simpler to drag an object into IB and then it would let you connect UI element outlets/action to any header file ... maybe that was bad form but it worked and was simple to understand. With storyboard, I can't seem to do the same and it seems like simple things can't be done without hairy looking back-flips. I could post some simple examples of trouble I'm running into if anyone would like to comment further.

Thanks

>One thing this Xcode change does is invalidate prevously printed books which only focus on XIB uage. It makes it much more difficult for someone new to the platform to find useful references and examples to follow; very much frustrates the learning process.

Books on Xcode have been a shameless liability for years. The authors had a habit of writing about betas to make their printing deadlines, the books themselves can't be updated without a reprint and re-purchase, and they routinely risked being out of date before they hit the shelves. Then the authors go silent when their customers have questions, and end up here looking for support, trying to ask questions about misleading details that vaporized with two year old betas.

Now, Apple appears to treat Xcode as a permanent beta, a not uncommon practice in the tech industry these days. New versions come out less than two weeks apart.

Best to go all in with digital and only get your Xcode references from the Mother Ship. It's the only way to be sure, and even then Apple leaves much to shear discovery on the dev's part.

> I've been struggeling a bit with finding good ways for the various controllers wired up with segues to reference one another (mostly up the chain). Mostly I've been resorting to using global variables to capture 'self' for the various controllers so that UI elements can find one another when needed. With XIB, it seemed simpler to drag an object into IB and then it would let you connect UI element outlets/action to any header file ... maybe that was bad form but it worked and was simple to understand.

They made storyboards too iOS-ish. And I'm open to giving them another try...but still have not had that *aha I see why this better* moment. Maybe I will have that moment, but I'm kind of doubtful. iOS apps are simpler. One view controller is *usually* an entire screen so storyboard rules don't feel as limiting when you are making an iOS app. Posts by other devs seem to indicate that I'm not alone in my feelings.

I don't think it's a better way to do things, it's just different, probably worse currently at least IMO. Disruptive changes should be weighed against productivity gained for future projects. If productivity gained is <= what's current, the decision of force-feeding change should be questioned.

> iOS apps are simpler.

And they work inside a single window, as opposed to macOS, which can multiples. That's also one of the main things that makes full re-writes easier than trying to port.

SBs came around right after I'd finally gotten comfortable w/XIBs and an integrated IB. I took my time moving to SB's, but now at least I get it.

I haven't touched a nib in years, but anyone that uses SB on macOS has my sympathies.