Live data from Hacker News

Swift 5: start your engines

lists.swift.org

71–80 of 186 posts

Re: Swift 5: start your engines

#71
post #21
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.

Apparently IBM has some sort of backend product written in Swift. I've never actually seen it in production though, nor have I heard of any of my friends companies either

They made a micro framework called Kitura. Maybe some other stuff as well, but I’m not really aware of anyone using it.

Re: Swift 5: start your engines

#72
post #65
post #54

Earlier quoted context omitted.

Hardest part isn't the language. Swift is among the best languages you can get today. 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). Stanford courses are the best you can find online for free. https://youtu.be/HitSIzPM_6E

I concur. The Android SDK seems to violate SOLID principles and fails to capitalize on OOP at all.

We tend to discuss that the SDK was written by recovering C devs learning Java on the job.

Re: Swift 5: start your engines

#73
post #62

Earlier quoted context omitted.

I'd use react-native if I were you. I think you'd pick up Swift pretty easily given your polyglot background, but if you already know javascript and you aren't doing something that screams to be native, RN would be my choice. You'll get to work in a familiar language, and get an Android version with much less work than if you do swift. Best resource to start a react native app I'd say is this, it was really easy for…

I evaluated react native and I really like what I saw and was on the edge to use it. BUT, I am still afraid that it will bite me somewhere in time where it will hurt much. For example, I want to build an app with 50% standard interface stuff and about 50% custom, with some animations throughout the interface. From what I gathered reading other people experiences it would be a bit of a pain in react native. And the ot…

Have you evaluated TypeScript native?

I prefer TS over JS, and I wonder how well it is supported, or if that is even an issue.

Re: Swift 5: start your engines

#74
post #58
post #52

Earlier quoted context omitted.

This is the question I've been asking my iOS dev buddies, with a catch: I want up-to-date resources. None of them were able to share a link so far.

Yeah, up-to-date was assumed in my post. I don`t want a post about Objective-C from 2012. I don`t know if it is against the guidelines to post this kind of links but I found this https://designcode.io/ (I have 0 affiliations with the product) that looks just like what I need. From 0 to app in the newest stack, would probably buy and try it if somebody does not have something better in mind?

No idea how good that book is but that newest stack won't be the newest in maybe a month or so. Assuming that is well written most of it will be applicable or will need only minor updating. That's probably why no iOS dev (from the original comment) can find anything "up to date" because we're right on the edge of a new release.

Re: Swift 5: start your engines

#75
post #54

Earlier quoted context omitted.

Hardest part isn't the language. Swift is among the best languages you can get today. 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). Stanford courses are the best you can find online for free. https://youtu.be/HitSIzPM_6E

>"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 relied on obj-c runtime facilities and the language itself doesn't provide enough metaprogramming facilities to compensate.

Also, patterns like KVO are still found from time to time as a last resort in frameworks, while being famously unsafe and still rely on the obj-c runtime.

For android basically everything should be rewritten from scratch. Last time i managed a team of android developpers, we basically came to the conclusion that doing regular mvc while supporting a good market share meant recoding our own controller base classes and screen transitionning apis.

Re: Swift 5: start your engines

#76
post #62

Earlier quoted context omitted.

I'd use react-native if I were you. I think you'd pick up Swift pretty easily given your polyglot background, but if you already know javascript and you aren't doing something that screams to be native, RN would be my choice. You'll get to work in a familiar language, and get an Android version with much less work than if you do swift. Best resource to start a react native app I'd say is this, it was really easy for…

I evaluated react native and I really like what I saw and was on the edge to use it. BUT, I am still afraid that it will bite me somewhere in time where it will hurt much. For example, I want to build an app with 50% standard interface stuff and about 50% custom, with some animations throughout the interface. From what I gathered reading other people experiences it would be a bit of a pain in react native. And the ot…

I think it is best to write the "core" of your application using a language that can run on all of your target platforms -- which typically means you'll have to use C/C++/Rust or something similar that can be compiled to native code and supports somewhat sane FFI. The UI for each platform should be done using the Native UI toolkit for the platform. That way, you can avoid most of the code duplication.

If you plan to target Android, you might want to check out Google's Java to Objective-C transpiler[1]. That will let you write the core of the app in Java and transpire it to Objective-C for iOS and macOS. The UI will still have to be written using the native toolkit for the platform, though. Fair warning: I have no idea how good or bad it is -- never used it myself.

[1] https://github.com/google/j2objc

Re: Swift 5: start your engines

#77
post #3

Maybe someone will explain this to me. Does Swift use this confusing "rapid release" versioning? Does Swift 4 break backwards compatibility with Swift 3? In my company people are looking for a language to rewrite some legacy Objective-C to. Swift is often discarded as "unstable" because of these major version bumps. Compare this to Go, which, seven or so years after the initial release is still 1.x and still doesn't…

The Swift 4 compiler has a Swift 3.2 mode that is 99.9% source compatible with Swift 3.x. Further you can link 3.2 and 4.0 binaries together. This allows a phased upgrade approach that was not possible in earlier releases. Swift 5 is about having a stable binary interface so you can link against pre-compiled code going forward. In other words a Swift 6/7/8 binary can link against one compiled with Swift 5. The bar fo…

> Further you can link 3.2 and 4.0 binaries together.

Do you have a source for this? This would imply ABI stability, which isn't being promised until Swift 5.

Re: Swift 5: start your engines

#78
post #67
post #62

Earlier quoted context omitted.

I evaluated react native and I really like what I saw and was on the edge to use it. BUT, I am still afraid that it will bite me somewhere in time where it will hurt much. For example, I want to build an app with 50% standard interface stuff and about 50% custom, with some animations throughout the interface. From what I gathered reading other people experiences it would be a bit of a pain in react native. And the ot…

> 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?

Re: Swift 5: start your engines

#79
post #65
post #54

Earlier quoted context omitted.

Hardest part isn't the language. Swift is among the best languages you can get today. 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). Stanford courses are the best you can find online for free. https://youtu.be/HitSIzPM_6E

I concur. The Android SDK seems to violate SOLID principles and fails to capitalize on OOP at all.

The Android framework is honestly a huge pain to develop with. I switched over to iOS development a year ago and am much happier. It feels almost impossible to get Activity/Fragment life cycles correct for simple things. And anything View related has to pass around a God Context object.

Re: Swift 5: start your engines

#80
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…

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 with Swift 4 (although not as many as in the 2->3 upgrade). I haven't yet looked into Swift 5, but presumably that brings yet more API changes.

A lot of time is spent just on this treadmill of porting previously working things to modified APIs. To make it worse, you have to manage a 4-way compatibility matrix between Swift versions, XCode versions, iOS versions, and macOS versions, where only very specific combinations work.

Post reply on HN