Apple Swift Lead Discusses Swift 5 in New Podcast

[gnasher729]

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

That's because they have a large existing codebase written in ObjC-ObjC++/C++/C and not bothering to switch wholesale to Swift without a good reason. Wait until you get that kind of app, with development started say in 2017.
[doublepost=1551277511][/doublepost]

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.

The demand for this by profession developers is zero. Apple _doesn't_ want the iPad to fully replace a computer - they want people to buy iPads when they don't _need_ computers. Especially if they have PCs and don't _need_ a computer.
[doublepost=1551277744][/doublepost]

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

You know you don't have to write callbacks in a nested form? You can just create a sequence of closure variables.
[doublepost=1551278103][/doublepost]

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.

It's all a matter of time. I could write code that is a bit faster than the compiler's code, but it takes ages. It's far more effective to spend the same amount of time on improving your algorithms. And it's much much more effective in my experience to look for code that does something totally stupid, and then you get often dramatic improvements by not doing stupid things

 

[RedGala]

IMHO, Swift is a colossal mistake. They should have continued improving Objective-C instead of indulging in what amounts to a compiler programmer's pet project.

It's an open source project, and it allows them to cultivate a great community of developers. Swift is a pretty good language, and I'd argue that most developers weren't really happy with Objective-C. Swift also has a lower learning curve, which makes all the Swift Playgrounds and high school app development workshops easier to advertise and run.

 

[chrono1081]

This has nothing to do with iOS getting ZBrush. ZBrush won't be written in Swift. They'll stick to C++ with interfaces to the native platform it's on and that is ObjC via ObjC/ObjC++ bridge and C#/C++ on Windows.

However, ZBrush on Mac will sooner or later have to port itself to Metal 2 API.

No it won't. ZBrush doesn't use GPU processing, it's entire little world lives in the CPU. They even state it in it's system requirements: https://pixologic.com/zbrush/system/

 

[djtech42]

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

no need to wait: https://github.com/yannickl/AwaitKit

 

[M150]

There are only specific cases why apps should use C/C++ now days. With the advanced optimisation compilers achieve the difference in performance should be negligible. The app I am working on is a mixture of Swift and C++. The only reason I have to use C++ is for the real-time audio part. Neither Objective C or Swift are suitable as they cannot guarantee the audio thread will not be blocked which causes glitches. Objective C is no faster than Swift and for for developers there is no need to learn it unless you have to support legacy applications. Swift is a more modern language.

 

[djtech42]

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

The development of Swift was a big push to getting ARC into Objective-C: https://twitter.com/clattner_llvm/status/1009829475792531457

 

[0924487]

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

You know swift is just a layer over c, right? In the end part from the additional libraries, it will be compiled down to machine code using pretty much a two step c compiler. The first step is compile down to c and c extension, then second step is down to machine code. When you run the binary, there is no difference between c and swift, because the architecture is pretty much the same.

 

[djtech42]

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.

Yeah, it wouldn't have been possible for Swift to be as stable in terms of changing as Objective-C right away. It was a brand new language. It will eventually even out (and already has started to) because the fundamentals will be established.

 

[Frank Dalton]

It's an open source project, and it allows them to cultivate a great community of developers. Swift is a pretty good language, and I'd argue that most developers weren't really happy with Objective-C.

You'd argue this based on what?

Swift also has a lower learning curve, which makes all the Swift Playgrounds and high school app development workshops easier to advertise and run.

There are plenty of other "easier" languages that can be used for teaching purposes. Swift was not necessary for this.
[doublepost=1551288935][/doublepost]

The development of Swift was a big push to getting ARC into Objective-C: https://twitter.com/clattner_llvm/status/1009829475792531457

I'm aware of that. But Swift didn't *need* to happen for things like this to be added for Objective-C.
[doublepost=1551288996][/doublepost]

There are only specific cases why apps should use C/C++ now days.

You mean like the Swift compiler itself?

 

[mms13]

ITT: A lot of people who think they know what they are talking about. I particularly loved the guy who, without citing a source, claimed that all the "Highest-Perf" (what does this even mean/why does it matter?) apps are written in Objective-C.

- iOS Developer who has been shipping production Swift apps for 4+ years

 

[elmateo487]

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

are you telling me that somehow Obj C is so much slower as a language that swift can't perform like the objc? Because if that's what you are saying.... you are extremely wrong.

The "highest-perf" (whatever that means) apps on the store use ObjC because its expensive to switch, with little gain. If they rewrote their apps today, guess what, it would be in Swift.
[doublepost=1551316465][/doublepost]

So this is a dumb question but why the hell can’t i use Swift on my iPad Pro?

You can

 

[travelsheep]

Most requested feature: no Developer Program annual fee (currently 99 USD)

 

[bjet767]

This has devolved into the typical Swift vs OC/C thread.

The truth is the compiler does the work of optimization. Where things slow down is when objects are called by a single line of code they do all their stuff in the background. The coder has no control over how the library developers wrote their algorithms so the he/she is at the mercy of the quality of the underlying libraries and associated efficiencies.

Now if one thinks they can improve on or need a feature not in the library you write it yourself and if that sometimes means going to a lower level language. If that's too much work live with what is provided.

Swift is just another higher level language designed by a new generation (the guy given the credit is now in his 40s and not so young anymore) whose goal is/was to thing "better" than those who came before them. Is it better? The answer lies in how many apps and programs written before Swift came into the light. So no it is not better nor is it worse, it will bring new developers into the fold who want something new and fresh to call their own.

What I think is interesting about Swift is the idea of no pointers, which makes programming concepts a lot less difficult to understand.

 

[Jyby]

Science Rules!

 

[Vjosullivan]

There are many successful companies that rewrite code constantly... Id Software, Facebook, Apple, Microsoft etc...

If you don't rewrite your code overtime and keep pace with technology people are actively using (not talking about bleeding edge). You're gunna suck more and more... and bright young people aren't going to want to work for you..

"rewrite code constantly" and "rewrite your code overtime" are good strategies but also the opposite to what was being referred to. It is throwing your code base out and rewriting from scratch which is the recipe for disaster that you should avoid.

 

[Jyby]

Science Rules!

 

[Doctor Q]

And then look at old dinosaurs like medical equipment manufactures... So expensive for them to release and be competitive cause their code is 25+ years old and tied to technology that is being harder to find manufacturing for....

The U.S. Internal Revenue Service runs ancient COBOL programs, for practical reasons:

Quote:

When it comes to working code, the longer it’s been running, the better it becomes as bugs and inefficiencies are eliminated over time. CIOs from the Department of Health and Human Services, the IRS and the Defense Department are just a few that have said that their legacy systems, written in Assembler and COBOL, are well written and can be kept current through ongoing stewardship.​

 

[cmaier]

You know swift is just a layer over c, right? In the end part from the additional libraries, it will be compiled down to machine code using pretty much a two step c compiler. The first step is compile down to c and c extension, then second step is down to machine code. When you run the binary, there is no difference between c and swift, because the architecture is pretty much the same.

No, swift is not a layer over C. It is not compiled to C on the way to machine code. It is compiled to llvm.

The binary that results from compiling swift may be different than the binary that results from compiling C. It may be better or may be worse, but it will certainly be different. They will also use different runtime environments that provide different behaviors and features (like memory management), so behavior will be quite different for anything more complicated than “hello world.”
[doublepost=1551628144][/doublepost]

Most requested feature: no Developer Program annual fee (currently 99 USD)

You don’t need to pay if you aren’t distributing apps. And if you are distributing apps, the $99 should be affordable (and may be deductible from your taxes depending on your jurisdiction. See a tax lawyer).

 

[Timemaster]

Yeah, I agree certain people are not capable of doing that well... I would love to rewrite my companies code from scratch

You are showing your lack of experiences there. I have been doing this a long time. Years ago I was completely pro rewrite from the ground up. I have learned rewriting from the ground up is asking for trouble. You are shut down for months and you are throwing away a lot of existing knowledge of bugs or where fragile issues are in the code and replacing them with a bunch of unknowns on both. I have worked on older apps for years and example where there is new feature request Y that should be simple. I knew and would increase estimate to do the work there. That is just working knowledge.

Now we also would rewrite parts of the code base and app over time. It was replacing some of the bad code but it was always over time and bit by bit.
There where sections of the the code with comments that said DO NOT CHANGE. It was a mess and I wrote it. I was being clever 5 years before hand and did not really know what I was doing. I honestly don't know how it ever worked or exactly know why that part of the code works but the important part was it WORKED. Before I left I had the newer version of that back end code written but the mess code stayed living due to multiple screens that relayed on it.

But rewrite over time is a good way and something everyone should strive for.
Your best developers can do the rewrite over time and know how to correctly do it. Your inexperienced developers or poor developers tend to scream rewrite from the ground up.
Anyone can write something from the ground up. It takes someone with talent to understand what someone else was doing and wrote and then expand on it and fix issues.

 

[travelsheep]

You don’t need to pay if you aren’t distributing apps. And if you are distributing apps, the $99 should be affordable (and may be deductible from your taxes depending on your jurisdiction. See a tax lawyer).

See a tax lawyer... that's 5000 USD for a couple of phone calls and a visit. This would give me 50 years of apple developer program membership.

 

[cmaier]

See a tax lawyer... that's 5000 USD for a couple of phone calls and a visit. This would give me 50 years of apple developer program membership.

Then don’t and hope that you get it right and don’t face any consequences.

 

[Emily Simmons]

I personally prefer Swift. It has many updates and ongoing growth plans, and the language receives great support from Apple. It is an easy-to-learn, secure, modern, and interactive programming language. Swift has simplified coding patterns as well as coding interface vs Objective-C.

Objective-C, when compared to Swift, is a more outdated language and lacks modern tools and properties.

 

[Doctor Q]

I've grown to appreciate Swift's protections against common errors, such as its requirement that switch statements cover every possible case. I grumbled about it at first ("I don't need a programming nanny!") but learned that it's easy to comply, and it can save you from insidious errors when there's a new possible value for the switch expression and you forgot to update the switch statement.

But I still don't like the requirement that the prefix not operator can't be followed by spaces. I find code easier to read when there's an intervening space, and therefore less prone to errors in logical expressions. To get past that annoying rule, I change !variable to !( variable ) so I can space it out.