And, if I cleave to the Apple toolset (as opposed to rewriting it, like I used to), that stuff is sorted. Apple has much better lawyers than I'll ever be able to afford.
Also, I use lots of dependencies. It's just that they are generally ones that I wrote.
True, it has something like that (which works to varying levels of success depending on the project). The excuse for not fixing weird syntax oddities like this though is breaking source compatibility, which my point was tooling should solve.
Essentially the tooling in the Apple ecosystem is rough to work with and feels poorly thought out - it feels like the teams work independently and then mash their stuff together right before go live.
Hey everyone. I have just completed a release of an iOS app, being a web developer.
Let me tell you… the Apple developer ecosystem is sooooooo convoluted! Is it just me or does anyone else feel that way?
Don’t get me wrong. The company is innovative and a trailblazer. It has done so much in terms of hardware-software integration. And I am not even talking about anything before MacOS X or iOS.
I mean … Objective C. XCode. The hodgepodge of a million different things smashed together. I have seen many people say it is elegant… I have seen many ecosystems. Apple’s one is, well, kludge upon kludge.
First there was [foo bar] but then you got also foo.bar and foo.setBar. You null, NULL but also nil, you had YES and NO but also got true and false later. You could swizzle but also you could have C++ features alongside Objective C for a while, for the ultimate in language law degrees. You got #include #import but also @import because hey, @ gave you random superpowers. You had protocol but later got NS versions of everything (like NSCopying) and then ARC bolted on and auto draining pools that worked some of the time.
Swift was much nicer and tried to go back to simplicity. It even helpfully renamed all your methods. But then it had things like exclamation points that you were never supposed to use, and a weird try/catch syntax that could crash your app anyway. And when Swift came out you also got YourApp-swift.h generated magically by XCode to bridge to Objective C, because of course you did. After all, you have to rely on XCode for so many things. Assets go in a special Package format, you see. They used to live on a Resource Fork but the filesystem got changed.
Apple’s class system is also a hodgepodge. You have NS from the good old days, you have Foundation framework, but then you also have a ton of others which duplicate some of the functionality.
But that’s just the start. You’ve got nib, make that xib, make that storyboards, and they are all different. You’ve got constraints of 10 different types but they don’t work as you’d expect with all the various tools. (Man I miss Visual Basic, that was 20-25 years ago!).
The buttons are tiny and functionality like dragging an IBOutlet are hard to discover when clicking does nothing. As a teenager I was on the Apple Human Interface Developers mailing list, and their Guidelines (anyone remember those?) said “no hidden modes”. Well, that is so quaint now, for the last 20 years the new Apple has violated all their HI Guidelines. Oh, and did I mention, you only had a couple page transitions, one of which was a curled page turn, and one was sliding up from the bottom — but sliding down from the top is just not a thing! Write it yourself! If you can.
But that’s not all. Not by a long shot. You have to work with CocoaPods as a package manager along with other ones, and put up with arcane error messages with each new OS version as things break because things that used to be OK are now not. And if that error comes from any of the hundreds of random build settings — good luck, buddy. Here is a video from an expert in the trenches … who is glad to discover someone else has been cataloguing all these build settings for years:
No wonder Apple is trying to move towards an all-Swift future.
Did I mention Apple FORGOT TO RENEW THE CERTIFICATE ON ITS OWN MAC APP STORE — not once but twice?
I imagine it is better actually inside Apple. But hey, I worked inside Bloomberg and I can tell you, that codebase is … idiosyncratic to put it mildly. I guess it is like that inside many companies, but when you build a platform for developers to use, you need to make it clean and cut down on the number of concepts that have to be used, or at least make the concepts all consistent, like BSD.
On the bright side, Apple did usher in the Mac, the iPod, iPhone, Apple TV, many innovations. It did absorb NeXT, try to bridge with Darwin, change CPU architectures a bunch of times, make Grand Central Dispatch, create secure enclaves, and more. So we can give them a pass I guess as a company. But boy does their development ecosystem feel a lot of kludges that accumulated over the years!
'From the get go, the product was not task oriented (as in “I want to upload some pictures and do a blog post about it”), but very object-oriented (an hierarchy of folders, with security, objects, drag-and-drop, etc.).'
This clicked for me. Everyone probably knows it already, but I never got it this crisply until now. There is a spectrum between user and programmer. Depending on what you're building, you can build in a lot of leverage for your users by making your tool less programmable. Apple does this the best.
But instead, iPhone developers are eagerly bending over begging Apple for more because of their myopic obsession with bad APIs, the twin geekgasms of both objecty stuff and C, bloated SDKs, impossible layout mechanisms, and all the rest of the archaic nonsense we’re going to have to rid the mobile Web of in the next few years.
It's pretty clear he's never developed with Objective-C, Cocoa/UIKit, etc. if he's calling it a bloated and bad API. UIKit in particular is fresh, clean, and very nice overall, IMO. (I spent years in Javascript/HTML/CSS, moved to the iPhone for awhile and worked on some major projects, and recently started developing an app on Cocoa for OSX - which is a lot more crusty than the iPhone.)
I also find it somewhat ironic that he talks about "impossible layout mechanisms" whereas almost every time I've been involved with a webapp I've hit upon some tricky layout requirement that is a pain in the ass because of CSS' builtin assumptions.
Thanks for that observation. You are totally right. Having learned to dive into framework headers and map idioms from one to another is totally something I learned at Apple, especially in the early days of creating a lot of the frameworks that form the foundation of the OS. I have always found Apple's docs to be frustrating, but when I look at them without the benefit of my background, I can see how it must be maddening to developers coming to the platform.
> As an industry we need to acknowledge the need for cohesive and consistent platforms, not just components.
Agreed, but it's also, apparently, a difficult bar to clear.
Apple manages to do it, by having iron-fisted control of the hardware, the operating system, and the SDKs.
But even they are starting to fray. I've been writing Apple code since 1986, and I'm getting familiar with some of the newer stuff, like CreateML and SwiftUI.
There's a ... difference ... in the way that documentation is being handled. In The Days of Yore, we had Inside Macintosh, which was a multi-volume Encyclopedia Britannica-like set of tomes, delving deep into the operating system and SDKs. It was written by really skilled people; often with advanced and esoteric degrees, and with great writing chops.
Yeah, you're right, but it's the difference between Apple running everything, from top to bottom, and an open system where all kinds of devices and uses can be found for the code.
It seems Apple isn't immune to the "rewrite entire codebase from scratch". I'm not saying it is a good thing or a bad thing, but it is a trope of software companies.
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?
Have you ever used an Apple dev tool? If so, I'm shocked at how dramatically different your experience has been from mine. I would rank Apple absolute dead last in terms of caring about the usability of their dev tools out of any vendor of dev tools I have experience with.
Good observation. I know barely anything about ObjC/Cocoa, but if I was pushed to provide an opinion on them I'd start griping about how awful the verbose mixed case method names and prefixes on everything look. Which obviously isn't hindering the other people making fantastic iPhone and Mac applications.
As an aside, look how clear and well-written this web page is. I'm always blown away by how well the whole Apple ecosystem (even the the developer documentation) is designed
Perhaps you're just building tons and tons of tableview cells or something else automatically laid out for you, so you're not really feeling it (or are too strident a believer of your position to learn then judge, rather than judge first). But if you do any manual layout at all, there are huge wins within days of starting to learn the tool.
It feels like I'm discussing with someone contending that zip files are as good as source control here.
The only two examples he gives for this "a lot" is a completely new framework that was released about a month ago, and a tool that is, honestly, still in development and not part of normal development workflows for Apple platforms.
Also, I use lots of dependencies. It's just that they are generally ones that I wrote.
I have control issues, I guess...
Everyone wants to write unique UI, but I've learned that's a trap. I write about that, here: https://littlegreenviper.com/miscellany/the-road-most-travel...
reply