Almost two years ago, Apple announced Swift, their next-generation language. Politically, it seems poised to imminently succeed Objective-C as the de facto standard language for Apple platforms. Practically, there are many questions.

Since the language’s debut, people have been pointing out the impedance mismatches between Swift, a type-safe and statically compiled language, and Objective-C, an unusually dynamic, almost “anything goes” language in which objects can be magically bound to do one another’s bidding at run time as opposed to compile time.

Brent Simmons recently ignited a round of (mostly) thoughtful analysis about the dynamic shortcomings of Swift, and whether Apple will eventually fill the dynamic void left by Swift, when they inevitably update their core frameworks to accommodate the new language.

Paul Kim, a long-time Mac developer, whose experience with AppKit goes back to the NeXT days, wrote a balanced defense of Objective-C’s dynamism. He concludes with an acknowledgement that many of the people who might contribute practical feedback to the Swift team about how it would best serve app developers, are too busy shipping apps:

What I do see makes me worry that it’s not the experienced app-writers that are being heard. Unfortunately, many of us are too busy to sit in the various mailing lists and forums. Yes, ok, we lose. But we all lose if those creating the platform don’t draw from the experience of those who have built upon it successfully.

It would be OK that a majority of established 3rd party app developers can’t embrace and offer feedback about Swift, so long as Apple were buying into the language internally and ironing out all the kinks on their own. But how can they? Apple is in all likelihood the single largest owner of valuable, time-tested, customer-pleasing Objective-C code. Thus they face, as a company, the same challenges that Paul Kim and many other developers do: they can’t afford to put everything on the line, divert all their attention from Objective C, just to embrace a language that is not completely mature, and which doesn’t offer the same features as its predecessor.

If Apple’s long-time Mac and iOS developers, and the company’s own internal framework developers, are not yet empowered to dive head-long into Swift development, who is? Early adopters. Very early adopters. God bless them. Unfortunately, Swift’s early adopters will become experts in precisely the techniques that the language currently affords, as they aren’t motivated to push the language in the direction it needs to move to accommodate long-time Objective C developers, and … Apple itself.

I have to imagine Apple is stewing on this problem internally. Hopefully they have some brilliant thinking on the subject, some of which will come to light at WWDC in June. In the mean time, Apple faces an unenviable conundrum: the growing number of Swift experts in the world are predominantly neither employed by Apple, nor familiar with the design patterns that have set Apple’s frameworks apart from the competition for at least 15 years.

Swift is a fascinating, beautiful language. How will it evolve to prove superior, in the long-run to Objective-C? By providing a suite of impedance-matched frameworks that fulfill all the needs of current iOS and Mac developers. How will those frameworks come to be in an environment where Apple’s most experienced framework developers, and Apple’s most experienced 3rd-party developers are steeped in a tradition that favors patterns not supported by Swift? I’ll be very eager to see how that plays out.