27 ms·

Apple’s use of Swift and SwiftUI in iOS 14

186 points by Timac 6y ago

surfsvammel 6y ago
The calculator being the first app for which they used Swift... I’m guessing a calculator app was the first app many Swift programmers wrote after viewing the excellent Swift lectures from Stanford.
- pvg 6y ago
  It's been an Interface Builder tutorial/demo since before the Apple days.
  - AntiRush 6y ago
    And, in fact, from the very early Macintosh Days: https://www.folklore.org/StoryView.py?story=Calculator_Construction_Set.txt https://www.folklore.org/StoryView.py?story=Calculator_Const...
  - Austin_Conlon 6y ago
    The Stanford lecturer Paul Hegarty also worked at NeXT, probably during those days.
mobilio 6y ago
Maybe soon we can see similar numbers in macOS?
- saagarjha 6y ago
  macOS is following a similar trajectory.
kensai 6y ago
What are the advantages, if any, in a nutshell?
- akmarinov 6y ago
  Of Swift and SwiftUI?
- ratww 6y ago
  Advantages of Swift and SwiftUI? Nevermind, I'll try to answer both: For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. It has a modern type system with type inference, string templating, Option type, tuples and simpler closures. It's pretty nice actually. SwiftUI is just a way of writing UIs using Swift and a reactive paradigm. It looks and feels like React but instead of the embedded HTML of React it only uses plain Swift. The previous recommended method used XML (in XIB files) and needed special tooling (Interface Builder), which was nice but not perfect. Also doing git merges in the XML files are much harder.
  - _qulr 6y ago
    > For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. That doesn't seem accurate. Interoperability with C and Objective-C was a fundamental design requirement of Swift. C interoperability is not particularly pleasant in Swift, but it's certainly there. It has to be there. Apple has been creating some easier to use Swift wrappers around old UNIX C API. For example, their Network framework, and the just-announced Swift System.
    - Jtsummers 6y ago
      I think GP meant syntactic compatibility. Objective-C is an embedding within C and C++ code and has to be (mostly) compatible with them for the free mingling of each language. Swift is freed from that need, but that doesn't mean it isn't designed for interop (calling between each language).
    - ratww 6y ago
      No, it is accurate. Notice I didn't say interoperability, I said backwards compatibility. Objective-C is a superset of C, so any valid C code is also valid Objective-C code, including all the pitfalls and footguns. This is similar to the relationship between C and C++, however C++ isn't strictly a superset of C.
melling 6y ago
It has been 6 years since the debate of using Swift or Objective C for iOS development began. It was like pulling teeth trying to convince developers to use Swift. https://h4labs.wordpress.com/2016/02/09/should-i-use-objective-c-or-swift-for-writing-ios-apps/ https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti... The “shiny new toy” argument doesn’t hold for long with Apple. You quickly get left behind in the Apple ecosystem if you don’t move with Apple. While every language, environment, etc doesn’t need to move this fast, I personally prefer to jettison legacy sooner.
- _qulr 6y ago
  > You quickly get left behind in the Apple ecosystem if you don’t move with Apple. The number of binaries and frameworks in iOS 14 using Objective-C vastly exceeds this relatively small list. Objective-C hasn't been jettisoned by Apple by any stretch of the imagination.
  - machello13 6y ago
    No, but they're releasing new frameworks with Swift-only APIs. They're not "jettisoning" Objective-C, and I'm sure teams at Apple will continue to write stuff in Obj-C for years to come. It'll likely never disappear entirely. But that number will continue to shrink.
    - Apocryphon 6y ago
      That's only because WidgetKit uses SwiftUI. Granted, if more and more APIs become reliant on preexisting Swift-only APIs like SwiftUI or Core ML, that certainly leaves Objective-C out of the cutting edge.
  - CharlesW 6y ago
    > Objective-C hasn't been jettisoned by Apple by any stretch of the imagination. True, but melling didn't say that Objective-C has been jettisoned. My understanding is that you can't iOS home screen widgets in Objective-C, correct? If so, isn't that a reasonably-clear signal that Objective-C developers are starting to be left behind?
dmitriid 6y ago
It's a good thing Apple is dogfooding. This means that a lot of issues and corner cases will be ironed out. On iOS. However, looking at the abysmal quality of apps they have been releasing on MacOS in the past few years, I wouldn't hold my breath.
- machello13 6y ago
  Big Sur has some rough edges right now that I hope will get ironed out (fortunately, they're mostly UI issues and not performance/stability), but using it for the past couple months has made me a little more optimistic about the Mac's future. They've brought over a lot of common-sense features and design ideas from iOS, but in a way that embraces the Mac's unique features, rather than feeling like a refresh-for-the-sake-of-a-refresh. My favorite is a much clearer contrast between active and inactive windows.
  - dmitriid 6y ago
    None of those changes are SwiftUI though. It's a new skin. And very few of those changes are new apps. In the past few years we've had anything from the new native AppStore that doesn't have a single consistent behaviour [1] to the plethora of half-baked barely functioning app stubs in Swift UI/Catalyst [2]. These are first-party apps by Apple themselves, and they are perfectly fine with the state they are in, and they had no qualms whatsoever when releasing them. That's what "obsessive attention to details"[3] has been on the Mac for the past many years. The very few examples/exceptions (Big Sur's Messages) are exactly that: very few. [1] https://grumpy.website/post/0RsaxCu3P https://grumpy.website/post/0RsaxCu3P and https://grumpy.website/post/0RsafwyK8 https://grumpy.website/post/0RsafwyK8 and https://grumpy.website/post/0SpwtkNB_ https://grumpy.website/post/0SpwtkNB_ [2] Home, News, Podcasts, Developer App... [3] That's from BigSur's marketing video
    - leadingthenet 6y ago
      I can’t believe you’re downvoted for criticising Apple on a thing they objectively pooped the bed on in the past couple of years. Mac apps released by Apple have been a mishmash of very inconsistent design lately, most people in the Mac enthusiast community even agree with this (think Gruber, Marco, etc.)...
jamil7 6y ago
I’ve been pretty on board with SwiftUI and have adopted it liberally in 2 apps but I’m a little disappointed with the state of it right now. Apple is seemingly dusting their hands after this years WWDC leaving us with something thats still half baked and filled with bugs, some that haven’t been fixed since the first announcement.
- gman83 6y ago
  Curious how it compares with other reactive mobile frameworks like Jetpack Compose (which my colleague says is not at all ready for primetime) and Flutter (which he says is great). Any thoughts?
  - jamil7 6y ago
    Conceptually it’s great and when it’s more stable I can’t imagine a faster way of building a cross platform Apple app that looks and feels correct. Styling a react native app felt tedious in comparison. Jetpack Compose appears to be going in a similar direction but last I checked it’s a long way off as you mention. Flutter is interesting but I have very limited experience, I was initially turned off by dart and the heavy focus on Android. I keep hearing positive things on HN and from other people though so I want to give it a another proper go. Overall it’s a bit of an awkward time for mobile development.
    - gman83 6y ago
      Thanks for the response. I have some personal experience with React Native which feels like a dead end to me. We've been building our apps with our small team with Swift (not SwiftUI) and Kotlin on Android, but the difficulty in keeping feature parity and UI consistency across platforms has tempted us to try Flutter, but as you say we're worried about how well the iOS widgets are replicated, also the accessibility story on Flutter seems not great, which is a moral problem for us as we don't want to exclude people with disabilities.
      - ghostwreck 6y ago
asadlionpk 6y ago
I recently did a side-project[1] as a chance to learn SwiftUI. Their docs were not so great and I didn't want to reverse engineer their API + document it. So I used React Native + Swift backend. Hopefully they improved/will improve the docs. https://asadmemon.com/projects/screenshothero/ https://asadmemon.com/projects/screenshothero/
stephc_int13 6y ago
The only hope I have about Swift is that Apple won't try to force every devs to use their language to release apps/games on their platforms. For now it is possible to use standard API (C/C++, Posix, OpenGL, Vulkan) But I have a bad feeling about this.
- kennywinker 6y ago
  Apple has always taken a position something like "do it our way, or you're on your own" with their developer tools - but I don't see the situation getting any WORSE any time soon. Apple has so much code that's written in C, C++, or ObjC, that I don't imagine they'll ever be in a position to drop support for those languages. So as long as your language is able to interop with C/C++ or ObjC you're going to be fine.
- pjmlp 6y ago
  Ironically that is how the game industry has evolved from Assembly, to C, to C++, to middleware using C# or Java,... Via the languages forced into game devs from platform SDKs.
  - stephc_int13 6y ago
    Well. C# and Java can be considered, at best, as branches in this evolution scheme. C++ is by far the dominant language to create games today, and IMHO, for the foreseeable future. Google tried to force every dev to use Java on Android for a while, but they finally and reluctantly added the NDK (C/C++) so that game devs would port their engines and games.
    - pjmlp 6y ago
      That is how C++ started to be used back in the 16 bit days. Oh the arguments how it was an heresy to even think contaminating the source code with C++ constructs. Track down any C vs C++ flamewar on Usenet back in those days. NDK exists since Android 2.0, hardly anything new, as is currently more castrated than on those days. It is impossible to create a production level game engine in Android without reaching out to Java, given the API surface. Game devs will use whatever the platform owner puts them on the table, when the platform is enticing enough to refuse being part of the party. Just like if enough Indies make money with HTML 5 games, some bigger studios will eventually suck it up and use JavaScript, WebGL, and whatever tooling targets WebAssembly.
61gun 6y ago
I recently started using swiftUI for a simple app. I loved it until i got a bug that causing a working app to stop working at all. I solved the bug by creating new app and copying everything to it. That's state of SwiftUI for me and i think it shouldn't be the case when you talk about Apple.
- zepto 6y ago
  That doesn’t sounds like it has anything at all to do with SwiftUI, but rather sounds like a bug in XCode. Just as annoying for sure.
- colejohnson66 6y ago
  Did you diff the old project with the new one? Maybe a config file got messed up?
  - deleted 6y ago
    [deleted]
lenkite 6y ago
I am so glad we sticked to Objective-C++ and UIKit. After reading all the comments here, it looks like SwiftUI will take another 2 years to stabilize.
- jamil7 6y ago
  Yeah. You could start introducing some Swift now for new code but I’d stay well clear of SwiftUI outside of widgets.
- pjmlp 6y ago
  The main problem with Objective-C++ is that only us old timers still have documentation available. Most newcomers won't even know it exists.
- zionic 6y ago
  Objective-C on UIKit in 2020?! You should absolutely be using Swift for all new UIKit view controllers, note that SwiftUI is not a requirement for usage of swift.
jimstead 6y ago
Having written prod code in asm, fortran, pascal, c, c++, java, basic, objc, and swift, I'm weary of arguments about better languages. But what is inarguably true about Apple (and before it NeXT) technology is they are not afraid to jettison what they decide is behind them, though it may linger a long time. Swift and SwiftUI is clearly the path forward.

186 points by Timac 6y ago

The calculator being the first app for which they used Swift... I’m guessing a calculator app was the first app many Swift programmers wrote after viewing the excellent Swift lectures from Stanford.

pvg 6y ago
It's been an Interface Builder tutorial/demo since before the Apple days.
- AntiRush 6y ago
  And, in fact, from the very early Macintosh Days: https://www.folklore.org/StoryView.py?story=Calculator_Construction_Set.txt https://www.folklore.org/StoryView.py?story=Calculator_Const...
- Austin_Conlon 6y ago
  The Stanford lecturer Paul Hegarty also worked at NeXT, probably during those days.

mobilio 6y ago

Maybe soon we can see similar numbers in macOS?

saagarjha 6y ago
macOS is following a similar trajectory.

kensai 6y ago

What are the advantages, if any, in a nutshell?

akmarinov 6y ago
Of Swift and SwiftUI?
ratww 6y ago
Advantages of Swift and SwiftUI? Nevermind, I'll try to answer both: For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. It has a modern type system with type inference, string templating, Option type, tuples and simpler closures. It's pretty nice actually. SwiftUI is just a way of writing UIs using Swift and a reactive paradigm. It looks and feels like React but instead of the embedded HTML of React it only uses plain Swift. The previous recommended method used XML (in XIB files) and needed special tooling (Interface Builder), which was nice but not perfect. Also doing git merges in the XML files are much harder.
- _qulr 6y ago
  > For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. That doesn't seem accurate. Interoperability with C and Objective-C was a fundamental design requirement of Swift. C interoperability is not particularly pleasant in Swift, but it's certainly there. It has to be there. Apple has been creating some easier to use Swift wrappers around old UNIX C API. For example, their Network framework, and the just-announced Swift System.
  - Jtsummers 6y ago
    I think GP meant syntactic compatibility. Objective-C is an embedding within C and C++ code and has to be (mostly) compatible with them for the free mingling of each language. Swift is freed from that need, but that doesn't mean it isn't designed for interop (calling between each language).
  - ratww 6y ago
    No, it is accurate. Notice I didn't say interoperability, I said backwards compatibility. Objective-C is a superset of C, so any valid C code is also valid Objective-C code, including all the pitfalls and footguns. This is similar to the relationship between C and C++, however C++ isn't strictly a superset of C.

melling 6y ago

It has been 6 years since the debate of using Swift or Objective C for iOS development began. It was like pulling teeth trying to convince developers to use Swift. https://h4labs.wordpress.com/2016/02/09/should-i-use-objective-c-or-swift-for-writing-ios-apps/ https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti... The “shiny new toy” argument doesn’t hold for long with Apple. You quickly get left behind in the Apple ecosystem if you don’t move with Apple. While every language, environment, etc doesn’t need to move this fast, I personally prefer to jettison legacy sooner.

_qulr 6y ago
> You quickly get left behind in the Apple ecosystem if you don’t move with Apple. The number of binaries and frameworks in iOS 14 using Objective-C vastly exceeds this relatively small list. Objective-C hasn't been jettisoned by Apple by any stretch of the imagination.
- machello13 6y ago
  No, but they're releasing new frameworks with Swift-only APIs. They're not "jettisoning" Objective-C, and I'm sure teams at Apple will continue to write stuff in Obj-C for years to come. It'll likely never disappear entirely. But that number will continue to shrink.
  - Apocryphon 6y ago
    That's only because WidgetKit uses SwiftUI. Granted, if more and more APIs become reliant on preexisting Swift-only APIs like SwiftUI or Core ML, that certainly leaves Objective-C out of the cutting edge.
- CharlesW 6y ago
  > Objective-C hasn't been jettisoned by Apple by any stretch of the imagination. True, but melling didn't say that Objective-C has been jettisoned. My understanding is that you can't iOS home screen widgets in Objective-C, correct? If so, isn't that a reasonably-clear signal that Objective-C developers are starting to be left behind?

dmitriid 6y ago

It's a good thing Apple is dogfooding. This means that a lot of issues and corner cases will be ironed out. On iOS. However, looking at the abysmal quality of apps they have been releasing on MacOS in the past few years, I wouldn't hold my breath.

machello13 6y ago
Big Sur has some rough edges right now that I hope will get ironed out (fortunately, they're mostly UI issues and not performance/stability), but using it for the past couple months has made me a little more optimistic about the Mac's future. They've brought over a lot of common-sense features and design ideas from iOS, but in a way that embraces the Mac's unique features, rather than feeling like a refresh-for-the-sake-of-a-refresh. My favorite is a much clearer contrast between active and inactive windows.
- dmitriid 6y ago
  None of those changes are SwiftUI though. It's a new skin. And very few of those changes are new apps. In the past few years we've had anything from the new native AppStore that doesn't have a single consistent behaviour [1] to the plethora of half-baked barely functioning app stubs in Swift UI/Catalyst [2]. These are first-party apps by Apple themselves, and they are perfectly fine with the state they are in, and they had no qualms whatsoever when releasing them. That's what "obsessive attention to details"[3] has been on the Mac for the past many years. The very few examples/exceptions (Big Sur's Messages) are exactly that: very few. [1] https://grumpy.website/post/0RsaxCu3P https://grumpy.website/post/0RsaxCu3P and https://grumpy.website/post/0RsafwyK8 https://grumpy.website/post/0RsafwyK8 and https://grumpy.website/post/0SpwtkNB_ https://grumpy.website/post/0SpwtkNB_ [2] Home, News, Podcasts, Developer App... [3] That's from BigSur's marketing video
  - leadingthenet 6y ago
    I can’t believe you’re downvoted for criticising Apple on a thing they objectively pooped the bed on in the past couple of years. Mac apps released by Apple have been a mishmash of very inconsistent design lately, most people in the Mac enthusiast community even agree with this (think Gruber, Marco, etc.)...

jamil7 6y ago

I’ve been pretty on board with SwiftUI and have adopted it liberally in 2 apps but I’m a little disappointed with the state of it right now. Apple is seemingly dusting their hands after this years WWDC leaving us with something thats still half baked and filled with bugs, some that haven’t been fixed since the first announcement.

gman83 6y ago
Curious how it compares with other reactive mobile frameworks like Jetpack Compose (which my colleague says is not at all ready for primetime) and Flutter (which he says is great). Any thoughts?
- jamil7 6y ago
  Conceptually it’s great and when it’s more stable I can’t imagine a faster way of building a cross platform Apple app that looks and feels correct. Styling a react native app felt tedious in comparison. Jetpack Compose appears to be going in a similar direction but last I checked it’s a long way off as you mention. Flutter is interesting but I have very limited experience, I was initially turned off by dart and the heavy focus on Android. I keep hearing positive things on HN and from other people though so I want to give it a another proper go. Overall it’s a bit of an awkward time for mobile development.
  - gman83 6y ago
    Thanks for the response. I have some personal experience with React Native which feels like a dead end to me. We've been building our apps with our small team with Swift (not SwiftUI) and Kotlin on Android, but the difficulty in keeping feature parity and UI consistency across platforms has tempted us to try Flutter, but as you say we're worried about how well the iOS widgets are replicated, also the accessibility story on Flutter seems not great, which is a moral problem for us as we don't want to exclude people with disabilities.
    - ghostwreck 6y ago

asadlionpk 6y ago

I recently did a side-project[1] as a chance to learn SwiftUI. Their docs were not so great and I didn't want to reverse engineer their API + document it. So I used React Native + Swift backend. Hopefully they improved/will improve the docs. https://asadmemon.com/projects/screenshothero/ https://asadmemon.com/projects/screenshothero/

stephc_int13 6y ago

The only hope I have about Swift is that Apple won't try to force every devs to use their language to release apps/games on their platforms. For now it is possible to use standard API (C/C++, Posix, OpenGL, Vulkan) But I have a bad feeling about this.

kennywinker 6y ago
Apple has always taken a position something like "do it our way, or you're on your own" with their developer tools - but I don't see the situation getting any WORSE any time soon. Apple has so much code that's written in C, C++, or ObjC, that I don't imagine they'll ever be in a position to drop support for those languages. So as long as your language is able to interop with C/C++ or ObjC you're going to be fine.
pjmlp 6y ago
Ironically that is how the game industry has evolved from Assembly, to C, to C++, to middleware using C# or Java,... Via the languages forced into game devs from platform SDKs.
- stephc_int13 6y ago
  Well. C# and Java can be considered, at best, as branches in this evolution scheme. C++ is by far the dominant language to create games today, and IMHO, for the foreseeable future. Google tried to force every dev to use Java on Android for a while, but they finally and reluctantly added the NDK (C/C++) so that game devs would port their engines and games.
  - pjmlp 6y ago
    That is how C++ started to be used back in the 16 bit days. Oh the arguments how it was an heresy to even think contaminating the source code with C++ constructs. Track down any C vs C++ flamewar on Usenet back in those days. NDK exists since Android 2.0, hardly anything new, as is currently more castrated than on those days. It is impossible to create a production level game engine in Android without reaching out to Java, given the API surface. Game devs will use whatever the platform owner puts them on the table, when the platform is enticing enough to refuse being part of the party. Just like if enough Indies make money with HTML 5 games, some bigger studios will eventually suck it up and use JavaScript, WebGL, and whatever tooling targets WebAssembly.

61gun 6y ago

I recently started using swiftUI for a simple app. I loved it until i got a bug that causing a working app to stop working at all. I solved the bug by creating new app and copying everything to it. That's state of SwiftUI for me and i think it shouldn't be the case when you talk about Apple.

zepto 6y ago
That doesn’t sounds like it has anything at all to do with SwiftUI, but rather sounds like a bug in XCode. Just as annoying for sure.
colejohnson66 6y ago
Did you diff the old project with the new one? Maybe a config file got messed up?
- deleted 6y ago
  [deleted]

lenkite 6y ago

I am so glad we sticked to Objective-C++ and UIKit. After reading all the comments here, it looks like SwiftUI will take another 2 years to stabilize.

jamil7 6y ago
Yeah. You could start introducing some Swift now for new code but I’d stay well clear of SwiftUI outside of widgets.
pjmlp 6y ago
The main problem with Objective-C++ is that only us old timers still have documentation available. Most newcomers won't even know it exists.
zionic 6y ago
Objective-C on UIKit in 2020?! You should absolutely be using Swift for all new UIKit view controllers, note that SwiftUI is not a requirement for usage of swift.

jimstead 6y ago

Having written prod code in asm, fortran, pascal, c, c++, java, basic, objc, and swift, I'm weary of arguments about better languages. But what is inarguably true about Apple (and before it NeXT) technology is they are not afraid to jettison what they decide is behind them, though it may linger a long time. Swift and SwiftUI is clearly the path forward.