(I didn't get the job)
I guess every team is different, but this attitude to dog fooding isn't great.
They specifically said I should have had more professional Swift experience when they rejected me. Of course all the companies I worked for were being more conservative and hadn't yet made the leap to Swift yet, so getting that professional experience was pretty much impossible. But I guess if anyone can afford to be picky, it's IBM on a project working directly with Apple.
So yeah, IBM is definitely gung-ho about Swift. Apple itself, possibly less so.
Another was something like "In Swift, what are higher-order functions?", which I somehow only heard that term a couple of times before and didn't have fresh in my head, despite using higher-order functions in plenty of programming languages (C#, Python, Ruby, even in Objective-C). That one was a case of knowing the concept but not the term.
I believe those two questions were the main ones that lead to the rejection, because I stumbled and didn't come across as confident there, but was otherwise pretty calm and answered the other questions well. I was in and out of there in 45 minutes, talked to one person who quizzed me on the names of UI objects on a given screen, and then the pop-quiz-style interview with two other people.
I also stupidly didn't show them the app I had partially built in Swift, even though I brought an iPad with me. I think I even mentioned it, and they're like "You have it here?" and I said "It's not finished..." and they just started asking me more questions. It was a working puzzle game, but some of the logic for clearing matches was wonky at the time and was visibly broken so I was hesitant to show it.
Apple isn't telling people to go use Swift on the server, IBM is. Apple is telling people to write iOS apps in Swift, which they are also doing themselves.
I'm aware. This is the (humorous) point I'm attempting to make. IBM is adopting technologies faster then Apple. While Apple started it's life out as the Anti-IBM. Indeed it is still fulfilling this role. The (humorous) point being, their roles have in a way swapped.
IBM lost the consumer space and is dominant in F100, while Apple won the consumer space and abandoned the enterprise.
With both IBM & Apple behind Swift the language is being positioned for success in both enterprise and consumer markets. It will be interesting to see how things evolve.
So,"early" not as in before expected, but during the beginning of that time (i.e. more akin to "first").
[1] https://9to5mac.com/2016/04/11/apple-mac-market-numbers-idc/
And because they have a phone, they could totally ditch the cdrom, because, like, who wants to use a CD on their phone, right?
And the ethernet jack! Man, I felt stupid having to plug my phone into the wall for the internets.
But that headphone jack. Their phone totally blazed that trail, getting rid of that. Wait, what? The Macbook dropped it in 2015?
Surely though, most people that have an iphone use a mac right? That's the leverage point! Well no, only about 10% of iphone users had a mac in 2015. Even if it was 1-1, what difference would it make? There's no leverage to be had. iphones work with windows last I checked, and the growing trend is not bothering to "sync" your phone with a computer at all.
If the share was calculated by individual PC models and not by company, even in the PC business, there would be a bunch of Apple stuff ranking quite high.
So they can scale on many aspects much better than their competition. (plus they still have margins)
Most people rebuild their software entirely prior to release, and deliver the entire package. Having a stable ABI doesn't do much to help this scenario.
Linux doesn't have a stable ABI, hasn't hurt its success much.
Linux does have a stable ABI. And GNU'e libc tries to have one but it breaks often enough to be a concern (even with symbol versioning). You're conflating GNU and Linux here.
Swift is great for client-side work, but I wouldn't use it on the server. Each tool good for a certain job. Our current stack is Swift on the client, Elixir on the server, and I haven't been happier.
Well, not ready for their purposes, which (guessing from Java) would be some App/iTunes store backend, etc.
Other teams in Apple already use it for native app development from what I've read.
I'd speculate that "not production ready" is at least partly rationalization or cover for "we really can't afford to screw around with this codebase, even though this is the company's Big New Thing."
The Dock and a few other components of macOS Sierra are written in 100% Swift, according to this year's WWDC.
It's probably a reasonably small codebase with well specified requirements, it's a standalone app already, and it's not likely to cause underlying OS performance or stability problems if it lost a little bit of performance migrating to Swift. I'm guessing it could be an experiment to see what parts of the OS are reasonably replaced with Swift?
People have also complained for several yearly releases now that OSX isn't improving as an operating system. It's also been around in various incarnations for like 18 or more years and has likely accumulated some deficiencies that needed addressing. Maybe things need some rewriting now to be positioned to become better in the future and a Swift migration is a good excuse to do both. Enough people are also complaining Apple isn't dogfooding Swift enough internally, so there you go, macOS is starting to dogfood it.
I'd also guess Apple probably has a reasonably hard time hiring for Objective-C positions to work with OS-level code (e.g. they've probably hired all of the existing, interested and qualified people willing to work in the Bay Area already), and the up and coming labor pool of people coming from iOS development is likely to be more interesting in or previously experienced with Swift. Modernizing your codebase where possible now seems like a reasonably way to hedge for the future hiring needs. Apple's been around long enough they likely have people retiring out of some critical positions.
(I believe the Dock "app" also encompasses Mission Control, Spaces and all that sort of desktop interaction wizardry.)
It does. I think it also handles Cmd-Tab. I remember seeing a bug now and then in these things (task switching and desktop spaces etc.) which gets fixed by relaunching the Dock process.
Choosing the Dock, it's probably one of the smaller end-to-end apps that makes use of many OS features.
So they may have done it purely to prove our Swift for core apps. Now if only they'd have actually updated the UI...
(You can work around this bug by changing some of the defaults in the Mission Control pane of System Preferences... I think the "Displays have separate Spaces" setting.)