Swift 5: start your engines
lists.swift.org
lists.swift.org
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.
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?
Definitely not a good way to introduce new programming languages to newbies.
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:
Another pay site that is be useful if you want to come up to speed quickly is http://nsscreencast.com
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.
Developer documentations should start following API like structures. For example, in API land we have:
/api/v1/users
/api/v2/users
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.
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?
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?
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.
Stanford courses are the best you can find online for free. https://youtu.be/HitSIzPM_6E
Could you elaborate on whats messy with these SDKs?
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.
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.
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...
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.
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.
Yes. I've found AutoLayout to be acceptable in this case, provided you're not doing something awful.
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)
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.
Yes, even on a 4S.
https://www.youtube.com/watch?v=g6yz5oX5iWc
FWIW, if you like and good at it, more power to you.
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.
Why on earth would you have a single blocking thread on a UI app?
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.
It's one reason they had to rely on compile-time codegen to implement the swift4 equivalent.
- 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.
Not always true, my favorite example being Idris. (but then again, it's all relative to what you know already)
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
Election is the new Flash. All hail new Flash! /s
Seriously, how do supposedly smart people come up with things like Electron?
Article on animation improvements from Feb: https://facebook.github.io/react-native/blog/2017/02/14/usin...
I prefer TS over JS, and I wonder how well it is supported, or if that is even an issue.
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.
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.
“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.
React Native is more fun to work with than PhoneGap though (I've shipped apps with the latter and really hated it).
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.
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.
str.substring(with: 7..<11)
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.
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.
Your biggest problem won't be the language, but the 30,000 other apps uploaded to the App Store every single day.
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.
I recommend to look at this site, he’s a really “clean” teacher
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.
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
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?
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.
I remember all the time the iOs developer spent with every iOs release. He didn't look any happy
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.
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).
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.
> 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.
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.
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.
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).
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.
Do you have a source for this? This would imply ABI stability, which isn't being promised until Swift 5.
They're both compatible
You have my assurances that it works ;-)
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.
Probably no one develops with them.
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.
import Vapor
let drop = try Droplet()
drop.get("hello") { req in
return "Hello, world."
}
try drop.run()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.
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.
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.
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.
“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.
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.
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.
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.
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.
I've never actually seen it in production though, nor have I heard of any of my friends companies either
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.
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.
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.
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.
https://academy.realm.io/posts/swift-on-android
Young but potential.
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).
That would be a first step toward agent like concurrency, but it would be general enough to apply to other types of concurrency models.
@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.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
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.
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.
Good. They are effectively saying 'Talk is cheap, show me the code'