Apple Swift Lead Discusses Swift 5 in New Podcast

[mamcx]

Developer here with 20+ years of experience:

FYI, the Highest-Perf apps in the iOS App Store are (still) written in an mix of Objective-C & "C".

What is the point of say this? Imply that swift is not for fast apps?

What does this mean for average Joe? Does that meant that more apps will get iOS release also (like Zbrush?) or something else? Sorry, coding is not my area of knowledge

For that, is necessary that Swift have a better support for non-Apple platforms. If I need to have something across many platforms is necessary to use a low-level lang like C/C++/Rust or a runtime like Java/.NET or similar.

This is certainly the biggest problem with swift, IMHO. I wish Apple get serious here and provide first class support for at least linux/windows of the core library:

https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swift_for_androidlinuxwindows_on_2018/

----
Is important to note than instead of

IMHO, Swift is a colossal mistake.

The colossal mistake is C/C++. Both of them are massive bugs-friendly, security-impossible piece of languages that are behind almost all the problems of crashes, weird bugs and security problems for decades now. Costing billons not only in damages but in the amount of time and effort required to workaround them.

The problem is that all the OS today are on top of the "C ABI" ie: Eventually you need to lower your hopes to whatever C can do, not matter how problematic. However, is possible to reduce the surface area and use a better language, like Rust or Swift for most of the tasks and only lower to C for compatibility or to access the vast ecosystem around it.

Swift, like Rust and others, are far from a mistake. Is what is necessary to move the industry forward. Stay forever with C/C++ is like stay with Cobol, but worse.

 

[Vjosullivan]

----- -----

 

[Stella]

Can devs write Swift apps on iOS yet? I think that we should all expect Apple to release Xcode for iPad Pro (if not iOS in general) at WWDC. If Apple wants iPad to fully replace a computer, they’re going to have to enable developers to program on it. It’s about time.

Developers write more than just Swift code on Macs. In this regard, having Xcode won't suffice. iOS still has a long way to go before it can fully replace a PC for developers.

 

[ksec]

I don’t think it will be that significant. A Swift-based Mac app typically has between 10–15 MB worth of libraries. Depending on the number of Swift-based iOS apps a user has, they will maybe save a few hundred MB at most. Considering that the size of iOS firmware itself has increased considerably in recent years, I doubt that there will be a trade-off at all.

He did said "small" apps. Those that are 10 to 30MB nows will get 10 - 15MB reduction. That is up to 50%. And there are many Apple iPhone Default Apps written in Swift, those will get slim down as well.

I think a side benefits is that Apps like Facebook may finally get a rewrite. Instead of a 300MB monster hopefully it could be much smaller.

A detail worth noting:

ABI stability in Swift 5 applies only to the Apple platforms (iOS, macOS, watchOS, tvOS).

ABI stability for non-Apple platforms is a future goal.​

I think they are aiming for Module Compatibility in Swift 5.1, that could be ready for WWDC. Linux ABI stability seems to be taking longer than expected.

I am hoping this year macOS and iOS will be getting major update and redesign in UI as well as massive under the hood changes with Swift.

 

[Stella]

Funny how every generation seems to have to learn software development principles from scratch, even when they're well known and have been around of decades...

Software principles are dynamic, they are not static. i.e., Practices that were routine in the past are now considered bad practice today. Sure, there are principles that don't change often, but overall, its evolving - developers need to keep up to speed.

 

[Frank Dalton]

That statement shows you know very little (nothing) about software development.

Not only is this an unnecessary ad-hominem, it's also completely wrong. I've been developing software since the mid-1990s.

Swift reduces the time to create an app by nearly half, and reduces the complexity of the code.

In what way? I've written software in Swift and haven't found this to be the case.

Swift code also runs faster than objective-c code, especially in math intensive functions.

Source? The only benchmarks I've seen show Swift to be slower. Has that changed recently?

It also takes advantage of memory management functionality that is absent in Objective-C

It's just reference counting. Same thing Objective-C has had since ARC was introduced.

There is no way to "improve" Objective-C to make it equivalent to what Swift is today.

Sure there is.
[doublepost=1551216647][/doublepost]

The colossal mistake is C/C++. Both of them are massive bugs-friendly, security-impossible piece of languages that are behind almost all the problems of crashes, weird bugs and security problems for decades now. Costing billons not only in damages but in the amount of time and effort required to workaround them.

The problem is that all the OS today are on top of the "C ABI" ie: Eventually you need to lower your hopes to whatever C can do, not matter how problematic. However, is possible to reduce the surface area and use a better language, like Rust or Swift for most of the tasks and only lower to C for compatibility or to access the vast ecosystem around it.

Swift, like Rust and others, are far from a mistake. Is what is necessary to move the industry forward. Stay forever with C/C++ is like stay with Cobol, but worse.

I'm not sure where you got the idea that I was advocating "staying" with C/C++ "forever." An evolutionary approach to improving Objective-C could have just as easily lead to the eventual removal of ANSI C compatibility. The creation of Swift is not an inevitable requirement to eliminate any of the issues you've described, it's just one possible approach. And one that I, *personally*, happen to dislike.

 

[mamcx]

I'm not sure where you got the idea that I was advocating "staying" with C/C++ "forever."

I was not saying you was advocating it. I mean more like a observation of why is necessary to move forward.

An evolutionary approach to improving Objective-C could have just as easily lead to the eventual removal of ANSI C compatibility. The creation of Swift is not an inevitable requirement to eliminate any of the issues you've described, it's just one possible approach.

I agree with the overall idea, but I think in practique will not fly with too many developers. Think how much resistance was for python 3, and that is for minor changes.

If a "evolutionary approach" is applied to a language that requiere so many changes, you will end with "obj-c++" and will so different that for all practical purposes is another language.

Then you start thinking in syntax changes (like remove C-style loops for the more sane "for x in y" idioms) and many other stuff and now is more problematic.

Or maybe, do it more slowly and piece meal? Probably with a VERY good source translator than rewrite the code to the new idioms, but then you multiple the times of code review. And still need a very good grasp in where you go so the changes are planed.

I'm unaware something like this have been done sucesfully.

 

[Frank Dalton]

I agree with the overall idea, but I think in practique will not fly with too many developers. Think how much resistance was for python 3, and that is for minor changes.

If a "evolutionary approach" is applied to a language that requiere so many changes, you will end with "obj-c++" and will so different that for all practical purposes is another language.

Then you start thinking in syntax changes (like remove C-style loops for the more sane "for x in y" idioms) and many other stuff and now is more problematic.

Or maybe, do it more slowly and piece meal? Probably with a VERY good source translator than rewrite the code to the new idioms, but then you multiple the times of code review. And still need a very good grasp in where you go so the changes are planed.

I'm unaware something like this have been done sucesfully.

Fair observations. I won't pretend to have a master plan of how it could have been done, but in general terms, I think incremental improvements, as they were already doing before Swift, could have moved us closer to the goalpost. And, eventually, dropping compatibility with C/C++ down the road.

(I have no problem conceding that Swift has *plenty* of nice attributes, but my biggest gripe with it is that it's a constantly changing target [so, re-opening a project from a year ago results in a bunch of compiler errors because they keep changing things] and, worse, it represents a total impedance mismatch with the Cocoa frameworks. The frameworks were not designed for Swift and Swift was deliberately not designed for those frameworks. It makes working with Swift in the context of Mac/iOS applications a drag, IMHO. Others may love it and that's great for them. I tried hard to like it, but I'm just not a fan.)

 

[tzm41]

I have no problem conceding that Swift has *plenty* of nice attributes, but my biggest gripe with it is that it's a constantly changing target [so, re-opening a project from a year ago results in a bunch of compiler errors because they keep changing things] and, worse, it represents a total impedance mismatch with the Cocoa frameworks.

I think most Swift developers accepted that this will be the painful reality for the beginning years of Swift until it is mature enough to be more stable. Migration between Swift versions has become easier and easier in each major version of Swift.

 

[Timemaster]

I don’t think it will be that significant. A Swift-based Mac app typically has between 10–15 MB worth of libraries. Depending on the number of Swift-based iOS apps a user has, they will maybe save a few hundred MB at most. Considering that the size of iOS firmware itself has increased considerably in recent years, I doubt that there will be a trade-off at all.

at this point that will add up fast. If you reduce the size of pretty much every app (including apples own apps) by 10-15 megs each that adds up really fast.
[doublepost=1551222794][/doublepost]

FYI, the Highest-Perf apps in the iOS App Store are (still) written in an mix of Objective-C & "C".

First things first you do not rewrite something that works for a new language. It will follow like I did at my former and even my current employer. New stuff goes in swift old stuff is object-c. Yes we still have to do some object-c for maintenance reason or minor improvement in those area but anything big or brand new features we just crank it out in switch or create an extension to the old object-c file and again write it in swift.
The beauty is they can live side by side in the same project.

 

[Gobie74]

Waiting for swift to have something like async / await. Nested callbacks are such a pain

 

[rjp1]

Waiting for swift to have something like async / await. Nested callbacks are such a pain

Chris Lattner once talked about how he thought that was nicest thing in C# that he wish they had in Swift before he left.

It is not quite the same, but we use PromiseKit (https://github.com/mxcl/PromiseKit). It is developed and maintained by an Apple employee. It helps get rid of all the nested callbacks.

 

[The Cappy]

All large deployed enterprise applications, graphics applications, Logic Pro X, Final Cut Pro X, etc., are in ObjC-ObjC++/C++/C

Some of that’s because of the lack of ABI stability. Even more is because it was already in those languages and you don’t just snap your fingers and switch languages just because you can. A much lesser reason has to do with speed differences. But there are advantages to a language beyond raw speed, like security, ease of coding both in the initial coding and in maintenance, ease of implementing abstruse concepts, etc. If speed was the only thing that mattered, we’d all write in assembly.

 

[Fixey]

FYI, the Highest-Perf apps in the iOS App Store are (still) written in an mix of Objective-C & "C".

A lot of my code is Objective-C and C, looked at Swift but no good for the type of apps I do.

Also most of the SDK is Objective-C and C and Swift is like an add on that is constantly changing and some of the keywords are wrong


let for a constant should of been const.

I prefer Objective-C just easer and nicer to follow than Swift, with all it’s (())??? Objective-C [[]] were as bad as they were made out to be and what about - + method found them useful.

I don’t see the need to rip everything up and recode everything just because Swift so great Apple tells us, I’ve just finished a new framework based in C, for retro game development and I need Objective-C as Swift just useless I find when I dealing with C code and pointers love pointers can’t have enough of them for retro games

 

[hipnetic]

For that, is necessary that Swift have a better support for non-Apple platforms. If I need to have something across many platforms is necessary to use a low-level lang like C/C++/Rust or a runtime like Java/.NET or similar.

This is certainly the biggest problem with swift, IMHO. I wish Apple get serious here and provide first class support for at least linux/windows of the core library:

https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swift_for_androidlinuxwindows_on_2018/

I popped in to ask about this, so thanks for your comments here. I got my CS degree way back in '93, worked with Microsoft VB early on, various things since then, and for the last few years I've been doing Java development, with a smattering of Kotlin exposure. I'd like to find a pet project to work on for an iOS app, but and Swift looks intriguing (from what I've read/seen, it's got a lot of similarities to Kotlin), but I'm disappointed by the Apple-only aspect of it. Jetbrains (the folks behind Kotlin) seem a lot more interested in making their language work across multiple platforms and operating systems.

 

[Fixey]

Yes, anyone in love with their trade should always keep their knowledge up to date. There are some developers so talented and so in love with code they can write Swift one day on a Mac and then write Basic the next day on a Commodore 64. Their vocabulary keeps expanding.

I looked at Swift but no good for the apps I do, but only took me a week to learn Objective-C, same time it took C and C++

ZX BASIC, well I was only a kid my first language so first all ways the longest to learn, the second easer, my second was Assembly so C was like Assembly in BASIC

Probably why I like Objective-C as if your a Obj-C programmer your a C programmer and C is like a Assembly written in BASIC

 

[123]

If speed was the only thing that mattered, we’d all write in assembly.

Not really, most of us are not nearly clever enough to write fast code in assembly. It's exactly the same thing with C++. There's no way Swift (or Obj-C) can beat it when it comes to raw speed, but it is so difficult to thoroughly understand all its concepts and write good C++ that it just doesn't matter. And it has nothing to do with not being sophisticated or tedious or anything (like C and Obj-C), it is actually much more powerful than toy-languages such as Swift, but it is just too hard to master for the average app developer.

 

[shansoft]

That's cuz the developers don't have time to rewrite the application. The highest performance apps have years of code written for it and rewriting it in another language would be a colossal time sink.
[doublepost=1551213377][/doublepost]

Depends on your perspective. The app would be usable in its current state for a very long period of time, but it will get increasingly harder to find qualified people who can maintain it as time goes on.

Imagine a codebase that was written back in 1980s. The paradigms and language features that were used back then is vastly different from what you would do now.

Not because its time consuming to rewrite. Rewrite actually happens pretty often periodically.

The problem is with Swift itself. Language itself is ambiguous, performance not on par with ObjC/C, and other supporting issues such as optional protocol syntax, header organizing, XCode is extremely slow with larger swift project, app size bloating, constant changing syntax between swift version.....etc

In fact, there are a few most well known App out there actually did the opposite, went from Swift to ObjC because all these reasons.

 

[123]

In fact, there are a few most well known App out there actually did the opposite, went from Swift to ObjC because all these reasons.

Interesting. Which ones?

 

[mamcx]

If speed was the only thing that mattered, we’d all write in assembly.

Nope! In fact, with modern compiler techniques, you will beat (almost all the time) any human on planet on this. Compilers are now very good to optimize code that even good assembler developers will miss.

Not underestimate the power of brute force and the ability of rewrite code before it hit the disk.

In fact, I wish instead of C/C++ as "assembler" intel/amd made a more high level target (alike llvm) so even more wins could be possible (this exist on mainframes but for some reasons is not adopted elsewhere)

 

[ipedro]

We've been developing iOS apps with Swift since 2014. Programming language has zero relevance to the concerns you noted.

You must’ve misread. My question was: “Can devs write Swift apps on iOS?” not “for” iOS.

The answer is no. Developers still need a Mac in order to run Xcode to develop iOS apps. That’s a problem if Apple wants to declare that the iPad can replace a Mac and be your only computer.
[doublepost=1551236048][/doublepost]

Developers write more than just Swift code on Macs. In this regard, having Xcode won't suffice. iOS still has a long way to go before it can fully replace a PC for developers.

Can you list what would need to happen on iPad for that to be possible? I’m not a developer but I’m curious.

As a Photographer, I’m so close to having everything I need to making my iPad Pro my one computer. Lightroom for iPad is in fact better than the Mac version. Nothing beats editing directly on the screen. Photoshop is coming. Access to external hardrives via the USB-C port is probably the final piece.

For developers, I wonder what’s still needed to get there.

 

[bjet767]

Ahh the debate of Swift vs OC goes on. The fact is Swift was/is being developed by Apple to expand the numbers of developers for iOS and OS X. It represents a new generation of coders who want something new and different and allows the old grumpy ones to write complaints and comparisons with the good old days.

Personally I started with COBOL, used Assembly, avoided Basic completely, learned C, C++, Objective C and tried some Swift but lost interest. I’m for anything that will help new blood make a living at what they enjoy.

By the way, execution speed of high level languages like Swift are not based on the syntax of the code it’s based on the engine that compiles it into machine based instructions.

 

[shansoft]

Interesting. Which ones?

Some blue / white icon app and some white / red icon apps......

Due to companies policy with Apple, I am not allow to tell.

 

[recoil80]

You must’ve misread. My question was: “Can devs write Swift apps on iOS?” not “for” iOS.

The answer is no. Developers still need a Mac in order to run Xcode to develop iOS apps. That’s a problem if Apple wants to declare that the iPad can replace a Mac and be your only computer.

I think they'll get there, but porting Xcode to the iPad isn't the only necessary step.
What about accessing the file system? I use the simulator a lot as I can easily open a terminal and see my app sandbox environment, I won't be able to do it on iOS. And what if I need to talk to a web service? I can have something on localhost to mock communications with a remote server. And if you write hybrid apps using the web inspector is crucial, but difficult to do on such a tiny display.
My daily driver is my 27'' iMac, I know a lot of developers are fine with a smaller display and I can get work done on my 15'' MBP, but I think I'd be too constrained by a 10 or 12'' iPad pro.

In the end I'm ok with them bringing Xcode to iOS to enable some productivity on the iPad, but I doubt the majority of developers would use an iPad as their main machine, unless iOS evolves a lot and you can easily use external displays
[doublepost=1551257670][/doublepost]

I expect the savings to be significant, especially for small apps. And the savings will increase over time as the built-in library grows.

That will help Swift adoption a lot. Some developers wrote Objective-C apps for the Watch as including Swift increased the binary size before, and that's bad for a Watch app as it takes more time to transfer to the device.

Most of my code base is still Objective-C and I don't feel like replacing existing code with Swift. While it is possibile to have a mix of Swift and ObjC I don't find a compelling reason for that.
Whenever I start something new I use Swift though. Writing iOS apps is more about knowing UIKit than the language, but I like Swift syntax more and I think I'm writing better code.

 

[Stella]

Can you list what would need to happen on iPad for that to be possible? I’m not a developer but I’m curious.

As a reminder, Apple is trying to reach this goal, as you quoted:

If Apple wants iPad to fully replace a computer, they’re going to
have to enable developers to program on it. It’s about time.

So, 3 basic requirements that iOS needs to improve:

- I'm going to need a file system that different Apps can access my source code and other files.

- A mouse - editing code with touch isn't going to work

- Better multi-tasking with improved UI to support this - I have an IDE running debugging an application, without any closing due to lack of memory. The current UI does not allow good placement of applications as we can do currently on a desktop environment.


Still, the above list is just a start there are multiple others ( some of which recoil80 touched on above ) . iPad would just struggle, due to lack of RAM, , UI limitations, sandboxing and walled garden.