Swift 5: start your engines(lists.swift.org)

274 pointsby mpweiher9 anni fa176 comments

lists.swift.org

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038645.html

185 comments

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.

Snackchez9 anni fa

This! I tried to learn Swift with the playground that came from "A Swift Tour"... A lot of examples didn't compile and it took WAY too long to figure out that it wasn't a problem on my end.

Definitely not a good way to introduce new programming languages to newbies.

saagarjha9 anni fa

I downloaded "A Swift Tour" a week or two ago and it was written in Swift 4 (a fact which I found out when I tried to run it in Swift Playgrounds 1.5). When did you try it?

melling9 anni fa

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 tutorials that are well maintained. Plenty of free examples too:

https://www.raywenderlich.com

Another pay site that is be useful if you want to come up to speed quickly is http://nsscreencast.com

amrshafik9 anni fa

Great URL's, also a number free iOS app examples and resources on this youtube channel (Lets Build That App) as well https://www.youtube.com/channel/UCuP2vJ6kRutQBfRmdcI92mA

acmecorps9 anni fa

Seconded on Lets Build That App. Found about it last week, and bought the subscription asap - was impressed with the quality.

However, I was an iOS dev 3-4 years ago and wanted to learn swift - so, it was a pretty smooth upgrade for me. I think whoever wants to learn iOS dev might be better off learn the basics more thoroughly and then come back to this course.

[deleted]9 anni fa

18nlknca9 anni fa

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.

saagarjha9 anni fa

File a Radar and someone will get around to fixing it: http://bugreport.apple.com/

protomyth9 anni fa

Yeah, right, that is some serious BS right there. I've filed radars on the Finder (multiple with reproducible crashes), location data, and Quicktime and it holding onto external drives. The only one they have ever fixed is the Quicktime bug but it reappeared later then went away again.

Apple is horrible about bugs and providing feedback. Why the heck would I need to file a radar anyway? Doesn't someone at Apple check the examples to make sure they still work? These are the examples Apple uses to promote and teach the language and how to build apps.

chc9 anni fa

Apple are super slipshod about their documentation in general. Hardly a day goes by that I don't get a Stack Overflow comment telling me that some link to Apple's docs is broken.

saagarjha9 anni fa

> Apple is horrible about bugs and providing feedback.

Yes, they can be a bit tight-lipped. I have found that they're pretty quick on fixing documentation though. They won't tell you that it's resolved, but it's usually updated within a couple of days.

> Doesn't someone at Apple check the examples to make sure they still work?

I'd expect that they do, but some slip through the cracks. Maybe on of the Apple engineers in this thread could weigh in?

forkLding9 anni fa

Ive filed before but they still send back the same docs about coreLocation, funniest is when the update is for Swift but they just send me the Apple docs with Obj-C (only has Obj-C, no swift for years), a swift beginner would never understand, I can because I can translate but its pretty frustrating still because you're still guessing thats the right way.

physicsyogi9 anni fa

Yeah, that's not ideal. Apple at least keeps the Swift language guide current though: https://developer.apple.com/library/content/documentation/Sw...

westoque9 anni fa

I propose a solution.

Developer documentations should start following API like structures. For example, in API land we have:

    /api/v1/users
    /api/v2/users

This means that making requests to v1 will only work with v1 and v2 only with v2. This makes sure that the API you are connecting to is using the correct parameters for its version.

Going back to documentations, they should state in the examples or in the documentation that this document is written for V2 of swift or anything more specifc. Even better would be sticking to Semver like specifications for the versioning.

cf9 anni fa

This is what sklearn does for their documentation and it's fantastic!

ssijak9 anni fa

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 <input_random_tech_here> because I like to experiment.

So, my question is. How hard and enjoyable is for someone like me to write not very complex native iOS/macOS app in Swift starting from scratch? Best resource to start with?

bsaul9 anni fa

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

askvictor9 anni fa

Languages are easy. It's always the frameworks (which are usually needed for any real world tasks) that are the killer.

infinisil9 anni fa

> Languages are easy.

Not always true, my favorite example being Idris. (but then again, it's all relative to what you know already)

likelynew9 anni fa

If you know, say Agda, Idris is not hard. The point is the concepts in Idris are hard, not the language. People learning haskell as first language in universities have more difficulty learning OO language than we have as we already know many OO languages.

jswizzy9 anni fa

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

pjmlp9 anni fa

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

trevor-e9 anni fa

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.

bogomipz9 anni fa

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

bsaul9 anni fa

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.

k-mcgrady9 anni fa

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

jakeva9 anni fa

As a ten year vet of Cocoa and Cocoa touch, I agree with your counterpoints. A lot of stuff is simply legacy.

bsaul9 anni fa

Ever tried to have 60fps on a tableview with constraint-based layout cells ? CALayer is definitely not legacy, it's often the only way to get smooth animation. Spring n struts is also sometimes the best way to get fast position for smooth scrolling.

Ever had to deal with Core Data migration on an app that needs to evolve throughout the year ? Migration is a mess, and so is concurrency. My personal conclusion after having used Core Data on a pro application for 4 years, is that most of the time i really don't need a database and so i'm back to file-based backups for my app's data. Works well, no magic, and no performance or threading issue.

saagarjha9 anni fa

> Ever tried to have 60fps on a tableview with constraint-based layout cells

Yes. I've found AutoLayout to be acceptable in this case, provided you're not doing something awful.

melloclello9 anni fa

We ran some casual benchmarks on this at work once, and it's important to note that the performance of AutoLayout dramatically improves based on the degree of nesting you employ.

If you have sixteen views on a cell and their locations all depend upon each other, it's going to take a long time to solve those constraints. But if you can break up the cell, say into four subviews with four elements inside them, it's likely to be faster (no guarantees, though)

throwaway911119 anni fa

Yup, it's easiest if you understand what the solver is doing and help point it towards solutions/find them trivially.

Unfortunately, i had to write my own constraint system and practice with it a lot to use AutoLayout with high performance where i was confident i was not introducing significant re-layout performance problems.

LeoNatan259 anni fa

> Ever tried to have 60fps on a tableview with constraint-based layout cells ?

Yes, even on a 4S.

mmargerum9 anni fa

I came to the same conclusion WRT core data. I'm caching data myself to files. I would use SQLite directly if I need a real data store before I would use code data again

acmecorps9 anni fa

How in the world did you managed to use storyboard? I hate using it for moderate-complex UI apps. This guy say it better than me on why I hate storyboard (especially the first reason):

https://www.youtube.com/watch?v=g6yz5oX5iWc

FWIW, if you like and good at it, more power to you.

k-mcgrady9 anni fa

I use it in combination with programmatic UI for more complex things but find it's so much easier and faster when doing auto layout to just use storyboards.

bsaul9 anni fa

The real reason for which i stopped using them is that it doesn't work well with git. As soon as you've got more than one people in the team, it's over.

jakeva9 anni fa

It is actually a solvable problem if you're willing to dig into the details of the file changes. It isn't pleasant, but welcome to life. Team members can make conflicting changes as long as someone is willing to dig through the mud to make them all agree with each other. I've been doing it personally for a long time, it isn't my favorite part of the job but it does enable significant parallel productivity.

acmecorps9 anni fa

Absolutely right. This right here is the killer for me.

aplummer9 anni fa

Hey on the struct serialisation thing, try the new codable feature, it's so great. I can probably delete 20% of my code in swift 4!

zackmorris9 anni fa

Also Apple uses a lot of patterns that lead to goto hell because of NeXT's foundations in the delegate pattern:

https://en.wikipedia.org/wiki/Delegation_pattern

So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control. Note that since Android copied many metaphors from iOS, it also inherited these complexities in things like its Activity class.

I agree that Core Data probably needs to go away (at least its iCloud integration) and be replaced by Firebase or PouchDB etc.

KVO was a great missed opportunity because it's not clear who is watching a value. I think the pattern itself has merit from a functional programming perspective (after all this is how Excel works).

I generally avoid native mobile development now for these reasons among many, not to mention cross-platform issues. We likely need web metaphors running above native code, writing plugs where necessary (like Cordova or React Native). These are generally quite painful to use though, so I don't see many solutions materializing for at least several more years.

coldtea9 anni fa

>So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control.

Why on earth would you have a single blocking thread on a UI app?

zackmorris9 anni fa

What I was trying to say is that in the olden days of say the 80s, Mac OS used cooperative threads and you just wrote a main loop that was completely self-contained. We made OS calls from there, the OS didn't call us with events like it does today (at least most of the time). So programs were much simpler to debug because we didn't have callback or goto hell.

The tradeoff was that it took pages of boilerplate to make even the simplest app, and Apple got made fun of incessantly for it. So they largely fixed that with OS X's message passing metaphors, but unfortunately due to bloat and a lot of other reasons, the boilerplate issue came back, and now we're also stuck with untraceable program flow.

To answer the original question - I have worked on both blocking and nonblocking code, and unfortunately nonblocking code doesn't scale. It eventually becomes too complex to follow the flow. It's like comparing a coroutine to a state machine. My personal feeling is that we're in a kind of nonblocking bubble right now and that the callback style that pretty much all frameworks use today is not going to be the way it's done in the future. I don't know what will replace it, but it will likely be something more like Redux/Elm/Clojure and declarative GUI syntax like how the web used to work.

throwaway911119 anni fa

I don't think that Core Data is that bad for local storage; it's basically just an ORM.

_delirium9 anni fa

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.

k-mcgrady9 anni fa

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).

_delirium9 anni fa

This project's still on Swift 3, so I don't have first-hand experience upgrading to Swift 4. It looks like there are breaking changes though, albeit not nearly as many as 3 had.

The most notable one looks like in the String API [1]. There are a few other minor ones that most projects won't hit, like in the dictionary/set API [2]. A few of these are also slightly more breaking than it initially seems because they've added temporary compatibility workarounds marked as deprecated in Swift 4 to avoid breaking as much working Swift 3 code, but these will go away for Swift 5, so you do still have to port anyway (just not immediately).

[1] https://github.com/apple/swift-evolution/blob/master/proposa...

[2] https://github.com/apple/swift-evolution/blob/master/proposa...

Tanegashima9 anni fa

jernfrost9 anni fa

I don't see why keyed archiver wouldn't work with swift. I've implemented identical systems in C++ with no dynamic features. Or you can just use JSON serialization for offline storage. I pretty much never use core data. Don't get why people use it so much. On iOS you are a single user of your data so you can easly rely on a combination of plain files for storage. I've seen how Java devs go crazy using core data to just store a few hundred bytes of data. I think people overcomplicate storage 90% of the time.

bsaul9 anni fa

Keyed archiver doesn't work with structs, and it also probably doesn't work whenevr you start nesting classes. It relies on introspection and dynamic typing for that, which can't work right now with swift.

It's one reason they had to rely on compile-time codegen to implement the swift4 equivalent.

ClassyJacket9 anni fa

For me it feels like the messaging is pretty clear: use AutoLayout. Springs and struts aren't used anymore, constraints are just a part of how AutoLayout works, and I'm not even sure what you mean by physic based.

myko9 anni fa

I assumed they were talking about UIDynamics (https://www.bignerdranch.com/blog/uidynamics-in-swift/)

kartickv9 anni fa

I found myself wasting months to do something that should have been handled better in iOS.

- APIs return non-descriptive error codes like -16405. Some of them aren't documented. And even the ones that are are not found clearly. Different codes are documented in different files. If you don't know where to look, you won't find it. Java-style descriptive error names like InvalidFrameRateException are sorely missing. iOS should either adopt exceptions or at least string error codes like INVALID_FRAME_RATE, not -16405.

Sometimes, there's no error code at all. I'm trying to record a video, using a AVCaptureMovieFileOutput, which is supposed to save to a file, and it doesn't. There's no error code, no exception, no log message telling me what went wrong and how to fix it. I spent a day or two trying various possibilities but nothing worked.

- Common abstractions like a photo gallery class aren't missing. It took me a month to write my own, because there are a lot of cases to deal with: swiping left and right, pinching to zoom, double-tapping to zoom, keeping the photo centered while zooming, taking care not to zoom the whitespace, keeping the photo gallery in sync with the Photos app (the user might delete a photo either in your app or in the Photos app, and you need to sync in both directions), and so on. Even now my gallery class doesn't support swipe down to close, which the Photos app supports, as I was told yesterday. That's what happens when you make people reimplement things — you'll get an inconsistent UX.

Forget a photo gallery class. Even a zoomable photo view is missing. It took me days of messing with UIScrollView to figure this out, until I found the ray wenderlich tutorial.

- Some APIs come in both sync and async versions, while others, like permissions, come only in an async version, though a sync version would be easier. Even the async APIs are inconsistent -- some invoke your callback on the main thread (UIKit APIs), some invoke it on the same thread you invoked it on, and some in a random thread (AVCapture). I filed a radar asking for consistency (maybe all async APIs can take a queue to invoke the callback on) but Apple closed it as WontFix.

Unfortunately, Swift doesn't have async/await, so dealing with the async APIs is a pain, and for some reason, this is not even a priority in Swift 5. It's being put off for years.

- Permissions are a pain to deal with, especially the common case that your app can't run without some permissions, like Camera and Photos for a camera app. I had to deal with the following cases:

+ You should take care to request a permission only after the previous one has been approved or denied by the user. Otherwise, you'll get a prompt for Camera, and before you respond, it disappears and is replaced by a prompt for Photos. And before you can respond, it disappears and is replaced by Location. When you respond to it, the Camera prompt re-appears, but again disappears and is replaced by Photos. This is a bad UX, caused by iOS not queueing multiple permission requests internally and asking the user for one only after the previous request was responded to.

+ You should ask for location before camera, because a GPS fix can take time.

+ You should take care to obtain permission before accessing the camera, otherwise the camera will vend frames consisting of black pixels, which you might accidentally save to the Photos app.

+ iOS distinguishes between a permission being denied (by the user) and restricted (by an admin or parent). My app would crash in the latter case, because the camera device is not found. But not in the former, because the camera exists but vends black frames.

+ If the user changes permissions of your app while it's running, Apple says that iOS will kill your app and restart it so that you don't have to deal with permission changing dynamically. Except when it doesn't, which goes back to the denied vs restricted case above.

In summary, you waste months of your time working around insufficiently-documented iOS issues, or debugging things, or reimplementing common things in every app.

I conclude that iOS is a poorly-designed platform from the developer point of view. Maybe other platforms are worse, I don't know, but iOS certainly is far from what it could have been. Ideally, you should implement only what makes your app unique.

LeoNatan259 anni fa

(1)

ssijak9 anni fa

Thanks, this looks really promising!

alexashka9 anni fa

I'm surprised no one has mentioned this but I'd say the #1 resource for learning the practical 'how do I get X thing done in a couple of hours' are tutorials on https://www.raywenderlich.com/ without a doubt.

It has tutorials for every basic question imaginable in a very easy to follow manner.

It'll definitely take some time, as for being enjoyable - I don't get a kick out of learning an entire new set of libraries and idioms for achieving the same thing I can do in another toolset, but if you do, then great :)

One last thing - the amount of information for macOS is about 1% compared to iOS, so I'd definitely go the iOS route.

LeoNatan259 anni fa

> One last thing - the amount of information for macOS is about 1% compared to iOS, so I'd definitely go the iOS route.

I thought that too, but it’s not accurate at all, from recent experience. There is a lot of hidden treasure for macOS, but it is buried under layers of bad Google results because somehow “NSViewController” makes Google shows me results for “UIAppDelegate” and “UIView”—makes sense. A lot of information is out there, on SO, Apple developer forums and mailing lists.

Tanegashima9 anni fa

Ray Wanderlich tutorials are good quality, but I don’t really like the way he writes.

I recommend to look at this site, he’s a really “clean” teacher

https://www.hackingwithswift.com/

delegate9 anni fa

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.

developer29 anni fa

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.

futurix9 anni fa

Did you forget to switch documentation from Objective-C to Swift?

aplummer9 anni fa

I think most people just use a string extension to allow

  str.substring(with: 7..<11)

or something similar.

mahyarm9 anni fa

String operations are also really slow in swift. Python is the same speed or faster

Rodd459 anni fa

dep_b9 anni fa

I only remember a very early review of string operation speeds that was pretty bad at times indeed. But that was about Swift 1 and the string implementation has been changed a few times. Do you have any recent source?

mahyarm9 anni fa

Personal experience making the same command line util in python and swift 3 that was parsing code with the same C library (sourcekit) and then doing a bunch of string manipulation after that.

Optimized swift 3 & python were the same speed, with %80 of the time being spent in the C library. I would expect swift would at least be 2x faster in that %20 portion that wasn't sourcekit library.

dep_b9 anni fa

I think strings in Swift are primarily meant to be very correct above being fast or easy to use. It's more strict than both Python 2 and 3. Handling of languages that use really complex character compositions springs to mind.

mahyarm9 anni fa

There is no obvious way to turn that off fortunately, when you don't need it.

LeoNatan259 anni fa

I think it's coming. Part of the String Manifesto Apple has is that they want to give both worlds.

shanev9 anni fa

You'll get up to speed in no time. Start with WWDC videos [1] in an area you're interested in. Then play around with some of Apple's sample code [2] and modify an app to your liking.

After you're a little more advanced, check out the resources at objc.io [3].

[1]: https://developer.apple.com/videos/

[2]: https://developer.apple.com/library/content/navigation/

[3]: https://www.objc.io

lordnacho9 anni fa

I did this a couple of years ago on a completely fresh MVP for a friend.

Worked fine, my background was in trading systems using C#, Python, and C++. I'd also done a lot of Android Java for another app MVP, so interesting to compare how iOS and Android do things.

I think most people who've done a few languages are not going to find a lot of problems with Swift. There's a lot of nice sugar in there to keep things neat.

Your main issue if you haven't done iOS before is learning iOS. It's a bit weird, you can tell some libs haven't been upgraded while others have. The old libs need a bridge header and have weird relics from Obj-C. Also the whole constraints layout system might take some getting used to, but I did manage to build some pretty complex components with it. It didn't seem to map well onto the Android layout engine, but I'm not that experienced with the layout engines.

physicsyogi9 anni fa

Hacking With Swift is pretty good for learning iOS and Swift. https://www.hackingwithswift.com/

samcat1169 anni fa

^ can confirm all of the books by Paul are really well written

caiob9 anni fa

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.

ssijak9 anni fa

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?

tarentel9 anni fa

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.

LeoNatan259 anni fa

> Yeah, up-to-date was assumed in my post. I don`t want a post about Objective-C from 2012.

What a ridiculous statement. Most of those resources are excellent and relevant today. An article/blog post on calendrical or localization or accessibility is still as relegate today, as “back in the day” in 2012. This is not some web “dev” nonsense where the “stack” changes every year and a half. iOS and macOS consist of some tried and tested APIs that are decades old.

[deleted]9 anni fa

jnbiche9 anni fa

I suspect that with your Java, you'll find Swift to be a snap to get started in, particularly if you've also experimented ever with Scala. Mastering idiomatic Swift is a bit harder, but definitely doable with a bit of effort.

smegel9 anni fa

> How hard and enjoyable is for someone like me to write not very complex native iOS/macOS app in Swift starting from scratch?

Your biggest problem won't be the language, but the 30,000 other apps uploaded to the App Store every single day.

andrewljohnson9 anni fa

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 me: https://facebook.github.io/react-native/docs/getting-started...

For Swift, here's a page from Apple, but I just plucked it from Google: https://developer.apple.com/swift/blog/?id=16

LeoNatan259 anni fa

Don’t use React Native.

There is little “native” about React Native. It’s something web “devs” like to convince themselves because they don’t know better.

Using merely UIView objects does not mean it is native. It’s not just an abstraction over native. The “great” minds at Facebook have decided to not only offer a JS wrapper around the native APIs and objects, but actually reinvent the wheel on everything. Tables? Let’s have a horrible implementation in JS. Gestures? Slow ones in JS. Navigation? Absolutely terrible in JS. Animations? Core Animation you say? Nope, in JS or in C++. Even simple stuff like buttons are not native UIButton objects. There is nothing “native” in React Native.

Also, the single threaded model of JS just does not scale. The larger the app gets, the more and more it starts to lag. UI is rendering at 60 FPS, sure, but the lag comes from a constantly busy single JS thread.

And that’s before mentioning things like accessibility, large type support, basic iOS concepts such as margins and layout guides, etc. that are sorely missing from RN.

y_u_no_rust9 anni fa

briandear9 anni fa

“I want to learn how to fly a Cessna where should I start?”

“I’d recommend hang gliding. That way, you don’t have to worry about the complexities of piston engines. Since you already know how to fly a kite, you’re practically there already.”

While hang gliders and Cessnas are both flying, there are a lot of things Cessna can do that hang gliders can’t.

I will be glad when JavaScript stops being the answer to every question. iOS apps aren’t just webpages running on a phone. How, for example, does react handle pre-release Apple APIs? How does it work with ARKit or other iOS specific tech?

Why do we insist on building to quite literally the lowest common denominator rather than building to the strengths of iOS and Android?

React Native could be a prudent choice for certain kinds of apps, but I’d argue that the apps for which React Native excels probably don’t need to be apps in the first place.

Apps ought not be glorified web pages; they should take advantage of the hardware to the fullest extent.

If an actual Swift developer recommends React Native, I might listen, but generally it’s web developers who downplay the advantages of Swift because they themselves have been unwilling to learn how to get the most out of it and the iOS APIs.

This whole cross-platform obsession results in lower quality applications. Case in point: Slack for Mac OS. It’s decent, but it would be significantly better if it were actually native. This trend of wrapping a webpage and calling it an app is a disservice to your customers.

There’s a reason I have an iPhone. Yet, with this cross-platform nonsense, developers are essentially kneecapping our devices. This applies to Android as well.

ssijak9 anni fa

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 other smaller reason is that I want to build native macOS app that goes along with it and as far as I can tell from my own experience, only natively written apps feel good on osx. And just don`t mention Electron, I hate it.

__sr__9 anni fa

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

__sr__9 anni fa

Why was it downvoted?

detaro9 anni fa

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

aianus9 anni fa

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

andrewljohnson9 anni fa

React-native animations have come a long way. I think your concerns are real, but you'd be pleasantly surprised. You might want to dip your toes, see how far you get in a day and how it feels.

Article on animation improvements from Feb: https://facebook.github.io/react-native/blog/2017/02/14/usin...

BatFastard9 anni fa

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.

__sr__9 anni fa

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

myko9 anni fa

IMO flutter.io looks a lot more promising (navigation isn't a mess, for example) but really native is the way to go. I'm biased towards native as that's what I do day to day.

React Native is more fun to work with than PhoneGap though (I've shipped apps with the latter and really hated it).

ainar-g9 anni fa

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 break code.

I just don't get breaking the language so often. Do people enjoy rewriting code?

eridius9 anni fa

Swift 3 was a major backwards-incompatible change. It came with an automatic migration tool, but the tool only kind of worked.

Swift 4 is a much smaller change. There are backwards-incompatible standard library changes, but not on the scope of Swift 3. Again, it comes with an automatic migration tool. I haven't tried it myself, but I'm optimistic that it will work much better, both because they've had a year to fix what went wrong the first time, and because the changes are much much smaller.

But Xcode 9 also supports Swift 3.2, which is the same language as Swift 3.1 with some miscellaneous bugs fixed and with the iOS 11 / macOS High Sierra SDKs. Your Swift 3.1 code will likely run under Swift 3.2 with no changes, and any changes that are necessary are going to be strictly due to SDK changes rather than language changes.

Xcode 9 also supports mixing Swift 3.2 and Swift 4 modules. You can have your application written in Swift 3.2 and use a library written in Swift 4, or vice versa. This means you have a full year to migrate to Swift 4 (since I assume Xcode 10 will drop Swift 3.2 support, though this is pure speculation).

randyrand9 anni fa

My biggest issue would be compiled libaries. I come from c++ so updating and recompiling all the libs would be a huge pain. How is it in Swift?

eridius9 anni fa

The major goal of Swift 5 is ABI stability. Until then, libraries written in Swift do have to be recompiled with each new version of the compiler.

xenadu029 anni fa

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 for source breaking changes is also much higher than the already high bar in Swift 4. We may not see any source breaking changes in Swift 5.

kibwen9 anni fa

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

slavapestov9 anni fa

Swift "3.2" and 4.0 are really the same compiler, run with -swift-version 3 and -swift-version 4 flags, respectively.

kibwen9 anni fa

I get that they're the same command-line tool, but as a bystander that doesn't tell me whether it's implemented underneath as two separate incompatible compilers that are toggled between with a flag. And even if it's a single compiler with mostly shared components, that doesn't have to imply that the binaries that are produced are ABI-compatible between the two. I'm not implying that I cannot believe that this use-case will work, only asking for some assurance from the compiler devs that it does.

slavapestov9 anni fa

> I'm not implying that I cannot believe that this use-case will work, only asking for some assurance from the compiler devs that it does.

You have my assurances that it works ;-)

lyinsteve9 anni fa

-swift-version 3 really just turns on some different paths through the parser and type checker to allow previously-valid Swift 3 code to survive to code generation time.

They're both compatible

Osmium9 anni fa

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.

nathcd9 anni fa

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 language, and it cannot be delayed any longer.

> ...

> Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.

ancarda9 anni fa

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

saagarjha9 anni fa

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

It means it's "safe" to ship binaries to people without providing the source and it should remain compatible forever™.

> It's a complete mess, and hearing year on year "this is the last time we'll break everything" is getting very tiring.

Swift 3->4 was much easier. Of course, if you're still stuck on Swift 2 this isn't going to help you much…

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

That's how it was supposed to be in Swift 4, and it should get better from there.

saagarjha9 anni fa

> Do people enjoy rewriting code?

No, of course not. The way I see it, Swift is scared to go the "Java" route where backwards compatibility is valued above all else, leaving the language an antiquated mess.

jorgemf9 anni fa

I want to know the opinion of managers about what they think when they have to rewrite the app everytime there is a new release.

I remember all the time the iOs developer spent with every iOs release. He didn't look any happy

eridius9 anni fa

You don't have to "rewrite the app". You run the migrator, then fix up what it didn't migrate.

Swift 3 was notorious for having migrator issues, largely due to the fact that it was a pretty radical change and a huge number of method names were changed.

Personally, on our hybrid app, the migrator did about 1/3rd of the work, and I did the rest, without any other engineers' involvement. Overall it took maybe 3 days to migrate the whole app.

jorgemf9 anni fa

It was a way of talking. I said it that way because the migration to swift and from swift 1 to swift 2 we had the double of developers for iOs than Android and still have to wait for them because of so many issues they were having.

Seems like things are not that bad now. But stills scares me that with every new version you lose a developer for some days (or weeks).

dep_b9 anni fa

The whole 1.x to 2.0 stretch was a rough ride. I had to maintain software without From 2 to 3 was pretty OK since very little changed in the language only API's got updated. From 3 to 4 mainly adds stuff and doesn't break much.

saagarjha9 anni fa

It really doesn't take all that long. I've migrated apps consisting of 20K-30K lines of code in a couple hours–mind you, many of the changes were not due to Swift 4, but those in the Cocoa/Cocoa Touch Swift overlays.

jorgemf9 anni fa

I said to swift, I meant from objective-c to swift. And also from swift 1 to swift 2, where problems weren't only the language but the apis an integration with the old objective-c library. I doubt it takes a couple of hours do that stuff (hour project was close to 100k lines, to one day for you), but If it really takes you that short time companies are going to fight hard to hire you!

s73ver9 anni fa

Saying "rewrite the app" is pure hyperbole. You have a few things to update, but that's it.

melling9 anni fa

Go has had breaking changes. You had to run a program to fix your source.

https://blog.golang.org/introducing-gofix

Swift 4 had very few changes. Most Swift 4 code “upgrades” without any changes.

I’ve got two dozens Swift examples that were easy to convert to Swift 4.

https://github.com/melling/ios_topics/blob/master/README.md

comex9 anni fa

Your Go link is from before 1.0. AFAIK, since 1.0 breakage has been very rare.

adamnemecek9 anni fa

Xcode has a migration plugin that's not too bad. The biggest changes are generally for the better so I'm like meh. It's kinda annoying if you have dependencies but maintained dependencies generally migrate very quickly.

paulddraper9 anni fa

By that logic, Chrome and Firefox are unstable platforms, with major version updates every 6-8 months.

Probably no one develops with them.

[deleted]9 anni fa

__sr__9 anni fa

I wish more effort were being made to make it a first class citizen on non-Apple platforms. With the popularity it has enjoyed, it could easily challenge the likes of Go, Python or even Java for server side programming.

bjt9 anni fa

The linked post talks about concurrency not being a focus until Swift 6 at the earliest. Personally, I don't want to make a commitment to server-side Swift until after that dust has settled.

bsaul9 anni fa

I've recently started to investigate web frameworks for swift, and specially the concurrency part. So just to clarify something : current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads.

This type of model is fine and has worked quite well in the past. It is not event loop like node, nor light threads ( like go), nor actors like erlang, but it does work fine. And since swift is fast, it'll probably work just a fine as your python / ruby / node backend.

What we're looking for for the future of swift is something better / safer than that. But my personnal conclusion is that it shouldn't prevent you from building regular webservice api with this language.

Matthias2479 anni fa

> current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads.

Imho that's just the description of event loop(s). There's a central queue, to which you post work (e.g. in the form of function objects or closures), which will get dequeued and executed in a serialized fashion. The thread look like while ((func = dequeue()) != null) { func(); }. That's the event loop.

The difference to node is that you have multiple of these event loops, which are referred to by queue name. In javascript there's only one single implicit loop. If we look at javascript which webworkers we also get multiple loops and queues (one in each worker). However those are more strongly isolated (no shared memory) than eventloops in multithreaded environments.

Jack4E4B9 anni fa

How much work is expected from the developer point of view? I'd love to have an alternative to Go, but no concurrency for me kills Swift right of the gate for server stuff.

bsaul9 anni fa

At the moment, it's mostly the framework's job. You write your handler and call the libs for interacting with i/o.

Posting a job ( aka function call) on a queue for async programming is also very very easy.

There's nothing like coroutines or channels though. So you're back to mutex and OS thread constraints in terms of the number of spawnable threads.

Jack4E4B9 anni fa

Thanks for that explanation... so in short is not ready yet. Go's channels is what makes it seamless. So few choices for solid concurrency today.

jordansmithnz9 anni fa

Agreed - I'd love to see it more widely adopted. It's a great language.

Once both ABI stability and a native concurrency model have been implemented, Swift would be in an even stronger position to take on these languages. I'm not sure that's the sole reason a stronger push hasn't been made yet, but waiting another few years to go after this goal would in some ways be tactful.

brian_herman9 anni fa

https://github.com/vapor/vapor

__sr__9 anni fa

It's not just about a framework. Some marketing/evangelism is needed. Those factors were major contributors to the rise of Go.

And the Swift community itself needs to work on making it officially available on more platforms. Officially, the only non-Apple platform that is supported is Ubuntu -- not Linux, Ubuntu. It runs on other distributions, but having “official” support for more platforms would be a big step towards acceptability. Most people I've talked to still consider Swift on Linux an experiment. Even C#/.Net Core seem to be more popular on Linux.

Having Windows support would make the language more acceptable by cross platform developers -- leading to more high quality libraries being written.

craigching9 anni fa

With a name like 'vapor', I thought this was some sort of joke. But this looks like fun! https://vapor.codes. An example from that page:

  import Vapor
  
  let drop = try Droplet()
  
  drop.get("hello") { req in
      return "Hello, world."
  }
  
  try drop.run()

aplummer9 anni fa

Hey, I'm using Vapor (in production). It's really great to work with and moving fast - feels like the early days of rails. There's a real technical advantage to having the brevity of swift (like ruby) but with the type checking of the compiler. I actually migrated this app from Node.js and it's faster and easier in almost every way (notably lack of 3rd party libraries).

jrs959 anni fa

I've been sort of going back and forth on what I want to work on as a side project, but server side Swift stuff is definitely an option. I love the language, and think it could end up being a really strong competitor in that space. At the moment it's just barely viable though, sadly.

xenadu029 anni fa

Swift is open-source. You are welcome to contribute support for other platforms!

colordrops9 anni fa

This cliche statement feels trite for such a large project. I'd understand it for a 1000 line JS library, but it makes no sense for a complex language ecosystem that requires multiple full time engineers to maintain.

xenadu029 anni fa

It isn't my intention to sound "trite". I've personally contributed a little bit to Swift. You don't have to be a compiler genius to help out - you can contribute to Swift Foundation which is almost entirely Swift code and would directly improve cross-platform support.

I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working on any open source project owes you anything. If you want the project to get better then find a way to contribute.

abiox9 anni fa

> I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working on any open source project owes you anything.

no, "i wish" just means "i wish". it doesn't imply anything like "being owed".

being "open source" doesn't establish carte blanche to oblige everyone to labor on the project if they dared to have a thought or opinion.

> If you want the project to get better then find a way to contribute.

there are thousands of projects i'd like to see get better. not everyone has the time, ability, desire or capacity to implement everything they've ever wished for. this is just silly.

__sr__9 anni fa

I am talking about "official" support here. Enterprises are not going to risk using an unofficial port. And unless there is a large scale adoption, it will become another niche language which only the enthusiasts would care about.

More importantly, it needs to happen while Swift still has momentum. Once a language gets old enough, it builds a certain kind of reputation. Once that happens, it is almost impossible to introduce it into new domains.

xenadu029 anni fa

> I am talking about "official" support here

You can take a look at what IBM has been doing in this space, but in general I'm not sure what you are asking for. Do you expect Apple to release a fully-baked Windows port?

It's a free project that is open-source. Cross-platform support will come from contributions by individual developers, testers, and documentation writers, or companies who find some strategic value in supporting it.

Sitting back and saying "I wish" seems a bit entitled, no? I'm not being glib, I really am saying if you want to see better Swift support on platform X then start contributing. Swift Foundation needs help filling out implementations on Linux and Windows. For the more adventurous you can contribute directly to the standard library or compiler.

__sr__9 anni fa

Since when did wishing for something mean someone is entitled to something?

“I wish it would stop raining.”

“I wish they'd launch it soon.”

Do any of these statements mean the speaker is entitled to something? Since when did wishing for something become a bad thing?

I am not expecting Apple to release anything. I am hoping for swift.org to one day proclaim that the toolchain and the libraries are available on Windows and other platforms. What I am expecting Apple to do is get behind its own language. I mentioned in another post in this thread -- it is not just about technical work. A lot of it has to do with marketing/evangalism. While individual contributors can help, it takes the backing of large company to get something adopted at a large scale. Why do you think Go succeeded while languages like Nim, D etc are not being adopted as well? What I expect from Apple is to spare a couple of people for the purpose of giving talks, writing blogs etc in addition to working on Swift -- something like what Rob Pike et al have been doing for Go. From what I understand, Apple writes a lot of their backend stuff in Java. Perhaps they could start investing in Swift on server side and open source some of the frameworks/libraries they come up with?

> I really am saying if you want to see better Swift support on platform X then start contributing.

I want to get Swift adopted at my workplace for the next project we are working on. I should tell the management I'll start working on it as soon as I get Swift ported to the platform I use. It would go down really well.

What makes you assume I am not contributing in whatever way I can?

> You can take a look at what IBM has been doing in this space, but in general I'm not sure what you are asking for.

IBM has done some good work, alright. But they are the only ones. A lot more work is required If Sipwift were to become a mainstream language.

heja_bruh9 anni fa

You should definitely try rust, it's better than its counterparts, rapidly growing, memory safe language with utmost priority on efficiency. Plus its cross-platform too :)

__sr__9 anni fa

I already use Rust for some stuff, but Rust and Swift don't compete in the same domain -- despite some overlap. Rust is more for Systems Programming whereas Swift is geared towards Application Programming. Of course, you could use them in each other's domains, but there will be challenges.

saagarjha9 anni fa

Are all of your comments about Rust?

sidlls9 anni fa

There's a reason a meme exists about Rust afficionados on HN.

jswny9 anni fa

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.

crb0029 anni fa

Victim of trying it the first week it came out, having to call down into C for anything POSIX, and giving up. If you don't have POSIX bindings, don't call yourself v 1.0.

saagarjha9 anni fa

What exactly do you mean "call down into C"? You should be able to call C functions directly from Swift, albeit with UnsafePointer and the like.

ainar-g9 anni fa

I assume, they mean that you don't need to have C at all. See how Go for example doesn't require C on most platforms to make syscalls (IIRC, the exceptions are Windows and Solaris).

saagarjha9 anni fa

So, based on this[1] they've just wrapped the calls with their own…not sure if there are any real benefits here.

[1]: https://golang.org/src/syscall/syscall_linux.go

brutus12139 anni fa

I've been using Swift for a few months and really want to like it. That said, breaking down to unsafepointer for newbie tasks is unacceptable IMHO. Try to do basic stuff like TCP/IP socket coms without a third party library or heck, just get the IPv4 address of your network interface.

bsaul9 anni fa

Currently trying a web framework, developping on a mac and running it on unbuntu ( vapor framework). I'm extremely positiely surprised by the user experience. Installation is easy, xcode is working fine with autocomplete, libraries seem good enough ( db querying on postgres using a default ORM seems to work).

I've now started to investigate deployment on ubuntu, and the only regret so far is that cloud platform don't support this language very well at the moment ( app engine with dockerfile is a pita, and i gave up to more regular engine instances).

I think starting to develop very basic web apps on this language is beginning to make sense.

cgb2239 anni fa

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

jrs959 anni fa

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

izacus9 anni fa

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.

veidr9 anni fa

I've been maintaining a project at work since Swift 2, where the goal has always been to add Linux support (in addition to macOS and iOS) as soon as it is viable. That project's fairly simple requirements include basic HTTPS networking, JSON encoding/decoding, managing multithreaded operation queues, and defining a hierarchy of objects to model an API's data structures. It doesn't need a GUI.

So I've looked at each Swift release through the lens of "Can we add Linux support yet?", and I would say Swift 4 will be the first release where it is viable. Viable, but still with caveats:

1.) The best tooling is still Xcode; the best way to write Swift code for Linux is to do it on a Mac with Ubuntu running in a VM, sharing the Mac's filesystem. Of course you can write code on Linux, but there are no editors that have more than a rudimentary set of Swift tools for code-completion, static analysis, or visual debugging.

2.) There are still many landmines lurking in the standard libraries on Linux. These are mostly obvious when you find them; various parts of the Foundation library (which is a Swift-native reimplementation of Apple's core framework for building apps, including basic networking, filesystem access, unicode string stuff, URL manipulation, UUIDs, etc.) have parts where the interface is there but the implementation on Linux just calls NSUnimplemented(), which immediately traps and halts the program. Fortunately, there are far fewer of these places in Swift 4 than Swift 3.

For this reason, if you are writing cross-platform Swift code that needs to run on macOS and Linux, you will probably find yourself using Swift's #ifdef-like "#if os(Linux) ..." feature to conditionalize execution based on the platform.

3.) Testing is a pain, because unlike on Apple platforms, which can borrow objc runtime features to do weird magic, Swift's native reflection capabilities still are not very strong, preventing it from doing useful things like finding and executing all your test cases automatically. You have to add an "#if os(Linux)" section to each test case class, and then manually add redundant boilerplate for each test method that your write. The more tests you write and refactor, the more annoying this is.

4.) Nothing works at first. It's not straightforward to just unpack a dev release and get basic things working: importing libraries into the REPL, debug on Linux using lldb. Those things do work but you will have to visit the Swift JIRA tracker and to learn the magic collection of permission changes, command-line flags, and environment variables that make it all possible.

5.) If Swift had a good answer for interprocess communication it would be awesome as a kind of scripting language. However, it does not. It has this terrible API based on the old Mac NSTask class, and you will probably end up abandoning that and trying to write an interface to popen(), write 100 lines of error-handling code just to launch some UNIX tool and get its result, rub your eyes, sigh, close the editor, delete the file, and write it in ruby or python.

However, there is also some really awesome stuff:

a.) Swift itself is awesome to program in, and except where explicitly unimplemented, it is stable and fast on Linux.

b.) Swift Package Manager is now robust and a pleasure to work with.

c.) The build system works great on Linux, aside from the slowness of a young compiler (which is not specific to Linux).

d.) The new Codable API for serialization is significant because none of the popular JSON libraries for Swift worked well on Linux (IBM had a fork of one that was purported to work). Now, it's built-in, awesome, and works great on Linux.

e.) If a web-delivered app UI is a requirement, there is some really awesome competition going between Vapor (I think still the most popular Swift web framework) and IBM's Kitura web app framework. Considering how niche Swift still is for web development, there is an amazing level of work being done in this area.

That's on off-the-top-of-my-head summary of where Swift on Linux is. I don't think it is at all advanced yet on any other non-Apple platforms.

dottrap9 anni fa

Swift on Android:

https://academy.realm.io/posts/swift-on-android

Young but potential.

frik9 anni fa

Would be interested as well.

How good is the ecosystem for server side applications on other OS?

I like the syntax of Swift, it would be awesome to be able to use it for iOS apps as well as server apps.

samcat1169 anni fa

There are a bunch of server side frameworks and web servers for Linux

tambourine_man9 anni fa

Since things at Tesla haven't worked out, I hope Lattner eventually returns to Apple.

Not that the Swift team is in a bad shape without him, it's just that it's nice to have an amazingly smart guy behind an open source language that many of us use (and that number that will probably only grow).

lyinsteve9 anni fa

There are tons of amazingly-smart people working on Swift at Apple right now

jorgemf9 anni fa

Swift developers, how is the evolution of the programming language now? does it still have backwards compatibility issues or things are more stable now (and will be with this new proposals)?

saagarjha9 anni fa

The Swift 3->4 migration was not bad, actually–just a couple of small changes to source here and there. With ABI stability I think we'll see the adoption of Swift for libraries and frameworks increase significantly.

j-me9 anni fa

I started out building prototypes with Swift 2. The migration to 3 caused a few headaches for me, and some migraines for others it seems. 3 -> 4 was relatively simple. Though, my experience was far less involved than those depending on Carthage/CocoaPods packages.

[deleted]9 anni fa

bsaul9 anni fa

About concurrency : does anyone know of a language that would let you tag portions of a codebase in some way, and declare something like "all those methods should execute in the same thread". Those declarations would then be checked by the compiler.

That would be a first step toward agent like concurrency, but it would be general enough to apply to other types of concurrency models.

tonyg9 anni fa

Reminds me of "multitier" programming, which is more focussed on a client/server split, but otherwise a similar idea. See for example http://hop.inria.fr/home/index.html and the extensive research literature, perhaps starting from http://queue.acm.org/detail.cfm?id=2330089 or https://www-sop.inria.fr/members/Manuel.Serrano/index-6.html

comex9 anni fa

You can do it in C++, actually, using Clang’s thread safety attributes:

https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

You can create a dummy ‘lock’ type that just represents being on a certain thread, with corresponding global variables for different named threads.

whowouldathunk9 anni fa

Ugh, makes me think of COM

https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

int_19h9 anni fa

This is different. COM apartments were a runtime mechanism to magically make the code to run on a single thread (or on multiple but specific threads for MTA), by introducing object proxies that "transparently" marshaled calls.

BinaryIdiot9 anni fa

That's an interesting concept. Would you also suggest having a way of saying "this method should execute in another thread" or "all of those methods should execute in another thread"?

bsaul9 anni fa

I'm still in the process of figuring how that would work. But mostly it would look something like annotation @threading("BACKGROUND_WORK_QUEUE_A") func someWork(data) {}

@threading("BACKGROUND_WORK_QUEUE_A") func someSubWork(data) {}

@threading("MAIN_QUEUE") func requestHandler() {}

and you wouldn't be able to directly call someWork() from requestHandler() directly, but calling someSubWork() from someWork() would be fine.

The idea is that i've observed that my code could often be split into parts running in their own threads, and the complex thread splitting code would be at the junction.

Adding annotation like that would help me make sure that a function designed to run inside some part wouldn't accidentaly be called directly from another part.

cmoscoso9 anni fa

Something like Agents in Clojure?

Jack4E4B9 anni fa

Concurrency finally, it has taken forever. Is there any built-in support now? Server side Swift is lacking this big time.

slavapestov9 anni fa

It doesn't cover everything, but libdispatch is available on both Darwin and Linux, with a "Swift-ified" API.

Jack4E4B9 anni fa

I am not a Swift expert, can you explain your point. How would that situation compare to say programming in Go where there is built-in support for channels, and concurrency?

real-hacker9 anni fa

The only complaint about swift programming is: they keep changing the programming interfaces, so if I import a third-party code file written with earlier versions of Swift, I have to go through the errors of 'obsolete APIs', updating the function signatures. The changes are automated by Xcode, but it is still a hassle.

I am totally OK with introducing new features of Swift language. But changing the API function signatures (even multiple times) seems totally unnecessary, and reflects the API designers' obsession of naming conventions.

martijn_himself9 anni fa

Tangential question- I'm in the UK and I am keen to become a iOS developer (I'm currently a senior .NET developer in a large firm). Are there enough opportunities remaining in iOS development as a contractor / creator of ('enterprise') apps to make a living? I would be very grateful if anyone could share any advice / personal experience.

geodel9 anni fa

> the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by requiring that all proposals have an implementation before they are officially reviewed by the Core Team.

Good. They are effectively saying 'Talk is cheap, show me the code'

the_common_man9 anni fa

Great to see chris still contributing - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...

seekler9 anni fa

Anyone else doing what swift will do: Inlines the standard library, but distributes it separately. Does not makes sense to me at all.

apple4ever9 anni fa

I'm sticking with Objective-C. A much better language than Swift, even at version 5.

legulere9 anni fa

Fixing the ABI might be interesting for interoperation with other programming languages

haterswillhate9 anni fa

RocketSyntax9 anni fa

I'd rather build hybrid apps. Fix your IDE.