Tag Archives: apple

Apple hijacks Unix headers into Xcode in Mavericks

I am currently taking a class on Unix systems programming. While following along with lecture, the professor stated that almost always the header files needed for our type of work are located at /usr/include. However, that directory does not exist on my brand new Mavericks MacBook Pro. I have learned (after much searching the web) that the header files are now here:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr

After doing some more research, I found that to get those Unix header files back into /usr/include, one has to install Xcode’s command line tools. But, in order to get those, one has to be a registered member on Apple’s developer website. Not necessarily a paying member, but registered.

I was once a paying member for Apple’s developer tools but I gave it up because I was not actually using everything that was made available. My focus changed and the annual $99 was going to waste. In fact, because of that and that Apple has so much of their Cocoa documentation available externally for free, my need to log into their website has decreased over time to my not touching it in over a year. Now I am jumping through the hoops to figure out which account I was using and what was the password, but that is turning out to be harder than expected for a variety of reasons on Apple’s side, the servers not propagating my Apple ID resets to the developer site being one of them. Yes, I should have done a better job of recording my information, but a simple password reset shouldn’t be this hard either. At this point, I will likely just create a new account solely for getting me what I need.

I have no idea when Apple hijacked the header files, and i can understand the logic and convenience of doing so for tool updates, but knowing what little I do about Unix, hijacking seems to be anathema to the Unix culture. Apple has made my morning nothing but hassle trying to get this fixed and I will have an assignment due soon. So, cheers for that, Apple.

UPDATE: I wound up creating an account solely for the developer account, and it was, as expected, faster and easier than mucking about with a bunch of password resets. Once I did that, getting the command line tools was not straightforward though not hard (Xcode > Open Developer Tool > More Developer Tools… which then kicks you over to a downloads page on the developer website, with registration required for access).

As for my comment about the new default header location being anathema to Unix, I realize now that’s not necessarily true. If anything, Apple can do whatever they want with their distro. But the fact remains based on everything I have read so far that there are some clear expectations about there things ought to be and the header file location is one of them. But at least now I can establish a workflow where I can use the muscle of Xcode to develop and then confidently test outside before submission.

Ars Technica: Nintendo president hints at exploring smartphone gaming support

“We are thinking about a new business structure,” Iwata told the press, according to a Bloomberg News report. “Given the expansion of smart devices, we are naturally studying how smart devices can be used to grow the game-player business. It’s not as simple as enabling Mario to move on a smartphone.”

“We cannot continue a business without winning,” he continued. “We must take a skeptical approach [to] whether we can still simply make game players, offer them in the same way as in the past for 20,000 yen or 30,000 yen, and sell titles for a couple of thousand yen each.”
Ars Technica: Nintendo president hints at exploring smartphone gaming support

I’m willing to bet dollars to donuts that Nintendo has some skunkworks deep in the heart of headquarters where Mario, Zelda, and their colleagues are running freely on iOS and Android, if not also on desktops, waiting and figuring out the best way to roll it out. This would be just like the rumor I had read ages ago that Apple has most incarnations of Mac OS running on Intel chips the entire time they were manufacturing with PowerPC chips. To see the benefit of doing so is not hard.

If Zelda came to iOS I would snap that up in a second. My Wii has barely been touched since I started school, there have been three new consoles since I started, and I still have a long way to go. I really hope they are moving in this direction, though I can also understand the hesitancy of handing over 30% of revenue to Apple.

Not quite as simple as all that

Nigel Warren:

The fact that iWork on the Mac has lost functionality isn’t because Apple is blind to power users. It’s because they’re willing to make a short-term sacrifice in functionality so that they can create a foundation that is equal across the Mac, iOS, and web versions. It will take time to bring these new versions of iWork up to parity with what the Mac used to have. In the meantime all platforms have to live with the lowest common denominator.

This is what I think, too. Doesn’t make it any easier to stomach if you relied on features that have gone away though. And let’s see how long “short-term” is.
Daring Fireball: iWork 13 is the New iMovie 08

This analogy falls short when discussing Applescript’s lack of support in iWork and its oftentimes murky support from Apple and its partners. From an application/GUI standpoint, sure, iWork is garnering the same reaction as iMovie and Final Cut Pro. Not that I want to point out the obvious here, but Applescript is not a GUI. Applescript is a programming language in its own right that extends the capability of any supporting application to well beyond the confines of its GUI. Looking at the current state of Applescript support is important to take into consideration here because there exists a deeper, more complex, history than what exists for iWork.

  • Search “Applescript” on Apple’s homepage, and there is no evangelism of any kind. There are, instead, links to developer documentation. What evangelism did exist has long since been migrated over to an external site run at one point by a freelancer specializing in Applescript solutions but now any clue of ownership is now hidden. What, exactly, is the Applescript community is to think of this? While there is nothing from Apple stating that Applescript support is going away, but there is an implication that Applescript is less than a second-class citizen in the Apple world, simply sent out to pasture and brought in for the occasional grooming. Attempts to improve Applescript’s profile are either weird or poorly implemented.
  • ApplescriptObjC was created to allow Applescript developers to create Cocoa applications in native Applescript, but it has some serious flaws. The source code file name changes from .applescript to .scpt upon compilation which destroys any links to included files. This is ultimately manageable but that just creates more ceremony before development can begin. Also, blocks are cannot be implemented in ApplescriptObjC, either.
  • Scripting Bridge, which goes the other way by allowing Applescript calls via native Objective-C (as opposed to using the NSApplescript class). But it relies on two command line apps that generate grossly erroneous or incomplete header files (with no tools for troubleshooting issues) and typically results in an API that is severely limited in scope by randomly not allowing the creation of certain classes.
  • Automator appears to be a bridge between budding power users that can’t code to those that can, but is a separate implementation in addition to Applescript despite both use the same frameworks. More work to implement another niche technology? Really?
  • Now we have a major name on the Mac, Adobe, allowing their Applescript APIs to fall apart and currently not allowing external script calls.

Given that context, iWork’s change in Applescript is not “the sky is falling” but rather the latest in a long line of dysfunctional behaviors from Apple.

If an analogy is sought of Applescript’s drop from iWork, then it could go something like this: For a certain class of “power users” (an analogy I equate to “people who drive trucks”), dropping Applescript support from a core application cutting off any further independent development and is akin to Apple dropping the Cocoa frameworks and Objective-C. Hard stop. There is no GUI to fall back on for what Applescript does for a lot of its users.

For that subclass of power users, those that have built processes and workflows that save their companies thousands of dollars and hours each year in productivity, any drop in Applescript support marginalizes those users into maintaining quickly-outdated systems. When talking about those power users, adding a “though” to “Doesn’t make it any easier to stomach if you relied on features that have gone away” is dismissive of the impact. The reaction from certain users is not about iWork but about the state of Applescript in general.

Given this affects a subclass of a subclass of all users, robust Applescript implementations are a relatively small niche. As such, support was never as solid or apparent as, say, Core Data. If support for a technology that I use to automate quantifiably money-saving processes is dodgy to the point where whole code migrations are required, then I, as well as others, will need to seek out more stable platforms. So, try to stomach that.