
Apple’s Use of Swift in iOS 13 - Timac
https://blog.timac.org/2019/0926-state-of-swift-ios13/
======
losvedir
On paper, Swift is my perfect language. It's like a slightly higher level
rust.

For a while I was enamored of Haskell and its famed "if it compiles it works"
saying, but I think I've realized that the features that contribute to that
are: non-nullability and algebraic data types. Turns out I don't particularly
like the extreme functional nature or (especially) the lazy aspect of it.

Rust is almost there, but then I'm dealing with lifetimes and working a little
lower than I usually need. But I found I _love_ its exhaustiveness checking
for enum variants.

The ML family is pretty much in my sweet spot, for some reason it doesn't
really get the love that it seems it deserves, and last I heard Ocaml had an
issue with being single threaded.

So that leaves Swift, with its non-nullability, algebraic data types, and
exhaustive enum pattern matching. The only downside is its focus on Macs! I'm
holding my breath, waiting for it to run just as smoothly on linux, and
developing some developer cultural cachet and libraries for servers. I hope it
does! I'm glad to see in this article that it's being used more and more at
Apple.

And with SwiftUI, which looks pretty promising, I have to imagine it will only
continue to grow in popularity.

~~~
choxi
Swift feels like a Frankenstein language though, there are so many keywords
and new ones get added in every update. This article here [1] stack ranked a
few languages by number of keywords and Swift is #4 on the list. And in Swift
2.1 they added some more, like properties wrappers and the `some` keyword. It
gets hard to keep track of them all and the special behavior each one implies.

On the other hand, you can kind of make your own language within Swift because
most of the keywords aren't required but allow some additive features. For
example, some features help you write your code functionally and others
support a declaritive style. It reminds me of what's going on with Babel and
JavaScript, where babel extensions are like these language plugins you can mix
and match to create your own language.

If you think of metaprogramming as a way to build your own language within a
language, lisps and Ruby were kind of like pioneers of a build-your-own-
language trend. I could see that as an interesting direction, I wonder if
people have tried it before.

[1] [https://medium.com/the-traveled-ios-developers-
guide/swift-k...](https://medium.com/the-traveled-ios-developers-guide/swift-
keywords-v-3-0-1-f59783bf26c)

~~~
skohan
The thing that makes this work in Swift is the concept of Progressive
Disclosure. One of the main tenants of the language is that it should be
possible to be productive with a small, high-level subset of the language, and
then you can gradually start to utilize the more powerful and obscure parts of
the language as you find needs for them

> you can kind of make your own language within Swift

This is one of my favorite aspects of working with Swift. Because it's a
relatively un-opinionated language with a diverse toolkit, and because of the
powerful type/protocol system, it can really feel like you can carve out a DSL
for each specific use-case.

~~~
ken
> The thing that makes this work in Swift is the concept of Progressive
> Disclosure. One of the main tenants of the language is that it should be
> possible to be productive with a small, high-level subset of the language

"Progressive Disclosure" is an interesting idea for PL research, but IME Swift
doesn't do a very good job at it. There's a million cases I've seen where
people trying to do simple things run into a pandora's box of complexity
(e.g., the infamous "Protocol 'P' can only be used as a generic constraint
because it has Self or associated type requirements"). There isn't really a
"small subset" I've found that's usable for anything but the absolute simplest
programs. Even the fundamental types like Int and String have a lot of not-
entirely-hidden complexity in Swift.

> Because it's a relatively un-opinionated language

It seems awfully opinionated to me. There is a clear preferred way to write
almost anything. Ask online about how to do things differently, and you'll be
told to do it in a more "swifty" way.

> because of the powerful type/protocol system, it can really feel like you
> can carve out a DSL for each specific use-case

I'll have to see if the new features in the latest versions of Swift (used for
SwiftUI) enable this more readily, but as of 4.2, anyway, writing DSLs in
Swift is moderately limited and painful.

------
melling
JetBrains had a recent survey that showed half of all iOS developers were
using Swift only.

[https://www.jetbrains.com/lp/devecosystem-2019/swift-
objc/](https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/)

How about HN devs?

~~~
ctdonath
Pure Swift now.

It wasn't viable as v1, but now it's solid & clean.

Seems like it was a good opportunity to take a well understood language
(C/C++/Obj-C) and after 30 years rebuild it ground-up into what it should be.
Some constructs & workarounds just weren't going away without a clean-slate
industry-wide fully-compatible restart.

Top problem now is getting developers to not force-unwrap optionals unless
unless able to prove it won't cause a crash.

~~~
saagarjha
Force unwrapping optionals is quite useful: it's great syntactic sugar for
what often just gets rewritten as guard/assertionFailure.

~~~
novok
That's so rare in practice that you should just write it out fully. If it's
happening frequently in your app, you should probably rethink your
architecture. As time goes on, I've realized why people think asserts are code
smells of their own.

~~~
saagarjha
Do you not use implicitly unwrapped optionals for IBOutlets?

~~~
ctdonath
If you can prove it won’t be nil, normal IBOutlet included, fine.

------
apple_acc
The reason why Swift isn't being used more is that the Build and Integration
team at Apple forbids the use of Swift for any project that has downstream
dependencies. This is because Swift doesn't support sending out its symbols,
meaning any Swift project has to be fully built and compiled before beginning
compilation of any of its dependencies. They're getting a little more lax on
it now but we've wanted to use Swift for years and are totally unable.

~~~
saagarjha
Do the new XCFramework/module stability improvements help here?

------
ehsankia
I wish they showed percentages, or the total number of binaries. It doesn't
really tell me much that 141 binary use Swift. I want to know what proportion
of iOS uses swift.

~~~
saagarjha
From a very rough check, there are on the order of a couple thousand binaries
in iOS.

------
ww520
I've waded into Swift recently. It's a surprisingly easy language to pick up,
with really nice modern language features. I really hope more platforms
support it.

------
aloer
Anyone here using Swift on the server? Perhaps something in production even?

~~~
prewett
I was thinking about it, however I've found that String performance is
horrible (at least with Japanese strings) if you do anything like hasSuffix()
or hasPrefix(). I think the problem is that String converts to unicode code
points as soon as it seems useful, instead of keeping everything in UTF-8 (or
whatever, really) and doing memcmp for hasSuffix() and hasPrefix()
specifically, which would work much faster. Using NSString everywhere is
faster, but then string concatenation involves a bunch of casting.

I'm not much of a server guy, so I might be wrong here, but dealing with
strings seems like something a server is likely to need to deal with.
Although, maybe the strings are short enough that it's not much of a problem,
or maybe strings that are almost always ASCII are fast. Anyway, something to
keep in mind.

~~~
bluk
Were your performance problems before or after Swift 5's switch to using UTF-8
as the preferred encoding? See
[https://swift.org/blog/utf8-string/](https://swift.org/blog/utf8-string/) .
It sounds like before, so you may want to check out the String performance
again.

Swift 5.0 and 5.1 each supposedly made some 10-20% gain in ARC performance
compared to the previous version (4.2 and 5.0), so that may also help. I think
Swift's performance can be very hit or miss but they (Apple) are making some
good strides.

~~~
prewett
It was Xcode 10.2, I think. (10.something), I think that’s Xcode 5.

hasSuffix() doesn’t need UTF-8 to be performant, though. As long as both
strings are both the same encoding, just go back len(suffix) bytes from the
end of the string and memcmp to see if they are equal.

------
steveklabnik
The site is infinitely redirecting for me;
[https://web.archive.org/web/20190926183124/https://blog.tima...](https://web.archive.org/web/20190926183124/https://blog.timac.org/2019/0926-state-
of-swift-ios13/) is the archive.org version.

~~~
Timac
Are you visiting this page [https://blog.timac.org/2019/0926-state-of-swift-
ios13/](https://blog.timac.org/2019/0926-state-of-swift-ios13/) ?

Which browser are you using? The site has been tested on a couple of platforms
and different browsers. I can't reproduce such a redirecting problem.

~~~
steveklabnik
Yep, same page.

Chrome 76.0.3809.132 (Official Build) (64-bit) (cohort: Stable), Windows 10.

That said, I guess I needed to update Chrome, so I just did to 77.0.3865.90
(Official Build) (64-bit) (cohort: Stable) , and same error.

Here's a "copy as cURL" for the request, maybe that can help?

curl '[https://blog.timac.org/2019/0926-state-of-swift-
ios13/'](https://blog.timac.org/2019/0926-state-of-swift-ios13/') -H
'authority: blog.timac.org' -H 'cache-control: max-age=0' -H 'upgrade-
insecure-requests: 1' -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64;
x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36'
-H 'sec-fetch-mode: navigate' -H 'sec-fetch-user: ?1' -H 'accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,
_/_ ;q=0.8,application/signed-exchange;v=b3' -H 'sec-fetch-site: cross-site'
-H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9'
\--compressed

------
pier25
Do you think Objective C will be phased out some day?

(As in not usable for development in the Apple ecosystem)

~~~
bsaul
Objective c probably will be phased out before C will. Objective-C libraries
are themselves a wrapper over optimized C, which is what constitutes most of
ios core.

I don’t think swift will phase out C until a very long time. It still needs to
sort its performance issues related to memory automatic reference counting and
global lock. Which requires something close to rust borrow checker, but with
an even more advanced technology to keep the syntax beginner friendly.

------
lenkite
Will start using Swift once they add C++ interop. Right now mixing Objective-C
and C++ is easy. This is not the case for Swift.

------
matchbok
Happy to see, it's a wonderfully designed language that's a joy to write.
Super powerful enums, pattern matching, etc.

------
viburnum
Is this why the Podcast app has become so buggy?

~~~
saagarjha
Podcasts still appears to be mostly Objective-C.

