Should Apple create a simple programming language?

From my perspective, Swift is a complicated program that is very difficult to make an app with. And I'm sure that I'm not the only person to arrive at this conclusion.

Consequently, I sometimes find myself thinking 'Wouldn't it be great if Apple had a simpler programming language. A piece of software that allowed me to make apps easily and quickly.'

So, that is the question...

Should Apple create a simple programming language?

Now, Apple are not going to create a simpler programming language than Swift just so that the lives of some developers improves. But they might do it if they realize that a simpler programming language would most likely increase their profits (possibly in a significant way.)

At the moment, Swift (and its complicated syntax) puts up a lot of barriers when creating an app. And what that means is that Swift is creating barriers in terms of the amount of profit Apple makes (and also reduces the amount of return an Apple investor gets.)

Therefore, I believe that Apple would be justified in creating another (easier to use) programming language, so that they make more profit and, at the same time, create more revenue for their investors.

And in this scenario, Apple would keep Swift for developing complex apps. And they would also make a simpler programming language for people who are unable to develop Apple apps because of Swift (possibly one that doesn’t involve the complexities of OOP - after all, what’s so bad about event driven programming?)

I think there’s an underlying premise here that’s simply false. The Swift syntax is probably the easiest part of developing apps. I don’t want that to be discouraging, but it’s really true.

Apps are complicated. In addition to your actual business logic, you have to worry about its representation, laying out views, adapting to different screen sizes, handling accessibility, dark mode, right-to-left languages, persisting user sessions across app launches, networking, caching, local persistence, rendering at 60 fps (or more now) and so on and so on, all while trying to be efficient with the user’s resources, esp. battery.

I think the software industry does more to share its advancements openly and to lower the barrier to entry than perhaps any other industry. There’s a common sentiment of “this was really complex, I figured it out, here’s a library I wrote for you to use so you don’t have to struggle like I did.” And yet, it’s still not simple, despite clear efforts. People have been trying to make “anyone can make programs” platforms for decades, and nobody has really cracked the code yet (pun intended). Have you seen one of these take off?

The modern generation of programming languages have been building on over 50 years of experience in language design. Balancing all sorts of factors (often competing) like complexity/speed of compilation, type safety, developer ergonomics, runtime performance, etc. If the languages still have complex syntax, it’s certainly not for lack of trying.


As was discussed in the previous thread, you seem to be conflating the Swift language with platform libraries such as SwiftUI.

You asked why we cannot present an alert simply by writing:


But we can - check it out:

func alert(_ message: String) {
  // ??? - show an alert


The Swift language absolutely allows you to define a function which takes a string parameter and does something with it. The language and syntax is not the issue. It's up to the system's UI libraries, which are responsible for presenting alerts, to decide whether that is an appropriate interface for their task.

The language has some features which help those libraries expose simpler interfaces - such as result builders - and I think it is quite successful at that.

I can show you a concrete example. I'm developing a (non-UI) library to process URLs, and there are a lot of complex edge-cases, so I wanted to create a live viewer where I could type in a string and have it processed both by my library and by the standard's reference implementation (written in Javascript), and for the app to highlight if there are any differences.

This is just a sort of interactive playground app - literally I am the only person who ever used it, while developing some other software. It's not a production app, and I don't really want to spend too much time on it. Anyway, here's one of the components - a URLForm:

// URLValues and URLModelProperty defined elsewhere

struct AnnotatedURLValues {
  var values: URLValues? = nil
  var flaggedKeys: [URLModelProperty] = []

struct URLForm: View {
  let label: String
  @Binding var values: AnnotatedURLValues

  var body: some View {
    GroupBox(label: Text(label)) {
      ScrollView(.horizontal) {
        VStack(alignment: .leading) {
          ForEach(URLModelProperty.allCases, id: \.self) { property in
              value: { $0[property] ?? "(nil)" } ?? "(URL is nil)"
            .foregroundColor(values.flaggedKeys.contains(property) ? .red : nil)

  private func row(name: String, value: String) -> some View {
    HStack(spacing: 10) {
        .frame(minWidth: 100, maxWidth: 100, alignment: .trailing)
        .frame(alignment: .leading)

That is super simple, right? A box, containing a scrollview (to handle overflow, so the text doesn't wrap), with some rows in it. The rows have a name and value, and some rows can be flagged as "bad". It's just a simple little component, and it only needs a very small amount of code.

Doing this with UIKit (the previous UI framework) would be much more complex - I'd either have to get involved with AutoLayout, which can be tricky and verbose, or write my own, imperative layout code, calculating and setting frames and such. By contrast, this is all declarative. I wrote it in a couple of minutes, and even though I haven't touched it in almost a year, I can read and understand it in seconds.

Integrating this component in another view is super easy, too:

var body: some View {
  // ...
  URLForm(label: "WebURL", values: $modelData.weburlResult)
  URLForm(label: "Reference result", values: $modelData.referenceResult)
  // ...

And it just works. Of course, the library doesn't exhibit any incorrect values in practice :wink:, but if I modify the library to introduce a bug, we can test it:


It also works on iOS, with no changes. It supports light/dark mode, automatically, and I think it also supports dynamic text sizes.

So yeah - some things (like the flags which determine whether an alert is visible or not, and state management in general) are quite different, and might take some getting used to. But overall I'm relatively happy with SwiftUI, and the Swift language features which enable it - especially when it comes to keeping simple things simple.

You can't just say that anything that isn't a single function call isn't simple. Here, I composed a bunch of system views in to a custom view, then composed a couple of those views in to yet another view. It all works in a very straightforward way, in a very small amount of code. Productivity was high, maintainability is high. I think it's simple.


Another spin on this: Apple has a simple programming language. It’s Shortcuts. (Though they did buy it rather than develop it in-house.)


Yet another spin: Apple had a simple programming environment/language. It was called HyperCard.


You are welcome to build apps for Apple platforms using JavaScript if you find that to be a “simpler” language. You can avoid needing to learn about things like generics, existentials, value types, actors or a number of other “complex” concepts found in Swift. However, you may find that as the complexity of your app grows, using a “simple” language like JavaScript does not scale very well and actually makes your job much more difficult. There may be more of an upfront learning curve to something like Swift but I think it will set you up for success long term and in more complex projects. I would be wary of the notion that app development can be simplified to the point of being trivial.


Thanks for replying everyone. I'll have a think about what you've posted and reply hopefully sooner rather than later.

1 Like

And, every time I try to build anything of substance in Shortcuts, I always end up making some frustrated noises eventually and starting over in Swift! I fear, @Xeny, that Swift may be just about as complex as is necessary to be expressive. As Einstein (sort of) said, "Everything should be made as simple as possible, and no simpler."

1 Like

As a mediocre programmer myself, I'd like to add in another thought – when Swift first came out I found the syntax comparatively easy to learn. What has overwhelmed me is the continual expansion of what it can do (and all the things to remember to do it).

So in reality, Swift still is simple if the coder ignores half the features. Downside is trying to achieve complicated outcomes without the complicated features.


There's a longstanding tension in language design where which things belong in libraries and which belong in the language is debatable, but beyond that it's often actually unclear whether a particular feature is a library or a language feature. Is NSString a feature of Objective-C? No of course not, it's in Foundation. But… NSString literals are a feature of ObjC, and those depend on NSString existing. So is it a language feature or a library feature? Kinda both.

This comes into play when learning a language because we tend to treat "learn the language" as a base task and "learn the libraries" as an ongoing extended task built on that. When the language blurs with the libraries, this leads to feeling overwhelmed because suddenly the base task is huge.

I think a correct solution is to approach teaching (and testing, and interviewing) differently, and recognize that continued learning of the Swift-the-language is a normal and expected part of continued learning of Swift-the-ecosystem. Very few engineers, even senior ones, will ever know Swift the way I know it, looking upwards from the runtime and bridging internals. But lots of engineers will know other parts of Swift far better than me (the stdlib often isn't a significant adopter of new features, especially those aimed at UI programming tasks). And that's fine!


I'd say among these three: "Simple language", "General purpose language", "Easy to program" you can only have two at once. Examples:

  • "Simple language" + "General purpose language" but not "Easy to program" → Turing machine (*)
  • "Simple language" + "Easy to program" but not "General purpose language" → language to control a telescope but nothing else.
  • "General purpose language" + "Easy to program" but not "Simple language" → Swift

(*) yes, it is possible to write an iOS app using that! It would be an absolute nightmare though.


is this a problem that swift has, or just objective-c? i personally have always felt that swift has a pretty good separation from Foundation, and things like Cocoa bridging and objective-c protocols can be safely ignored by programmers who do not directly interact with objective-c frameworks.

I was just using Foundation as an example. In Swift it would be the stdlib, or _Concurrency, or StringProcessing, and so on.

But, even just considering Foundation there is at least one place the line is still blurred from a learner's perspective, which is the NSString methods that automagically show up on String.

My broader point is that moving things into the language increases the complexity of the language, but doesn't necessarily increase (and may even decrease) the complexity of the ecosystem as a whole, which calls into question whether thinking about the complexity of the language in isolation even makes sense.


even though it is not available on all platforms, i consider _Concurrency part of the standard library, and concurrency as a skill is so important that i don’t think you can skip learning about it and say you are proficient in swift.

yes, this is very annoying, but this is sourcekit-lsp’s and the VSCode extension’s fault, not swift’s fault.

i agree completely.

I've always considered Foundation to be Objective-C's standard library. It's not officially its standard library, but it has types such as strings, arrays, hashmaps, etc that most other languages provide as part of their standard library. Even networking is part of the standard library in some other languages.

I agree, and I think it's important that we keep that in mind as we add things like ownership annotations to the language. I worry that many open-source libraries will want to adopt them, but they have the potential to intimidate and overwhelm developers.

1 Like

So that's a resounding no then. Okay, got it. Thanks!

Hey Xeny, the tone here is a bit ambiguous to me, I’m not sure if you’re in genuine agreement or being sarcastic/antagonistic.

I found the Shortcuts example particularly compelling, personally. “But it doesn’t do what I need”, and therein would be the issue with too-simple tools.

Yes Alexander, in hindsight, it is ambiguous and I certainly wasn't trying to be sarcastic or antagonistic. That's my mistake, sorry about that.

Let me try again.....

Well it appears that there's not much demand for a simpler programming language. So it looks like the answer to my question is a resounding no. Nonetheless, thanks to everyone who posted, it was good to get your feedback :)


How about writing your own compiler? A Recursive Descent Parser is easy to understand and construct for making your own Pascal-like language. If it compiles your new language into Swift or Objective-C as its output then that can be loaded into XCode or automatically passed to another compiler to produce the executable binary. Such a parser lends itself well to adding built-in keywords that can translate directly to UIKit/SwiftUI/CoreGraphics/SpriteKit/etc. classes and functions.

Such a compiler is only a few days work even if you know nothing about it to begin with, and requires nothing like the amount of complexity in a project such as LLVM or GCC.

1 Like

I am not sure that's the take away from this thread. I'd rather say: There is a huge demand for a simpler programming language, be it on an Apple platform or any other. It has always been that way. Historically, pretty much from the get go people always wanted to have an easier way of accomplishing things in software (and perhaps also in life in general, but I digress...).

You addressed the business value of such a thing in your opening, basically emphasizing it's a good thing to reduce barriers and enabling more people to develop apps. Unfortunately "more people" means you have a very, very diverse and large set of potential developers. And, even if you think it's complicated and still has a lot of barriers, Swift is basically as good as it gets for now.

Swift, or pretty much any new language, is in a way always the result of people trying to achieve what you set out. The countless evolution discussions on here show that making things easy is pretty much the common goal of any changes (at least that's my impression). Sure, there's disagreements whether a given feature succeeds in that, but the goal is always there.

The only other thing you can do to make a language significantly easier is reduce its applicability. Which then reduces the number of potential developers that can benefit from it, defeating the very motivation that made you write this.

All in all this shows, in my opinion, that there is a limit to making things easier. This may sound trivial, but I really think sometimes people forget that. There is not always a way to make things more easy. If there were, we would at one point in the future just write "make app as I want it" and the compiler gives us a perfect artifact... So we're asymptotically approaching a limit here and Swift (and other modern languages) show that we need much effort to even just get a small step closer towards the probably unachievable goal of finding the perfect, super easy and super useful language.