Live data from Hacker News

Swift 5: start your engines

lists.swift.org

81–90 of 186 posts

Re: Swift 5: start your engines

#81
post #44

And just today I was contemplating writing my first native iOS and macOS app... I was looking at the options and decided to go native with Swift. I have never written Objective-C app and never used x-code for dev. But I have ~10 years of dev experience, mostly Java and Python on the backend and front end dev exp mostly with Angular. Some Android, and a little from because I like to experiment. So, my question is. How…

Regarding iOS and macOS kits, all of the documentation is in Objective-C. The libraries' Obj-C is imported and usable with Swift-only code, but the Swift documentation lazily links you to examples in the Obj-C docs. You have to perform trial-and-error by manually converting the Obj-C examples into the equivalent Swift (which often entails renamed classes, methods, types, etc.).

If your projects typically do a lot of string parsing, get ready for a world of hell. Swift 4 didn't improve upon the very basic ability to extract a substring from the middle of a string. It takes 3-4 lines of code, with throwaway explicitly defined variables, to do the equivalent of a str.substr(start, end|length). It boggles the mind that you can't do a str.utf8.substr(3, 5) in Swift.

Re: Swift 5: start your engines

#82
post #78
post #67

Earlier quoted context omitted.

> And just don`t mention Electron, I hate it. Election is the new Flash. All hail new Flash! /s Seriously, how do supposedly smart people come up with things like Electron?

Why was it downvoted?

Sarcastic comments repeating the sentiment of the parent don't add value to the discussion.

Re: Swift 5: start your engines

#83
post #75

Earlier quoted context omitted.

>"IOS sdk, on the other hand, has become a bit of a mess, due largely to the pace at which the field is moving ( although not as bad as android)." Could you elaborate on whats messy with these SDKs?

For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) and swift relies on compile-time codegen hack to provide easy struct serialization, because techs like nscoding r…

>> For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all)

I disagree with most of this. Laying out views was a mess for a while but auto layout is easy to get right once you understand the fundamentals (especially when used in storyboards). Springs and struts is old pre-autolayout tech which shouldn't be used. CALayer is the lower level object that UIView is based on. Not sure what the complaint is here (they're mostly unrelated to autolayout/springs and struts).

As for CoreData it's a pretty simple way to manage your data. When originally introduced to iOS it was a mess but I've used it extensively in the last few years, first through a higher level framework (MagicRecord I think?) and now directly and it providing you exercise some care around threading it performs very well, especially for something simple like offline data storage.

Re: Swift 5: start your engines

#84
post #78
post #67

Earlier quoted context omitted.

> And just don`t mention Electron, I hate it. Election is the new Flash. All hail new Flash! /s Seriously, how do supposedly smart people come up with things like Electron?

Why was it downvoted?

Because you didn't mention what specifically is wrong with Electron

Re: Swift 5: start your engines

#85
post #75

Earlier quoted context omitted.

For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) and swift relies on compile-time codegen hack to provide easy struct serialization, because techs like nscoding r…

It also doesn't help that these APIs are rapidly changing, in ways ranging from minor rearrangements that the XCode auto-upgrader can mostly handle, to real porting hassles. I've been working on a project that was started in early 2016, so it was originally in Swift 2, the then-current version. A ton of things changed for Swift 3, which came out 6 months later, in late 2016. And a bunch of things are changing again w…

AFAIK Swift 3 was supposed to be the last version to introduce breaking changes. Have they changed that policy? I know that the last Swift update I did was very manageable compared to in the past (where I'd easily lose a day or two).

Re: Swift 5: start your engines

#86
post #35
post #11

Earlier quoted context omitted.

Swift has a clear policy on this, but basically: it's worth breaking things early on rather than freeze in bad design decisions. They provide a code migrator to help with this pain. However , this was only in the early releases. The plan is to stop breaking changes soon and freeze the ABI. They're a little behind schedule for this, but it should happen soon.

To expand on this, from the linked post: > First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a requirement of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the langu…

>In Swift 5, [ABI stability] is a requirement of the release.

Once Swift 5 comes out, does that mean it's "safe" for people to write things in Swift?

My company still has apps stuck on Swift 2.x because we simply can't give people the time to fix the hundreds of issues that happen when we try to upgrade the project to Swift 3. Unfortunately the migration tools just don't work and we end up having to either fix almost every line of code or revert the repo. Everyone is frozen on a specific version of Xcode as Swift 2.x isn't supported anymore. It's a complete mess, and hearing year on year "this is the last time we'll break everything" is getting very tiring.

For a variety of reasons we're likely to rewrite our app in the coming months. I'm very seriously considering pushing for writing it in Objective-C because it's just more stable than Swift. We can't do a yearly rewrite, especially as mobile is going to be a bigger focus for us this year and next year.

Can you promise me if I push for the rewrite in Swift 5 it will be the last time we need to do that (for a reasonable amount of time, say 5 years? Or that changes will be far far more gradual and can incorporate it with our workflow?).

If not, we're going to abandon Swift because it's already left a horrible taste in our mouths.

Re: Swift 5: start your engines

#87
post #15

Can someone with Swift experience comment on the status of Swift on non-Apple platforms? Is it being used outside of the Apple ecosystem? How is the tooling, deployment, availability/support, etc.

It's a second class citizen and official examples and community tend to heavily rely on Apple OS provided libraries and APIs to do their work.

The implementations of standard libraries are currently far from perfect.

Unfortunately it seems to me that Swift on non-Apple platforms will forever be stuck in Mono-like role: "kinda working", but always the second class citizen that just waits to spring a hard-to-debug issue on you due to different implementation of underlying libraries. I wouldn't trust it with production code, especially considering how many other stable and properly supported cross-platform languages exist.

Re: Swift 5: start your engines

#88
post #60

One of the problems I find with Swift is that Apple doesn't go back and properly update their sample code at developer.apple.com. They have examples that will not build. If you search you can find folks that have patch sets, but they really need to fix the examples.

I don't think that matters. The iOS Swift community is large enough that there's lots of example code. I've got almost 7000 urls in my database of Swift blogs: http://www.h4labs.com/dev/ios/swift.html?age=90 - Last 90 days Take a look at a weekly view: http://www.h4labs.com/dev/ios/swift.html?week=0 Most topics get sufficient coverage. If you don't mind paying a small monthly fee, Ray Wenderlich's site has lots of tu…

[deleted]

Re: Swift 5: start your engines

#89
post #60

One of the problems I find with Swift is that Apple doesn't go back and properly update their sample code at developer.apple.com. They have examples that will not build. If you search you can find folks that have patch sets, but they really need to fix the examples.

I don't think that matters. The iOS Swift community is large enough that there's lots of example code. I've got almost 7000 urls in my database of Swift blogs: http://www.h4labs.com/dev/ios/swift.html?age=90 - Last 90 days Take a look at a weekly view: http://www.h4labs.com/dev/ios/swift.html?week=0 Most topics get sufficient coverage. If you don't mind paying a small monthly fee, Ray Wenderlich's site has lots of tu…

Definitely recommend visiting their list of swift blogs. Nicely aggregates different sources, as a primarily iOS dev, it's a great way for me to catch up every once in a while on the dozens of blogs I don't want to follow daily.

Re: Swift 5: start your engines

#90
post #44

And just today I was contemplating writing my first native iOS and macOS app... I was looking at the options and decided to go native with Swift. I have never written Objective-C app and never used x-code for dev. But I have ~10 years of dev experience, mostly Java and Python on the backend and front end dev exp mostly with Angular. Some Android, and a little from because I like to experiment. So, my question is. How…

Depending on complexity of your app and the level of polish, it might take a while.

I mean, you can make an app in a day if you follow a tutorial, but if you want to enjoy the language and what you're doing, then you'll have to put in the effort.

Objective-C can probably be avoided, but will help a lot in some cases - especially when interfacing with libraries written in ObjC or C++. So you might want to learn them in parallel, or at least spend a bit of time understanding the semantics of the language, memory management, concurrency, etc.

Oh and native iOS is different from native macOS, some APIs are not compatible, but you can reuse quite a bit of utility-level functions related to your app (since it's the same language).

I enjoyed learning ObjC and Swift and writing apps for iOS, the only issue I have with this platform is that it's too crowded for (new) solo devs.

If you don't care about that as much, then by all means go ahead, you will love it.

Post reply on HN