Apple's use of Swift and SwiftUI in iOS 17

I think that’s impossible, Swift should try to be a great language for building Mac/iOS apps and hopefully frameworks.

But what do I know. I wouldn’t think writing a new industry grade C++ compiler in a modular architecture would be feasible. Just use GCC. And yet here we are with clang and LLVM.

There will be language subsets for embedded and kernel development, not all features would be able to be used at the lower levels.

1. https://www.youtube.com/watch?v=lgivCGdmFrw

1. The empirical evidence does not support the notion of fewer bugs, even for static typing, never mind Swift

And no, this is not from lack of trying. People have tried to show this time and time again. And time and time again they end up not showing it, with effect sizes tiny and pointing in both directions.

And as an anecdotal example: which way has Apple software quality gone since they started adopting Swift and SwiftUI? System Settings anyone?

2. Swift is slow, not fast

I did fairly extensive research for on this for chapter 9 of my macOS/iOS Performance book. Even those cases where I fully expected Swift to be faster, which were not numerous, it managed to be slower. And there are really egregiously bad examples, like Swift Coding, which despite the overwhelming evidence to the contrary some people still believe to be fast.

Why do they believe it to be fast? Because so much work can be done in the compiler. So it must be fast. But it just is not. In fact, it's ludicrously slow. This is probably lesson #1 from performance optimisation: things are not fast because simply you did something that you believe to be fast. You need to measure to figure out whether they are fast and in order to figure out how to make them fast.

(And those mistaken beliefs actually lead to slow code, because you already did the thing that makes it fast, not need to check or optimise. I am pretty confident that a similar effect happens with static typing and safety.)

Or check out the computer languages shootout. Swift tends to be somewhat on par with Java. Which is not particularly fast.

3. Swift needs loads of runtime

For example, due to the somewhat bizarre idea of having protocols be polymorphic over (pass-by-value) structs and (pass-by-reference) objects, Swift has to dynamically dispatch the copying of individual arguments to a function when protocols are involved. If you're both lucky and not using modular code, the compiler may be able to figure out how to elide that dispatch. But it won't tell you if it managed to figure it out or not.

Oh, and speaking from 30+ years of experience: message passing simply is not the bottleneck in 99%+ of the cases, and if it is it is fairly trivial to remove.

Swift most certainly has a runtime: https://github.com/apple/swift/tree/main/stdlib/public/runti... And most or all of it is written in C++, not Swift last I checked. Whenever you see a `_swift_fooBarBaz` symbol in a stack trace, that's the runtime.

But now, the Apple brand has its own status, independently of any particular group. Their products have gone the same way.

Prior to some Swift version — Swift 4? don't remember — iOS apps that used Swift did have to bring their own runtime, and iirc this was because Swift was evolving so fast that Apple wasn't willing or able to commit to including a bunch with iOS.

as the apps get big, state becomes a mess, fully reusing code is very hard, making anything even slightly reactive becomes not only a lot of code, but a jumbled mess of mutability, usually copy pasted from somewhere else. I will take any other type of app over that - I don't care if it's angular, vue, react, next, whatever.

So i contend that not only is "managing a bit of state and writing sensible CSS to make it reusable" very hard, I haven't even seen it done ever, at least in my personal experience of the code I touched

Sometimes you choose hypothetically difficult debugging if it eliminates the need to deal with the mechanics of the lowest level of interacting with a system. If you haven't needed to do that, then you'd be inclined to think it's an unlikely situation to be in.

Xcode presents the equivalent of a “header” when you follow a symbol to a framework you don’t have the source for… it’s a swift file full of definitions only and no implementations. The compiler emits this for you automatically as a .swiftinterface file

> or keep things non-`public`

I definitely am a swift developer that would complain about this. It’s way too easy to be cavalier about using the “public” keyword and making things part of the public API when they probably shouldn’t be. It’s like engineers have muscle memory from Java and just type “public class” without really questioning why first.

That problem was already solved with header files; trivial to split interface from implementation, they’re just two different files. But sometime around the 90s, probably Java and this was deemed inconvenient. Now we’re trying to reinvent that same pattern

Why parse out a whole C file when you can get the only bits that matter for compiling your file from a 30 line header?

Possibly in ways that are very inconvenient/hard to use in Obj-C.

Of course, C has a lot of ugly traps which makes it less than ideal for this domain. This hypothetical subset language addresses those issues. While, again, you would only reach for the 'Objective' parts when your code benefits from being object oriented.

It is true that the inherit dynamism of message passing makes static analysis impossible to cover all cases, but as with all things in life there are tradeoffs. You lose the nice aspects of object oriented systems if you do not allow for that, and OO is particularly well suited to UI code.

Of course, Swift abandoned the object oriented model completely. Which is fine. But Objective-C showed that you can have your cake an eat it too, offering OO where appropriate, and a non-OO language for everything else.

Objective-C's downfall was really just in that C didn't age well – which, among other things, I am sure contributed to seeing the use of the 'Objective' bits where they weren't really appropriate.

Honestly though, the problem with XCode for me is 90% that the autocomplete is just enormously stupid (they need to just ask JetBrains how to do it), and that Swift compilation is slow (which they are working on).