Why Apple Developed the Swift Programming Language - Hint - Apple Car

| Particle Debris

Soon our cars will be semi- or fully autonomous. That will require the best minds on the planet, engineers and A.I. experts, to write highly error proof and secure code. Current computer languages are close, but earn no cigar and weren't designed for Apple's needs. What better than for Apple to invent its own language, Swift, and get the whole world to test it first?

Let me tell you a story....

One of my favorite military aircraft of all time was the Lockheed F-104 Starfighter. Take a great aluminum airframe, insert a powerful (for its time) J-79 turbojet engine, add analog instruments and radios, and include a 20 mm cannon, and you had a Mach 2 beauty of an air superiority fighter. But that was 1958.

Lockheed F-104 from the 1950s. Not a computer on board. But fast.

Today, the Lockheed Martin F-35 Lightning II has over 8 million lines of code to debug and certify. That has caused many, many delays in the operational status of this aircraft. But this kind of evolution was inevitable in aircraft and is now coming to our cars. 

For example, in 1969, a Ford Mustang Mach I had a V-8 engine with a simple carburetor, a 4-speed transmission, drum brakes and a few instruments on the dash. (Zero airbags. Zero computers.) Lately, however, computers have been more and more a part of our automobiles. The article I'll link to next mentions that a current day Ford F150 truck has 150,000 lines of computer code. One can imagine an autonomous car from Apple in 2020 having several million lines of code. Hopefully, it'll all just work. ::gulp::

One has to wonder, I do, if Apple's Swift programming language was a necessary precursor to the "Titan" electric car Project. See, for example. "Interview: How to Write Secure Software, Guaranteed."

In that interview, I asked the CEO of Galois, Dr. Rob Wiltbank, whether some languages are better for secure code.

Dr. Wiltbank: There are definitely better languages. We happen to use one called Haskell. The reason is that Haskell is a very strongly typed language that forces constraints, and it checks for things along the way that have to do with how you express your intentions to the system. [emphasis added.] As a result, there are certain expressions that you cannot communicate to Haskell in an unclear manner.

Martellaro: I read that Apple's Swift language has some of its roots in Haskell.

Dr. Wiltbank: Yes. And Apple is definitely doing more and more with this kind of stuff. That is, eliminating design bugs very, very early in the process. Before you've even written a single line of code.

Of course, it's just a theory. But I ran across a CES article that makes me think it's a good one. Here's an article that echoes my thinking on computer technology and cars. "Self-driving cars won the week at CES 2016, with AI and big data the unsung heroes." To quote:

Perhaps the biggest challenge that existing automakers face in the race to autonomous vehicles is that these future cars are going to be shells for a lot of big data analytics, cloud computing, and artificial intelligence. Those aren't areas that carmakers have as a core competency. While computers have been deeply embedding themselves in cars for more than a decade—Ford says there are over 150,000 lines of code in an F150—the kind of intelligence and machine learning that it will take to power a self-driving car is a whole different ballgame. Google and Tesla already have that baked into their DNA. Every automaker will have to change to become that kind of company.

It's a whole new game, and Apple appears to be betting that is can be one of the companies whose DNA can be included in the short list above along with Google and Tesla. Some traditional car companies won't have the technical and financial resources to keep up and will fade from view.

Future highly computerized autonomous cars will look the same on outside,
but be very different on the inside.

However, Apple's unique technology history and expertise puts it into a perfect position to forge a new marriage between computers and cars, just as aerospace companies already have done with computers and jet aircraft. [Note, Apple has James A. Bell, former president of the Boeing Company on its board.] That evolution would include, I surmise, creating a much improved programming language, Swift, and getting thousands of developers write and test millions of lines of code before it ever appears in an Apple car.

I like it.

Next: The Tech News Debris for the Week of January 11th. Science, analysis and bozos.

Popular TMO Stories


John C. Welch

Except the F-104 was a horrible air superiority aircraft everywhere but on paper. Huge turning radius, incredibly bad low-speed behavior. If you only needed it to fly in a straight line really fast, it was awesome. Which is probably why there are less than 5 confirmed F-104 air-to-air kills in the operational history of the airframe, almost 20 years. It was very pretty, but also more hazardous to its own pilots and maintenance crews than it was to enemy aircraft.

In terms of reliability and cost of maintenance, that 1969 Mustang is going to cost you a lot more money than the modern F-150 due, in large part, to the computer code you imply causes problems. A modern vehicle will, with not much more than changing the fluids and tires on time, last ten years with ease. There’s no way you could run a ‘69 Mustang for ten years with a similar level of maintenance.

You’re creating a false relationship here. The amount of computer code in and of itself indicated neither a lack of nor superior reliability and performance. The problems with the F-35 have less to do with the LOC numbers and more with how hard it is pushing the envelope in terms of what a fighter aircraft can be.

The B-1B had a lot of problems early in its history, and now it is the backbone of the USAF’s ability to deliver large amounts of ordinance on target day or night, and with far less maintenance costs than a B-52. The F-22 has far more lines of code than the F-104 and is a better aircraft in every way than the F-104.

The idea that swift was created to support a car is still completely unsupported and as much of a stretch as I’ve seen.

John Martellaro


I am well aware of the F-104’s history and limitations. I am a semi-historian of the aircraft.  It was used as an editorial example of speed and simplicity without computers - leading to the car analogy.

The story about both aircraft cited and how cars will soon to have millions of lines of code is indeed a sobering story.

I formed a theory based on some evidence. The interview with Dr. WIltbank, the timing of Swift, the above trend in airframe/carframe code, the concerns over autonomous car safety and finally Mr. Bell (former Boeing) on Apple’s board of directors. No there is no specific evidence, but I enjoy connecting dots and forming theories.  Time will tell - as we know from page 2 of this week’s column.

Thanks for reading. I always appreciate your astute feedback.


Dude, the Starfighter was a joke!!! Research bubba.  We have one here in Burbank planted on a 25º rod pointing up. For the time it looked cool - but it was a “failure” on the whole.
Swift? Who knows? You can’t say Apple has ANYTHING to do with a car at this point; it could be R&D, drone system or as I’ve said before- a “system” for autonomy. Swift could be used for a better iOS or a home automation scheme. Sensors and the language thereof are what is going to drive autonomous drones and cars, and so far Apple has NO sensor knowledge - it’s all farmed out stuff. Nvidia will be the huge sensor maker for some autonomous systems. I wonder if Apple should buy Nvidia. Drones will make a BILLION dollars in sales this year…where is Apple in that? Any nut that bought an Apple Watch would surely want a personal ‘security’ drone to follow them around, right?


It’s not for nothing that the F-104 was known as the “Widowmaker”. Something like a dragster - death or glory.

Back to the topic of Swift, I seem to recall that it started as a personal project and, after a while, Apple blessed and supported it (Apple is good that way, although they don’t say much about it for obvious reasons). My take is that, while this genesis (i.e for a car) is possible, it’s not likely. That said, it could be hugely important for it. But I don’t think that was the start. I’m willing to be corrected though.

I wonder how much code there is for a Google or similar self-driving car. John mentioned that there were 150K in a Ford F-150 and that would be no surprise. My suspicion is that the code needed for a self-driving car is two orders of magnitude bigger, at least. Does anyone have a number that can be publicly shared? I am intrigued. I know it’s huge, but not just how huge.


But the F-104 looked cool, just like Apple products (but Apple products work better).


A followup on the code-in-cars topic, and the point that John M quoted
“Perhaps the biggest challenge that existing automakers face in the race to autonomous vehicles is that these future cars are going to be shells for a lot of big data analytics, cloud computing, and artificial intelligence. Those aren’t areas that carmakers have as a core competency.”

This is absolutely the case. I will share my experience with BMWs as I’ve owned more than half-a-dozen 5-series over the years. All were “good” or better for their time, some were great. The vehicle-operations stuff has been fine (although I have had two “soft” failures over ten years, in different cars).

Quite a few years ago, BMW introduced “iDrive” as the preferred method for controlling preferences and “in-car comfort”. What a debacle. The UI was lumpy and inconsistent. You never knew whether a click would take you one level or two. The idea was to make this simple but in fact it was sufficiently complex as to make using it dangerous in anything other than quiet traffic.

BMW took note and newer version have more physical controls for the things you want/need to control while driving (temperature, etc), while still retaining, quite appropriately, for the more complex settings that you’d only ever change while stationary. Big progress.

However the implementation of the audio system is really poor (this is on a 2012 F10 5-series). My typical usage is either radio, or an iPod Classic (on the grounds that smaller devices are unable to hold my iTunes library). But about once a week the car and the iPod get snitty with one another and disconnect. On some occasions, this happens when the iPod drive (remember - the Classic has the tiny HDD) is spun up. And then the battery drains to zero. Other times the car just says that the iPod is “Not Connected”. No amount of unplug/replug will solve the problem. If I do a hard boot of the iPod, the car tries to reposition back to what had been playing, and locks up again. The only reliable way to clear this is to
1. hard reset on iPod
2. start some music while iPod is disconnected
3. re-plug into car
4. optional - choose what music you’d like (as the selection from (2) is ephemeral)

Now you might well wonder why I bore you with such awful details.  That’s because these are only the appetizer. The main course is that
1. my BMW dealer says that everything is working OK
2. the dealer says that BMW audio systems don’t support “old” devices (despite the fact that the iPod is in fact newer than the car)
3. there are NO people at the dealership who can deal with the cross-current of mechanical and electronic issues. None.

Note: this occurs about once a week so I suspect that it’s a memory leak/exhaustion issue. I have an old iPhone (therefore no HDD) and the disconnect happens much less frequently, but still happens. For the iPhone, unplug/replug will reconnect.

Also, whether playing from radio or iPod, once in a while there’s a very very brief pause in the audio. About a quarter-second or so, but just enough to un-nerve you. It sounds like a buffer-underrun but I have no way to know.

One other point - having been through a long career of software development, I expect that computer-y things work in reliable, predictable ways. So it scares me that the car info systems (nav, audio, etc) start up differently at various times. That’s quite scary, and I have no idea why it’s so. Sometimes it comes up with a “BMW” screen, sometimes it’s the audio screen (which is what was usually on when the car was turned off, so no surprise), sometimes it’s a nav screen. The notion that these systems do not have a predictable boot sequence is quite scary. Predictable initialization is typically a touchstone for embedded systems. Who know - maybe they have found a better way?

John C. Welch

John, you posted two questions, both of which deal with safer languages, and then draw a line that says Swift was created for cars because…2+2 = cheese?

There’s a gob of reasons for swift that have nothing to do with cars. Safer languages are a requirement *everywhere*. If a car is built, I’ve no doubt much of it’s code will be in swift. But there is a huge, huge difference between that and your assertion, which is that the primary motivator for Swift was the car. That you have yet to show. And again, the number of lines of code in modern transport is interesting, but in terms of your claims, unrelated.


He was comparing an analog item to one that is computerized.  Who the heck cares about the performance-characteristics of the F-104?  Really people!

He’s referring to the simplicity of an analog plane vs. the complexity of a modern aircraft.  That’s it.

I’ll say one thing’s for sure… I owned a 1968 Mustang for 20 years, and a 1996 Dodge Ram pickup truck and my ‘68 was far and away more reliable then the truck.  I can diagnose an analog issue easy on the Mustang.  On the truck, I have to put it into diagnostic-mode and hope the series of flashing-lights actually tell me the problem, which was rarely the case.

I own an “older” 1993 Honda motorcycle, and a 2006 BMW K1200S.  The BMW has broken down countless of times, many of which the mechanics could not figure out which required engineers from Germany to be included.  My more analog Honda rarely needed anything more than tires and oil.  Done.

Computerized vehicles are the norm.  It’s inevitable.  The technology it gives us is amazing… when it works… Sadly, that same benefit also is its detriment as it does result in difficulty in resolving problems that come up, and in today’s security-conscious age… gives outside individuals an ability to hack into those systems from the comfort of their sofa and wreak havoc.

Apple is in a great position for to address this.  The other car makers, not so much so.  They can build cars, but when it comes to software… I have zero faith in their ability to keep me protected and safe.

John C. Welch

If you’re going to make claims about a thing, it really, really helps those claims are correct. Otherwise, it has a deleterious effect on the rest of your claims.

As far as anecdotes on car reliability, okay, I had a ‘73 mustang which was perennially requiring tuneups and other preventative maintenance. I also had a 2000 civic which required naught but scheduled checkups and on-time fluid replacements. The ‘73 was far simpler to troubleshoot, which was good since I had to do it all the bloody time.

Anecdote countered.

My wife’s previous car was a 2000 impala which was, to be kind, a pile of feces. Her current decade-newer honda is a thing of reliable beauty. O noes, both were computerized, yet one is reliable and the other is not. Almost as if the introduction of computers, in and of itself does not mean a car becomes de facto less reliable than a more analog version.

Anecdote countered.

Isn’t this *fun*!

By the “analog is more reliable” logic, we should all go back to CRTs and VGA, because those never broke down. And yet, no one seems to want to do that. I mean, why wouldn’t you want a three hundred pound 20” CRT that uses as much electricity as how many LCDs, takes up more space, etc.  it’s more reliable and requires less care, purely because it is less computerized.

And if you’re relying on software to protect you in or from an accident, there are many, many points that you’re missing. By a wide margin.

John made a specific claim: that the primary motivator behind swift was the as yet mythical Apple car.

Nothing in his article even came close to supporting it beyond part of an interview that says “safer languages are good”.

John Dingler 1

On the issue of aesthetic of early military fighter jets, this one is supreme:



Swift was developed by Dr. Chris Lattner ( see his comments at: http://nondot.org/sabre/ ) and the effort to build it started in 2010.  He is the founder and chief architect of the open source LLVM Compiler Infrastructure project. There is nothing to indicate Swift was developed for use in an Apple car project and it seems doubtful anyone was considering such a project in 2010. Dr. Lattner explains ( see link ) some of his reasons for developing Swift and there are no mentions of specific Apple projects. Of course, Swift’s data type safety is a boon and clearly will help with code development and integration but (AFAICT) there is no evidence of a plan to develop Swift for use with an Apple car project. Yeah, it’s fun speculate but real evidence, if it exists, isn’t publicly available. However,  thank you for writing an interesting article.

Lee Dronick

In regards to automobile and aircraft software, see today’s Joy of Tech comic:


John Martellaro

brilor: Thanks for a most informative and gracious response. Theories are made to be tested. Mine was intriguing while it lasted.


Wow, touchy touchy touchy!! Talk about over-analyzing!!

I thought it was a good analogy, John, and I followed what you were intending to do. Apple cannot be involved in EVERYTHING tech-focused, but will invest, develop, and release tech products that it feels it can do better than its competition. I think an Apple car is definitely in this arena. Not that Swift won’t help in a lot of respects, but I think Apple will approach a car differently than anything we have seen, and will build on its strength in manufacturing processes and working with metal as much as its software. Apple is also known for throwing away the old for the future, and the current automobile is ripe for that. Steering wheel? Gone. Foot pedals? Gone. Radio, navigation, instrument panel? Gone and replaced with iPhone and iPad. Put all the brains into the iPhone and iPad with of course physical redundant systems for safety-critical items and I think they can excel with an Apple Car. Start off semi-autonomous and evolve into full autonomous - the dinosaurs which are today’s automobile manufacturers will start to go bankrupt.


I make my living writing Apple code, specifically building iPad and iPhone apps for corporations. Despite Swift being out for roughly two years or so I’ve yet to take a stab at it, mostly because there’s no need on my part, Objective-C serves our purposes well, is still well supported by Apple and is our legacy code. Kind of hard to convince the business side of things to budget for us to go and restructure all the apps in Swift when the only selling point is it might be more elegant to look at than some of the Objective-C code.

It has always been my belief Apple adopted Swift as a means to make the segue from web development to native Apple device development easier. So if a programmer has spent a decent chunk of his/her career ensconced in Javascript, PHP, CSS or .NET, making the leap to Obj-C can be difficult. (I can personally attest to this coming from PHP to Obj-C required a learning curve replete with the gnashing of teeth and wailing of this and that. Eventually though I was won over by Obj-C and have grown to love it. ) But making the transition easier makes good business sense.

As an example, writing an array:

NSArray* arrThings = [[NSArray alloc]  initWithObjects:@“foo”, @“bar”, nil];

Alternatively as a literal (roughly around 2012):
NSArray* arrThings = @[@“foo”, @“bar”];

Swift (roughly around 2014):
var arrThings = [“foo”, “bar”]

var arrThings = [“foo”, “bar”];

So, if you follow the progression I think you can see how Apple was trying to make a language which web developers would be comfortable with. I once worked for a very successful engineering software firm and ate lunch one day with one of the founding brothers and (this was 1998ish) remember discussing our efforts to gain marketshare. He explained that he had felt that they had reached a point where you could only offer the users so many ways to make a circle and that they had to look, pardon the pun, outside the circle, to increase or retain our users. We introduced that year I think, the first major software product where you could get upgrades as our engineers produced them, not having to wait for a new version, all over your AOL crappy modem connection. It probably took someone half a day to download it back then but it was innovative.

Apple is hitting that wall in a way (as is Google). You can only make it so much lighter or thinner or cram so many pixels into the image. So if you can’t make the device itself much better than you need to look at other areas - in this case content. The more developers you can get developing for your device, the more content there is to offer, the more customers you have.

I really think the explanation for Swift is that simple. My Occam’s Razor approach to it. Will Swift be the language of the car if Apple goes that way, maybe,  but that does not mean the former was developed for the latter.

Samuel Danielson

The F-104 was a point defense weapon meant to be scrambled on 100 mile 60,000 ft targets. It was a missile with decision making, observation, and communications capability. Equipped with a camera it could deter spy aircraft from flying where they didn’t belong. Everyone here saying it sucked for air superiority is correct, but it was the best interceptor of its time.

Log in to comment (TMO, Twitter or Facebook) or Register for a TMO account